1 2014-07-30 00:51:16 <cfields> BlueMatt: ping
2 2014-07-30 00:51:33 <BlueMatt> pong
3 2014-07-30 00:52:15 <cfields> could i get some help trying to build the comparison tool?
4 2014-07-30 00:52:53 <BlueMatt> heh, probably not but I'll try ;)
5 2014-07-30 00:53:11 <cfields> translation: where do i start?
6 2014-07-30 00:53:12 <cfields> :)
7 2014-07-30 00:55:09 <BlueMatt> I think I was too lazy and never made a maven file for it, but if you just throw bitcoinj in some java ide and tell it to make a jar with BitcoindComparisonTool as the main class, you should be good
8 2014-07-30 00:56:08 <cfields> well, as someone who knows nothing of java, where should i start with building it from cli?
9 2014-07-30 00:57:27 <BlueMatt> hmm....
10 2014-07-30 00:57:54 <BlueMatt> if you want a runnable jar...have fun, its been a long while since Ive done that (should be able to build all, then zip it up and add a MANIFEST_MF thinggy)
11 2014-07-30 00:59:30 <cfields> mm
12 2014-07-30 00:59:49 <cfields> would you be interested in helping out? This will be one of the last pieces needed to replace the pull-tester
13 2014-07-30 01:07:09 <sipa> cfields: if you just want to test, there's a .jar available
14 2014-07-30 01:07:26 <sipa> i've never gotten around to building it myself either, though
15 2014-07-30 01:07:29 <cfields> sipa: i want to build it as a dependency
16 2014-07-30 01:07:46 <sipa> oh.. of course!
17 2014-07-30 01:08:02 <cfields> i've got it as a jar for testing, but makes perfect sense to have it modifiable
18 2014-07-30 01:08:22 <cfields> sipa: heh, wtf are you up?
19 2014-07-30 01:08:32 <sipa> can't sleep
20 2014-07-30 01:09:09 <cfields> ah
21 2014-07-30 01:10:12 <cfields> sipa: i know you've described some alternatives to BitcoindComparisonTool. Do you think it's worth hacking the current one to work for now? Or working on something else instead?
22 2014-07-30 01:10:33 <sipa> cfields: define 'to work' ?
23 2014-07-30 01:11:34 <cfields> sipa: either shoving the jar into git (which would likely result in an infinite flamewar), or get it to build as a dependency. Either way, running as it currently does with current behavior
24 2014-07-30 01:11:54 <sipa> the jar can be a 'source' in your package system
25 2014-07-30 01:12:03 <sipa> with a known URL and hash
26 2014-07-30 01:12:07 <cfields> hmmm
27 2014-07-30 01:12:40 <cfields> now that seems perfectly reasonable :)
28 2014-07-30 01:13:07 <sipa> i don't think it should be hard to build either, once you figure out how to build bitcoinj from cli
29 2014-07-30 01:13:36 <cfields> ok
30 2014-07-30 01:14:21 <cfields> but, grabbing it from a url and installing sounds perfect for now, to avoid having to build it as a blocker for the pull-tester stuff
31 2014-07-30 01:14:27 <cfields> then building as a next step
32 2014-07-30 01:14:40 <sipa> i know i could build executable .jar files from the cli when i was a student (including loadable .so files and everything), but i haven't done any java since (which was in 2005-6 or so)
33 2014-07-30 01:15:49 <cfields> mm, that's more than me. I've built, but only when it was a simple automated command away
34 2014-07-30 01:16:58 <sipa> but yeah, i'd like a network-rule-agnostic comparison tool... with some scripting language to construct the blocks, and either tell it to compare the behaviour of two separate nodes, or tell it directly what the observed behaviour should be
35 2014-07-30 01:17:29 <cfields> right
36 2014-07-30 01:18:54 <cfields> well, your suggestion gets me over the hump for feature parity. so i'll do that for now, and we can move forward from there
37 2014-07-30 01:18:58 <cfields> tyvm
38 2014-07-30 01:19:15 <sipa> yw
39 2014-07-30 01:20:45 <cfields> besides, the new tester won't be spamming on failures anymore. So even if the comparisontool is showing false negatives, our mailboxes will get a break
40 2014-07-30 01:21:36 <sipa> is there a way to run travis ourselves, btw?
41 2014-07-30 01:22:13 <cfields> mm, kinda
42 2014-07-30 01:22:52 <cfields> the caching requires a special account, so free accounts will rebuild fully each time
43 2014-07-30 01:22:54 <sipa> because we do have hardware to run something like that on
44 2014-07-30 01:23:51 <cfields> imo that's a bad idea. I've talked about it with wumpus and gavinandresen some.
45 2014-07-30 01:23:58 <cfields> i'd rather let the pro's handle it
46 2014-07-30 01:24:03 <cfields> however
47 2014-07-30 01:24:10 <sipa> well, one does not exclude the other
48 2014-07-30 01:24:14 <cfields> of course it's all generic enough that anyone can setup their own
49 2014-07-30 01:24:47 <cfields> sure
50 2014-07-30 01:25:17 <cfields> it'd be trivial to teach jenkins to use the same process.
51 2014-07-30 01:29:23 <cfields> sipa / BlueMatt: is the jar at https://github.com/TheBlueMatt/test-scripts at all current? Or should I grab it off of the current tester?
52 2014-07-30 01:30:31 <cfields> bbl
53 2014-07-30 01:31:21 <BlueMatt> cfields: ummmm....look at the timestamp
54 2014-07-30 01:31:42 <sipa> the one on pulltester is from august 2012...
55 2014-07-30 01:33:05 <sipa> oh no, october 2013
56 2014-07-30 01:34:33 <sipa> cfields: the one on pulltester is binary identical with the one in that repo
57 2014-07-30 01:35:46 <sipa> cfields: it's not a single file though
58 2014-07-30 01:39:26 <BlueMatt> sipa: thanks for checking
59 2014-07-30 01:50:55 <cfields> sipa: mm, right, i'll fetch the necessary ones. Thanks for verifying
60 2014-07-30 03:18:17 <earlz> Is it possible that bitcoind will ever use 2 change transactions?
61 2014-07-30 03:18:31 <earlz> for 1 transaction to a single address
62 2014-07-30 03:18:42 <dsnrk> why do you think that is needed?
63 2014-07-30 03:19:14 <earlz> I'm not saying it's needed. just making sure my thinking is correct
64 2014-07-30 03:19:18 <dsnrk> that would just needlessly pollute the UTXO.
65 2014-07-30 03:19:35 <earlz> that's what I was thinking. so no, correct?
66 2014-07-30 03:19:35 <pigeons> you can just manually create another output
67 2014-07-30 03:19:38 <dsnrk> it's possible, sure, but it's not needed. if you have to break up big outputs that's a manual task.
68 2014-07-30 03:19:42 <sipa> you mean 2 change outputs? no it doesn't do that currently, but it may be useful for privacy
69 2014-07-30 03:20:02 <Luke-Jr> dsnrk: I wouldn't rule it out for the future.
70 2014-07-30 03:20:09 <earlz> And also there is no good way (without dropping down to raw) to set the change address of a transaction, right?
71 2014-07-30 03:20:35 <Luke-Jr> earlz: it's not a useful thing to do, so no.
72 2014-07-30 03:20:37 <pigeons> earlz turn on advanced features/coincontrol and you can do it in bitcoin-qt
73 2014-07-30 03:20:42 <earlz> Best bet for accounting is sending the transaction, then checking it after the fact to determine what the change address is (ie, by filtering out the address(s) you sent to)
74 2014-07-30 03:20:49 <earlz> eh, using pure RPC though
75 2014-07-30 03:20:50 <Luke-Jr> pigeons: doesn't make it a *good* way :P
76 2014-07-30 03:20:54 <pigeons> :)
77 2014-07-30 03:21:04 <dsnrk> Luke-Jr: lets get idiots like bc.i using change addresses before we try and do two.
78 2014-07-30 03:21:07 <Luke-Jr> earlz: there should never be any need to touch change addresses
79 2014-07-30 03:21:40 <earlz> In counting unspent outputs I need to account for change to make sure it's not counted
80 2014-07-30 03:21:51 <pigeons> ?
81 2014-07-30 03:21:54 <dsnrk> what
82 2014-07-30 03:21:55 <Luke-Jr> you shouldn't be counting unspent outputs unless you're writing a wallet
83 2014-07-30 03:22:24 <Luke-Jr> ACTION looks around for the cluebat
84 2014-07-30 03:22:58 <earlz> Well despite the warning last night about never reusing addresses, reused addresses is something I must account for, so I have to manually account for them by using listunspent
85 2014-07-30 03:23:05 <dsnrk> Luke-Jr: it's OK man, don't worry about private keys. blockchain.info has an API that returns a private key for you.
86 2014-07-30 03:23:11 <earlz> lmfao
87 2014-07-30 03:23:39 <Luke-Jr> earlz: listreceivedbyaddress does that
88 2014-07-30 03:23:57 <pigeons> but why do you care if they are change
89 2014-07-30 03:24:18 <pigeons> what's the diffrence between your change and any other unspents
90 2014-07-30 03:24:27 <earlz> yea, but if you spend the funds out of the reused address, listreceived will not be accurate
91 2014-07-30 03:24:45 <Luke-Jr> earlz: funds aren't held in addresses; listreceived is always accurate
92 2014-07-30 03:24:57 <earlz> yea, I'm kinda seeing your point. My internal account would basically just never need to account for change because it's not a relevant address
93 2014-07-30 03:25:12 <pigeons> sure its relevant.
94 2014-07-30 03:25:32 <earlz> I send 1 BTC to X, then the unspent txo to X is spent, listreceived will still say X is 1
95 2014-07-30 03:25:42 <dsnrk> that's correct.
96 2014-07-30 03:26:01 <dsnrk> the address still received 1 BTC, no matter what happened with it after that.
97 2014-07-30 03:26:11 <Luke-Jr> earlz: the unspent txo is not "to X"
98 2014-07-30 03:26:21 <Luke-Jr> earlz: the unspent txo is just in the wallet. unrelated to X.
99 2014-07-30 03:26:37 <Luke-Jr> the address received 1 BTC, but the unspent txo is not related to that afterward
100 2014-07-30 03:26:55 <earlz> I feel like we're splitting hairs here. Somehow, I need to know with the private key to X, how many coins I can get out of the network
101 2014-07-30 03:27:24 <dsnrk> it's a very important distinction really.
102 2014-07-30 03:28:01 <Luke-Jr> earlz: private keys and addresses are distinct. only wallet software should ever care about keys.
103 2014-07-30 03:28:30 <earlz> sure at a low enough level...
104 2014-07-30 03:28:44 <Luke-Jr> earlz: if you insist on doing stupid things the wrong way, please leave, rather than making the channel useless by scaring off other bitcoin devs who know what they're talking about.
105 2014-07-30 03:28:57 <Luke-Jr> (and don't complain when you lose all your bitcoins)
106 2014-07-30 03:29:25 <dsnrk> don't complain when you lose *other people's* bitcoins either, which is probably more the issue.
107 2014-07-30 03:29:59 <Luke-Jr> dsnrk: true
108 2014-07-30 03:30:49 <LooseLarry> is there a maximum to how many public keys the bitcoin wallet can handle
109 2014-07-30 03:30:51 <earlz> you can't just blackhole people that accidentally sent to the (once good) address accidentally. Address reuse isn't "good", but until some more advanced technologies like HD seeds are more prevalent, it's what many services must deal with
110 2014-07-30 03:30:52 <LooseLarry> before it breaks down ?
111 2014-07-30 03:31:19 <LooseLarry> I mean, if I have 500,000 public keys/addresses on my wallet
112 2014-07-30 03:31:23 <LooseLarry> is that a problem ?
113 2014-07-30 03:31:38 <dsnrk> yes. it's not designed for that.
114 2014-07-30 03:31:48 <Luke-Jr> earlz: whether you have to deal with it or not, you're still doing it wrong
115 2014-07-30 03:32:11 <LooseLarry> dsnrk, these exchanges, and places that give out public keys to new users
116 2014-07-30 03:32:16 <LooseLarry> how do they handle that ?
117 2014-07-30 03:32:18 <LooseLarry> multiple wallets?
118 2014-07-30 03:32:25 <dsnrk> first of all they give out addresses, not public keys.
119 2014-07-30 03:32:27 <LooseLarry> what would you say is a safe limit
120 2014-07-30 03:32:31 <LooseLarry> hmm
121 2014-07-30 03:32:33 <Luke-Jr> LooseLarry: discard old keys after you've used them
122 2014-07-30 03:32:36 <LooseLarry> addresses? are not public keys ?
123 2014-07-30 03:32:45 <Luke-Jr> LooseLarry: no, they're opaque identifiers
124 2014-07-30 03:32:46 <LooseLarry> I thought when I call getNewAddress
125 2014-07-30 03:32:49 <dsnrk> usually they have their own wallet systems, they don't use the bitcoin core wallets.
126 2014-07-30 03:32:52 <justusranvier> LooseLarry: There are some bitcoin walet implementations that don't have a problem handling half a million addresses
127 2014-07-30 03:32:55 <LooseLarry> and it sends back via RPC a new address
128 2014-07-30 03:32:57 <LooseLarry> that's a public key
129 2014-07-30 03:33:01 <LooseLarry> it's not?
130 2014-07-30 03:33:01 <Luke-Jr> LooseLarry: no
131 2014-07-30 03:33:02 <dsnrk> LooseLarry: yes, but an address is *not* a public key, they are a hash of a public key.
132 2014-07-30 03:33:09 <dsnrk> big difference.
133 2014-07-30 03:33:14 <justusranvier> btcwallet being one of them
134 2014-07-30 03:33:18 <Luke-Jr> LooseLarry: version 1 addresses are *implemented using* ECDSA keypairs, but they are not *equivalent* to them
135 2014-07-30 03:33:20 <LooseLarry> dsnrk - I see
136 2014-07-30 03:33:36 <LooseLarry> dsnrk, so if I call getnewaddress via RPC against the wallet 50,000 times?
137 2014-07-30 03:33:43 <LooseLarry> that's not 50,000 new public keys, that's 50,000 addresses
138 2014-07-30 03:33:50 <dsnrk> LooseLarry: you'll turn it to treacle.
139 2014-07-30 03:33:50 <LooseLarry> ok- then my question needs to be updated heh-
140 2014-07-30 03:34:03 <LooseLarry> is it okay to have 50,000 addresses (recieve) ?
141 2014-07-30 03:34:07 <LooseLarry> for a wallet?
142 2014-07-30 03:34:13 <Luke-Jr> LooseLarry: if you're doing 50,000 transactions at any given time, then the blockchain won't work for you
143 2014-07-30 03:34:16 <dsnrk> no, the client will crawl and probably won't work at all.
144 2014-07-30 03:34:18 <LooseLarry> I see the wallet .DAT grow ABOUT 4k per 4 addresses.
145 2014-07-30 03:34:31 <LooseLarry> Luke-Jr - it's just to handle giving a new user a public address
146 2014-07-30 03:34:36 <LooseLarry> so they can deposit etc
147 2014-07-30 03:34:36 <Luke-Jr> LooseLarry: Bitcoin Core cannot handle high volume
148 2014-07-30 03:34:59 <Luke-Jr> LooseLarry: also, you really don't want to make addresses public
149 2014-07-30 03:35:01 <dsnrk> if you are working with 50k addresses, bitcoind is not the wallet you are looking for.
150 2014-07-30 03:35:02 <LooseLarry> well there are sites out there that have thousands of users - each user gets a public address
151 2014-07-30 03:35:14 <dsnrk> sure, I can say for a fact they don't use bitcoind.
152 2014-07-30 03:35:20 <LooseLarry> I figure they have genearted thousands of addresses - question is, it it from many wallets
153 2014-07-30 03:35:24 <Luke-Jr> LooseLarry: that's doing it wrong. each *deposit* should get an address given *only* to the depositer
154 2014-07-30 03:35:26 <LooseLarry> dsnrk - really.
155 2014-07-30 03:35:27 <LooseLarry> interesting
156 2014-07-30 03:35:39 <LooseLarry> Luke- yeah, only to the depositer
157 2014-07-30 03:35:40 <LooseLarry> right
158 2014-07-30 03:35:45 <LooseLarry> same page.
159 2014-07-30 03:35:50 <Luke-Jr> LooseLarry: point is you make a new address for every deposit, not every user
160 2014-07-30 03:36:03 <Luke-Jr> they make 2 deposits, they use 2 addresses
161 2014-07-30 03:36:05 <LooseLarry> Luke, I see your point, to do it properly
162 2014-07-30 03:36:13 <LooseLarry> each transaction ideally having it's own address
163 2014-07-30 03:36:26 <Luke-Jr> LooseLarry: you can also discard used keys this way
164 2014-07-30 03:36:29 <LooseLarry> so then, how do these sites that handle thousands of addresses do it?
165 2014-07-30 03:36:37 <LooseLarry> they are not using a wallet daemon to process?
166 2014-07-30 03:36:47 <dsnrk> they have their own external wallet which connects to the core daemon.
167 2014-07-30 03:37:55 <dsnrk> LooseLarry: that's not really an assumption you can make today. wallets support "address books" with static addresses. not keeping past keys will cause major butthurt.
168 2014-07-30 03:38:01 <dsnrk> er, Luke-Jr ^^
169 2014-07-30 03:38:24 <Luke-Jr> dsnrk: really? what wallets still have address book nonsense?
170 2014-07-30 03:38:52 <LooseLarry> so, if I have 5,000 users, and want to give each a new address each time they want to make a payment or deposit etc...
171 2014-07-30 03:39:04 <LooseLarry> I should not call getnewaddress on the wallet d
172 2014-07-30 03:39:33 <earlz> What is the reference wallet good for if "the correct way" causes it to break heh
173 2014-07-30 03:39:46 <Luke-Jr> earlz: stability?
174 2014-07-30 03:39:50 <dsnrk> earlz: it's a wallet for users, not for services.
175 2014-07-30 03:39:57 <Luke-Jr> indeed
176 2014-07-30 03:40:00 <earlz> eh, good point I guess
177 2014-07-30 03:40:06 <LooseLarry> I see
178 2014-07-30 03:40:10 <Luke-Jr> services are expected to budget for the wallet sw they require
179 2014-07-30 03:40:11 <LooseLarry> what is used for services?
180 2014-07-30 03:40:17 <Luke-Jr> or at least outsource to someone who does
181 2014-07-30 03:40:20 <Luke-Jr> hence BitPay
182 2014-07-30 03:40:37 <dsnrk> earlz: bitcoin core is meant to be the rock solid, never changing foundation for users. not high speed, play fast and break everything.
183 2014-07-30 03:40:46 <LooseLarry> well - back to my original question though, will a wallet support 1 million addresses ?
184 2014-07-30 03:40:49 <earlz> I remember a while back everyone saying it's crazy to run critical services on non-reference wallets, due to almost every one of them forking at some point. I assume that's less of a problem with SPV and all though
185 2014-07-30 03:40:54 <LooseLarry> that would be 4 GB in size
186 2014-07-30 03:41:00 <dsnrk> LooseLarry: I've said it like 4 times. NO.
187 2014-07-30 03:41:06 <LooseLarry> dsnrk- ok ok - OK lol
188 2014-07-30 03:41:39 <dsnrk> LooseLarry: Hive wallet does have an address book with static addresses, for one.
189 2014-07-30 03:41:56 <Luke-Jr> earlz: non-reference *nodes*, not wallets
190 2014-07-30 03:41:58 <LooseLarry> I'm just looking for something to support handling large amounts of addresses
191 2014-07-30 03:42:17 <Luke-Jr> dsnrk: complain to them. they seem receptive to constructive criticism
192 2014-07-30 03:42:22 <dsnrk> LooseLarry: make it, outsource it, find an open source solution.
193 2014-07-30 03:42:27 <LooseLarry> and i've learned in the last 15 min, the wallet is not the proper way :)
194 2014-07-30 03:42:39 <LooseLarry> well I just made a solution
195 2014-07-30 03:42:41 <LooseLarry> but it uses the wallet
196 2014-07-30 03:42:46 <LooseLarry> I did create 100,000 addresses
197 2014-07-30 03:42:49 <LooseLarry> and I stored them in a database
198 2014-07-30 03:42:57 <LooseLarry> the .DAT file grew thoguh - considerablty.
199 2014-07-30 03:43:04 <Luke-Jr> LooseLarry: you can use -blocknotify and scan blocks yourself
200 2014-07-30 03:43:05 <dsnrk> why do you want to make them ahead of time?
201 2014-07-30 03:43:14 <LooseLarry> dsnrk, time I suppose
202 2014-07-30 03:43:14 <Luke-Jr> also what dsnrk said :P
203 2014-07-30 03:43:24 <Luke-Jr> LooseLarry: making them on demand is not slow..
204 2014-07-30 03:43:29 <Luke-Jr> at least for HD wallets
205 2014-07-30 03:43:35 <dsnrk> LooseLarry: I'm too busy trying to get bc.i to fix their broken shit. they STILL haven't fixed the latest bug :C
206 2014-07-30 03:43:38 <LooseLarry> what is an HD?
207 2014-07-30 03:43:49 <dsnrk> see BIP32.
208 2014-07-30 03:43:50 <LooseLarry> as to wallets?
209 2014-07-30 03:43:56 <LooseLarry> ok I'll google this
210 2014-07-30 03:43:58 <Luke-Jr> LooseLarry: Hierarchial Deterministic wallets create all the addresses from a single private (non-ECDSA) key
211 2014-07-30 03:44:15 <LooseLarry> Luke- I see. That is how I thought it worked
212 2014-07-30 03:44:25 <LooseLarry> I thought all addresses are derived from just the private key
213 2014-07-30 03:44:35 <Luke-Jr> non-HD wallets require a private key for every address
214 2014-07-30 03:44:38 <LooseLarry> so much to learn
215 2014-07-30 03:44:47 <dsnrk> Luke-Jr: I mean, seriously it's been over a week and a half on this one ,,(balance 3M1S3tZVkEJw7zVBtn1Mq8McVyfnNMAuoX)
216 2014-07-30 03:44:48 <gribble> -0.00887168
217 2014-07-30 03:44:50 <LooseLarry> oh. I didn't even know non HD existed
218 2014-07-30 03:45:18 <Luke-Jr> dsnrk: why waste your time? the more obviously broken bc.i is, the fewer people will misplace their trust in it..
219 2014-07-30 03:45:25 <LooseLarry> I wonder if unicode was used, if the keys could be shorter in length
220 2014-07-30 03:45:29 <Luke-Jr> LooseLarry: Bitcoin Core only supports non-HD wallets today
221 2014-07-30 03:45:37 <earlz> still has to be decoded at some point
222 2014-07-30 03:45:54 <earlz> is there any plans to add HD support, or is that left to other walelts?
223 2014-07-30 03:46:00 <Luke-Jr> earlz: it's planned
224 2014-07-30 03:46:04 <dsnrk> Luke-Jr: the one before that bug was exploitable on mainnet and could have caused people to lose tens of thousands of BTC.
225 2014-07-30 03:46:11 <Luke-Jr> but Core is slow moving, so it remains stable
226 2014-07-30 03:46:32 <earlz> it still has commits everyday lol. not that slow
227 2014-07-30 03:46:47 <Luke-Jr> dsnrk: only if they trust bc.i
228 2014-07-30 03:46:58 <Luke-Jr> earlz: commits that have been ongoing works for months, yes
229 2014-07-30 03:47:07 <dsnrk> Luke-Jr: people do. there's large websites which rely on their API.
230 2014-07-30 03:47:21 <Luke-Jr> dsnrk: the more people lose their money because of bc.i, the fewer will use it :P
231 2014-07-30 03:48:22 <dsnrk> Luke-Jr: I get that, but if I can avoid people losing their money I'll report exploitable bugs. the non exploitable bugs well, I post them and laugh at bc.i for them.
232 2014-07-30 03:48:40 <Luke-Jr> heh âº
233 2014-07-30 03:49:10 <dsnrk> http://blockchain.info/block/0
234 2014-07-30 03:50:18 <dsnrk> http://blockchain.info/address/RysdH6jZwzjM4YHaVNJB2j7S9onvSHoykw5d57aAzDcqhhFmWy37Tcfva4r24QCTMzk78tyQEVjhGL9wpzw9Yua6qD7p1n9xM
235 2014-07-30 03:50:30 <dsnrk> see? we are laughing and nobody gets hurt.
236 2014-07-30 03:50:50 <earlz> lol wtf
237 2014-07-30 03:51:12 <Luke-Jr> dsnrk: it's all chinese! :p
238 2014-07-30 03:51:38 <dsnrk> Luke-Jr: that's your fault, go to http://blockchain.info/en/address/112edB6q to set your cookie back to something sensible.
239 2014-07-30 03:51:56 <Luke-Jr> dsnrk: it's the default, I think
240 2014-07-30 03:51:59 <Luke-Jr> going to /en never fixes it
241 2014-07-30 03:52:05 <Luke-Jr> (except for that one page)
242 2014-07-30 03:52:21 <dsnrk> you must have a bad entry in their GEOIP database
243 2014-07-30 03:52:25 <Luke-Jr> maybe
244 2014-07-30 03:52:31 <dsnrk> so do I, totally the wrong country.
245 2014-07-30 08:52:36 <cryptorecruiter> anyone lookign for FT btc opportunities
246 2014-07-30 08:52:49 <cryptorecruiter> i have a number of requirements
247 2014-07-30 08:56:48 <jcorgan> not really a discussion for this channel
248 2014-07-30 10:33:09 <cryptorecruiter> anyone lookign for any btc jobs
249 2014-07-30 10:33:56 <cryptorecruiter> i have roles in Europe and the US ( some remote) in engingeerin ( Ruby,Python,C++) Mobile (Android/ios)
250 2014-07-30 10:39:38 <elichai2> there is any bot here? (that i can check when was the last one someone was online)
251 2014-07-30 10:45:35 <gribble> elichai2 was last seen in #bitcoin-dev 5 minutes and 57 seconds ago: <elichai2> there is any bot here? (that i can check when was the last one someone was online)
252 2014-07-30 10:45:35 <t7> !seen elichai2
253 2014-07-30 10:47:19 <elichai2> !seen arioBarza
254 2014-07-30 10:47:20 <gribble> I have not seen arioBarza.
255 2014-07-30 10:47:28 <elichai2> t7: not working lol
256 2014-07-30 10:51:05 <Jouke_> wumpus: regarding issue 4604, is there something I can do to help to identify the problem?
257 2014-07-30 10:53:42 <wumpus> Jouke_: it would be useful to know whether it happens on the server or client side; what does the server do after recieiving the command, does it run it to completion, or stop at some point (and why?), or even crash
258 2014-07-30 10:53:56 <wumpus> or does it complete the command but not send the result
259 2014-07-30 10:54:12 <Jouke_> Server does not crash
260 2014-07-30 10:54:12 <wumpus> maybe some buffer becomes too big
261 2014-07-30 10:54:34 <wumpus> as said, it isn't a timeout issue because there are no timeouts on commands
262 2014-07-30 10:54:56 <Jouke_> I believe I tried to query it with curl with a large timeout and it wouldn't return a result either if I remember correctly.
263 2014-07-30 10:55:21 <Jouke_> Is there an other method to know if the server runs it to completion?
264 2014-07-30 10:58:27 <wumpus> running the server in gdb would be the most comphrehensive way to see what happens, another way would be to add lots of LogPrintf
265 2014-07-30 11:32:01 <nandubatchu> hello
266 2014-07-30 11:37:09 <Forex> does it happen that sometimes block takes say 3 hours to solve? due to the possibility of it?
267 2014-07-30 11:37:44 <Forex> is there any website that shows average and min max times it took to solve block? :)
268 2014-07-30 12:08:19 <jgarzik> Forex, the average is 10 minutes
269 2014-07-30 12:09:28 <Forex> yes I wonder how many time it went significantly longer than average
270 2014-07-30 12:09:32 <Forex> *times
271 2014-07-30 12:09:42 <Forex> perhaps there are some stats somewhere
272 2014-07-30 12:09:43 <belcher_> its a poisson process
273 2014-07-30 12:09:59 <belcher_> theres a gribble function that works it out
274 2014-07-30 12:10:52 <Forex> nice whats its called @gribble function
275 2014-07-30 12:11:07 <belcher_> something like ;;tbls
276 2014-07-30 12:13:40 <Forex> ;;tbls
277 2014-07-30 12:13:41 <gribble> Error: "tbls" is not a valid command.
278 2014-07-30 12:14:10 <Forex> ;tbls
279 2014-07-30 12:15:49 <wumpus> the actual statistics do not match a poisson process, at least not one with a fixed average of 10 minutes, due to increase in hash power over time
280 2014-07-30 12:17:03 <Forex> true
281 2014-07-30 12:17:04 <Forex> The most recent large difference was between block 270193 and 270194 with a difference of 7741 seconds (2 hours and 9 minutes).
282 2014-07-30 12:17:08 <Forex> from net
283 2014-07-30 12:19:33 <Forex> wumpus: when diff is adjusted its adjustement is communicated via p2p port and stored where?
284 2014-07-30 12:19:36 <Forex> wonders :)
285 2014-07-30 12:20:00 <Forex> MIT could make some crypto classes :)
286 2014-07-30 12:20:50 <lianj> diff adjustment is an algo that ever peer does for himself at the point of every retarget interval
287 2014-07-30 12:22:11 <jgarzik> Forex, note that block timestamp is not necessarily block creation time. miners may adjust that number.
288 2014-07-30 12:22:55 <jgarzik> Forex, the diff adjustment and other rules are not communicated. they are already baked into software. each individual node runs their own validation based on their notion of rules.
289 2014-07-30 12:23:17 <wumpus> and indeed, miners can mess (within certain bounds) with the timestamps too
290 2014-07-30 12:23:20 <jgarzik> Forex, if you fail to come up with the same answer as other nodes, that creates a fork.
291 2014-07-30 12:28:39 <Forex> wumpus: yes I am aware of time stamp maniplation its not huge
292 2014-07-30 12:28:50 <Forex> like under 10% even less
293 2014-07-30 12:30:25 <Forex> jgarzik: what I mean, when say hash increases by 80% and via sampling timestamps nodes see it, do they just adjust diff locallly based on shared params?
294 2014-07-30 12:32:06 <jgarzik> Forex, difficulty is adjusted based on the history of the last two weeks (144*14) worth of blocks
295 2014-07-30 12:32:46 <Forex> yes thats make sense, so the only reason for longer than 10 min blocks are probablity?
296 2014-07-30 12:32:57 <Forex> like getting 40 reds in roulette?
297 2014-07-30 12:32:57 <jgarzik> Forex, correct
298 2014-07-30 12:33:02 <Forex> cool
299 2014-07-30 12:35:10 <Forex> what if block will take say 1 week, will adding more hash increase chances of solving it faster?
300 2014-07-30 12:36:17 <Forex> or use o confirms lol risky but :)
301 2014-07-30 12:36:18 <Forex> 0
302 2014-07-30 12:37:38 <jgarzik> Forex, we constantly perturb the input data making that less likely
303 2014-07-30 12:37:48 <jgarzik> Forex, but statistically, we could get stuck for 1,000 years ;p
304 2014-07-30 12:38:43 <Forex> lol
305 2014-07-30 12:40:53 <Forex> well in this case miners have to delete latest getwork request result en masse
306 2014-07-30 12:41:15 <Forex> like a soft roll back
307 2014-07-30 12:42:16 <Forex> also why network identifier must produce large 4-byte int at any alignment?
308 2014-07-30 12:42:26 <Forex> I am reading code comments :)
309 2014-07-30 12:57:25 <zks> Hi guys
310 2014-07-30 12:58:32 <zks> I'd like to print bitcoin address in C++ bitcoin core source code - but failed to it. Can anyone help?
311 2014-07-30 12:59:04 <zks> Should I use HexStr?
312 2014-07-30 12:59:22 <t7> there should be a nice base58 thing
313 2014-07-30 12:59:51 <zks> Can you please pinpoint me?
314 2014-07-30 13:00:38 <zks> You mean EncodeBase58()?
315 2014-07-30 13:01:03 <jgarzik> zks, a bitcoin address in base58 is fundamentally a printable string
316 2014-07-30 13:01:25 <zks> Thanks. Trying now.
317 2014-07-30 13:02:06 <jgarzik> zks, in C++, ToString() returns the printable string
318 2014-07-30 13:05:05 <cryptorecruiter> anyone lookign for any btc gigs?
319 2014-07-30 13:08:56 <zks> jgarzik, Still fails. I did: CKey key; key.MakeNewKey(true); CPubKey pub = key.GetPubKey(); cout << EncodeBase58(pub.begin(), pub.end());
320 2014-07-30 13:09:17 <zks> jgarzik, it prints 29fpz9Wr27awCtTNBuCmW8BZL8e4gXNCeot4gCqoopiPp
321 2014-07-30 13:09:39 <zks> jgarzik, I run on regtest, but it seems wrong pub key anyway...
322 2014-07-30 13:10:54 <jgarzik> zks, look at CBitcoinAddress examples
323 2014-07-30 13:11:20 <zks> jgarzik, looking ...
324 2014-07-30 13:13:42 <jgarzik> ACTION wonders who is this?
325 2014-07-30 13:13:48 <jgarzik> 2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=162.219.2.72:8333, peer=11846
326 2014-07-30 13:15:05 <jgarzik> this bitcoinseeder continually reconnects
327 2014-07-30 13:15:34 <jgarzik> 2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=162.219.2.72:8333, peer=11843
328 2014-07-30 13:15:46 <jgarzik> 2014-07-30 13:13:26 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11847
329 2014-07-30 13:15:46 <jgarzik> 2014-07-30 13:13:33 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=290000, us=162.219.2.72:8333, peer=11848
330 2014-07-30 13:15:46 <jgarzik> 2014-07-30 13:14:21 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11849
331 2014-07-30 13:15:55 <jgarzik> another annoying seeder
332 2014-07-30 13:16:06 <jgarzik> no excuse to connnect every few seconds
333 2014-07-30 13:16:30 <zks> jgarzik, thanks! It worked! CBitcoinAddress(pubkey.GetID()).ToString()!!!
334 2014-07-30 13:17:35 <zks> jgarzik, is there any better way to print CPrivKey than just for(const_iter ... )?
335 2014-07-30 13:40:22 <kostaz> Is there createrawtransaction-RPC for P2PK?
336 2014-07-30 14:06:17 <jgarzik> kostaz, no
337 2014-07-30 14:06:51 <jgarzik> kostaz, wouldn't be difficult to do yourself, but as that's lower security than hash(pubkey), it probably wouldn't get added upstream
338 2014-07-30 14:50:42 <michagogo> o/
339 2014-07-30 15:52:36 <kostaz> jgarzik, I did "CBitcoinSecret(key).ToString()" - worked fine (just did some debug).
340 2014-07-30 16:24:27 <stonecoldpat> im sure this has been asked a thousand times - but is there a good way to run an IsStandard() test on a rawtransaction that is used for testnet?
341 2014-07-30 16:25:29 <gmaxwell> Sure. return true .... there is no IsStandard on testnet.
342 2014-07-30 16:28:14 <stonecoldpat> haha yeah I know it's turned off by default, but is there a way to the transaction through an IsStandard checker to see if it would be standard for mainnet?
343 2014-07-30 16:28:46 <stonecoldpat> as i only have testnetcoins, but would be nice to make sure the transaction is-standard for mainnet
344 2014-07-30 16:39:17 <jgarzik> it would be fun if pchMessageStart were a hash of the network's policy
345 2014-07-30 16:39:26 <jgarzik> ie. hard forks change the network id
346 2014-07-30 17:16:56 <michagogo> Hm, does regtest have IsStandard?
347 2014-07-30 17:17:16 <michagogo> (re: stonecoldpat's question)
348 2014-07-30 17:33:13 <sipa> michagogo: yes, afaik
349 2014-07-30 17:34:58 <jrick> regtest doesn't do the IsStandard check
350 2014-07-30 17:39:35 <gmaxwell> sipa: undocumented side effect of commit cfeb8235 (2014-03-22)
351 2014-07-30 17:40:31 <gmaxwell> hm. well not even that, but a mixture of that and the merge of regtest.
352 2014-07-30 17:46:15 <yk> warning
353 2014-07-30 17:46:16 <gribble> Error: "can" is not a valid command.
354 2014-07-30 17:46:16 <yk>
355 2014-07-30 17:46:16 <yk> do they record&analyse everything we do on the internet,,can they harm you using these informations??
356 2014-07-30 17:46:16 <yk> do usa&israel use the internet 2 collect informations,,can we call that spying??
357 2014-07-30 17:46:16 <yk> do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy??
358 2014-07-30 17:46:16 <yk> warning
359 2014-07-30 17:46:16 <yk> you may be watched
360 2014-07-30 17:46:17 <gribble> Error: "can" is not a valid command.
361 2014-07-30 18:20:06 <theymos> Does anyone know off-hand whether version 0.1 allowed a scriptSig ending with a pushdata opcode to turn the scriptPubKey into a (true) constant?
362 2014-07-30 18:31:46 <michagogo> theymos: Well, I think the technical answer to your question is yes -- OP_RETURN used to be "return true" IIRC
363 2014-07-30 18:32:26 <sipa> OP_RETURN used to be just 'return'; truth was determined by the resulting stack, afaik
364 2014-07-30 18:32:53 <michagogo> ah
365 2014-07-30 18:33:27 <michagogo> so TRUE RETURN <PUSHDATA> would be true, not even getting to the sPK
366 2014-07-30 18:33:52 <michagogo> theymos: why do you ask?
367 2014-07-30 18:37:44 <theymos> Someone on the Bitcoin Stack Exchange said that ending the scriptSig with a pushdata op was another OP_RETURN-like vulnerability, which seems plausible, and I haven't found anything that contradicts this in the code, but this seems like a much more obvious vulnerability to me, so I thought that it might be prevented somewhere in the 0.1 code that I haven't found.
368 2014-07-30 18:38:42 <michagogo> Oh, I see what you're saying
369 2014-07-30 18:39:00 <michagogo> Ending with the pushdata _opcode_ to make the scriptSig become a data push
370 2014-07-30 18:39:16 <michagogo> Missed that part in the initial question
371 2014-07-30 18:39:27 <michagogo> erm, make the sPK*
372 2014-07-30 18:39:29 <theymos> Yeah, so the whole scriptPubKey will become a constant, and any non-zero constant will be true, so the script will validate.
373 2014-07-30 18:40:06 <michagogo> No, I think that was possible -- IIRC it just literally concatenated the sS and the sPK and ran them
374 2014-07-30 18:40:21 <michagogo> Hence OP_CODESEPARATOR(sp)
375 2014-07-30 18:41:28 <gmaxwell> theymos: I'm pretty sure that wouldn't have been the case. It was 'concatenated' but not at the byte level.
376 2014-07-30 18:41:56 <theymos> michagogo: That's what it seems to do, but you never can tell with C++. The code is: txin.scriptSig + CScript(OP_CODESEPARATOR) + txout.scriptPubKey
377 2014-07-30 18:42:35 <michagogo> gmaxwell: ah, really? I thought I'd heard otherwise
378 2014-07-30 18:43:37 <sipa> i think it was concatenated at the byte level
379 2014-07-30 18:43:41 <sipa> judging by the code
380 2014-07-30 18:44:17 <gmaxwell> cute.
381 2014-07-30 18:45:08 <theymos> Yeah, I'm looking at it now and I think so too. CScript is derived from vector<unsigned char>.
382 2014-07-30 18:45:18 <sipa> indeed
383 2014-07-30 18:46:15 <theymos> Thanks for the help. Satoshi must've been in a pretty big hurry when he wrote the script code. :)
384 2014-07-30 18:48:29 <gmaxwell> The details are a killer, as always.
385 2014-07-30 18:50:14 <sipa> hmm, that means maybe the separate execution of the two scripts may have been a hard fork
386 2014-07-30 18:51:11 <sipa> perhaps in combination with if/then
387 2014-07-30 18:51:48 <amaclin> are you talking about script concatenation? it was my answer on SE. i found it somewhere else
388 2014-07-30 18:52:35 <theymos> amaclin: Your comment prompted me to look into it further because I wasn't sure that you are correct. But it looks like you were.
389 2014-07-30 18:53:40 <amaclin> in fact i haven't looked in old sources. i found bitcoin for myself only in the end of '13
390 2014-07-30 18:58:16 <sipa> i checked the 0.1.5 source
391 2014-07-30 20:30:45 <kuzetsa> g
392 2014-07-30 20:32:15 <Forex> when miner submits hash and its invalid it does remember it or not?
393 2014-07-30 20:32:34 <Forex> or it can sometimes re send same invalid solution
394 2014-07-30 20:48:05 <dsnrk> Forex: not really a -dev question, take it to #bitcoin and we can work out what you're asking.
395 2014-07-30 20:48:31 <Forex> oki :)
396 2014-07-30 20:51:39 <BlueMatt> I love waiting for prodnet blocks to test things :(
397 2014-07-30 20:53:33 <jgarzik> BlueMatt, turn on your CPU miner, make the network go faster!
398 2014-07-30 20:53:45 <BlueMatt> heh
399 2014-07-30 21:06:42 <jgarzik> receive version message: Dain 0.0.1: version 70002, blocks=313236, us=162.219.2.72:8333, peer=23
400 2014-07-30 21:06:46 <jgarzik> Dain? That's a new one.
401 2014-07-30 21:15:44 <BlueMatt> seriously? 45 minutes since last block?
402 2014-07-30 21:15:47 <BlueMatt> fuck probability
403 2014-07-30 21:16:24 <sipa> ;;tblb 45m
404 2014-07-30 21:16:25 <gribble> Error: '45m' is not a valid positive integer.
405 2014-07-30 21:16:36 <BlueMatt> ;;tslb 45m
406 2014-07-30 21:16:36 <gribble> (tslb takes no arguments) -- Shows time elapsed since latest generated block. This uses the block timestamp, so may be slightly off clock-time.
407 2014-07-30 21:16:44 <sipa> ;;tblb [calc 45*60]
408 2014-07-30 21:16:46 <gribble> The expected time between blocks taking 45 minutes and 0 seconds to generate is 21 hours, 4 minutes, and 44 seconds
409 2014-07-30 21:16:54 <sipa> happens more than once a day!
410 2014-07-30 21:16:59 <BlueMatt> indeed
411 2014-07-30 21:17:01 <BlueMatt> fuck probability
412 2014-07-30 21:17:31 <sipa> no thanks
413 2014-07-30 21:17:55 <sipa> there's a block
414 2014-07-30 21:17:57 <sipa> ;;tblb
415 2014-07-30 21:17:58 <gribble> (tblb <interval>) -- Calculate the expected time between blocks which take at least <interval> seconds to create. To provide the <interval> argument, a nested 'seconds' command may be helpful.
416 2014-07-30 21:18:02 <sipa> ;;tslb
417 2014-07-30 21:18:08 <gribble> Error: Problem retrieving latest block data.
418 2014-07-30 21:18:16 <dsnrk> go go blockchain.info!
419 2014-07-30 21:18:18 <sipa> ;;tslb
420 2014-07-30 21:18:24 <gribble> Error: Problem retrieving latest block data.
421 2014-07-30 21:18:30 <sipa> does that use bc.i? :o
422 2014-07-30 21:18:31 <dsnrk> it means a block just came in. their server freezes when that happens.
423 2014-07-30 21:18:36 <dsnrk> yes.
424 2014-07-30 21:18:47 <dsnrk> that's why ;;balance returns negatives.
425 2014-07-30 21:19:10 <sipa> lol
426 2014-07-30 21:20:38 <dsnrk> ;;balance 3M1S3tZVkEJw7zVBtn1Mq8McVyfnNMAuoX
427 2014-07-30 21:20:39 <gribble> -0.00887168
428 2014-07-30 21:21:33 <dsnrk> reported july 20, july 22 they told me the patch was written and going into place, july 30 they told me they'd never written the patch to begin with.
429 2014-07-30 21:30:48 <Forex> nice long blocks :D