1 2014-10-13 01:10:12 <saivann> In the absence of critical feedback, public stats for bitcoin.org will be published tomorrow, October 13th. https://github.com/bitcoin/bitcoin.org/issues/605
  2 2014-10-13 04:16:29 <netbit1> hello...room/group/devs
  3 2014-10-13 04:16:43 <netbit1> and audience
  4 2014-10-13 04:17:57 <arowser> Anybody can help to confirm if this is a getrawtransaction command issue https://github.com/arowser/bitcoin/compare/fix_getrawtransaction?diff=split&expand=1
  5 2014-10-13 04:23:03 <phantomcircuit> arowser, what are you trying to fix?
  6 2014-10-13 04:24:25 <arowser> when tx not in block, the confirmations should show 0, but its not show confirmations
  7 2014-10-13 04:25:38 <phantomcircuit> arowser, i believe you're misinterpreting that code
  8 2014-10-13 04:26:18 <phantomcircuit> if hashblock is not null
  9 2014-10-13 04:26:34 <phantomcircuit> and that block is orphaned
 10 2014-10-13 04:26:40 <phantomcircuit> then confirmations returns 0
 11 2014-10-13 04:26:46 <phantomcircuit> otherwise it's simply not set
 12 2014-10-13 04:26:51 <phantomcircuit> there's 3 states
 13 2014-10-13 04:26:58 <phantomcircuit> im not sure it makes sense that there's 3 states
 14 2014-10-13 04:27:00 <phantomcircuit> but still
 15 2014-10-13 04:33:29 <arowser> yes, you are right, so the tx in orphaned block be indexd too when txindex=1?
 16 2014-10-13 04:36:18 <phantomcircuit> i think so
 17 2014-10-13 04:36:53 <arowser> ok, got it.
 18 2014-10-13 04:37:00 <arowser> thanks
 19 2014-10-13 05:41:52 <phantomcircuit> sipa, has anybody tried replacing leveldb for the utxo with a simple sequential file
 20 2014-10-13 06:20:12 <BlueMatt> phantomcircuit: yes. its called the blockchain?
 21 2014-10-13 06:20:36 <phantomcircuit> har
 22 2014-10-13 06:20:41 <phantomcircuit> i meant a snapshot
 23 2014-10-13 06:20:49 <phantomcircuit> like
 24 2014-10-13 06:20:55 <phantomcircuit> at block x the utxo was y
 25 2014-10-13 06:21:11 <BlueMatt> yes. its called utxo commitments
 26 2014-10-13 06:22:59 <phantomcircuit> BlueMatt, actually implemented by anybody yet?
 27 2014-10-13 06:23:17 <BlueMatt> I thought there was one or two, but I'd have to search to find it
 28 2014-10-13 06:23:32 <BlueMatt> there were some designed to be effeciently updateable
 29 2014-10-13 06:28:52 <sipa> phantomcircuit: i'm sure that a specifically designed database for the utxo set can be much simpler and more performant than leveldb now
 30 2014-10-13 06:29:17 <sipa> but just a single flat file would be terribly inefficient if it doesn't fit in memory entirely
 31 2014-10-13 06:29:26 <sipa> which currently requires like 3 GB
 32 2014-10-13 06:32:44 <phantomcircuit> sipa, really?
 33 2014-10-13 06:32:49 <phantomcircuit> didn't think it was that much
 34 2014-10-13 07:08:41 <sipa> phantomcircuit: there's huge overhead from dynamic allocation
 35 2014-10-13 07:08:56 <sipa> phantomcircuit: you can't just access ctransactiins in serialized form
 36 2014-10-13 07:09:08 <sipa> you get like a 8x blowup by just deserialixing
 37 2014-10-13 07:14:50 <phantomcircuit> sipa, right
 38 2014-10-13 07:38:00 <wumpus> a more compact in-memory representation is likely possible
 39 2014-10-13 07:38:52 <gmaxwell> sure, if its not mutable you preallocate the size of the whole thing, and just have lengths followed by the data. :)
 40 2014-10-13 07:42:24 <sipa> wumpus: the extreme would be just not deserialize, but prefix an index structure with offsets
 41 2014-10-13 07:42:52 <sipa> the hard part is CScript, as that woyld mean it cannot dervice from std::vector anymore
 42 2014-10-13 07:44:48 <gmaxwell> could always keep that part 'seralized' and deseralize it on use... as there are relatively few places where a CScript is not opaque. (well not as few as there should be)
 43 2014-10-13 07:49:33 <wumpus> gmaxwell: it's mutable (at least up to a degree) - outputs are marked spent and removed
 44 2014-10-13 07:56:15 <phantomcircuit> strictly speaking the utxo just needs to be a set of unspent txid, n values
 45 2014-10-13 07:56:31 <phantomcircuit> reorgs would be expensive, but that seems like a fair trade
 46 2014-10-13 07:58:06 <sipa> you need the scriptpubkey in the utxo set
 47 2014-10-13 07:58:10 <sipa> and amounts
 48 2014-10-13 07:58:24 <wumpus> gmaxwell: there are some optimizations that are possible due to the current 'expanded' structure, like removing spent outputs of a transaction from memory, then again maybe it's worth giving those up if the whole structure can be represented w/ X times less memory
 49 2014-10-13 07:58:56 <phantomcircuit> sipa, you need to be able to look those up, they dont necessarily have to be in the utxo set itself
 50 2014-10-13 07:59:51 <wumpus> phantomcircuit: it's probably a lot faster if they are, though
 51 2014-10-13 08:00:06 <sipa> phantomcircuit: they need to be quickly acceasible, however you do that
 52 2014-10-13 08:00:41 <wumpus> there was talk here at some point about not storing those and having the client provide them, but that'd require huge changes to the protocol
 53 2014-10-13 08:01:23 <sipa> and to the mode of operation
 54 2014-10-13 08:01:43 <sipa> you're talking about insertion-ordered txo commitments
 55 2014-10-13 08:02:11 <sipa> but those also require wallet clients to keep track of where 'their' coins are in the merkle tree
 56 2014-10-13 08:02:19 <sipa> so they can construct spending proofs
 57 2014-10-13 08:02:34 <wumpus> doesn't bitcoin core do that at the moment? :-)
 58 2014-10-13 08:02:47 <sipa> there is not even a tzo tree...
 59 2014-10-13 08:02:51 <sipa> *txo tree
 60 2014-10-13 08:03:08 <sipa> wumpus: it's also incompatible with offline wallets
 61 2014-10-13 08:03:13 <wumpus> right, it keeps track of where the transactions are in the *block* merkle tree
 62 2014-10-13 08:03:25 <sipa> you need to know where your coins are *now* in the tree
 63 2014-10-13 08:03:36 <sipa> to be able to spend them
 64 2014-10-13 08:03:49 <wumpus> ... that's a big drawback indeed
 65 2014-10-13 08:04:05 <sipa> it does mean you can have o(1) full nodes though
 66 2014-10-13 08:04:45 <sipa> but transactiins and blocks on wire (not on disk) would become a lot bigger because they need to carry spending proofs
 67 2014-10-13 08:04:51 <sipa> with higher bandwidth as a result
 68 2014-10-13 08:05:40 <sipa> a spending proof for bitcoin now would be over a kilobyte per txin
 69 2014-10-13 08:05:50 <wumpus> and bandwidth is going to be a problem with scaling
 70 2014-10-13 08:05:58 <sipa> with such a txo commitment scheme
 71 2014-10-13 08:06:25 <wumpus> given everything else is equal, it would be preferable to use more storage than use more bandwidth
 72 2014-10-13 08:06:28 <sipa> sorry, a bit less than a kb
 73 2014-10-13 08:06:37 <sipa> it's a compromise
 74 2014-10-13 08:06:50 <sipa> and maybe both are interesting, as usage can adapt to where the costs lie
 75 2014-10-13 08:07:40 <wumpus> I'm still surprised sometimes that we're able to send data over all the world that cheaply
 76 2014-10-13 08:08:27 <sipa> a compromise is something that petertodd came up with: keep the most recently updated part of the txo tree guaranteed available by full nodes (like a utxo set), so spending anything from that would not require proofs
 77 2014-10-13 08:08:42 <sipa> you'd only need them for spends of older coins
 78 2014-10-13 08:09:38 <wumpus> sound like a decent compromise, on the other hand that'd mean that offline wallets would not be possible for older coins
 79 2014-10-13 08:10:50 <sipa> the proof creation can be outsourced
 80 2014-10-13 08:11:07 <sipa> you can have indezing services that add proofs to your transactions, perhaps for a cost
 81 2014-10-13 08:12:42 <wumpus> right - the wallet (signing) itself could still be offline, you'd at most reveal what coins you own to the indexing service (which could be a local node)
 82 2014-10-13 08:12:57 <phantomcircuit> sipa, hmm
 83 2014-10-13 08:12:57 <wumpus> so it's not that bad
 84 2014-10-13 08:13:20 <phantomcircuit> you're right it would cause significant performance issues for that to be a separate lookup
 85 2014-10-13 08:14:12 <phantomcircuit> i assume the current leveldb layout is basically (txid, n) -> (scriptpubkey, amount)
 86 2014-10-13 08:14:31 <wumpus> phantomcircuit: more like txid -> [(scriptpubkey, amount)]
 87 2014-10-13 08:15:01 <phantomcircuit> no index?
 88 2014-10-13 08:15:18 <wumpus> this saves space in repeated txids, but ofc has some other drawbacks like having to update entire "Coins"
 89 2014-10-13 08:20:12 <sipa> yeah, i want to experiment with per-txout utxo indexing at some point rather than per-txid
 90 2014-10-13 08:20:28 <sipa> duplicating version and height seems unnecessary
 91 2014-10-13 08:20:37 <sipa> but it does mean a more flat structure
 92 2014-10-13 08:23:03 <wumpus> I wouldn't be too concerned about the version and height, but wouldn't you have to store those 32 bytes of the txid for every output?
 93 2014-10-13 08:23:15 <sipa> in memory, yes
 94 2014-10-13 08:23:29 <sipa> not on disk, as leveldb deduplicates repeated key prefixes
 95 2014-10-13 08:23:35 <wumpus> if you have a transaction with say 300 outputs, that's kind of a waste
 96 2014-10-13 08:23:50 <wumpus> ok right, maybe the same is possible in memory
 97 2014-10-13 08:24:06 <sipa> well, yes... by doing what we do now :D
 98 2014-10-13 08:24:15 <wumpus> lol, yes
 99 2014-10-13 08:24:22 <sipa> i don't know which one is better
