1 2014-07-16 03:02:49 <earlz> What can you use to spend a non-standard input, such as a puzzle?
2 2014-07-16 03:08:45 <poutine> earlz, what?
3 2014-07-16 03:09:51 <shesek> earlz, iirc, eligius accepts non-standard transactions
4 2014-07-16 03:10:13 <shesek> you can use http://eligius.st/~wizkid057/newstats/pushtxn.php to get the transaction mined
5 2014-07-16 03:10:49 <jrick> pretty sure he means to spend it, to make and send a tx that uses it as one of of the txin
6 2014-07-16 03:11:37 <dgenr8> sipa: here?
7 2014-07-16 03:13:19 <dgenr8> sipa: you'll like this one
8 2014-07-16 03:13:29 <earlz> shesek: thanks
9 2014-07-16 03:14:16 <earlz> I assume I'd have to construct the transaction myself using one of the serivces for that
10 2014-07-16 03:14:35 <poutine> I construct my raw nonstandard transactions with bitcoinjs-lib, but there's a number of ways
11 2014-07-16 03:15:26 <jrick> earlz: there are libraries you can use to create the script
12 2014-07-16 03:15:38 <earlz> yea, I've been trying to figure out a good way to go about doing that. For that service to get it mined, I assume there is a significant delay due to the mining pool being smaller?
13 2014-07-16 03:15:49 <shesek> though, if he's doing something that's really non-standard, it might be easier doing that by hand
14 2014-07-16 03:15:57 <poutine> earlz, look at the block performance at eligius.st
15 2014-07-16 03:15:59 <earlz> I'm still wrapping my head around all that heh
16 2014-07-16 03:16:01 <jrick> earlz: e.g. http://godoc.org/github.com/conformal/btcscript#ScriptBuilder
17 2014-07-16 03:16:04 <poutine> I've had it take up to 6 hours for my stuff to get picked up
18 2014-07-16 03:16:17 <earlz> 6 hours isn't bad. I was expected days
19 2014-07-16 03:16:25 <shesek> earlz, they have about 6% of the hashpower
20 2014-07-16 03:16:52 <poutine> https://blockchain.info/tx/219b5815886af9c9ff74fdbe8146731534b0c1b1dc23bfd3fab81745433bbc3f?show_adv=true
21 2014-07-16 03:16:58 <earlz> Also, on the hardfork wish list, there is this "Scripts should be fully enabled after a careful audit." does that mean treat all transactions as standard and relayable that follow signature and size limits?
22 2014-07-16 03:17:18 <shesek> earlz, so it should take about 16 blocks on average, or about 2.5 hours
23 2014-07-16 03:17:39 <shesek> (on average, yes? the variance should be quite large)
24 2014-07-16 03:17:54 <earlz> yea, that's not bad at all. I assume standard transaction fees apply? Or does it allow free ones?
25 2014-07-16 03:18:51 <poutine> no, and if you submit with 0 fee, don't expect it to ever get mined
26 2014-07-16 03:19:24 <earlz> I expected that heh
27 2014-07-16 03:19:51 <earlz> So, for my other question, what does "Scripts should be fully enabled after a careful audit." mean?
28 2014-07-16 03:20:03 <earlz> on the bitcoin wiki's hardfork wishlist
29 2014-07-16 03:20:27 <shesek> poutine, I'm not so sure about that... if you're using aged outputs as your inputs and your output are large enough, it might get mined even if its non-standard
30 2014-07-16 03:20:54 <shesek> I'm not sure how eligius behaves exactly, but it might allow that
31 2014-07-16 03:22:06 <poutine> shesek, I've had transactions sit in limbo for months, I can't speak on age of output or anything like that, but I do believe they post their fee policy
32 2014-07-16 03:22:26 <poutine> in any event venturing a bit past dev talk so I'll stop
33 2014-07-16 03:22:30 <shesek> non-standard ones?
34 2014-07-16 03:22:47 <shesek> I've had plenty of standard ones mined without fees
35 2014-07-16 03:22:54 <poutine> yes non-standard
36 2014-07-16 03:23:59 <earlz> what is the big fear around allowing all transactions to be relayed as standard? I'd think that if an exploit existed, it'd have been done by now
37 2014-07-16 03:37:00 <earlz> hmmm.. only possible exploit I see that could happen is denial of service on nodes with a malicious non-standard tx... but eh, I'm not seeing how that'd happen in relay code without happening when parsing the block as well
38 2014-07-16 03:41:44 <gmaxwell> earlz: relaying all transactions would agressively break forwards compatibility when people started putting random garbage in places that are reserved for forward compatibility.
39 2014-07-16 03:42:04 <gmaxwell> Also a DOS attack which is only available to miners is far less of a concern.
40 2014-07-16 03:42:37 <Luke-Jr> [03:16:58] <earlz> Also, on the hardfork wish list, there is this "Scripts should be fully enabled after a careful audit." does that mean treat all transactions as standard and relayable that follow signature and size limits? <-- this refers to opcodes that are missing in Bitcoin Script today
41 2014-07-16 03:42:46 <earlz> ah I see
42 2014-07-16 03:43:07 <gmaxwell> also the idea that DOS attacks are prevented by the consumption of fees does not work if the transaction will never be mined... so if relay is too disjoint with mining thats bad too.
43 2014-07-16 03:43:09 <earlz> I was also wondering why so many trivial sounding opcodes were disabled
44 2014-07-16 03:43:11 <Luke-Jr> particularly ones that Satoshi removed in like 0.3.2
45 2014-07-16 03:43:44 <gmaxwell> earlz: because they were remotely exploitable vulnerabilties.
46 2014-07-16 03:44:03 <gmaxwell> (in fact, I now thing that every single disabled one was actually explotable, though I'd have to go check carefully to be sure)
47 2014-07-16 03:44:24 <gmaxwell> (mostly thanks to out of control memory usage possible due to the bignums)
48 2014-07-16 03:44:33 <earlz> things like multiplication even? idk maybe I just haven't read enough into it so see the exploits of those opcodes
49 2014-07-16 03:45:00 <gmaxwell> earlz: yea, see this is why woring on this stuff is dangerous.
50 2014-07-16 03:45:39 <earlz> I like that P2SH is finally standard in master :)
51 2014-07-16 03:46:38 <gmaxwell> it's been standard since it was introduced.
52 2014-07-16 03:46:44 <earlz> Is there any plans to ever allow things like puzzles to be relayed as standard, or is that just considered as not belonging on the network?
53 2014-07-16 03:47:03 <earlz> Well, bigger than 520 bytes(?) or whatever
54 2014-07-16 03:47:10 <gmaxwell> PUSH_520_bytes OP_DUP OP_MUL OP_DUP OP_MUL [OP_DUP OP_MUL]*95 ... now every node is using 17867063951360 exobytes of ram.
55 2014-07-16 03:47:44 <gmaxwell> earlz: a P2SH redeem script cannot be >520 bytes (no push can be)
56 2014-07-16 03:47:57 <earlz> yea I see your point. I imagine you'd have to construct things in some VM-ish thing with strict resource cotnrols or something
57 2014-07-16 03:48:19 <gmaxwell> earlz: well thats what script already is, but the bignums used in the now disabled opcodes violated that.
58 2014-07-16 03:48:20 <andytoshi> ...and they'd have to be exactly the same resource controls for every node ever
59 2014-07-16 03:49:04 <earlz> yea tough to maintain consensus across so many different platforms, not to mention the possibility of people using non-reference clients
60 2014-07-16 03:49:39 <earlz> So, how do you redeem a p2sh multisig, with say 5 signatures required?
61 2014-07-16 03:50:00 <gmaxwell> the limit is on the redeemscript not on the signatures.
62 2014-07-16 03:50:01 <shesek> earlz, this is, in fact, a standard transaction
63 2014-07-16 03:50:44 <earlz> ah forgot about redeem/signatures being separate. sorry
64 2014-07-16 03:52:34 <earlz> So, maybe I'm not understanding this then ugh
65 2014-07-16 03:52:58 <earlz> what is an "input script" anyway in this case?
66 2014-07-16 03:54:06 <poutine> an input script prepended to a referenced tx's output script has to equal OP_TRUE for the tx to be valid
67 2014-07-16 03:55:01 <earlz> So, in a standard transaction what would the input script be? I thought it'd be a signature, but that doesn't appear to be true
68 2014-07-16 03:55:11 <earlz> well wait, it'd be the public key maybe?
69 2014-07-16 03:56:38 <sipa> dgenr8: yes?
70 2014-07-16 03:57:35 <earlz> are there any good resources that explain all this? The wiki explains some of the technical details, but is a bit lacking as to how it all ties together and how you'd construct transactions on your own
71 2014-07-16 03:58:48 <sipa> earlz: the output script is the condition you must satisfy to spend that output
72 2014-07-16 03:59:12 <sipa> earlz: the input script contains the data to feed to an output script to make it evaluate to true
73 2014-07-16 04:00:19 <earlz> so in a standard transaction, the input would be the public key of the spender, correct? But then what goes into the input for multisig is what I'm having trouble with
74 2014-07-16 04:01:41 <sipa> in a standard transaction, the hash of the public key goes in the output (requiring a pubkey and a signature, the signature validnfor that pubkey, and the hash of the pubkey equal to that know value), the input contains the actual full public key andnsignature
75 2014-07-16 04:02:14 <shesek> earlz, if its P2SH, then its `OP_0 {signatures...} {multisigScript}`
76 2014-07-16 04:02:32 <shesek> multisigScript being `m {pubkeys...} n OP_CHECKMULTISIG`
77 2014-07-16 04:02:59 <poutine> https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L303-969 <- Good reading for how scripts work
78 2014-07-16 04:03:19 <earlz> need a Script For Dummies book lol
79 2014-07-16 04:04:09 <earlz> If inputscripts are limited to 520 bytes, I'm not seeing how you can provide everything to spend it
80 2014-07-16 04:04:16 <earlz> for a larger multisig
81 2014-07-16 04:04:38 <sipa> individual data elements are limited to 520 bytes
82 2014-07-16 04:04:46 <sipa> not the entire script
83 2014-07-16 04:05:47 <shesek> the redeemScript becomes an individual data element when you're using p2sh, so that is limited to 520 bytes
84 2014-07-16 04:06:10 <shesek> but the signatures aren't included in that and are pushed as separate elements
85 2014-07-16 04:06:12 <sipa> but the redeemscript only contains the public keys
86 2014-07-16 04:06:24 <earlz> so confusing ugh
87 2014-07-16 04:06:37 <sipa> which are 34 bytes per push with compressed pubkeys
88 2014-07-16 09:25:47 <jcorgan> wumpus: iwilcox: both getrawtransactino and searchrawtransactions are working with headersfirst+txindex+addrindex, except the config options are not being read correctly
89 2014-07-16 09:26:40 <iwilcox> jcorgan: Cool, well, get some sleep :)
90 2014-07-16 09:27:16 <jcorgan> as i mentioned in #bitcoin, i had to turn on fAddrIndex and fTxIndex in main.cpp as defaulting to true, as it is ignoring the config file txindex=1 or cli -txindex (same for addrindex)
91 2014-07-16 09:27:25 <iwilcox> My node is still c r a w l i n g through bootstrap.dat anyway so it'll probably be a day before I can try your workaround.
92 2014-07-16 09:28:12 <shesek> was addrindex merged eventually? I had the impression it was abandoned in favor of watchonly
93 2014-07-16 09:28:34 <iwilcox> Not merged, but I wouldn't try h-f unless I could keep addrindex
94 2014-07-16 09:28:45 <jcorgan> no, it was (and may never be) merged, but I've maintained the patch fresh against current master and am testing headersfirst with it
95 2014-07-16 09:28:51 <jcorgan> it wasn't
96 2014-07-16 09:29:54 <shesek> I see. thanks for the clarification
97 2014-07-16 09:29:59 <wumpus> addrindex will likely never be merged, but jcorgan is maintaining it anyway
98 2014-07-16 09:30:10 <jcorgan> :)
99 2014-07-16 09:30:32 <wumpus> at some point bitcoind should be modular enough that it can just be plugged in...
100 2014-07-16 09:31:26 <jcorgan> perhaps one day. i find it very useful for some work i'm doing, maintaining the patch privately isn't much work.
101 2014-07-16 09:32:27 <jcorgan> wumpus, i'll test headersfirst without the addrindex patch to see if it still has issues with txindex=1 in the config file
102 2014-07-16 09:33:06 <wumpus> jcorgan: nah, if it's just an argument parsing problem it shouldn't be too hard to figure out why it's going wrong
103 2014-07-16 13:04:03 <jrick> hearn: I was looking for other examples of serializing a dynamic_bitset but didn't see any. Do you think the bip should specify the order in that case? (so is a single true 0x01 or 0x80?)
104 2014-07-16 13:05:19 <jrick> also, ordering with > 8 elements
105 2014-07-16 13:11:41 <hearn> yes, probably. good point. the protocol is a weird mix of different endiannesses
106 2014-07-16 13:11:50 <hearn> so it's not really obvious
107 2014-07-16 13:11:56 <hearn> thanks for the review jrick
108 2014-07-16 13:21:00 <jrick> sure np. can't say I'm thrilled from the proposed feature (because of the authentication issues) but if it does go in, hopefully the code and bip both make sense
109 2014-07-16 13:23:04 <maaku> jrick: absolutely
110 2014-07-16 13:23:09 <maaku> also see my hashtree branch
111 2014-07-16 13:23:22 <maaku> which has a dynamic_bitset serializer for the utxo stuff
112 2014-07-16 13:23:37 <maaku> jrick: what's the context for what you are doing?
113 2014-07-16 13:24:25 <jrick> gmaxwell had asked us (btcd guys) for input on the getutxos stuff
114 2014-07-16 13:24:49 <maaku> https://github.com/maaku/bitcoin/blob/hashmap/src/hash_map.h#L143
115 2014-07-16 13:25:40 <maaku> a single true should be 0x01 fwiw
116 2014-07-16 13:26:04 <jtimon> maybe some input from libbitcoin/darkwallet would be useful too
117 2014-07-16 13:27:17 <maaku> iirc i had to do some bit-order swaps though in order to get things "right" when working with a dynamic_bitset
118 2014-07-16 13:34:01 <maaku> for future additions, check_mempool should probably be a flags field with bits 2-8 reserved (write zero, ignore on read)
119 2014-07-16 13:35:25 <maaku> maybe the mempool height sentinal value should be zero?
120 2014-07-16 13:44:49 <jrick> ACTION wipes eyes of c++
121 2014-07-16 14:04:01 <maaku> ACTION hands jrick a haskell tissue
122 2014-07-16 14:15:07 <hearn> wumpus: what's the plan with the pull tester?
123 2014-07-16 14:15:36 <wumpus> hearn: it's going to be replaced with Travis
124 2014-07-16 14:15:51 <hearn> presumably the tests it run will remain the same however?
125 2014-07-16 14:15:57 <wumpus> yes
126 2014-07-16 14:16:00 <hearn> ok
127 2014-07-16 14:16:14 <hearn> so it's just the "poll for changes/rebuild/rerun the tests" part that'd be replaced
128 2014-07-16 14:16:54 <wumpus> although it will do so with the same build environment as for gitian
129 2014-07-16 14:17:02 <wumpus> yes
130 2014-07-16 14:17:48 <wumpus> unless you think it makes sense to run other tests, I'm sure that can be changed too, but the tests themselves are pretty good (apart from a timeout issue here and there)
131 2014-07-16 14:20:18 <wumpus> also,AFAIK travis can run tests on OSX, so it adds one more environment
132 2014-07-16 14:20:29 <sipa> ooh nice
133 2014-07-16 14:21:13 <hearn> no that sounds good. i'll probably add getutxo tests to the pull tester. i'm not sure how to upgrade it to the latest bitcoinj code though
134 2014-07-16 14:21:18 <hearn> i actually know very little about how that works
135 2014-07-16 14:23:12 <sipa> i've been using the jar that BlueMatt put on a site, but i would sort of like to know how to build it myself :)
136 2014-07-16 14:23:56 <BlueMatt> hearn: does it not build these days?
137 2014-07-16 14:24:33 <BlueMatt> sipa: it should be just 1. import bitcoinj into your favorite java dev environment 2. click buil runnable jar 3. select BitcoindComparisonTool 4. profit
138 2014-07-16 14:24:49 <BlueMatt> i'm not sure that i ever wrote a mvn script for it
139 2014-07-16 14:24:58 <BlueMatt> but you could probably do that easily too by changing the default class
140 2014-07-16 14:25:03 <hearn> BlueMatt: what i mean is, i don't know where it runs or how to upgrade it etc. the bitcoinj parts i understand
141 2014-07-16 14:25:10 <sipa> BlueMatt: i haven't opened a java dev environment in 10 years
142 2014-07-16 14:25:39 <BlueMatt> hearn: didnt it get thrown in the bitcoinj repo at some point?
143 2014-07-16 14:25:45 <BlueMatt> or did it end up in bitcoind's repo?
144 2014-07-16 14:25:51 <hearn> BlueMatt: the tool is there, sure.
145 2014-07-16 14:26:01 <hearn> BlueMatt: but obviously it runs somewhere, someone has access to it, there are scripts involved etc
146 2014-07-16 14:26:15 <BlueMatt> hearn: its just a single main class to run
147 2014-07-16 14:26:19 <sipa> sure, it runs on our devserver, the jar can be updated
148 2014-07-16 14:26:32 <hearn> ok, you have access to it sipa?
149 2014-07-16 14:26:38 <BlueMatt> hearn: if you go in intellij or whatever and tell it to run BitcoindComparisonTool as the main class you can get the jar
150 2014-07-16 14:26:39 <gmaxwell> so does BlueMatt
151 2014-07-16 14:26:42 <sipa> yes
152 2014-07-16 14:26:44 <sipa> indeed
153 2014-07-16 14:26:47 <BlueMatt> then ./configure --with-comparison-tool=path/to/jar
154 2014-07-16 14:26:50 <BlueMatt> and make check
155 2014-07-16 14:27:03 <hearn> right but BlueMatt has been busy with university and so on. good to know i can bug sipa to upgrade it :)
156 2014-07-16 14:27:07 <hearn> producing a new jar isn't very hard
157 2014-07-16 14:27:08 <sipa> and gavin and wumpus too afaik
158 2014-07-16 14:27:11 <BlueMatt> hearn: I'm out now :)
159 2014-07-16 14:27:16 <hearn> yay. party time :)
160 2014-07-16 14:27:19 <BlueMatt> (and working on bitcoin full time-ish in a week or so)
161 2014-07-16 14:27:22 <BlueMatt> no, that was the last month
162 2014-07-16 14:27:30 <hearn> yes ...... party time! :)
163 2014-07-16 14:27:37 <BlueMatt> ACTION just finished up about a month of roadtrips with a gf
164 2014-07-16 14:27:41 <hearn> ooh
165 2014-07-16 14:27:49 <sipa> galois fields are always fun
166 2014-07-16 14:27:50 <daybyter> ACTION likes java
167 2014-07-16 14:28:03 <hearn> like, cruising along an interstate wearing shades, listening to rock in an open top car?
168 2014-07-16 14:28:11 <hearn> then stopping at a motel and watching an elvis impersonator?
169 2014-07-16 14:28:22 <BlueMatt> hearn: actually, thats incredibly accurate
170 2014-07-16 14:28:36 <BlueMatt> red convertible, specifically
171 2014-07-16 14:29:17 <hearn> for some reason the term road trip always makes me think of this photo: http://i1.ytimg.com/vi/OVRn7-JXnvA/maxresdefault.jpg
172 2014-07-16 14:29:40 <iwilcox> BlueMatt: Full time? That foundation-funded post with Gavin, or something else?
173 2014-07-16 14:30:02 <BlueMatt> iwilcox: well, full-time-ish
174 2014-07-16 14:31:11 <drizztbsd> https://pbs.twimg.com/media/Bsh1NteCAAAUzz7.jpg:large
175 2014-07-16 14:31:15 <hearn> he means full time when it's not party time
176 2014-07-16 14:31:47 <BlueMatt> https://plus.google.com/photos/104449506075868014180/albums/6036667030428252177/6036667030237945074?pid=6036667030237945074&oid=104449506075868014180
177 2014-07-16 14:32:32 <hearn> that's pretty damn road trippy
178 2014-07-16 14:33:43 <hearn> BlueMatt: i got you beat though
179 2014-07-16 14:33:44 <hearn> BlueMatt: https://plus.google.com/u/0/114798402540078632611/posts/Czzghp2Eji7
180 2014-07-16 14:33:50 <hearn> that was my office this morning
181 2014-07-16 14:34:11 <BlueMatt> I'll beat you...I'm working out of hawaii next week
182 2014-07-16 14:34:56 <hearn> i'll get back to you when i find a suitable retort
183 2014-07-16 14:35:07 <BlueMatt> :p
184 2014-07-16 14:41:15 <wumpus> the weather is almost Hawai here right now
185 2014-07-16 14:43:56 <ahmed_> anyone here run eloipool or use jgarzik's python-bitcoinrpc lib?
186 2014-07-16 14:46:40 <hearn> BlueMatt: turns out the pull tester no longer works, at least not for me :(
187 2014-07-16 14:46:41 <wumpus> lots of people do, better to just ask your question
188 2014-07-16 14:46:44 <hearn> seems bitcoind disconnects when it shouldn't
189 2014-07-16 14:47:04 <BlueMatt> hearn: are you running with the extra blocks thing? thats a known bug
190 2014-07-16 14:47:11 <BlueMatt> with that option disabled it should pass?
191 2014-07-16 14:47:15 <hearn> i'm not running with anything, just the default arguments
192 2014-07-16 14:47:26 <BlueMatt> hmm, where did it fail?
193 2014-07-16 14:47:30 <BlueMatt> b1001 or related blocks?
194 2014-07-16 14:47:41 <hearn> after b7
195 2014-07-16 14:47:43 <ahmed_> wumpus: trying to run eloipool and for some reason i cant seem to get it to run.
196 2014-07-16 14:47:45 <BlueMatt> :(
197 2014-07-16 14:47:49 <ahmed_> just end up with this error:
198 2014-07-16 14:47:50 <sipa> hearn: which code?
199 2014-07-16 14:48:03 <sipa> which commit, i mean
200 2014-07-16 14:48:10 <ahmed_> File "/usr/lib/python3.4/http/client.py", line 1093, in _send_request
201 2014-07-16 14:48:10 <ahmed_> File "/usr/lib/python3.4/http/client.py", line 948, in putrequest
202 2014-07-16 14:48:10 <ahmed_> http.client.CannotSendRequest: Request-sent
203 2014-07-16 14:48:10 <ahmed_> raise CannotSendRequest(self.__state)
204 2014-07-16 14:48:10 <ahmed_> self.putrequest(method, url, **skips)
205 2014-07-16 14:48:39 <hearn> current head
206 2014-07-16 14:48:46 <ahmed_> dir
207 2014-07-16 14:49:21 <hearn> i think the problem is that local nodes are now being disconnected if they do a protocol violation, not just "not banned"
208 2014-07-16 14:49:48 <hearn> pull tester does not expect to be disconnected
209 2014-07-16 14:49:56 <ahmed_> wumpus: i can connect via curl and also by running a local bitcoind and using rpcconnect just fine
210 2014-07-16 14:50:03 <sipa> the pulltester script sets whitelisting for localhost
211 2014-07-16 14:50:17 <hearn> ah
212 2014-07-16 14:50:18 <sipa> so it shouldn't disconnect for protocol violations
213 2014-07-16 14:50:26 <hearn> where is the pulltester script?
214 2014-07-16 14:50:39 <sipa> ?
215 2014-07-16 14:50:46 <sipa> in qa/... something
216 2014-07-16 14:50:57 <sipa> but it's all automatic, it should use that when you do make check
217 2014-07-16 14:52:31 <hearn> ah i see. didn't realise it was all so integrated now. though i do not have mingw setup. anyway, will use the script to run bitcoind
218 2014-07-16 15:05:22 <hearn> ACTION gets the feeling nobody bothers to read what he writes sometimes
219 2014-07-16 15:06:19 <wumpus> hearn: how's that?
220 2014-07-16 15:42:56 <jcorgan> wumpus: is there a write up of how headersfirst is supposed to work? also, i seem unable to recreate the config problems i was seeing earlier.
221 2014-07-16 15:43:25 <sipa> jcorgan: i can tell you how the current implementation works...
222 2014-07-16 15:43:38 <jcorgan> sure, thanks.
223 2014-07-16 15:44:32 <sipa> i'll try to do some writeup once it gets merged (which is sort of blocked by pulltester needing significant changes before it can deal with it...)
224 2014-07-16 15:44:53 <jcorgan> i'm testing the branch here, all seems well, but i don't know all the new behaviors i'm supposed to be seeing
225 2014-07-16 15:45:33 <sipa> so in terms of expected behaviour
226 2014-07-16 15:45:53 <sipa> as long as it's catching up headers, it should only be fetching blocks from a single peer
227 2014-07-16 15:46:18 <sipa> which should take at most ~minutes
228 2014-07-16 15:46:27 <sipa> during which you'll see a lot of retarget messages
229 2014-07-16 15:48:55 <jcorgan> i have addnode'd a local fast peer, so the getheaders looks like it completed in ~30 sec
230 2014-07-16 15:48:58 <sipa> afterwards fetching should happen from multiple peers in parallel
231 2014-07-16 15:49:23 <sipa> ideally all peers are approximately the same order of magnitude in bandwidth/throughput
232 2014-07-16 15:49:56 <jcorgan> i can see the parallel downloads, nice, will have to do some getpeerinfo's to check bandwidth
233 2014-07-16 15:51:42 <jcorgan> looks like i have 8 connections, each with 16 "inflight" blocks
234 2014-07-16 15:52:02 <sipa> there's a limit of 16 per peer afaik
235 2014-07-16 15:55:34 <jcorgan> so what does having the headers in the first few minutes actually enable?
236 2014-07-16 15:56:02 <sipa> knowing what to download
237 2014-07-16 15:56:16 <sipa> and having verified the PoW already for it, so there's much less DoS risk
238 2014-07-16 15:56:34 <sipa> currently we just have to ask peers to give us what we have - we don't know what they have in advance
239 2014-07-16 15:56:35 <jcorgan> got it
240 2014-07-16 15:57:07 <jcorgan> working great so far
241 2014-07-16 15:57:23 <jcorgan> and fyi, it even works with addrindex :)
242 2014-07-16 15:57:34 <sipa> i wouldn't expect it not to
243 2014-07-16 15:58:14 <jcorgan> the headersfirst changeset is surprisingly small
244 2014-07-16 15:58:33 <sipa> that's because it's the 10th pullrequest :)
245 2014-07-16 15:58:38 <sipa> most logic went in before
246 2014-07-16 15:59:40 <jcorgan> i was having a problem earlier getting txindex and addrindex turned on, but i'm convinced now it was sleep-deprived operator error
247 2014-07-16 16:00:22 <jcorgan> fixed the sleep part, now it is working
248 2014-07-16 16:20:17 <ahmed_> anyone with any ideas?
249 2014-07-16 21:19:40 <jgarzik> Bundesbank PPP paper on bitcoin, http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2461588
250 2014-07-16 22:34:43 <opencryptoreview> Hi all, I've made a new site that allows disscussion on published, yet to be published or semi formal papers. I posted the link to /r/bitoin but haven't gotten any contributors yet. Is anyone here interested in something like this? You can post anything you want and crit it. www.opencryptoreview.com
251 2014-07-16 22:36:58 <opencryptoreview> This is a topic that interests me greatly. If someone has a particular opinion about this, it would be great to get your opinion here: http://www.opencryptoreview.com/papers/70/near-zero-bitcoin-transaction-fees-cannot-last-forever
252 2014-07-16 22:39:12 <gmaxwell> 2010 wants their headline back? transaction fees on average have not been near zero for a long time. :)
253 2014-07-16 22:39:25 <gmaxwell> opencryptoreview: sounds like a useful site.
254 2014-07-16 22:43:11 <andytoshi> opencryptoreview: cool site, i'll check it out and maybe crosspost a few things from bitcoin.ninja
255 2014-07-16 22:45:33 <andytoshi> opencryptoreview: any plans to support openid?
256 2014-07-16 22:48:27 <justanotheruser> opencryptoreview: I wish I didn't have to log in to comment
257 2014-07-16 22:48:30 <justanotheruser> good website though
258 2014-07-16 22:50:35 <opencryptoreview> I had support for openID but removed it
259 2014-07-16 22:51:22 <opencryptoreview> do you think I should put it back?
260 2014-07-16 22:51:42 <andytoshi> i think so, launchpad and stackexchange use it
261 2014-07-16 22:54:06 <opencryptoreview> andytoshi: ok, I will look at putting it back
262 2014-07-16 22:54:38 <opencryptoreview> andytoshi: what is bitcoin.ninja? google wasn't kind to me
263 2014-07-16 22:55:07 <andytoshi> opencryptoreview: bitcoin.ninja is the URL :)
264 2014-07-16 22:56:55 <opencryptoreview> andytoshi: ahh I see. that POS article would be something great to discuss as many people say it's insecure but most ignore that advice.
265 2014-07-16 22:57:18 <andytoshi> yeah, i'm adding an abstract and fixing the citations now..
266 2014-07-16 22:57:51 <iwilcox> sipa: Is there a technical limitation that prevents parallel sync of blocks in the first few seconds of h-f sync, or is it just low priority making that stage parallel too?
267 2014-07-16 22:59:15 <sipa> iwilcox: it would imply fethching all headers from everyone
268 2014-07-16 22:59:28 <opencryptoreview> andytoshi: is it your article? and is bitcoin.ninja your site?
269 2014-07-16 22:59:46 <sipa> iwilcox: or at least, nontrivial to avoid
270 2014-07-16 23:00:18 <andytoshi> opencryptoreview: the POS article is mine. bitcoin.ninja is BlueMatt's site
271 2014-07-16 23:00:41 <iwilcox> sipa: I suspect what's tripping me up here is insufficient understanding of the wire protocol
272 2014-07-16 23:01:13 <sipa> well to start fetching blocks from peers, you need to know what blovks they havr
273 2014-07-16 23:01:19 <sipa> blocks, have
274 2014-07-16 23:01:26 <opencryptoreview> andytoshi: ok great, so I guess you could post it on opencryptoreview and then ping people you rate to provide some feedback
275 2014-07-16 23:01:38 <sipa> if you're only learning about those headers yourself, that's harder
276 2014-07-16 23:02:02 <opencryptoreview> andytoshi: would something like that be useful for you?
277 2014-07-16 23:02:03 <sipa> you could periodicially poll peers, so see if they know about block X you've just learned about
278 2014-07-16 23:02:32 <sipa> my implementation now just wait until we've come reasonably close in prpcessing headers from one peer
279 2014-07-16 23:02:39 <iwilcox> sipa: So how did you learn about block X? By asking a peer based on height?
280 2014-07-16 23:02:50 <sipa> there is no height based indexing
281 2014-07-16 23:03:08 <sipa> you just ask peers "what headers do you have following block X"
282 2014-07-16 23:03:12 <andytoshi> opencryptoreview: yeah, a review site would be really great. current strategy is "post on IRC asking for comments repeatedly"
283 2014-07-16 23:03:27 <andytoshi> opencryptoreview: we should move this discussion to #bitcoin-wizards, it is not on topic here
284 2014-07-16 23:03:40 <sipa> agree
285 2014-07-16 23:03:45 <iwilcox> sipa: Including in the non-h-f sync case?
286 2014-07-16 23:04:07 <opencryptoreview> andytoshi: ok, my bad, what is bitcoin-wizards?
287 2014-07-16 23:04:13 <sipa> iwilcox: yes, though currently we just ask for hashes rather than full headers
288 2014-07-16 23:04:23 <andytoshi> opencryptoreview: /join #bitcoin-wizards it is the channel next door
289 2014-07-16 23:05:02 <iwilcox> sipa: And then all block requests are done by hash from then on, yeah?
290 2014-07-16 23:05:09 <sipa> yup
291 2014-07-16 23:06:22 <iwilcox> Sorry to make noise with basic questions; just think it'd be more useful to try h-f already knowing these basics, so I can picture what's going on when it's working (or broken)
292 2014-07-16 23:06:59 <sipa> feel free to ask
293 2014-07-16 23:07:18 <jgarzik> grrrrr
294 2014-07-16 23:07:26 <jgarzik> suddenly bitcoin-tx utility needs uiInterface
295 2014-07-16 23:07:47 <sipa> why?
296 2014-07-16 23:07:55 <jcorgan> fyi, full headersfirst sync from fast local node and 7 remote nodes was ~100 mins
297 2014-07-16 23:07:56 <sipa> it shouldn't..
298 2014-07-16 23:08:05 <sipa> jcorgan: nice
299 2014-07-16 23:08:55 <sipa> jgarzik: oh, you're including main.h i see
300 2014-07-16 23:09:00 <sipa> that feels wrong...
301 2014-07-16 23:09:36 <sipa> some of the constants relating to core data structures can probably move to core.h
302 2014-07-16 23:10:36 <sipa> jcorgan: that'_s the lowest number i've seen i think
303 2014-07-16 23:11:47 <jcorgan> well, the local node is over GbE, and .bitcoin is on RAID5 :)
304 2014-07-16 23:12:20 <jcorgan> i'll do it again without the local node, and also try it on an EC2 instance
305 2014-07-16 23:13:30 <jcorgan> but the log does show constant activity from all the peers, not the just the local one
306 2014-07-16 23:13:51 <jgarzik> sipa, need main.h for MAX_BLOCK_SIZE
307 2014-07-16 23:14:07 <jgarzik> sipa, but I can strip out the _("...") to get rid of ui_interface.h
308 2014-07-16 23:14:19 <jgarzik> sipa, Just odd. It builds w/ Qt just fine locally, but pulltester dislikes.
309 2014-07-16 23:16:20 <jgarzik> odd
310 2014-07-16 23:16:35 <jgarzik> bitcoin-cli gets along just fine without noui
311 2014-07-16 23:20:42 <kazcw> jgarzik: pulltester has been failing a lot today, in one build it said /tmp ran out of space (pinging BlueMatt), so try repushing with a new timestamp before any extensive debugging
312 2014-07-16 23:27:39 <BlueMatt> sipa: gavinandresen wumpus can someone fix this? my access to the server appears to be borked
313 2014-07-16 23:37:53 <jgarzik> ah, sneaky auto-merge thing
314 2014-07-16 23:38:09 <jgarzik> uiInterface got moved. robot merged to upstream master, and build broke.