1 2012-10-02 00:16:41 <jgarzik> evoorhees, on SD: "September was the second-strongest month ever in terms of bet volume, after last month's record-breaking performance.
2 2012-10-02 00:18:04 <BlueMatt> yay stupidity!
3 2012-10-02 00:20:10 <nimdAHK> ?
4 2012-10-02 00:20:25 <BlueMatt> guess there's no the average intelligence of a bitcoin user is higher than the average population...oh well, one can hope
5 2012-10-02 00:21:14 <nimdAHK> Judging by the money invested in pirate...
6 2012-10-02 00:21:41 <BlueMatt> it really is astounding...people's ability to ignore reality when its staring them in the face...
7 2012-10-02 00:21:59 <BlueMatt> whether its investing in obvious shit, or gambling against the odds
8 2012-10-02 00:22:50 <nimdAHK> gambling against the odds makes sense, if you consider the entertainment value
9 2012-10-02 00:23:18 <nimdAHK> If I'd spend $30 at a movie theater, I'd spend $30 at a casino
10 2012-10-02 00:23:21 <BlueMatt> there are better...cheaper ways to be entertained
11 2012-10-02 00:23:34 <nimdAHK> diversity is one of the secrets to happiness
12 2012-10-02 00:23:46 <BlueMatt> true, but gambling all your money away isnt ;)
13 2012-10-02 00:24:05 <nimdAHK> I have more than $30 :|
14 2012-10-02 00:24:08 <nimdAHK> lol
15 2012-10-02 00:24:32 <BlueMatt> there are those who bet once, but to get the kind of volume sd has, you have to have at least a few repeat "customers"
16 2012-10-02 00:24:43 <nimdAHK> lol
17 2012-10-02 00:24:48 <gmaxwell> 19:21 < nimdAHK> Judging by the money invested in pirate...
18 2012-10-02 00:24:51 <nimdAHK> betting once is the second-best strategy
19 2012-10-02 00:24:58 <gmaxwell> I think the claims of investment amount sthere are mostly fiction.
20 2012-10-02 00:24:58 <nimdAHK> yes gmaxwell ?
21 2012-10-02 00:25:14 <nimdAHK> gmaxwell: well just sum up the values of PPT assets on GLBSE
22 2012-10-02 00:25:17 <BlueMatt> gmaxwell: lets call it "donated" to pirate
23 2012-10-02 00:25:20 <gmaxwell> There is basically no evidence for the really big numbers people have trown around.
24 2012-10-02 00:25:21 <nimdAHK> it was around 100K, gmaxwell
25 2012-10-02 00:25:31 <nimdAHK> gmaxwell: the evidence is in GLBSE historic data
26 2012-10-02 00:25:32 <gmaxwell> nimdAHK: the PPTs could invest in themselves and claim any size they wante.d
27 2012-10-02 00:25:50 <gmaxwell> and it was strongly in their own interest to inflate their sizes.
28 2012-10-02 00:25:58 <nimdAHK> still
29 2012-10-02 00:26:01 <nimdAHK> someone had to invest
30 2012-10-02 00:26:08 <nimdAHK> or he wouldn't have ran, lol
31 2012-10-02 00:26:32 <gmaxwell> sure. But it could be 'only' tens of thousands...
32 2012-10-02 00:26:42 <nimdAHK> gmaxwell: I don't believe the 500K, ofc
33 2012-10-02 00:27:01 <BlueMatt> ACTION votes for 21 million btc
34 2012-10-02 00:27:06 <nimdAHK> I held PPT bonds in-between dividends
35 2012-10-02 00:27:17 <nimdAHK> to take advantage of the saw-tooth prices
36 2012-10-02 00:27:21 <gmaxwell> zeekrewards apparently had pulled in over 600 million before the sec shut them down.
37 2012-10-02 00:27:21 <nimdAHK> it was great
38 2012-10-02 00:27:53 <gmaxwell> nimdAHK: you're calling people stupid for owning the toxic assets and yet you admit to having touched them yourself!
39 2012-10-02 00:28:07 <nimdAHK> whoa man
40 2012-10-02 00:28:09 <nimdAHK> I touched them
41 2012-10-02 00:28:13 <nimdAHK> but with a much lower risk
42 2012-10-02 00:28:15 <gmaxwell> don't you reconize that the "I'm to smart to be left holding the bag" thinking is what powered many of the victims?
43 2012-10-02 00:28:28 <gmaxwell> s/to smart/too smart/
44 2012-10-02 00:28:29 <nimdAHK> yes
45 2012-10-02 00:28:40 <nimdAHK> but you saw how long it took for the assets to tank
46 2012-10-02 00:28:43 <nimdAHK> I anticipated that
47 2012-10-02 00:29:00 <nimdAHK> and I only held them in-between dividends
48 2012-10-02 00:29:01 <gmaxwell> You can't prove to me that you escaped because of reason instead of chance.
49 2012-10-02 00:29:04 <BlueMatt> claiming brilliance in hindsight is easy...
50 2012-10-02 00:29:27 <nimdAHK> gmaxwell: I don't really think I need to
51 2012-10-02 00:29:33 <gmaxwell> You might have??? but _everyone_ who escaped can justify if the same way you did. And lots of people who didn't escape had considered exit plans.
52 2012-10-02 00:29:56 <nimdAHK> I considered it entertainment, too
53 2012-10-02 00:30:04 <gmaxwell> (esp since pirate had told many people he'd give forwarning before shutting down)
54 2012-10-02 00:30:12 <nimdAHK> it went on my entertainment budget
55 2012-10-02 00:30:15 <gmaxwell> nimdAHK: and so did many other people who plunked funds in.
56 2012-10-02 00:30:22 <nimdAHK> lol
57 2012-10-02 00:30:26 <nimdAHK> then why are they whining?
58 2012-10-02 00:30:36 <gmaxwell> and likewise??? for many people all their bitcoins ??? even if there are tens of thousands??? are just enterttainment budget.
59 2012-10-02 00:30:44 <nimdAHK> the entertainment budget is meant to be thrown away
60 2012-10-02 00:30:46 <gmaxwell> nimdAHK: because the whining is entertaining too!
61 2012-10-02 00:30:50 <nimdAHK> rofl
62 2012-10-02 00:30:53 <nimdAHK> you lost me there
63 2012-10-02 00:31:07 <nimdAHK> I get a good kick out of a lot of things
64 2012-10-02 00:31:11 <gmaxwell> also, fairly few releative to the likely totl participants are complaining I think.
65 2012-10-02 00:31:26 <gmaxwell> the peoples love the drama, it is their circus.
66 2012-10-02 00:31:39 <nimdAHK> like I said in #bitcoin
67 2012-10-02 00:31:50 <nimdAHK> there's a drama more than once a week in bitcoinland
68 2012-10-02 00:31:57 <nimdAHK> that's more frequent than reality tv
69 2012-10-02 00:31:58 <gmaxwell> woops. I thought this was #bitcoin
70 2012-10-02 00:32:03 <gmaxwell> this is OT for here.
71 2012-10-02 00:32:04 <jgarzik> heh
72 2012-10-02 00:32:12 <nimdAHK> ACTION shuffles over to #bitcoin
73 2012-10-02 00:32:36 <BlueMatt> gmaxwell: my bad, guess I started it in earnest...
74 2012-10-02 00:32:44 <jgarzik> ACTION does too
75 2012-10-02 00:34:08 <BlueMatt> ACTION waits for the google "Failure Trends in a Large SSD Drive Population" Paper to follow up the disk one...
76 2012-10-02 00:35:06 <jgarzik> BlueMatt: eventually Google will be nothing but fast or slow RAM
77 2012-10-02 00:35:12 <BlueMatt> heh
78 2012-10-02 06:27:05 <dusty_> hi all, I've another problem on a strange transaction... help from a script wizard would be great :)
79 2012-10-02 06:27:12 <dusty_> it's EFDF1B981D7BBA9C941295C0DFC654C4B5E40D7B9744819DD4F78B8E149898E1 of testnet3
80 2012-10-02 06:27:48 <dusty_> scriptsig is "2147483647 OP_NEGATE OP_DUP OP_ADD" : what value should this expressione give?
81 2012-10-02 06:28:13 <dusty_> but apart from that, the scriptpubkey is "feffffff80 OP_EQUAL", and how it's supposed to work?
82 2012-10-02 06:28:55 <dusty_> we can't compare 5 bytes with the result of the previous expression, whatever it was, because arithmetic in bitcoin script should be 4 bytes
83 2012-10-02 06:59:07 <dusty_> any takers? :-??
84 2012-10-02 08:27:47 <AnonX> what happens to the coins if your transaction gets rejected?
85 2012-10-02 08:31:49 <_dr> how do you reject a transaction? did you modify the tx fee of your client?
86 2012-10-02 08:32:26 <AnonX> multibit showed a 35btc balance when it only had 25btc
87 2012-10-02 08:43:02 <edcba> if your client 'accepted' the tx then there are spent that's all
88 2012-10-02 08:44:50 <AnonX> edcba: I sent the coins to my mtgox account and they never got there, so where are the coins?
89 2012-10-02 08:46:53 <edcba> you will have to wait for ppl to include your tx in a block
90 2012-10-02 08:47:03 <edcba> or include it yourself
91 2012-10-02 08:47:33 <edcba> is your client showing the transaction ?
92 2012-10-02 08:50:05 <AnonX> edcba: nevermind, solved it
93 2012-10-02 08:51:15 <epscy> AnonX: what happened?
94 2012-10-02 08:52:08 <AnonX> <sturles> Yep, it is probably synchronized with the network, but it has lost track of your unspent outputs.
95 2012-10-02 08:52:20 <AnonX> I just reset my transactions and got it syncrohnize again
96 2012-10-02 08:55:31 <edcba> there is a reset function for tx now ?
97 2012-10-02 08:55:58 <AnonX> in multibit
98 2012-10-02 09:43:35 <BCBot> Stats: http://bit.ly/bitcoin-irc-stats
99 2012-10-02 09:44:22 <BCBot> Stats: http://bit.ly/bitcoin-irc-stats
100 2012-10-02 10:37:06 <Luke-Jr> There are some pretty major non-fix changes in master, so 0.7.1 really needs a branch IMO.
101 2012-10-02 10:40:02 <andyrossy> i branch
102 2012-10-02 11:26:36 <gavinandresen> Who broke the commit-notify-bot ?
103 2012-10-02 11:26:56 <kinlo> gavinandresen: cia.vc is gone beyond recovery
104 2012-10-02 11:27:09 <gavinandresen> cia.vc ?
105 2012-10-02 11:27:20 <gavinandresen> (I have no idea how it worked before....)
106 2012-10-02 11:27:28 <kinlo> well
107 2012-10-02 11:27:36 <kinlo> cia.vc is just a service one could use
108 2012-10-02 11:27:46 <kinlo> and they didn't take backups from their servers
109 2012-10-02 11:27:57 <gavinandresen> oh. oops.
110 2012-10-02 11:28:02 <kinlo> and according to what I read, they patched their live version without checking in their code
111 2012-10-02 11:28:07 <gavinandresen> the phrase "we get what we pay for" comes to mind
112 2012-10-02 11:28:08 <kinlo> so the user database is gone
113 2012-10-02 11:28:24 <kinlo> and the code is not entirely recoverable either
114 2012-10-02 11:28:41 <kinlo> but apparently they are working on a recovery
115 2012-10-02 11:28:56 <kinlo> probably a new setup of the old code, minus some critical patches, and with a clean database
116 2012-10-02 11:29:59 <kinlo> there are alternatives, but Diablo-D3 says there is much hope on a good recovery
117 2012-10-02 11:30:11 <kinlo> but one could look at kgb, fbi or irker
118 2012-10-02 11:31:20 <kinlo> but to install any of them I guess repository access would be required
119 2012-10-02 11:40:37 <Luke-Jr> gavinandresen: [12:37:05] <Luke-Jr> There are some pretty major non-fix changes in master, so 0.7.1 really needs a branch IMO.
120 2012-10-02 11:41:13 <gavinandresen> like what?
121 2012-10-02 11:43:03 <dusty_> I'm sorry to re-request but I don't know where to ask for such a tecnical question... l, I've problem on a strange transaction : it's EFDF1B981D7BBA9C941295C0DFC654C4B5E40D7B9744819DD4F78B8E149898E1 of testnet3, scriptsig is "2147483647 OP_NEGATE OP_DUP OP_ADD" : what value should this expressione give?
122 2012-10-02 11:43:17 <dusty_> but apart from that, the scriptpubkey is "feffffff80 OP_EQUAL", and how it's supposed to work? we can't compare 5 bytes with the result of the previous expression, whatever it was, because arithmetic in bitcoin script should be 4 bytes
123 2012-10-02 11:46:21 <gavinandresen> dusty_: those odd scriptsigs all come from the unit tests in the source tree, src/test/data/script_valid.json
124 2012-10-02 11:46:52 <gavinandresen> (well, gmaxwell or somebody might have added some, the ones I embedded in the testnet3 chain are all from script_valid.json)
125 2012-10-02 11:47:35 <Luke-Jr> gavinandresen: bootstrap loading, stopdetach RPC, various GUI behaviour changes; I haven't been keeping entirely up to date, but those stand out at least
126 2012-10-02 11:48:09 <gmaxwell> Luke-Jr: stopdetach is half a bugfix.
127 2012-10-02 11:48:16 <Luke-Jr> otoh, if 0.7.1 is meant to be like 0.6.1 instead of just fixes, maybe those are fine
128 2012-10-02 11:48:23 <gmaxwell> The whole fact that the user should ever need to worry about detach is a bug. :P
129 2012-10-02 11:48:57 <gavinandresen> bootstrap loading is an invisible new experts-only feature, I'm fine with that getting into the 0.7.1 release
130 2012-10-02 11:49:13 <gmaxwell> GUI changes are worth reviewing I expect.
131 2012-10-02 11:49:59 <dusty_> gavin: thanks, so I suppose the test is this: ["2147483647 NEGATE DUP ADD", "-4294967294 EQUAL"], but the scriptpubkey is different, has 5 bytes, not four: "feffffff80 OP_EQUAL"
132 2012-10-02 11:50:32 <dusty_> so somewhere there is a bug, maybe when they were put in the block
133 2012-10-02 11:50:49 <dusty_> that 0x80 byte should'nt be there
134 2012-10-02 11:50:59 <gavinandresen> 0x80 is the negative
135 2012-10-02 11:51:23 <gavinandresen> if it wasn't there it would be +4 billion something, right?
136 2012-10-02 11:51:36 <dusty_> isn't the first bit the negative?
137 2012-10-02 11:51:57 <dusty_> so it's explained in the wiki, and in effect all the other tests works this way
138 2012-10-02 11:52:30 <gavinandresen> let me use my ask-the-audience: CScript encodes numbers big or little endian?
139 2012-10-02 11:52:33 <dusty_> for example ["-2147483647 -100 100", "WITHIN NOT"], has the negative constant in 4 bytes with the most significant bit set
140 2012-10-02 11:54:49 <gavinandresen> dusty_: okey doke. I vaguely remember being surprised at the encoding of numbers near the top or bottom of the 32-bit range, which is why those tests are in script_valid.json
141 2012-10-02 11:56:08 <gavinandresen> dusty_: ... but I don't remember the details. In any case, the data in the testnet3 chain is valid by definition, although it is certainly possible some other scriptsig could also satisfy the scriptPubKey
142 2012-10-02 11:56:31 <gavinandresen> dusty_: if you want to test, it is trivial to add test cases to src/test/data/script_valid.json or script_invalid.json
143 2012-10-02 11:56:42 <gavinandresen> ... then just 'make test' in src/
144 2012-10-02 11:58:32 <dusty_> gavin: thanks, I'll take a look, the problem is that I'm working on a implementation from scratch and I used 32bits for values as stated in the wiki, while in this case we have at least 33 bits :P
145 2012-10-02 11:59:19 <gavinandresen> dusty_: oh, I see. The arithmetic operations can PRODUCE values more than 4 bytes big, they just can't CONSUME values more than 4-bytes big
146 2012-10-02 11:59:49 <gavinandresen> And OP_EQUAL is not arithmetic, it can compare arrays of arbitrary length
147 2012-10-02 12:00:01 <dusty_> gavin: Understood, thanks
148 2012-10-02 13:45:06 <TD> something that occurs to me, is that wallet software should stop showing the balance on-screen at all times
149 2012-10-02 13:45:29 <TD> i'm keeping a bit too much coinage in my hot wallets at the moment and twice now people have looked at my screen whilst i'm paying them and said "wow you have a lot of coins"
150 2012-10-02 13:45:31 <TD> privacy fail
151 2012-10-02 13:51:03 <sipa> TD: just reply "oh, that's just testnet"
152 2012-10-02 13:51:12 <TD> hah
153 2012-10-02 13:51:23 <TD> sipa: do you have the slides for your talk anywhere?
154 2012-10-02 13:52:10 <TD> i want to write down some thoughts on payment protocols
155 2012-10-02 13:52:16 <TD> but don't want to duplicate anything you already did
156 2012-10-02 13:53:25 <sipa> TD: second, need to find the url
157 2012-10-02 13:53:28 <TD> ok
158 2012-10-02 13:54:40 <sipa> http://prezi.com/iehicj84gxgo/bitcoins-challenges-for-the-near-future/
159 2012-10-02 13:55:55 <sipa> there's not too much on the slides though
160 2012-10-02 13:58:04 <TD> yeah
161 2012-10-02 13:58:05 <TD> thanks
162 2012-10-02 13:59:34 <sipa> TD: i talked about payment protocols a bit with stefan and michael gronager at the conference, and i'm sure gmaxwell and gavin and other people here are interested in it as well
163 2012-10-02 13:59:47 <TD> yeah
164 2012-10-02 13:59:48 <sipa> so maybe we should start some discussion
165 2012-10-02 13:59:50 <TD> i'm drafting a mail
166 2012-10-02 13:59:51 <TD> to the list
167 2012-10-02 14:01:38 <sipa> here's my original gist proposal: https://gist.github.com/1237788
168 2012-10-02 14:01:53 <sipa> it's somewhat outdated, and probably tries to do too much
169 2012-10-02 14:02:12 <sipa> i'd first like to standardize a payment-request and payment-submission format
170 2012-10-02 14:02:27 <sipa> the transport layer can be done later
171 2012-10-02 14:04:22 <TD> yes
172 2012-10-02 14:04:27 <TD> transport layers :)
173 2012-10-02 14:04:51 <sipa> indeed, several
174 2012-10-02 14:05:09 <sipa> https, manual/IM/email, NFC, ...
175 2012-10-02 14:06:04 <helo> will the payment requests support signing?
176 2012-10-02 14:09:41 <helo> indeed it does...
177 2012-10-02 14:10:32 <jgarzik> gavinandresen: 0.7.1 does not need a separate branch, IMO
178 2012-10-02 14:10:46 <sipa> let's look at the changelist from 0.7 to 0.7.1
179 2012-10-02 14:19:18 <sipa> s/0.7.1/HEAD/
180 2012-10-02 14:20:56 <Luke-Jr> git log --no-merges v0.7.1..master
181 2012-10-02 14:22:07 <gavinandresen> I'd like to get a fix for the DB_RUNRECOVERY into 0.7.1
182 2012-10-02 14:24:31 <sipa> there were some non-trivial non-bugfix things since 0.7, but not too many\\
183 2012-10-02 14:28:49 <denisx> btw, when will hash1 and midstate finally be removed?
184 2012-10-02 14:29:33 <Luke-Jr> denisx: no sooner than someone bothering to write the code to remove the calculations :p
185 2012-10-02 14:31:02 <wumpus> jgarzik: are you serious about the stratum protocol in bitcoind?
186 2012-10-02 14:31:17 <gavinandresen> no, he's not
187 2012-10-02 14:31:24 <sipa> i thought stratum was just a concatenation of serializeed JSON directly over HTTP
188 2012-10-02 14:31:31 <jgarzik> yes
189 2012-10-02 14:31:37 <gavinandresen> get out
190 2012-10-02 14:31:46 <wumpus> it uses protocol buffers right?
191 2012-10-02 14:31:49 <jgarzik> conditional logic in that thread, not simple answer
192 2012-10-02 14:31:50 <jgarzik> no
193 2012-10-02 14:31:50 <sipa> not afaik
194 2012-10-02 14:32:07 <jgarzik> stratum protocol == JSON-RPC line + "\\n"
195 2012-10-02 14:32:10 <gavinandresen> oh, if it just a JSON/HTTP variant then that's fine
196 2012-10-02 14:32:12 <wumpus> ok, then it's not as bad as I thought
197 2012-10-02 14:32:16 <jgarzik> but my logic in that thread was CONDITIONAL
198 2012-10-02 14:32:18 <sipa> they implement mining-over-stratum and electrum-over-stratum, but those are separate protocols imho
199 2012-10-02 14:32:29 <sipa> those two are unrelated, afaik too
200 2012-10-02 14:32:30 <jgarzik> I said: stratum > Yet Another Custom Protocol
201 2012-10-02 14:32:35 <jgarzik> I did not say "let's use stratum"
202 2012-10-02 14:32:51 <Luke-Jr> I'm not sure there's any easy solution to that one, unfortunately
203 2012-10-02 14:32:59 <jgarzik> gavinandresen: stratum is not HTTP; it is a JSON-RPC stream
204 2012-10-02 14:33:22 <jgarzik> gavinandresen: connect, and receive "JSON-RPC\\n" asynchronously, or send "JSON-RPC\\n" asynchronously
205 2012-10-02 14:33:29 <jgarzik> it is an improvement over HTTP
206 2012-10-02 14:33:37 <jgarzik> but it is Yet Another Custom Protocol
207 2012-10-02 14:33:38 <gavinandresen> I see, direct connection over a socket?
208 2012-10-02 14:33:43 <jgarzik> gavinandresen: correct
209 2012-10-02 14:33:43 <wumpus> well my solution is easy and keeps HTTP semantics
210 2012-10-02 14:33:57 <sipa> well, stratum probably also requires some pubsub mechanism
211 2012-10-02 14:34:03 <sipa> s/requires/defines/
212 2012-10-02 14:34:26 <sipa> which may not be useles for block/tx update events, either
213 2012-10-02 14:34:36 <jgarzik> sipa: dunno about pubsub, but certainly there is some per-connection server-side state
214 2012-10-02 14:34:37 <sipa> that said... KISS
215 2012-10-02 14:35:20 <gavinandresen> Yes, KISS. And we should be sure to keep track of what problem we're trying to solve
216 2012-10-02 14:35:36 <sipa> brb
217 2012-10-02 14:35:48 <jgarzik> If the problem space is "server [listening socket] may asynchronously send data to client [connecting socket]", then you have HTTP long-polling or $New_Protocol
218 2012-10-02 14:36:06 <jgarzik> HTTP long-polling is an ugly (but effective!) hack
219 2012-10-02 14:36:09 <Luke-Jr> or websocket?
220 2012-10-02 14:36:21 <jgarzik> websocket is a brand new protocol, from bitcoind's perspective
221 2012-10-02 14:36:30 <jgarzik> stratum is nicer than websocket
222 2012-10-02 14:36:35 <Luke-Jr> i c, wasn't sure how complex websocket was over simple HTTP
223 2012-10-02 14:36:43 <jgarzik> websocket is stupid, overly complex shite
224 2012-10-02 14:36:53 <jgarzik> but standardized shite, it must be admitted
225 2012-10-02 14:37:12 <jgarzik> nevertheless, stratum is easier to debug and use than websocket
226 2012-10-02 14:37:35 <Luke-Jr> I suppose LP could work iff clients can maintain 2 connections, the latter of which is a "double LP", but that's getting into $New_Protocol ugliness too
227 2012-10-02 14:37:51 <Luke-Jr> and even worse hack than LP itself
228 2012-10-02 14:38:01 <jgarzik> you cannot get much more simple than a line-by-line text protocol, which is stratum
229 2012-10-02 14:40:41 <gavinandresen> simpler: create two boost::interprocess::message_queues, one for new head-of-blockchain events, one for tranaction-into-the-memory-pool events. Event messages are just block/tx hashes.
230 2012-10-02 14:40:56 <gavinandresen> ... and dont' support it on Windows, because Windows sucks.
231 2012-10-02 14:41:35 <Luke-Jr> gavinandresen: I think a goal is to allow access from other hosts
232 2012-10-02 14:41:42 <Luke-Jr> that was one of the problems people had with -blocknotify
233 2012-10-02 14:41:52 <gavinandresen> then install a listener that listens to the queue and does whatever you like.
234 2012-10-02 14:41:57 <TD> windows supports IPC message queues
235 2012-10-02 14:41:59 <gavinandresen> LESS CODE IN CORE
236 2012-10-02 14:42:03 <TD> if boost doesn't then boost sucks
237 2012-10-02 14:42:18 <gavinandresen> TD: we've had trouble using them for URI support
238 2012-10-02 14:42:21 <Luke-Jr> heh
239 2012-10-02 14:42:39 <jgarzik> Separate but related: I think bitcoind will eventually support GBT-over-stratum
240 2012-10-02 14:42:45 <Luke-Jr> could just tell people who want this to connect on the p2p port and look for invs ;)
241 2012-10-02 14:42:51 <TD> ACTION suspects boost sucks then :)
242 2012-10-02 14:42:54 <gavinandresen> GBT is an acronym I don't recognize.
243 2012-10-02 14:43:00 <jgarzik> gavinandresen: getblocktemplate RPC
244 2012-10-02 14:43:24 <gavinandresen> I was thinking gay/bisexual/transgender....
245 2012-10-02 14:43:24 <Luke-Jr> jgarzik: probably some synthesis of GBT and stratum is inevitable, though I'm not sure it's a priority right now
246 2012-10-02 14:43:26 <jgarzik> ACTION has been infected with the Luke-Jr acronym virus, it seems
247 2012-10-02 14:43:36 <jgarzik> lol
248 2012-10-02 14:43:48 <jgarzik> Luke-Jr: it was not claimed a priority
249 2012-10-02 14:43:56 <jgarzik> Luke-Jr: but if there is alignment with separate issues, it is relevant
250 2012-10-02 14:44:12 <Luke-Jr> sure
251 2012-10-02 14:45:29 <Luke-Jr> jgarzik: I don't disagree with stratum being probably one of the most practical options
252 2012-10-02 14:46:08 <jgarzik> gavinandresen: I understand the "don't do it in core" argument, but realistically we have not seen much -blocknotify takeup vis a vis external processes
253 2012-10-02 14:46:15 <jgarzik> at least not that I've seen
254 2012-10-02 14:46:41 <jgarzik> from the user perspective, -blocknotify creates another "moving part" that might break
255 2012-10-02 14:46:54 <gavinandresen> somebody should write up an example that implements "send email when any transaction to my wallet gets 6 confirmations"
256 2012-10-02 14:47:17 <wumpus> over a interprocess::message_queue you still need a protocol
257 2012-10-02 14:47:24 <jgarzik> indeed
258 2012-10-02 14:47:27 <Luke-Jr> jgarzik: afaik -blocknotify has put blkmond out of business
259 2012-10-02 14:47:45 <wumpus> though you could of course stream json over that...
260 2012-10-02 14:47:52 <gavinandresen> jgarzik: sure, but I'm a much bigger fan of the unix-philosophy of small, solid, inter-operating tools.
261 2012-10-02 14:47:53 <wumpus> then again, if you do that, why not simply a socket
262 2012-10-02 14:48:04 <jgarzik> wumpus: precisely
263 2012-10-02 14:48:09 <jgarzik> Luke-Jr: afaik progress and pushpool obsolescence pushed blkmond out of business ;-)
264 2012-10-02 14:48:19 <wumpus> a socket IS a simple interprocess message queue, integrated into the OS
265 2012-10-02 14:48:28 <Luke-Jr> jgarzik: yes, but the new poolservers still use SIGUSR1 :p
266 2012-10-02 14:48:41 <wumpus> boost:interprocess is really ugly, uses shared memory mappings etc...
267 2012-10-02 14:48:45 <jgarzik> indeed
268 2012-10-02 14:49:04 <jgarzik> we already know how to do handle "socket IPC"
269 2012-10-02 14:49:10 <wumpus> well mr. unix would also propose using sockets and pipes :P
270 2012-10-02 14:49:11 <jgarzik> and that IPC works remotely, as well as locally
271 2012-10-02 14:49:15 <jgarzik> and cross-platform too :)
272 2012-10-02 14:49:24 <gavinandresen> sockets or named pipes would be fine
273 2012-10-02 14:50:54 <gavinandresen> the can of worms opens up when you get off the local machine, in my opinion. If you listen on a socket then suddenly you need authentication.
274 2012-10-02 14:51:08 <wumpus> we already have authentication in the JSONRPC web server
275 2012-10-02 14:51:09 <gavinandresen> If you connect out, suddenly you're vulnerable to MITM attacks
276 2012-10-02 14:51:20 <wumpus> that's why I proposed to simply extend that
277 2012-10-02 14:51:35 <wumpus> connecting out is a bad idea, yes
278 2012-10-02 14:51:43 <wumpus> there's so many ways to do that
279 2012-10-02 14:52:28 <gavinandresen> wumpus: I like the connection-means-subscription model via existing JSON-HTTP-RPC
280 2012-10-02 14:52:52 <wumpus> and it'd also add more administration... and what if you want multiple listeners?
281 2012-10-02 14:53:14 <wumpus> yes, with that model an arbitrary number of people can simply connect and listen
282 2012-10-02 14:54:05 <gavinandresen> wumpus: I don't like the complexity of our existing RPC code, I think we've had a lot of feature creep. But c'est la vie
283 2012-10-02 14:55:40 <wumpus> I don't like it either, but we need some kind of RPC, otherwise bitcoind would get a bit lonely.. I mean, if we'd move JSONRPC to an external processs we'd still need a protocol/RPC mechanism to let it talk to the core...
284 2012-10-02 14:57:05 <gmaxwell> splitting the blockchain and wallet would clean up some of the RPC bloat. (as a lot of the rpc bloat is wallet related)
285 2012-10-02 14:57:36 <wumpus> yes
286 2012-10-02 14:58:39 <TD> another way to solve it would be to reimplement some RPC protocol on top of a separate app, eg, based on bitcoinj
287 2012-10-02 14:58:45 <TD> that talks p2p to a local node
288 2012-10-02 14:59:16 <TD> then people who don't necessarily know C++ can add new RPC protocols as they see fit, maybe with some plugins or whatever.
289 2012-10-02 14:59:18 <wumpus> though the wallet would have to talk with the block chain, so you'd need *some* RPC bloat
290 2012-10-02 15:00:25 <Joric> there was a question about using the same key in two different wallet.dat's will it work correctly? will it pick transactions from the blockchain?
291 2012-10-02 15:00:26 <wumpus> so you would have a daemon that only does P2P, but offers no outside access?
292 2012-10-02 15:00:46 <wumpus> interesting, but I wonder why people would run that in the first place
293 2012-10-02 15:00:58 <gavinandresen> wumpus: I'm not thinking of the number of RPC methods, I'm thinking of IPv4/IPv6/SSL/non-ssl/authentication/IP restrictions/DoS prevention ....
294 2012-10-02 15:01:10 <wumpus> oh right
295 2012-10-02 15:01:21 <wumpus> would be fine with me to make jsonrpc localhost-only
296 2012-10-02 15:01:44 <wumpus> want it external, fine, run a proxy
297 2012-10-02 15:02:00 <gavinandresen> yes, that's what I think we should've done. ah well.
298 2012-10-02 15:02:22 <wumpus> DoS protection in the RPC server? you can't be serious.. :/
299 2012-10-02 15:02:55 <gavinandresen> sure. There's a check for trying to DoS using failed basic authentication, to prevent brute-forcing the password
300 2012-10-02 15:03:00 <wumpus> Joric: just don't
301 2012-10-02 15:03:31 <phantomcircuit> gavinandresen, something tells me that generally speaking if the rpc interface is available there are other issues at play
302 2012-10-02 15:03:54 <jgarzik> boy this convo is wandering far afield ;p
303 2012-10-02 15:03:55 <Joric> wumpus, why?
304 2012-10-02 15:04:09 <wumpus> Joric: because you'll get into a world of pain
305 2012-10-02 15:04:19 <jgarzik> maybe some Tex-Mex will make things clear *poof*
306 2012-10-02 15:04:26 <gavinandresen> Joric: because we don't test that case and when it doesn't work we won't fix it
307 2012-10-02 15:05:48 <gmaxwell> Joric: it does, but there are nice race conditions to stomp yourself when writing transactions.
308 2012-10-02 15:08:47 <Joric> i just was going to give a copy of the wallet.dat to my wife
309 2012-10-02 15:09:58 <gmaxwell> Joric: and in that case you'll get the two wallets diverging.. eventually some random fraction of your funds will be in each and unspendable in the other.
310 2012-10-02 15:10:34 <OneEyed> I'm surprised nobody sees key derivation as a top priority for bitcoind
311 2012-10-02 15:11:04 <gmaxwell> OneEyed: oh sure, it's just under the 40 other top priorities.
312 2012-10-02 15:11:07 <OneEyed> (I know I would probably work on this if I used bitcoind to generate my keys)
313 2012-10-02 15:11:23 <gmaxwell> Though, I'm not sure what exactly you're thinking there.
314 2012-10-02 15:11:47 <OneEyed> gmaxwell: keys derived from a single key, as in Armory or in Electrum
315 2012-10-02 15:12:08 <gmaxwell> (and that doesn't really have a baring on Joric's question: multistarting a wallet is still not going to work right no matter how the keys are generated)
316 2012-10-02 15:13:13 <OneEyed> gmaxwell: what do you mean? Armory instances at different places and using the same wallet are kept in sync, because any of the instances know the keys that will be generated, so anything received in the wallet is spendable from anywhere
317 2012-10-02 15:14:31 <gmaxwell> OneEyed: And when you manage to send from two places concurrently and double spend an input, causing a bunch of inputs in your wallet to become at least temporarily unspendable?
318 2012-10-02 15:14:52 <OneEyed> Oh sure, I hadn't understood you talked about that
319 2012-10-02 15:16:18 <gmaxwell> If you only concern was the keys staying in sync you could just set the keypool to 50,000 keys and call it done.
320 2012-10-02 15:16:34 <OneEyed> gmaxwell: are change addresses included in the keypool now?
321 2012-10-02 15:16:43 <OneEyed> (I remember reading something about that some time ago, that may be moot)
322 2012-10-02 15:17:36 <gmaxwell> OneEyed: they've _always_ been in the keypool. Thats the point. 0_o
323 2012-10-02 15:32:04 <Luke-Jr> Anyone have spare testnet3 coins? myWxSedFAaiVntDfSYskCtMnimANxPSAWU
324 2012-10-02 15:33:26 <gmaxwell> Luke-Jr: you burned through the ones I gave you fast. :P
325 2012-10-02 15:33:49 <Luke-Jr> gmaxwell: were those tn3? >_<
326 2012-10-02 15:33:55 <gmaxwell> yea.
327 2012-10-02 15:33:55 <Luke-Jr> ACTION ponders what directory they might be in
328 2012-10-02 15:33:58 <gmaxwell> hah.
329 2012-10-02 15:34:21 <Luke-Jr> ok, nobody send to that address
330 2012-10-02 15:34:25 <Luke-Jr> about to overwrite it with others
331 2012-10-02 15:34:27 <Luke-Jr> <.<
332 2012-10-02 15:34:44 <lianj> http://blockexplorer.com/testnet/address/myWxSedFAaiVntDfSYskCtMnimANxPSAWU
333 2012-10-02 15:34:54 <gmaxwell> fwiw for testnet key management .. er.. I've been using that utility that scans the disk for keys to merge wallets.
334 2012-10-02 15:34:55 <sipa> Joric: you can, but be ware
335 2012-10-02 15:35:20 <sipa> Joric: yes the transactions will get picked up by the other node, but the keys will diverge
336 2012-10-02 15:35:34 <sipa> Joric: if you sync the wallets every (keypool)-transactions, it should be fine
337 2012-10-02 15:35:58 <sipa> Joric: but there are other caveats, like trying to send coins while your node hasn't seen they' re already spent by the other one
338 2012-10-02 15:36:22 <Luke-Jr> gmaxwell: found it :D
339 2012-10-02 15:54:42 <gmaxwell> " roughly 3-5% of our initial members double-spent. " 0_o huh?
340 2012-10-02 15:54:43 <gavinandresen> Luke-Jr: http://testnet.freebitcoins.appspot.com/ is up
341 2012-10-02 15:55:17 <lianj> gavinandresen: thats were he got the 50 from
342 2012-10-02 15:55:45 <gavinandresen> lianj: testnet faucet doesn't limit to one-per-customer
343 2012-10-02 15:56:44 <gavinandresen> gmaxwell: is that a quote from Peter ?
344 2012-10-02 15:56:56 <gmaxwell> yes.
345 2012-10-02 15:57:15 <gavinandresen> oh, he means 'double-paid' not double-spent
346 2012-10-02 15:57:26 <gmaxwell> I did figure that out; although it's still confusing!
347 2012-10-02 16:01:53 <midnightmagic> Luke-Jr: Do you still need tn3 coins?
348 2012-10-02 16:02:05 <Luke-Jr> midnightmagic: no, I found the ones gmaxwell sent me
349 2012-10-02 16:02:10 <Luke-Jr> gavinandresen: midnightmagic: thanks tho
350 2012-10-02 16:02:13 <midnightmagic> ok
351 2012-10-02 16:04:00 <BlueMatt> gmaxwell: just what I was thinking
352 2012-10-02 16:09:07 <jgarzik> gmaxwell: See this, from last night? http://pastebin.com/vnaxq3zf
353 2012-10-02 16:09:21 <jgarzik> gmaxwell: that happens after almost every testnet3 block, on us4.exmulti.net
354 2012-10-02 16:09:45 <jgarzik> gmaxwell: getpeerinfo shows nearly 100% satoshi clients
355 2012-10-02 16:12:52 <BlueMatt> jgarzik: heres your source: " pfrom->PushGetBlocks(mapBlockIndex[inv.hash], uint256(0));"
356 2012-10-02 16:13:16 <BlueMatt> or...seems to be its the only call to PushGetBlocks thats !pindexBest
357 2012-10-02 16:14:11 <BlueMatt> (its called if you are the second node to send the block, and send it after the node already has the block)
358 2012-10-02 16:14:33 <BlueMatt> (or, more realistically, it processes the message after it processes the block)
359 2012-10-02 16:15:17 <jgarzik> hmmm
360 2012-10-02 16:15:33 <jgarzik> that means fAlreadyHave is true
361 2012-10-02 16:15:57 <BlueMatt> ehh...maybe its the other way around then
362 2012-10-02 16:16:16 <jgarzik> but these guys are continuously sending getblocks(-1,0) with each new network block
363 2012-10-02 16:16:33 <BlueMatt> wait, no thats right
364 2012-10-02 16:16:40 <BlueMatt> yea, you are the second node to send the inv to them
365 2012-10-02 16:16:42 <jgarzik> seen on mainnet regularly, but more visible on testnet3. Was hoping testnet3 behavior would lead to debugging
366 2012-10-02 16:17:21 <jgarzik> I don't think that comment is accurate
367 2012-10-02 16:17:29 <jgarzik> I don't think the nodes are on a long side chain
368 2012-10-02 16:17:43 <BlueMatt> the comment is one of the cases where that code is called
369 2012-10-02 16:17:58 <BlueMatt> but its also possible because we get dup invs all the time
370 2012-10-02 16:18:15 <BlueMatt> (have to process the block before sending out the announce, so if we get send another inv during that period...dup)
371 2012-10-02 16:18:26 <jgarzik> ACTION wonders if this is a side effect of sending hashBestChain, as the method of triggering getblocks continuation (for IBD)
372 2012-10-02 16:19:53 <BlueMatt> indirectly, sure
373 2012-10-02 16:20:11 <BlueMatt> its a side-effect of some nodes getting on long side-chains and sipa having to write a fix for that ;)
374 2012-10-02 16:20:58 <jgarzik> BlueMatt: I really don't think that is what's happening
375 2012-10-02 16:20:59 <BlueMatt> (long, here, being not-that-long since we were limiting getblocks to SendBufferSize...)
376 2012-10-02 16:21:07 <jgarzik> BlueMatt: otherwise the locator would not be -1
377 2012-10-02 16:21:26 <BlueMatt> jgarzik: thats the point, that code is called in other cases, not just the stuff that it says in the comment
378 2012-10-02 16:21:36 <BlueMatt> (though it does fix the issue described in the comment)
379 2012-10-02 16:22:13 <gmaxwell> yea, I initially thought this was the keep-feeding prod but I couldn't see how that got a -1 locator.
380 2012-10-02 16:22:39 <gmaxwell> though I admit I haven't had much time to look at it. :(
381 2012-10-02 16:23:32 <BlueMatt> hmm...well it should have to be that...its the only one that isnt pindexBest (and all of those are response to an inv where they should reasonably have pindexBest)
382 2012-10-02 16:23:44 <BlueMatt> but...yea seems odd that that is -1 anyway
383 2012-10-02 16:24:06 <BlueMatt> anywhoo...needs -debug testing with a few nodes...
384 2012-10-02 16:26:06 <jgarzik> maybe a special debug patch that logs peer node version
385 2012-10-02 16:26:12 <jgarzik> any info debug info that might be helpful?
386 2012-10-02 16:26:22 <jgarzik> IP address, to see if it's the same nodes
387 2012-10-02 16:26:43 <BlueMatt> jgarzik: it doesnt seem to be "weird" (as in non-std node) behavior, Id think you'd see it in a large enough testnet-in-a-box network
388 2012-10-02 16:27:00 <jgarzik> BlueMatt: how?
389 2012-10-02 16:27:30 <jgarzik> BlueMatt: I can see the behavior is sane, iff locator != -1
390 2012-10-02 16:27:57 <jgarzik> but every single new network block sees multiple clients getblocks(-1,0)
391 2012-10-02 16:27:58 <gmaxwell> I think if you're seeing it on tn3 then it must be 0.7 doing it, no?
392 2012-10-02 16:28:06 <jgarzik> gmaxwell: presumably
393 2012-10-02 16:28:11 <BlueMatt> jgarzik: whether its sane or not, i'd guess its too prevalent to be happening from just crap nodes, seems like it should appear with std nodes
394 2012-10-02 16:28:38 <jgarzik> as gmaxwell points out, testnet3 is an elite subset ;p
395 2012-10-02 16:28:45 <jgarzik> since we just changed the pchMessageStart
396 2012-10-02 16:28:57 <jgarzik> most likely standard nodes
397 2012-10-02 16:33:18 <BlueMatt> hmm...yea makes no sense, but its been happening forever...I thought it was a flag because Id seen it so long ago
398 2012-10-02 16:44:49 <sipa> jgarzik: wasn't that a known BitcoinJ problem?
399 2012-10-02 16:45:03 <sipa> with the getblocks(-1,0), or was that something else?
400 2012-10-02 16:45:10 <sipa> TD[gone]: ?
401 2012-10-02 16:54:01 <jgarzik> sipa: getpeerinfo reports satoshi clients
402 2012-10-02 16:54:14 <jgarzik> sipa: this is testnet3, so pretty much everybody is satoshi 0.7
403 2012-10-02 16:54:36 <sipa> ok, right
404 2012-10-02 16:54:39 <sipa> that is strange
405 2012-10-02 16:55:53 <jgarzik> sipa, BlueMatt, gmaxwell: http://pastebin.com/LEc6QuJV (getpeerinfo | grep -i subver)
406 2012-10-02 16:56:12 <jgarzik> looks like there is 1 bitcoinj, surprisingly
407 2012-10-02 16:56:28 <gmaxwell> oh ho!
408 2012-10-02 16:56:28 <jgarzik> going to instrument to print out IP addr and subver
409 2012-10-02 17:00:25 <jgarzik> I seriously doubt one BitcoinJ would send 4+ getblocks(-1,0) though
410 2012-10-02 17:20:24 <jgarzik> OK, testnet3 public node and local, behind-firewall node instrumented
411 2012-10-02 17:20:33 <jgarzik> let's see who those getblocks weirdos are, now
412 2012-10-02 17:20:54 <jgarzik> ProcessBlock: ACCEPTED
413 2012-10-02 17:20:54 <jgarzik> SetBestChain: new best=000000000422c384f6ba height=32195 work=1148841233482094 date=10/02/12 19:19:59
414 2012-10-02 17:21:04 <jgarzik> all satoshi clients, as expected
415 2012-10-02 17:22:01 <jgarzik> that's testnet3 btw
416 2012-10-02 17:22:28 <jgarzik> 54.243.211.176:55101 /Satoshi:0.7.0.3/ getblocks -1 to 00000000000000000000 limit 500
417 2012-10-02 17:29:28 <jgarzik> 173.170.188.216:45040 /Satoshi:0.7.0.99/next-test:20120920/ getblocks -1 to 00000000000000000000 limit 500
418 2012-10-02 17:29:28 <jgarzik> 89.40.16.241:58926 /Satoshi:0.7.0.3/ getblocks -1 to 00000000000000000000 limit 500
419 2012-10-02 17:29:52 <jgarzik> at least one repeater
420 2012-10-02 17:30:12 <jgarzik> make that two
421 2012-10-02 17:30:34 <jgarzik> and again,
422 2012-10-02 17:30:36 <jgarzik> 89.40.16.241:58926 /Satoshi:0.7.0.3/ getblocks -1 to 00000000000000000000 limit 500
423 2012-10-02 17:30:56 <jgarzik> so
424 2012-10-02 17:31:27 <jgarzik> Clear proof that nodes are getting stuck, even with new blocks appearing on network
425 2012-10-02 17:45:29 <D34TH> so it seems that the server i started downloading blocks on last night wants to commit suicide, cpu load = 0.7 ram = 565/15953MB load avg=5.63
426 2012-10-02 17:50:26 <jgarzik> D34TH: it is primarily in disk wait, then?
427 2012-10-02 17:50:49 <D34TH> i dont even know
428 2012-10-02 17:51:52 <D34TH> give me a second
429 2012-10-02 17:51:57 <sipa> 1
430 2012-10-02 17:52:44 <D34TH> seems like it
431 2012-10-02 17:53:10 <D34TH> 21.6 w/s
432 2012-10-02 18:01:08 <jgarzik> 178.63.48.141:61626 /Satoshi:0.7.0.3/ getblocks -1 to 00000000000000000000 limit 500
433 2012-10-02 18:01:08 <jgarzik> 96.21.113.151:33994 /Satoshi:0.7.0.99/ getblocks -1 to 00000000000000000000 limit 500
434 2012-10-02 18:01:09 <jgarzik> 173.170.188.216:45040 /Satoshi:0.7.0.99/next-test:20120920/ getblocks -1 to 00000000000000000000 limit 500
435 2012-10-02 18:01:24 <jgarzik> quite odd. IP addresses appear repeatedly, making this request
436 2012-10-02 18:01:36 <jgarzik> ...but it is not guaranteed that they request after -every- block
437 2012-10-02 18:01:49 <jgarzik> perhaps they are hitting !fAlreadyHave in those cases
438 2012-10-02 18:01:52 <sipa> jgarzik: did you check what their initial height was when connecting?
439 2012-10-02 18:02:11 <jgarzik> sipa: no
440 2012-10-02 18:02:19 <jgarzik> ACTION adds that to the logging
441 2012-10-02 18:05:22 <sipa> quite sure it's my unstuck logic that is causing this
442 2012-10-02 18:06:35 <sipa> yup, it is
443 2012-10-02 18:07:26 <jgarzik> pfrom->PushGetBlocks(mapBlockIndex[inv.hash], uint256(0));
444 2012-10-02 18:07:41 <jgarzik> are we certain that mapBlockIndex[inv.hash] actually has a useful value?
445 2012-10-02 18:07:48 <jgarzik> we might have seen it... but not yet in block index, right?
446 2012-10-02 18:07:50 <sipa> yes
447 2012-10-02 18:08:11 <sipa> because it's not !fAlreadyHave, and not an orphan
448 2012-10-02 18:09:13 <sipa> in the (nInv == nLastBlock) check, can you add && (inv.hash != pindexBest->GetHash())
449 2012-10-02 18:09:20 <jgarzik> sipa: AlreadyHave() returns 'true' by default though... ;p
450 2012-10-02 18:09:35 <sipa> not for blocks
451 2012-10-02 18:10:16 <jgarzik> sipa: sadly changing my node's PushGetBlocks processing won't do much
452 2012-10-02 18:10:29 <sipa> oh damnit
453 2012-10-02 18:10:34 <sipa> of course, it's the other side
454 2012-10-02 18:10:35 <jgarzik> I don't have a local reproducer, just observing the other side
455 2012-10-02 18:11:37 <sipa> can i -connect to you, with a patched node, to see if it happens?
456 2012-10-02 18:20:06 <jgarzik> sipa: sure
457 2012-10-02 18:20:11 <jgarzik> sipa: us4.exmulti.net:18333
458 2012-10-02 18:20:25 <jgarzik> sipa: just restarted with log-nStartingHeight update
459 2012-10-02 18:26:02 <jgarzik> my my
460 2012-10-02 18:26:04 <jgarzik> ERROR: CTxMemPool::accept() : not enough fees 24e2737de230ade56cab84d3fa453563a14e3e57e4bc0bafb5ae97c2b3d9b7d0, -99950000 < 0
461 2012-10-02 18:26:11 <jgarzik> that's an interesting testnet transaction
462 2012-10-02 18:26:51 <sipa> jgarzik: sec, rebasing ultraprune
463 2012-10-02 18:27:27 <jgarzik> sipa: Here's output with starting height: http://pastebin.com/Dfh4Xn2m
464 2012-10-02 18:27:43 <jgarzik> (third data item is nStartingHeight)
465 2012-10-02 18:28:25 <jgarzik> more output, block #32231: http://pastebin.com/mj5YMq2Q
466 2012-10-02 18:38:44 <jgarzik> more output, block #32233-32235: http://pastebin.com/50ahaUxp
467 2012-10-02 18:39:23 <sipa> jgarzik: i know an easy fix (only triggering the unstuck logic when there's more than 1 block in the inv), but there's a deeper issue
468 2012-10-02 18:42:06 <sipa> jgarzik: got it
469 2012-10-02 18:42:29 <sipa> imagine a getblocks that sends the current best tip as locator
470 2012-10-02 18:42:55 <sipa> the receiver gets a pindex out of that which refers ideally to his own tip
471 2012-10-02 18:43:18 <jgarzik> more output, block #32236: http://pastebin.com/mRwvtG4x
472 2012-10-02 18:43:18 <sipa> there's pindex = pindex->pnext in the "getblocks" handler
473 2012-10-02 18:43:33 <sipa> as you want to start sending at the block after the last own the other side has
474 2012-10-02 18:43:45 <sipa> but as you already were at the tip, pindex is now NULL
475 2012-10-02 18:44:02 <sipa> and what you actually do is start sending the entire index from scratch
476 2012-10-02 18:44:47 <jgarzik> indeed, I see it
477 2012-10-02 18:45:11 <jgarzik> BTW, unrelated note: that last pastebin has an interesting strSubVer
478 2012-10-02 18:45:11 <sipa> so imho, a getblocks should be silently ignored in that case
479 2012-10-02 18:45:25 <sipa> as it requests something for which only the empty set is the correct answer
480 2012-10-02 18:46:08 <jgarzik> 93.56.34.243:52480 JavaCoin/1.0-DEV 518 getblocks 2019 to 00000000000000000000 limit 500
481 2012-10-02 18:46:10 <jgarzik> JavaCoin!
482 2012-10-02 18:46:32 <jgarzik> sipa: if they are already at the tip, wonder why it sends the request at all?
483 2012-10-02 18:46:48 <sipa> because they don't know they're at the tip
484 2012-10-02 18:49:08 <sipa> jgarzik: actually, we already ignore it
485 2012-10-02 18:49:31 <sipa> the loop afterwards in the getblocks handler runs only as long as pindex is not NULL
486 2012-10-02 18:49:39 <sipa> so the only problem is the output really
487 2012-10-02 18:50:00 <sipa> (and the fact that it shouldn't be triggered at all in normal circumstances)
488 2012-10-02 18:50:47 <sipa> i wonder whether we can avoid it during IBD as well
489 2012-10-02 18:56:36 <sipa> SHA-3 == Keccak
490 2012-10-02 19:04:17 <jgarzik> sipa: link?
491 2012-10-02 19:04:27 <sipa> http://www.nist.gov/itl/csd/sha-100212.cfm
492 2012-10-02 19:04:38 <jgarzik> owel, that shoots down all my Linux kernel work on skein ;-)
493 2012-10-02 19:05:30 <sipa> the second author of RIjndael (AES) is also the second author of Keccak...
494 2012-10-02 19:05:39 <sipa> <conspiracy_theories>
495 2012-10-02 19:15:54 <gmaxwell> Boom.
496 2012-10-02 19:15:56 <gmaxwell> I called it
497 2012-10-02 19:16:00 <gmaxwell> ACTION goes to collect bets.
498 2012-10-02 19:16:27 <gmaxwell> Skein was the only finalist without an internal state 2x the output in the recommended config.
499 2012-10-02 19:18:44 <sipa> skein was also significantly faster than keccak
500 2012-10-02 19:21:03 <maaku> damn. i was hoping for skein because that would have been de facto standardization of Threefish as a block cipher
501 2012-10-02 19:22:28 <helo> sounds like they made a great choice!
502 2012-10-02 19:23:23 <sipa> it looks like an unusual construction, though
503 2012-10-02 19:23:51 <gmaxwell> Increases diversity.
504 2012-10-02 19:24:05 <maaku> sipa: from the wording of the press release, that appears to be a primary consideration
505 2012-10-02 19:24:16 <sipa> i'm somewhat glad that they dare choose something "new"
506 2012-10-02 19:24:52 <gmaxwell> there were several others submissions with similar structure.
507 2012-10-02 19:25:13 <gmaxwell> 'sponge+permutation' is sort of popular for research.
508 2012-10-02 19:25:22 <jgarzik> ACTION picked Skein because of the block cipher, and because I like Bruce ;p
509 2012-10-02 19:25:32 <maaku> sipa: well they picked something unusual with AES as well
510 2012-10-02 19:25:53 <sipa> maaku: and in both cases the "unusual" part was in fact designed by Joan Daemen, from what I hear
511 2012-10-02 19:27:17 <sipa> a friend of mine actualy made a submission (LANE), but he didn't make it to the second round
512 2012-10-02 19:29:14 <amiller> was "unusual" an explicit goal from the outset?
513 2012-10-02 19:29:26 <jgarzik> http://keccak.noekeon.org/
514 2012-10-02 19:29:37 <jgarzik> "Keccak makes use of the sponge construction and is hence a sponge function family."
515 2012-10-02 19:30:15 <maaku> amiller: not as such; there are pros and cons that come with it
516 2012-10-02 19:32:02 <maaku> if you're talking about the NIST's goals at least; i don't know if Keccak's authors were purposefully trying to be original
517 2012-10-02 19:32:20 <jgarzik> absent other constraints, diversity is good
518 2012-10-02 19:33:10 <jgarzik> same reason I like bitcoin... bitcoin provides a heterogenous environment, when it lives alongside fiat currencies. Good for checks-and-balances.
519 2012-10-02 19:34:13 <sipa> according to sebastiaan, keccak was actually designed to be original
520 2012-10-02 19:34:15 <maaku> jgarzik: but an unusual design means there has been less research in that area, meaning there is a higher probability of undiscovered attack vectors
521 2012-10-02 19:35:03 <maaku> but in this case that's probably not an issue since SHA-2 is still a suitable alternative
522 2012-10-02 19:35:09 <jgarzik> maaku: quite true as well
523 2012-10-02 19:36:22 <sipa> best attacks on SHA-2 work on 1/2nd to 2/3rd of the number of rounds only
524 2012-10-02 19:36:39 <sipa> so i can see there was reason to be suspicious about its safety in the very long run
525 2012-10-02 19:36:41 <maaku> then again the NSA gets input into the final selection, so maybe one can read into this that they know quite a bit about the sponge function family ;)
526 2012-10-02 19:41:40 <jgarzik> oh god
527 2012-10-02 19:41:46 <jgarzik> Keccak is indeed _so_ horrible
528 2012-10-02 19:42:17 <Luke-Jr> ?
529 2012-10-02 19:42:17 <sipa> how so?
530 2012-10-02 19:42:25 <sipa> it looks quite elegant, imho
531 2012-10-02 19:42:37 <Luke-Jr> someone remember to announce a switch of POW to SHA-3 on April 1
532 2012-10-02 19:42:49 <sipa> Luke-Jr: ACK :p
533 2012-10-02 19:42:50 <maaku> lol
534 2012-10-02 19:42:57 <jgarzik> http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip
535 2012-10-02 19:43:11 <jgarzik> a dozen unreadable implementations, #ifdef'd to hell and back
536 2012-10-02 19:43:32 <jgarzik> Luke-Jr: hehehe
537 2012-10-02 19:43:50 <jgarzik> I meant the Keccak source code is horrible
538 2012-10-02 19:43:52 <jgarzik> not design
539 2012-10-02 19:45:11 <sipa> Luke-Jr: "Because the SHA256 PoW function used in Bitcoin was superceded by Keccak (SHA-3), Bitcoin 0.9 will retroactively switch to Keccak for POW. Large reorganisation is expected."
540 2012-10-02 19:45:32 <Luke-Jr> sipa: that's too obvious?
541 2012-10-02 19:45:41 <sipa> hmm, true
542 2012-10-02 19:46:11 <sipa> jgarzik: oh, didn't check the source code
543 2012-10-02 19:47:52 <jgarzik> ROFL, from the Keccak page: "Markku-Juhani O. Saarinen posted an implementation of Keccak in C aimed at readability and clarity, as an alternative to our specifications summary." http://www.mjos.fi/dist/readable_keccak.tgz
544 2012-10-02 19:48:29 <sipa> Keccak seems systematically faster than SHA-256, but slower than SHA-512...
545 2012-10-02 19:48:45 <sipa> on 64-bit hardware, that is
546 2012-10-02 19:50:57 <jgarzik> sipa: strange that nStartingHeight is so uniform: http://pastebin.com/5yBWFL7W
547 2012-10-02 19:51:34 <sipa> jgarzik: it only happens with up-to-date nodes
548 2012-10-02 20:06:13 <jgarzik> flood of these on testnet3:
549 2012-10-02 20:06:15 <jgarzik> GetNextWorkRequired RETARGET
550 2012-10-02 20:06:15 <jgarzik> nActualTimespan = 326059 before bounds
551 2012-10-02 20:06:27 <jgarzik> same before/after in each message
552 2012-10-02 20:08:23 <jgarzik> wonder if it's related to the internal miner
553 2012-10-02 20:09:36 <maaku> u
554 2012-10-02 20:09:50 <jgarzik> yep
555 2012-10-02 20:09:58 <jgarzik> turn on internal miner... flood of the above
556 2012-10-02 20:10:02 <jgarzik> turn off, no messages
557 2012-10-02 20:55:52 <Diablo-D3> http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html
558 2012-10-02 20:56:05 <sipa> old news
559 2012-10-02 20:56:10 <sipa> we're already defining SHA-3.14159 here
560 2012-10-02 20:56:52 <jgarzik> Diablo-D3: we're prepping the April 1 announcement for bitcoin's switch to SHA-3
561 2012-10-02 20:57:04 <Diablo-D3> jgarzik: :D
562 2012-10-02 20:57:22 <D34TH> jgarzik, thats going to break the miners right?
563 2012-10-02 20:57:56 <Diablo-D3> D34TH: all of them
564 2012-10-02 20:57:59 <Diablo-D3> doubly so for asic
565 2012-10-02 20:58:02 <gmaxwell> sipa: I started on a joke SHA-3 submission but didn't bother finishing it and completing it.. that was called SHA-?? and it was a hash function based on using indexing into the hex expansion of PI as the inner strong one way function.
566 2012-10-02 20:58:06 <jgarzik> D34TH: yep
567 2012-10-02 20:58:16 <Diablo-D3> gmaxwell: wat
568 2012-10-02 20:58:27 <gmaxwell> I was trying to work it out so that there was a security proof related to the irrational of pi tht proved it secure... but I got stuck. :(
569 2012-10-02 20:58:38 <Diablo-D3> that'd be fucking hilarious
570 2012-10-02 20:58:52 <gmaxwell> (it was totally impratical as the cost of computing the hex expansion at offset x is linear in x.
571 2012-10-02 20:58:55 <gmaxwell> )
572 2012-10-02 20:59:42 <D34TH> jgarzik, Diablo-D3 : https://www.youtube.com/watch?feature=player_detailpage&v=vVof0qj7SOw#t=6s
573 2012-10-02 21:00:03 <D34TH> thats what I imagine the community will be like
574 2012-10-02 21:00:45 <sipa> gmaxwell: i actually once started designing an actual hash function, and i think it's decent myself; however, as i'm not a cryptoanalist, and never peer reviewed, i'd be stupid to think it's hard to attack :)
575 2012-10-02 21:01:25 <Diablo-D3> so what I should do now
576 2012-10-02 21:01:29 <Diablo-D3> is build a better crypto hash
577 2012-10-02 21:01:30 <Diablo-D3> FOR THE LULZ
578 2012-10-02 21:03:56 <Luke-Jr> something tells me D34TH doesn't understand the significance of April 1st
579 2012-10-02 21:04:17 <D34TH> i think it would be funny to do on april first though
580 2012-10-02 21:04:26 <D34TH> as it would seem like a joke
581 2012-10-02 21:04:29 <Diablo-D3> gmaxwell: actually, why don't hashes use fucking gigantic internal states?
582 2012-10-02 21:04:30 <D34TH> then the realization hits
583 2012-10-02 21:04:35 <D34TH> then the depression
584 2012-10-02 21:04:40 <Luke-Jr> Diablo-D3: scrypt is supposed to
585 2012-10-02 21:04:54 <gmaxwell> Diablo-D3: because memory is costly.
586 2012-10-02 21:05:15 <gmaxwell> And SHA-3 _does_ use a fairly large internal state.
587 2012-10-02 21:05:16 <Diablo-D3> gmaxwell: exactly.
588 2012-10-02 21:05:24 <Diablo-D3> sha3 isnt as big as um
589 2012-10-02 21:05:26 <gmaxwell> Diablo-D3: hashes aren't intended to be expensive.
590 2012-10-02 21:05:26 <sipa> Diablo-D3: hash functions are not actually designed to be slow or hard; key derivation is
591 2012-10-02 21:05:30 <Diablo-D3> shit, that one the alt coin uses that just goes apeshit
592 2012-10-02 21:05:41 <Luke-Jr> http://blog.ip.fi/2012/04/we-dont-understand-hashes.html
593 2012-10-02 21:05:51 <sipa> 200 bytes of internal state is a lot
594 2012-10-02 21:05:54 <gmaxwell> Hash != KDF != Hashcash.
595 2012-10-02 21:05:56 <Diablo-D3> sipa: yeah, but keccack is unsafe for pbdkf2
596 2012-10-02 21:06:02 <sipa> Diablo-D3: how so?
597 2012-10-02 21:06:10 <Diablo-D3> Im not sure, but apparently thats a thing.
598 2012-10-02 21:06:17 <sipa> it's certainly no less safe than SHA256
599 2012-10-02 21:06:21 <sipa> (afaik(
600 2012-10-02 21:06:23 <gmaxwell> Diablo-D3: well, not more than sha-2. You're wanting memory hard like scrypt.
601 2012-10-02 21:06:36 <Diablo-D3> gmaxwell: yeah, scrypt was what I was trying to think of
602 2012-10-02 21:06:54 <Eliel> D34TH: I don't think it would be possible to force a mining algorithm upgrade on people without a good reason to do so.
603 2012-10-02 21:07:13 <D34TH> true
604 2012-10-02 21:07:35 <Diablo-D3> jesus, Im looking at the keccak algo
605 2012-10-02 21:07:35 <sipa> the _only_ reason i would consider suggesting changing the PoW function, is when a serious vulnerability is found in SHA256
606 2012-10-02 21:07:37 <Diablo-D3> thats pretty nifty
607 2012-10-02 21:07:38 <gmaxwell> Eliel: s/without a good reason/unless bitcoin is dead unless its done/
608 2012-10-02 21:08:02 <Eliel> gmaxwell: yes, that's pretty much the only plausible reason to do so.
609 2012-10-02 21:08:03 <gmaxwell> sipa: most vulnerabilities wouldn't matter for _pow_ in any case. E.g. I don't know of any reason MD5 wouldn't be fine.
610 2012-10-02 21:08:14 <gmaxwell> for the hash trees and signatures; thats another matter.
611 2012-10-02 21:08:21 <sipa> gmaxwell: yes, it has to be a preimage attack
612 2012-10-02 21:08:29 <sipa> collision attacks are not significant for PoW
613 2012-10-02 21:08:41 <gmaxwell> With lower complexity than the difficulty!
614 2012-10-02 21:08:54 <Diablo-D3> why should hashes be fast, though?
615 2012-10-02 21:08:57 <Diablo-D3> what do we gain with that?
616 2012-10-02 21:09:02 <sipa> time
617 2012-10-02 21:09:03 <upb> lol
618 2012-10-02 21:09:18 <Diablo-D3> network and disk io is typically far slower than cpus
619 2012-10-02 21:09:25 <gmaxwell> Diablo-D3: because you can always make something slow by doing more of it. Not so much for fast. And it's important that the hashes are fast or block validation would be slow.
620 2012-10-02 21:09:42 <sipa> Diablo-D3: making a good hash function isn't hard (if you know how)
621 2012-10-02 21:09:45 <gmaxwell> e.g. consider the hash trees... N transactions means 2* the number of hash operations.
622 2012-10-02 21:09:49 <sipa> Diablo-D3: making a good fast hash function is
623 2012-10-02 21:11:34 <sipa> Diablo-D3: you're certainly right that in many application the hash speed is largely irrelevant
624 2012-10-02 21:13:25 <sipa> but in some cases it certainly is relevant (also its complexity to implement in a performant way in hardware matters), so if you can come up with two hash function of equal cryptographic strength, and A took a month to find but is slow, and B took 5 years to find but is 20% faster... after you spent (as a society) the research to find B, why wouldn't you use it?
625 2012-10-02 21:16:26 <Diablo-D3> so what we need is an algo that is fast and secure?
626 2012-10-02 21:18:05 <gmaxwell> secure isn't a single dimension either.
627 2012-10-02 21:19:17 <rejoin_> Hello all :)
628 2012-10-02 21:20:06 <rejoin_> Is it a good idea to run mining software on my workstation?
629 2012-10-02 21:21:41 <sipa> depends what hardware you'd mine with
630 2012-10-02 21:21:53 <rejoin_> ...laptop
631 2012-10-02 21:22:00 <gmaxwell> rejoin_: if you're interested in mining, sure. Depending on your workstation it might not make more in coins than the power to run it costs you though.
632 2012-10-02 21:22:09 <gmaxwell> and on a laptop I'd generally recommend against it...
633 2012-10-02 21:22:23 <sipa> rejoin_: unless you have an FPGA or a high-end ATI graphics hard, don't
634 2012-10-02 21:22:32 <gmaxwell> just because many laptops don't actually like being run at full load 24/7 and it may cause earlier hardware failure.
635 2012-10-02 21:22:43 <rejoin_> Makes sense :)
636 2012-10-02 21:23:25 <rejoin_> When I first found out about bitcoin, my machine was too slow... 2 years later with a new machine, still.
637 2012-10-02 22:19:49 <jrmithdobbs> so, we have sha3 now
638 2012-10-02 22:20:20 <jrmithdobbs> and of course they picked one of the ones i haven't had a chance to even look at. was so hoping it'd be blake or skein. I like those. ;p
639 2012-10-02 22:23:00 <jgarzik> jrmithdobbs: don't look at keccak code, your eyes will bleed
640 2012-10-02 22:23:36 <jrmithdobbs> jgarzik: ya that's why i liked blake and skein, they were simple, elegant, and easy as fuck to implement (with good implementations already availabe)
641 2012-10-02 22:25:51 <jrmithdobbs> jgarzik: is it at least unencumbered IP-law-wise?
642 2012-10-02 22:26:00 <jrmithdobbs> or'd they fuck us on that too
643 2012-10-02 22:26:16 <gmaxwell> meh, dunno about the code; but it's quite simple.
644 2012-10-02 22:26:32 <jgarzik> jrmithdobbs: dunno
645 2012-10-02 22:26:46 <jrmithdobbs> i'm pulling up the paper now, looking for their sample impl
646 2012-10-02 22:26:52 <jgarzik> jrmithdobbs: presumably the IP is OK, otherwise there would be holy hell raised I think
647 2012-10-02 22:27:07 <jgarzik> but one doesn't bet the farm on presumption ;p
648 2012-10-02 22:27:48 <gmaxwell> all applicants had to agree to a patent release at least.
649 2012-10-02 22:27:48 <jgarzik> jrmithdobbs: their website points to a _third party_ implementation that is readable and reviewable, because their version is not
650 2012-10-02 22:27:55 <jrmithdobbs> ya, only ones i remember coming from places that there were pretty good guarantees were blake (salsa based and we all know djb's feeling on the topic) and skein (because same for schneier)
651 2012-10-02 22:28:16 <gmaxwell> (and it was a requirement that it be unencumbered; so the opposition would have called out any that were known to be)
652 2012-10-02 22:32:00 <jrmithdobbs> jgarzik: where? I'm not seeing it
653 2012-10-02 22:32:14 <jrmithdobbs> oh nm just scrolled far enough to see it
654 2012-10-02 22:33:14 <jrmithdobbs> ugh, not even a hash or https link to that download either, how thoughtful