100 2014-10-13 08:24:35 <sipa> but a vector has also.around 32 bytes of overhead in memory
101 2014-10-13 08:24:47 <wumpus> it has
102 2014-10-13 08:24:55 <sipa> and we currently need a vector per txid, to store the unspent txouts
103 2014-10-13 08:26:01 <wumpus> but those are peanuts, when you compute the overhead, by far most of the overhead is in the outputs themselves
104 2014-10-13 08:26:11 <sipa> oh sure
105 2014-10-13 08:26:38 <wumpus> the std::vector for the script, for example
106 2014-10-13 08:26:55 <sipa> yes, that's how this conversation started
107 2014-10-13 08:27:24 <sipa> now CTra saction is immutable, we could use indexed undeserialized single-malloced blocks for transactions
108 2014-10-13 08:27:32 <wumpus> at least the vector for the unspent txouts is one per transaction, so if you divide that by the average number of outputs per transaction (which is quite large), not much remains
109 2014-10-13 08:27:44 <sipa> if only CScript supported more than a simole stdvector as backend
110 2014-10-13 08:27:57 <wumpus> leveldb::slice :)
111 2014-10-13 08:28:12 <sipa> yeah, something like that
112 2014-10-13 08:28:23 <sipa> it's a bit silly though
113 2014-10-13 08:28:31 <sipa> a CScriot just *is* a byte vector
114 2014-10-13 08:29:06 <sipa> it could be rewritten to turn CScriot into jusy utility functions that operate on byte arrays
115 2014-10-13 08:29:11 <wumpus> maybe we shouldn't subclass at all, and just have function that take a memory slice that can be a vector or arbitrary (start,size) slice...
116 2014-10-13 08:29:13 <wumpus> right
117 2014-10-13 08:29:22 <sipa> rather than being methods of something that derives from one data structure
118 2014-10-13 08:29:30 <sipa> right
119 2014-10-13 08:30:57 <wumpus> indeed, we already concluded for other reasons that it makes sense to move in that direction for the core structures, to have data structures and separate utility functions
120 2014-10-13 08:31:13 <sipa> indeed
121 2014-10-13 08:40:07 <dabura667> With the headers first sync. I was able to sync from 0 to fully synched in 3 hours 34 minutes... amazing stuff...
122 2014-10-13 08:43:32 <phantomcircuit> receive version message: /BQS:0.0.1/: version 70001, blocks=0, us=127.0.0.1:8333, peer=2, peeraddr=
123 2014-10-13 08:43:36 <phantomcircuit> same peer
124 2014-10-13 08:43:37 <phantomcircuit> ERROR: CScriptCheck() : 058520b2b46ea7ec48a8efb764f8f526ce337ded801bbcbc584e0e1a3f09c88e:0 VerifySignature failed
125 2014-10-13 08:43:43 <phantomcircuit> any idea what's the deal there
126 2014-10-13 09:33:41 <wumpus> for better or worse, the headers-first "release" is treated as a sort of 0.10.0rc0
127 2014-10-13 09:34:01 <wumpus> phantomcircuit: peer sent a transaction with an invalid signature?
128 2014-10-13 09:36:00 <wumpus> it's pretty easy to get those errors when playing around w/ manual transaction signing, although you'd expect that to be rare on the main network
129 2014-10-13 09:39:17 <wumpus> you'd be a fool to test your experimental wallet with real coins
130 2014-10-13 09:39:53 <Phoebus> agreed
131 2014-10-13 09:41:56 <kinlo> at some point you do need to use real money in your code
132 2014-10-13 09:42:02 <kinlo> that's usually the scary part
133 2014-10-13 09:42:08 <kinlo> did I screw up or not :p
134 2014-10-13 09:43:33 <phantomcircuit> wumpus, yeah it's weird and has a pretty unique client signature
135 2014-10-13 10:00:52 <dabura667> wumpus: tell that to my clients... lol
136 2014-10-13 10:01:37 <dabura667> I have told them numerous times... and they keep putting it off...
137 2014-10-13 10:02:27 <dabura667> meanwhile, their debug staff makes little transactions with 0.00006 BTC outputs.
138 2014-10-13 10:02:38 <dabura667> *sigh*
139 2014-10-13 10:03:26 <dabura667> they were talking about testing on Monacoin... to which I *facepalmed* very very hard.
140 2014-10-13 10:03:43 <dabura667> how can you not afford testnet and yet afford an altcoin...
141 2014-10-13 10:04:06 <dabura667> </endrant>
142 2014-10-13 10:04:48 <dabura667> wumpus: I am really pumped for 0.10 tho... I will start recommending running full nodes to the semi-advanced bitcoin user friends of mine.
143 2014-10-13 10:16:55 <wumpus> dabura667: I wonder too. Maybe because testnet coins have no value they feel nothing is 'at stake' so it's not real testing?
144 2014-10-13 10:17:56 <dabura667> wumpus: That was one thing they said "where do you buy testnet coins? we don't have any and can't test." to which I said "I have like 200 tBTC, you can have them if you want. They're worthless.
145 2014-10-13 10:18:16 <dabura667> they just don't want to have to touch their backend
146 2014-10-13 10:18:25 <dabura667> their lead dev is lazy imo
147 2014-10-13 10:18:45 <wumpus> but that can't explain it: they have to touch it to use an altcoin as well
148 2014-10-13 10:19:23 <dabura667> wumpus: I know... my thought is maybe they are planning on copy+pasting from a previous Monacoin endeavour.
149 2014-10-13 10:19:30 <wumpus> right
150 2014-10-13 10:19:40 <dabura667> which comes back to = lazy
151 2014-10-13 10:20:31 <dabura667> *gah* luckily I'm not a member of their company. Just an "advisor" which I they have signed off that I am not responsible for anything they do, in return they don't have to listen to me.
152 2014-10-13 10:20:45 <dabura667> which makes me wonder what I'm doing with my time.
153 2014-10-13 10:21:05 <dabura667> oh well.
154 2014-10-13 12:33:46 <endlessdark> Hi, I would like to review the state of some of bitcoin related projects or startups. Is there any updated directory? Or should I crawl google and bitcointalk? Thanks!
155 2014-10-13 12:38:56 <Adlai> 
ACTION keeps getting "Error: Invalid -rpcallowip subnet specification: 10.0.0.*" when running sipa:headfirst8, adding an -rpcallowip flag doesn't help

