1 2015-01-23 00:28:31 <Luke-Jr> got it again
2 2015-01-23 02:28:17 <Luke-Jr> everyone's afk tonight?
3 2015-01-23 02:29:38 <gmaxwell> I'm just back now.
4 2015-01-23 02:30:47 <sipa> michagogo: libsecp256k1 doesn't do batch validation (yet), but it's not (directly) applicable to Bitcoin anyway, as it needs slightly more information than our current signatures encode
5 2015-01-23 02:32:10 <Luke-Jr> any way around GDB being unable to evaluate methods (like vector.operator[]) due to inlining? :/
6 2015-01-23 02:32:48 <sipa> compile without inlining :)
7 2015-01-23 02:33:11 <Luke-Jr> yeah, but then I may lose the current runtime
8 2015-01-23 02:36:17 <gmaxwell> zuber: what vanitygen does is different from anything currently in libsecp256k1. I have a kludgy implementation based loosly on libsecp256k1 which does about 20MH/s on a cpu... there are a number of useful algebraic optimizations that none of the vanity generators have.
9 2015-01-23 02:36:24 <sipa> gmaxwell: he left
10 2015-01-23 02:36:29 <gmaxwell> might read the logs.
11 2015-01-23 02:36:46 <gmaxwell> I haven't released it because it's throw away code (and really outdated now) and because really people shouldn't be using vanitygen for much of anything.
12 2015-01-23 02:36:47 <sipa> @later tell zuber < gmaxwell> zuber: what vanitygen does is different from anything currently in libsecp256k1. I have a kludgy implementation based loosly on libsecp256k1 which does about 20MH/s on e.
13 2015-01-23 04:02:17 <Luke-Jr> hm, so my main hot node is apparently serving out bad blocks. old version, will report more as I learn it
14 2015-01-23 04:02:44 <Luke-Jr> do current versions do any sanity check before sending blocks?
15 2015-01-23 04:03:26 <sipa> i believe they do a sanity check after reading from disk
16 2015-01-23 04:09:56 <Luke-Jr> sure enough 2015-01-23 04:02:20 ERROR: bool ReadBlockFromDisk(CBlock&, const CDiskBlockPos&)() : deserialize or I/O error
17 2015-01-23 04:10:56 <sipa> ... but why does it still send?
18 2015-01-23 04:12:12 <Luke-Jr> 0.8 didn't have the assert master does
19 2015-01-23 04:12:36 <Luke-Jr> ACTION ponders how to repair his node
20 2015-01-23 04:13:38 <Luke-Jr> anyone can pastebin 00000000000001c2e0d5846aa6f31bb97c78aae74960371b8b06233a5579c51a ? >.>
21 2015-01-23 04:15:45 <Luke-Jr> (or know a service to fetch it from raw)
22 2015-01-23 04:16:40 <Luke-Jr> sipa: oh, the reason I thought it had recovered was that it re-UpdateTip'd blocks after restart; expected for some reason?
23 2015-01-23 04:16:51 <Luke-Jr> it did in fact get stuck on the same block after that
24 2015-01-23 05:08:12 <Luke-Jr> looks like my blk0003.dat is just truncated
25 2015-01-23 05:08:18 <Luke-Jr> 00003*
26 2015-01-23 05:52:37 <Luke-Jr> fwiw, conversation in #bitcoin-otc about multiple users choosing to use a webwallet because of the blockchain size
27 2015-01-23 05:54:25 <volante> how do i solve this build problem? qt/test/../paymentrequestplus.h:8:31: fatal error: paymentrequest.pb.h: No such file or directory
28 2015-01-23 06:03:00 <volante> ok nm I solved it
29 2015-01-23 06:05:52 <Luke-Jr> to the inevitable googler who finds this log: that error probably means you need to install protobuf dev packages (eg, protoc)
30 2015-01-23 06:06:25 <volante> and then you need to run configure again
31 2015-01-23 06:06:35 <Luke-Jr> âº
32 2015-01-23 06:09:50 <volante> does v0.10.0rc3 contain headers first sync? i'm running that and expected the sync to be really fast, but it's going very slow for me
33 2015-01-23 06:10:29 <Luke-Jr> yes
34 2015-01-23 06:10:39 <Luke-Jr> if your computer is slow, nothing will help
35 2015-01-23 06:11:20 <volante> my machine is fast, but after 10 mins i'm still 5 years 51 weeks behind
36 2015-01-23 06:12:44 <volante> ok it's moving a bit faster now
37 2015-01-23 06:13:50 <volante> all of a sudden it's flying along... very nice :)
38 2015-01-23 06:16:19 <volante> gotta go... thanks.
39 2015-01-23 06:17:44 <earlz> Is a DER encoded signature never more than 73 bytes long?
40 2015-01-23 06:19:37 <earlz> Also, what's the max size of a public key (not hashed) ?
41 2015-01-23 07:09:11 <wumpus> max size of a public key is 65, or 33 for a modern compressed pubkey
42 2015-01-23 07:10:48 <wumpus> and yes a DER signature is never larger than 73 bytes, you should read sipa's BIP
43 2015-01-23 08:28:49 <fanquake> #4515 Could use some review/feedback
44 2015-01-23 08:42:35 <wumpus> yes
45 2015-01-23 08:44:08 <thermoman> is there an implementation of a bitcoin address validator in php that actually does function properly?
46 2015-01-23 08:45:02 <thermoman> there are many libs that claim they do but they with some addresses
47 2015-01-23 08:58:12 <wumpus> I doubt it
48 2015-01-23 09:17:39 <gdm85> I noticed that if the last rev000??.dat and blk000??.dat are 0-bytes files, bitcoind won't start. would it be dangerous to assume they are corrupt and retrieve them again instead?
49 2015-01-23 10:28:37 <wumpus> gdm85: I suppose they can be legally 0 bytes if there is just no data in them yet
50 2015-01-23 10:28:58 <wumpus> gdm85: though if the block index refers to them, there is likely data missing that should be there
51 2015-01-23 10:30:16 <gdm85> wumpus: yes that is my case e.g. index is referring to them but they are 0 bytes
52 2015-01-23 10:31:17 <wumpus> in that case it's time to do reindex
53 2015-01-23 10:32:45 <wumpus> I wonder how it came about that way though; the files should flushed before the database is written
54 2015-01-23 10:44:29 <gdm85> wumpus: it's a problem on the toolchain I use
55 2015-01-23 10:46:28 <gdm85> basically the block files created by bitcoind are not group or world readable by default, this creates a problem in another tool that ends up with 0byte files on destination pre-seeded node
56 2015-01-23 10:46:44 <gdm85> (I am fixing it at root cause, but was wondering about the specific bitcoind behavior with 0bytes blocks)
57 2015-01-23 10:48:10 <gdm85> btw, bitcoin core is not using any DNS lookup functions anywhere, right?
58 2015-01-23 11:10:22 <wumpus> a) for DNS seeding b) if you provide named nodes to connect to
59 2015-01-23 11:18:06 <gdm85> mmh..interesting! I was looking at rpcallowip, would like to use DNS there too
60 2015-01-23 11:18:32 <gdm85> I know it sounds counter-intuitive, but I have a DNS that will solve only specific hostnames and that would have been handy there
61 2015-01-23 11:20:10 <wumpus> lookup is disabled for those
62 2015-01-23 11:20:40 <wumpus> I can only see that end in pain anyway, to specify IP ACLs using hostnames
63 2015-01-23 11:22:19 <gdm85> wumpus: right.
64 2015-01-23 12:10:47 <jonasschnelli> I think we should delete: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/conflictedbalance.sh
65 2015-01-23 12:11:15 <jonasschnelli> this test is broken (misses fees) and some core changes did also made things different.
66 2015-01-23 12:11:51 <jonasschnelli> i tried to move this to .py but some core changes did detect the conflict erlier.
67 2015-01-23 12:16:53 <wumpus> well, or just change the test, so that it tests the current conflict detection
68 2015-01-23 12:17:27 <wumpus> it's a risk of not running the test automatically, it gets out of date with the code even due to non-bugs
69 2015-01-23 12:18:58 <jonasschnelli> wumpus, maybe i wasn't looking deep enough, but isn't this test (https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/txn_doublespend.py) doing that already?
70 2015-01-23 12:22:48 <wumpus> hm could be
71 2015-01-23 12:25:15 <fanquake> speaking of tests, #5422 has been sitting in the pull queue for a while.
72 2015-01-23 12:34:07 <wumpus> IIRC it was not passing travis
73 2015-01-23 12:34:36 <wumpus> but yes, needs rebase
74 2015-01-23 12:42:21 <jgarzik> wumpus, FYI "ab" makes a great tester. ApacheBench. Comes with httpd package, or associated utilities.
75 2015-01-23 12:47:08 <wumpus> thanks
76 2015-01-23 13:06:01 <jtimon> I just separated #5697 from #5681, now #5681 becomes trivial
77 2015-01-23 13:08:54 <jtimon> I've also created #5696, another trivial PR that will help with the include cleanup and will simplify later consensus and policy encapsulation changes
78 2015-01-23 13:10:33 <jtimon> Am I missing any consensus constant here? https://github.com/jtimon/bitcoin/commit/7c8fc8ac37730204b51a2a555cacb26315ce8b59
79 2015-01-23 13:11:09 <jtimon> Am I missing any policy constant or global in https://github.com/jtimon/bitcoin/commit/6dcf6633786b335d1fc9efb08c02b0e3d3baf21c ?
80 2015-01-23 13:11:24 <wumpus> ok evhttp is *really* slower at sustained requests than the current 'dedicate a thread to a connection', I guess that makes sense, if you have a thread servicing one connecting you can reach higher throughput then when multiplexing
81 2015-01-23 13:12:11 <wumpus> all thanks to keep-alive. Of course this means that you can never have more connections than the number of theads, which is exatly what it is wrong with it currently...
82 2015-01-23 13:14:50 <wumpus> so in every case there are more connections than rpcthreads, evhttp wins compared to the old server, as the extra connections will get completely stuck
83 2015-01-23 13:15:32 <wumpus> the thing is, that benchmark program doesn't care about starved connections, just about total throughput, so the result is distorted
84 2015-01-23 13:17:40 <wumpus> (4 connections get super-fast-replies, the other 96 idle - hence the benchmark's req/s is a bad measure - it's also dumb and latency is only counted for requests that actually get a response :P)
85 2015-01-23 13:20:52 <wumpus> jtimon: you have MAX_BLOCK_SIZE in two places
86 2015-01-23 13:21:35 <warren> https://github.com/bitcoin/bitcoin/issues/5693 Any comments on this unimportant cleanup? I enjoy killing magic numbers.
87 2015-01-23 13:21:45 <wumpus> jtimon: ah no, looking wrong
88 2015-01-23 13:23:19 <jtimon> wumpus can't you have an open thread per open connections apart from the number of threads selected by the user?
89 2015-01-23 13:24:02 <wumpus> jtimon: eh, the point is to have only a limited number of threads
90 2015-01-23 13:24:31 <wumpus> jtimon: of course you could simply spawn a new thread for every connection, but I'd think that's not what we want (also because everything holds the cs_main lock anyhow)
91 2015-01-23 13:24:42 <wumpus> also threads use tons of memory
92 2015-01-23 13:31:19 <fanquake> wumpus Is #5647 going into 0.10.0?
93 2015-01-23 13:33:05 <wumpus> hmm also this is a localhost benchmark, which means the threads can run at full speed; over a network I suppose things are different, as I/O throughput starts playing a role
94 2015-01-23 13:34:04 <wumpus> fanquake: could be
95 2015-01-23 13:40:38 <wumpus> warren: +1 for creating a constant for the magic number, although I don't think it should be unified with the wallet constant
96 2015-01-23 13:41:02 <jtimon> 1 Single thread creating and destroying connection threads
97 2015-01-23 13:41:02 <jtimon> M worker threads processing the messages (the only ones that should get cs_main locks)
98 2015-01-23 13:41:02 <jtimon> N connection threads pushing messages to worker threads, waiting for the result and sending it out
99 2015-01-23 13:41:02 <jtimon> wumpus what I think I would do is the folllowing (assuming zmq, nanomsg or another lib with similar functionality which I assume libevent has):
100 2015-01-23 13:41:30 <jtimon> I'm going to eat, afk
101 2015-01-23 13:42:25 <wumpus> jtimon: currently it's 1+M, not 1+N+M, not sure it's worth the extra complexity in this case
102 2015-01-23 13:43:20 <wumpus> also it'd mean reimplementing evhttp, which assumes there is only one thread handling connection as well as pushing/pulling data from connections
103 2015-01-23 13:51:00 <wumpus> bleh, this microbenchmarking was a diversion anyhow, the original motivation for this was that (in contrast to the old http server) it can do sane connection timeouts and handle more connections, also this gets rid of the boost:asio dependency, which a lot of people regard as ugly and hard to understand
104 2015-01-23 13:55:30 <jonasschnelli> hmm... how could the legacywallet code be organized? I move the "old" wallet.* and walletdb.* to a folder legacywallet/. I tried to use a custom namespace "legacywallet" but didn't succeed. Now i could make it switchable during compile time (same class name, same interface)... or
105 2015-01-23 13:55:53 <jonasschnelli> i could rename to class and make a adapter (or something like this)
106 2015-01-23 13:56:07 <kanzure> is there already a name for nonlegacywallet?
107 2015-01-23 13:56:40 <jonasschnelli> kanzure, https://github.com/bitcoin/bitcoin/pull/5686 no new name
108 2015-01-23 13:59:21 <warren> wumpus: what's the purpose for amount.h? why not there?
109 2015-01-23 13:59:35 <warren> creating a redundant constant won't make this any less confusing
110 2015-01-23 14:04:21 <wumpus> warren: It makes sense to be able to set it for the wallet and network separately
111 2015-01-23 14:04:34 <wumpus> warren: you asked my opinion, so I gave it :)
112 2015-01-23 14:05:05 <wumpus> kanzure: yes, newwallet is a silly name :P
113 2015-01-23 14:06:36 <warren> that thing is really ARBITRARYNUMBER - ANOTHERARBITRARYNUMBER
114 2015-01-23 14:06:39 <kanzure> secondwallet
115 2015-01-23 14:07:29 <warren> wumpus: there might not be any value in keeping the 1000 there at all.
116 2015-01-23 14:07:50 <warren> it's equally aribtrary without it
117 2015-01-23 14:10:05 <wumpus> possibly, but I'd argue 'I don't like magic numbers' is a very bad reason to change it
118 2015-01-23 14:11:13 <wumpus> as said I'm very much ok with making it a named constant, but anything more impactful needs a good reason
119 2015-01-23 14:11:45 <warren> MAGICA - MAGICB. Remove MAGICB. It's still magic.
120 2015-01-23 14:12:40 <timothy> hi, what do you think about https://github.com/bitcoin/bitcoin/issues/5698 ?
121 2015-01-23 14:24:10 <strompike3> Anyone able to tell me what is wrong with this raw transaction? http://pastebin.com/raw.php?i=brvX300e
122 2015-01-23 14:29:01 <wumpus> warren: you remove the negative magic so you get moar magic
123 2015-01-23 14:29:28 <warren> wumpus: no less arbitrary than it currently is
124 2015-01-23 14:30:52 <jonasschnelli> fanquake, he added one: https://github.com/bitcoin/bitcoin/pull/5700/files#r23452258
125 2015-01-23 14:31:15 <fanquake> jonasschnelli Github is playing tricks on me :/
126 2015-01-23 14:31:32 <jonasschnelli> fanquake, i also had to look closely.
127 2015-01-23 14:31:52 <fanquake> jonasschnelli is that a bug that actually needs fixing?
128 2015-01-23 14:32:26 <jonasschnelli> fanquake, yes. just reproduce the bug and it is real. Will test his fix now but looks good.
129 2015-01-23 14:32:42 <fanquake> jonasschnelli the patch is correct.
130 2015-01-23 14:40:40 <jtimon> warren CAmount's typedef was intended as a first for #4067 CFeeRate will eventually become movable to policy.o
131 2015-01-23 14:47:05 <wumpus> CAmount is basically there so that it's easier for altcoins to change the money type
132 2015-01-23 14:48:40 <jtimon> but it could be also useful for bitcoin's typesafety if the initial proposal was completed
133 2015-01-23 14:49:00 <jtimon> but it was very controversial so it wasn't completed
134 2015-01-23 14:50:09 <jtimon> completion -> if the typedef became a struct/class
135 2015-01-23 14:51:49 <jtimon> and then when I splitted core into primitives/transaction and primitives/block I moved CFeeRate there until CTxOut::isdust moves policy...
136 2015-01-23 14:52:12 <wumpus> using a different type in the consensus code is extremely controversial , that is never going to happen
137 2015-01-23 14:52:17 <jtimon> and put the amount constants plus MoneyRange()
138 2015-01-23 14:53:12 <jtimon> yes, I was just trying to explain the history to warren, not reopening the issue
139 2015-01-23 14:53:30 <jtimon> what is that he wants to move to amount.h ?
140 2015-01-23 14:53:33 <wumpus> in the wallet code and RPC code and such I'm not opposed to it, but the consensus code should use simple CPU types as possible
141 2015-01-23 14:54:11 <wumpus> right
142 2015-01-23 14:54:45 <wumpus> jtimon: some magic constant to do with block space allocation to free transactions, I don't think it belongs there
143 2015-01-23 14:55:58 <jtimon> policy, warren please see #5696
144 2015-01-23 14:56:48 <jtimon> i can add your contant
145 2015-01-23 14:56:58 <jtimon> constant
146 2015-01-23 14:57:22 <jtimon> or you can add it later
147 2015-01-23 14:57:24 <wumpus> indeed, relay policy
148 2015-01-23 15:03:29 <jonasschnelli> wumpus, looks ready to merge IMO: https://github.com/bitcoin/bitcoin/pull/5700
149 2015-01-23 15:06:33 <wumpus> agreed, needs to go in 0.10 as well
150 2015-01-23 15:10:15 <jonasschnelli> wumpus, can go in 0.10, looks sane.
151 2015-01-23 16:08:58 <gdm85> [OT] this is a nugget I found today: http://pastebin.com/JEA49pru <-- that 'mac.update((byte) 0);' doesn't convince me
152 2015-01-23 17:53:20 <Luke-Jr> hm, IBD with 0.10 is only using 30-80% of a single core for me
153 2015-01-23 17:53:42 <Luke-Jr> I guess maybe I'm bandwidth limited
154 2015-01-23 17:54:23 <wumpus> Luke-Jr: at what block?
155 2015-01-23 17:54:36 <Luke-Jr> 266203
156 2015-01-23 17:54:44 <Luke-Jr> after running all night
157 2015-01-23 17:56:12 <wumpus> that's still pretty early, heavy cpu load starts later
158 2015-01-23 17:58:03 <Luke-Jr> I would think as soon as we got to >4 tx per block, it'd be kept busy
159 2015-01-23 17:59:15 <Luke-Jr> hm, seems silly that the debug window network traffic clears when you change its size larger :/
160 2015-01-23 18:23:30 <gmaxwell> Luke-Jr: it's latency bound earlier in the chain because it won't request many blocks at once.
161 2015-01-23 18:23:56 <gmaxwell> As it'll only request 16 per peer at a time.
162 2015-01-23 18:24:08 <Luke-Jr> would think that'd be enough. oh well
163 2015-01-23 18:24:21 <gmaxwell> Which is obviously a bit dumb, but the overall effect on the whole transfer is only a few minutes slowdown.
164 2015-01-23 18:24:45 <gmaxwell> Nah, with those really early small blocks you'd really want to be requesting thousands at a time.
165 2015-01-23 18:24:45 <Luke-Jr> well, it's been at least 8 hours now
166 2015-01-23 18:25:09 <gmaxwell> lol. then you shouldn't be bandwidth limited; is this on that small usb computer?
167 2015-01-23 18:25:50 <Luke-Jr> no, my desktop PC
168 2015-01-23 18:26:49 <Luke-Jr> 11h14m to be exact
169 2015-01-23 18:28:47 <sipa> Luke-Jr: is it requesting blocks from all peers?
170 2015-01-23 18:28:52 <sipa> see getpeerinfo, the 'inflight' field
171 2015-01-23 18:32:26 <Luke-Jr> sipa: http://codepad.org/jQgYiuso
172 2015-01-23 18:32:56 <Luke-Jr> no, just some
173 2015-01-23 18:34:02 <sipa> hmm, it doesn't even know which blocks some of your peers have...
174 2015-01-23 18:37:19 <dgenr8> gmaxwell: bug report. enter .4 and 980 at https://people.xiph.org/~greg/attack_success.html also try .4 and 2000
175 2015-01-23 18:39:26 <gmaxwell> dgenr8: it just runs out of precision in double precision at some point.
176 2015-01-23 18:42:10 <Luke-Jr> this is odd: /BitCoinJ:0.12SNAPSHOT/Satoshi:0.2.0/
177 2015-01-23 18:51:18 <gmaxwell> Luke-Jr: thats busted that its taking so long.
178 2015-01-23 19:50:08 <netg> any core-devs at www.bundesbank.de/Redaktion/EN/Downloads/Bundesbank/Research_Centre/Conferences/2015/2015_01_29_frankfurt_programme.pdf ?
179 2015-01-23 19:50:27 <netg> Workshop "P2P Financial Systems 2015"
180 2015-01-23 19:51:07 <warren> Is there a way to make it request more than 16 blocks at a time/
181 2015-01-23 19:51:37 <sipa> warren: increase a compile-time constant
182 2015-01-23 19:53:00 <gmaxwell> warren: later in the chain doing that results in bad results; really it should be something adaptive... but we didn't want to delay headers first for small optimizations.
183 2015-01-23 19:56:06 <warren> syncing from a local node used to be blazing fast
184 2015-01-23 19:56:59 <warren> gmaxwell: adaptive to the average block size or something?
185 2015-01-23 19:57:27 <sipa> and to your bandiwdth and latency
186 2015-01-23 19:57:35 <sipa> but definitely for block size, yes
187 2015-01-23 19:58:17 <warren> yeah, don't want to delay for that
188 2015-01-23 22:08:12 <warren> sipa: after the point where it knows the height from all the headers, couldn't you scale the quantity of blocks relative to the proportion of blocks remaining?
189 2015-01-23 22:10:22 <tonester> I'm looking to build out what was proposed in https://en.bitcoin.it/wiki/Dominant_Assurance_Contracts - any suggestions on where else to look?
190 2015-01-23 22:11:09 <zooko> tonester: what are you looking for?
191 2015-01-23 22:11:16 <zooko> You mean to see if someone else has already implemented it?
192 2015-01-23 22:13:18 <tonester> Yeah! I mean that was from 2012 and without multi-sig, so I thought there might be something more recent.
193 2015-01-23 22:24:37 <gavinandresen> tonester: not sure if Lighthouse uses the algorithm from that wiki page or not, but see: https://www.vinumeris.com/lighthouse