156 2014-10-13 12:46:47 <Adlai> 
ACTION fixes his bitcoin.conf >_<

157 2014-10-13 13:05:28 <Adlai> 
ACTION begins headfirst sync from 307206

158 2014-10-13 13:27:24 <dabura667> Adlai: you will be surprised how fast it is. I synced mine in 3 1/2 hours from 0 (fresh install)
159 2014-10-13 13:31:55 <Adlai> load average >3 (on a core2duo), now @ 308507 ∴ >500 blocks/min, eta 34 minutes!?
160 2014-10-13 14:25:21 <dabura667> Does anyone have a guesstimate of how large a fully pruned blockchain would be? I know headers only is like 26MB and the full chain is 23GB
161 2014-10-13 14:25:38 <dabura667> ie only txes with utxo are kept. the rest are pruned.
162 2014-10-13 14:27:20 <helo> dabura667: maybe gettxoutsetinfo
163 2014-10-13 14:27:55 <helo> so ~470MB
164 2014-10-13 14:36:38 <dabura667> thanks
165 2014-10-13 14:47:36 <earlz> Is there any estimate of when 0.10 will be released?
166 2014-10-13 15:16:18 <Adlai> dabura667: you built up my expectations, but it's only at 315250 now
167 2014-10-13 15:23:05 <dabura667> how many connections / what's your DL speeds like?
168 2014-10-13 15:23:51 <dabura667> I had about 22 connections DLing at a stable 5Megabytes/s spurts, slowing down when verifying.
169 2014-10-13 15:24:15 <dabura667> plus I have a 4.3 GHz 4-core CPU
170 2014-10-13 15:24:25 <dabura667> which might help.
171 2014-10-13 15:24:41 <dabura667> 
ACTION laughs uncomfortably

172 2014-10-13 15:48:52 <sipa> Adlai: master and headersfirst etc use subnet specification so you need rpcallowip=10.0.0.0/24
173 2014-10-13 15:50:44 <Adlai> 8 connections, rpcallowip=127.0.0.1
174 2014-10-13 15:51:30 <sipa> headersfirst only downloads from outgoing connections btw
175 2014-10-13 15:52:05 <Adlai> makes sense
176 2014-10-13 15:53:08 <Emcy> headersfirst is not spv mode right
177 2014-10-13 15:53:17 <Emcy> so you still cant use bitcoin until its finished
178 2014-10-13 15:53:29 <Emcy> but its a subset of spv functionality
179 2014-10-13 15:54:49 <sipa> no
180 2014-10-13 15:55:02 <sipa> it just changes how the client synchronizes
181 2014-10-13 15:55:10 <sipa> externally nothing changes
182 2014-10-13 15:55:49 <Emcy> right
183 2014-10-13 15:56:18 <Emcy> what is the main mechanism in which it makes the initial sync faster? Im derping about it a bit.
184 2014-10-13 15:56:31 <Emcy> its still like 3 hours or so according to reports right
185 2014-10-13 15:56:41 <sipa> downloading from all (outgoing) peers at once
186 2014-10-13 15:56:56 <sipa> because it knows what to download in advance
187 2014-10-13 15:57:28 <Emcy> so the headers d/l is linear and obv much faster
188 2014-10-13 15:57:38 <Emcy> then the block filling is parallelised
189 2014-10-13 15:57:38 <sipa> indeed
190 2014-10-13 15:57:51 <sipa> it's explained in my mail :)
191 2014-10-13 15:58:23 <Emcy> i read it just wanted to confirm
192 2014-10-13 15:58:38 <Emcy> good work sipa
193 2014-10-13 15:59:16 <sipa> it also does not get confused by other peers announcing blocks anymore
194 2014-10-13 16:00:16 <sipa> which before would trigger syncing from them, which, if you already were, would just confuse things and likely result in not downloading anything anymore for a while
195 2014-10-13 16:00:24 <Emcy> i guess this should also properly leverage the switch to leveldb
196 2014-10-13 16:01:22 <Emcy> i didint know about that behavior........no wonder so many people turn up complaining about stalled sync
197 2014-10-13 16:01:25 <sipa> ...?
198 2014-10-13 16:01:37 <sipa> we switched to leveldb in 0.8.0
199 2014-10-13 16:01:47 <Emcy> i know
200 2014-10-13 16:02:05 <Emcy> and now it can get fed blocks faster
201 2014-10-13 16:02:20 <sipa> no
202 2014-10-13 16:02:47 <sipa> it's very orthogonal to that
203 2014-10-13 16:03:10 <Emcy> hm ok
204 2014-10-13 16:03:46 <Emcy> so now with headersfirst where is the sync bottleneck? openssl dsa?
205 2014-10-13 16:06:45 <lechuga_> headers dont have any signatures
206 2014-10-13 16:08:12 <Emcy> the blocks contents do
207 2014-10-13 16:08:35 <kjj> sipa, you finally killed my ramdisk nodes.  Now they have no advantage over disks
208 2014-10-13 16:11:45 <fanquake> What’s the fastest headersfirst sync time anyones seen so far? Anything well under 3 hours?
209 2014-10-13 16:12:31 <sipa> from local nodes on a fast machine you may get under 3 hours
210 2014-10-13 16:13:02 <sipa> Emcy: yes, after the last checkpoint signature verification is certainly the bottleneck
211 2014-10-13 16:14:30 <Emcy> what is the norla sync time currently (before headersfirst). The chain is like 25gb now right
212 2014-10-13 16:15:06 <sipa> depends; if you are lucky with your download peer maybe a day
213 2014-10-13 16:15:13 <sipa> otherwise maybe a week
214 2014-10-13 16:15:28 <sipa> most of the time is just spent doing nothing
215 2014-10-13 16:15:56 <Emcy> indeed
216 2014-10-13 16:16:11 <Emcy> perhaps bootstrap.dat will be deprecated after this
217 2014-10-13 16:17:09 <kjj> ramdisk to ramdisk, I could do almost as good as headers first.
218 2014-10-13 16:19:11 <kjj> my fastest method was importing a blockchain.dat from a running pre-leveldb node and just reindexing.  I suspect that is still a hair or two faster, but not worth the upkeep any more
219 2014-10-13 16:35:04 <blast_> Wow never seen It take a week
220 2014-10-13 16:46:45 <sipa> blast_: neither have i, but i always reindexed or used a fast peer or bootstrap.dat
221 2014-10-13 16:46:58 <sipa> but i have seen people complain
222 2014-10-13 16:48:14 <BlueMatt> sipa: I'll have a blazing-fast headersfirst benchmark later today (assuming its not supermicro's fault)
223 2014-10-13 16:59:44 <psdn> Is this the place to ask about bitcoind, and the best way to get accepting bitcoin payments on website?
224 2014-10-13 17:10:23 <helo> psdn: probably #bitcoin for starters
225 2014-10-13 17:11:09 <psdn> Thank you helo.
226 2014-10-13 17:13:14 <jgarzik> I've seen reports of the current release client taking days to sync
227 2014-10-13 17:13:41 <jgarzik> I'm too impatient to test that ;p  I restart if it starts spewing orphans, a common sync behavior today
228 2014-10-13 17:14:52 <gmaxwell> the people reporting a week that I've talked to had been doing things like turning it off over night... or seeing it 'get stuck' (really just waiting for the next block) and deleting the blockchain and starting over. But >1 day is not unlikely, it's worse on slower links.
229 2014-10-13 17:16:00 <Adlai> 
ACTION got stuck due to unrelated sillyness, now past 319000. we're syncing, we're syncing!

230 2014-10-13 17:51:53 <blast_> Its a Syncing ship, adlai!
231 2014-10-13 17:52:36 <Adlai> 
ACTION doesn't know whether he can link that ad in here without getting kickbanned

232 2014-10-13 17:53:17 <blast_> most ad's are bad ads
233 2014-10-13 17:54:35 <Adlai> but vat are you sinking... abaut?
234 2014-10-13 18:04:07 <cfields> sipa: i'm not very helpful for headers-first code-review. are there any tests i can help out with?
235 2014-10-13 18:21:14 <dgenr8> jgarzik: few are that patient. so i expect headersfirst to reverse the downtrend in node count
236 2014-10-13 18:23:16 <jgarzik> Adlai, guffaw :)
237 2014-10-13 18:23:27 <Adlai> 
ACTION stopped running his node for months because it took too long to sync after some downtime

238 2014-10-13 18:36:12 <earlz> I asked early. but is there any estimation of when bitcoin 0.10 will be released?
239 2014-10-13 18:39:08 <helo> none precise and accurate
240 2014-10-13 18:40:23 <earlz> Well, like 6 months? a year?
241 2014-10-13 18:40:50 <helo> yes, not unlike those
242 2014-10-13 18:58:40 <sipa> earlz: when it's ready :)
243 2014-10-13 18:58:48 <sipa> earlz: likely within a few months
244 2014-10-13 18:59:16 <earlz> work faster :)
245 2014-10-13 18:59:25 <Adlai> is it customary to see lots of "Error: inputs already spent" and "Non-canonical public key" log messages?
246 2014-10-13 18:59:26 <earlz> Is there a list of things on the roadmap?
247 2014-10-13 18:59:38 <sipa> earlz: headersfirst and bip62
248 2014-10-13 18:59:46 <sipa> are blockers for 0.10
249 2014-10-13 19:00:08 <earlz> Nothing big beyond that?
250 2014-10-13 19:00:08 <sipa> Adlai: yeah
251 2014-10-13 19:00:46 <sipa> well 0.10 already has a large number of changes compared to 0.9.2
252 2014-10-13 19:00:51 <sipa> i lost track
253 2014-10-13 19:01:12 <earlz> yea I've noticed teh code is crazy different. Lot more stuff in chainparams.cpp and all
254 2014-10-13 19:01:22 <earlz> That's just refactorings though
255 2014-10-13 19:01:24 <Luke-Jr> sipa: don't forget proposals? :p
256 2014-10-13 19:03:38 <sipa> Luke-Jr: we'll see where we get with that after headersfirst is in
257 2014-10-13 19:04:15 <earlz> What's the status on headersfirst?
258 2014-10-13 19:04:38 <Adlai> earlz: just got my 9th connection after headfirst finished syncing
259 2014-10-13 19:04:53 <sipa> earlz: it works, maybe
260 2014-10-13 19:05:03 <sipa> the code is safe, maybe
261 2014-10-13 19:11:06 <earlz> does it work, just need bugs and security review?
262 2014-10-13 19:11:30 <sipa> earlz: see my mail
263 2014-10-13 19:13:01 <earlz> your mail?
264 2014-10-13 19:13:21 <sipa> to the mailinglist
265 2014-10-13 19:13:46 <sipa> http://sourceforge.net/p/bitcoin/mailman/message/32921390/
266 2014-10-13 19:35:00 <BlueMatt> cfields: ping
267 2014-10-13 19:35:07 <cfields> pong
268 2014-10-13 19:35:24 <BlueMatt> it looks like you took out the mingwthrd dep?
269 2014-10-13 19:35:58 <cfields> it ends up being pulled in differently by the compiler driver anyway
270 2014-10-13 19:36:17 <BlueMatt> you sure it always does? we had lots of problems with that in the past
271 2014-10-13 19:36:40 <BlueMatt> recall https://bitcoin.org/en/alert/2012-03-16-critical-vulnerability
272 2014-10-13 19:36:56 <cfields> it should as long as -mthreads is used, and that's added by an autoconf check
273 2014-10-13 19:37:14 <cfields> ok, i'll read-up. thanks for letting me know!
274 2014-10-13 19:38:58 <cfields> BlueMatt: i suppose it has to do with properly catching exceptions in bitcoin-qt ?
275 2014-10-13 19:39:14 <BlueMatt> yes, without it exceptions lead to strange crash bugs
276 2014-10-13 19:39:41 <BlueMatt> (the one previously was a crash bug that could be triggered because our network handling has a lot of exception usage)
277 2014-10-13 19:40:53 <cfields> BlueMatt: i was going by this note in gcc man page:
278 2014-10-13 19:41:15 <cfields> http://pastebin.com/raw.php?i=vdX3BHnj
279 2014-10-13 19:42:05 <cfields> verifying now.
280 2014-10-13 19:42:13 <BlueMatt> cfields: ok, it may have been that that was broken on the old gcc we used at the time
281 2014-10-13 19:42:18 <BlueMatt> but yes, please double-check
282 2014-10-13 19:42:47 <BlueMatt> is there an easy way to do a double-check that it is linking mingwthrd at compile/run-time?
283 2014-10-13 19:42:55 <BlueMatt> s/compile/link/
284 2014-10-13 19:43:14 <cfields> yea, it definitely makes sense to try to sanity-check for that
285 2014-10-13 19:43:17 <cfields> i'll see if i can add one
286 2014-10-13 19:43:30 <cfields> we do similar for libc/libstdc++ sanity
287 2014-10-13 19:43:52 <cfields> any chance you can remember a type of exception that wasn't properly handled?
288 2014-10-13 19:43:59 <BlueMatt> all exceptions
289 2014-10-13 19:44:07 <BlueMatt> but its not reliable iirc
290 2014-10-13 19:44:11 <BlueMatt> its a rather strange crash
291 2014-10-13 19:44:14 <cfields> they were racy, i'm guessing?
292 2014-10-13 19:44:24 <BlueMatt> if you ran bitcoind and sent it random crap to the network port, it would crash at that time
293 2014-10-13 19:44:29 <BlueMatt> I dont recall, sorry
294 2014-10-13 19:44:37 <cfields> np, i'll research. thanks again.
295 2014-10-13 20:05:00 <cfields> BlueMatt: you're very right. there's some fishy stuff going on there.
296 2014-10-13 20:05:22 <cfields> looks like that would've broken things
297 2014-10-13 20:55:57 <sipa> cfields: travis failed (randomly?) on your pr
298 2014-10-13 20:56:31 <cfields> heh, i'm glad it seems to always fail on me, at least :)
299 2014-10-13 20:56:33 <cfields> looking
300 2014-10-13 20:58:40 <cfields> mm, odd.
301 2014-10-13 21:01:09 <cfields> sipa: not much to go on, maybe it took a half day for Columbus day...
302 2014-10-13 21:01:20 <cfields> i'll fixup your nits and push a new one
303 2014-10-13 21:22:13 <Luke-Jr> sipa: well, it's ready to merge now.. I'm okay with rebasing after headers first, but I'd rather not if it jeopardises getting it into 0.10 :/
304 2014-10-13 21:23:21 <sipa> Luke-Jr: does it work?
305 2014-10-13 21:23:33 <sipa> as in: does it report errors from block validation?
306 2014-10-13 21:23:51 <sipa> (sorry, haven't looked at the code now)
307 2014-10-13 21:24:49 <Luke-Jr> sipa: yes, it's been working since 0.6.x (though admittedly, I skipped testing the latest rebase since I was expecting to have to rebase again - but the last one was a trivial rebase…)
308 2014-10-13 21:25:26 <Luke-Jr> the only thing that doesn't quite "work" as expected is truly-orphan blocks, which we can't validate
309 2014-10-13 21:25:37 <Luke-Jr> but it has well-defined behaviour for that case
310 2014-10-13 21:25:40 <sipa> hmm, then i'll have to look again
311 2014-10-13 21:26:02 <sipa> i thought you never fixed the problem that ProcessBlock does not report validation errors anymore
312 2014-10-13 21:26:58 <Luke-Jr> sipa: I don't recall that ever being a problem (but I might not even if I had fixed it)
313 2014-10-13 21:28:25 <sipa> Luke-Jr: the code as-is cannot work
314 2014-10-13 21:28:42 <sipa> ProcessBlock does not return rejection reasons
315 2014-10-13 21:28:49 <sipa> i thought i mentioned that before?
316 2014-10-13 21:29:39 <sipa> you'd need to plug into InvalidBlockFound
317 2014-10-13 21:30:19 <Luke-Jr> sipa: I don't see where ProcessBlock fails to return rejection reasons
318 2014-10-13 21:30:46 <sipa> Luke-Jr: because all it does is add the block to the database, and then reorg until it reaches a stable point
319 2014-10-13 21:31:05 <sipa> but that reorg code already catches and deals with all invalidity, because it can result in more reorgs
320 2014-10-13 21:31:18 <Luke-Jr> sipa: it also calls CheckBlock etc
321 2014-10-13 21:31:27 <sipa> yes, i'm talking about the last step only
322 2014-10-13 21:31:32 <sipa> script validation
323 2014-10-13 21:31:36 <sipa> inputs checking
324 2014-10-13 21:31:47 <Luke-Jr> hm
325 2014-10-13 21:31:47 <sipa> not-more-outputs-than-inputs
326 2014-10-13 21:31:58 <sipa> those things are validated asynchronously
327 2014-10-13 21:32:01 <Luke-Jr> does that mean the counter-DoS logic is broken for such invalid blocks?
328 2014-10-13 21:32:07 <sipa> no
329 2014-10-13 21:32:14 <sipa> InvalidBlockFound deals with those
330 2014-10-13 21:32:19 <Luke-Jr> i c
331 2014-10-13 21:34:22 <Luke-Jr> sipa: and this stuff would be a waste to try to address now, since HF will force redoing it anyway, correct?
332 2014-10-13 21:36:14 <Luke-Jr> or is that part of the HF code that's already merged/not changing?
333 2014-10-13 21:39:19 <sipa> so either we use a more generic callback mechanism, where more than just a nodeid can be used to send reject notices to, and the proposal code could pass in its own callback
334 2014-10-13 21:40:00 <sipa> or you use ConnectBlock directly rather than ProcessBlock, but that requires duplicating a bunch of logic for now that is in Accept* rather than Connect* or Check*
335 2014-10-13 21:40:27 <sipa> and that is stuff that is touched by headersfirst, so why i suggested doing it afterwards
336 2014-10-13 21:41:45 <sipa> Ah, i made that comment on 3727, not on 1816
337 2014-10-13 21:41:48 <sipa> but it applies equally
338 2014-10-13 21:42:13 <Luke-Jr> wait, doesn't that mean submitblock is broken right now, even without changes?
339 2014-10-13 21:43:01 <Luke-Jr> (since it will accept invalid blocks)
340 2014-10-13 21:43:11 <sipa> seems like it, yes
341 2014-10-13 21:43:56 <Luke-Jr> seems like a bugfix for that fixes proposals too <.<
342 2014-10-13 21:44:01 <Luke-Jr> definitely should fix that in any case
343 2014-10-13 21:45:07 <Luke-Jr> sipa: please set Milestone 0.10 for at least this, so we don't forget: https://github.com/bitcoin/bitcoin/issues/5083
344 2014-10-13 22:43:50 <Luke-Jr> http://blog.pryds.eu/2014/06/compile-bitcoin-core-on-raspberry-pi.html <-- I thought we couldn't handle Pi anymore?
345 2014-10-13 22:43:57 <Luke-Jr> did headers first fix that or something?
346 2014-10-13 22:48:01 <gmaxwell> Luke-Jr: "couldn't handle" ... well if you're happy with it being barely usable then it can run on anything... pretty much.
347 2014-10-13 22:49:04 <Luke-Jr> gmaxwell: <512 MB RAM?
348 2014-10-13 22:52:13 <Luke-Jr> hm, thoughts on merging 1816 anyway, since the only issue with it is something that's already a bug regardless of it?
349 2014-10-13 22:52:50 <Luke-Jr> maybe better to just wait, but if the bug doesn't get fixed until RC, it'll have a hard time as a "new feature beyond freeze"