1 2014-05-22 00:15:57 <warren> I haven't been following the recent news, do any of the major clients support Trezor now?
  2 2014-05-22 01:13:47 <CoinHeavy> Given any block, the first transaction contains the newly minted/generated/unlocked coins.  Is this statement always true?  It seems to be from random sampling but I have not done a full scan nor have I found a protocol definition stating this to absolutely be the case.
  3 2014-05-22 01:15:06 <justanotheruser> CoinHeavy: I believe blocks without coinbase tx are invalid
  4 2014-05-22 01:15:48 <gmaxwell> CoinHeavy: its a requirement that the first transaction be the coinbase txn. It's one of the first checks made against a block.
  5 2014-05-22 01:15:53 <CoinHeavy> but does that coinbase tx necessarily need to occupy the first space in the array of transactions, or is that just convention?
  6 2014-05-22 01:15:59 <CoinHeavy> excellent — thank you
  7 2014-05-22 01:17:09 <cbeams> gmaxwell: if it is indeed required that the coinbase tx is the first, we should probably update http://bitcoindev.us.to/en/developer-reference#term-coinbase-tx to be explicit about it.
  8 2014-05-22 01:17:28 <cbeams> I've noticed before that it's not. Simply states "Every block must include a coinbase transaction", and goes no further.
  9 2014-05-22 01:18:28 <gmaxwell> it is indeed required. it's even well documented in the only prior place I would have expected someone to look: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages
 10 2014-05-22 01:19:07 <gmaxwell> (item 6)
 11 2014-05-22 01:20:15 <CoinHeavy> gmaxwell: thank you — I was indeed looking at the developer reference cbeams linked because the wiki is often out of date (e.g. getnetworkhashps is not listed)
 12 2014-05-22 01:20:51 <harding> cbeams: I swore we added that coinbase had to be first to the dev docs.  I'll look in a moment.
 13 2014-05-22 01:20:57 <gmaxwell> the developer reference page itself is a very new document and not yet worn smooth by many hands. :P  the tech details in it are mostly extracted from the wiki.
 14 2014-05-22 01:21:21 <CoinHeavy> taking for instance the recent coinbase txn of 107cf2c46a67ad56119302b095f3c85b53a45ff0f103b4c59849dbb186439aab (newly minted coins) — is there a way that I could determine programatically that the value of 25.00780000 was made up of 25 ‘new’ coins and 0.0078 in miners’ fees (old coins)?  Assuming that I did not have knowledge external to that block of the current reward amount.
 15 2014-05-22 01:21:44 <gmaxwell> CoinHeavy: no.
 16 2014-05-22 01:21:45 <cbeams> harding: https://github.com/saivann/bitcoin.org/issues/132
 17 2014-05-22 01:22:03 <gmaxwell> CoinHeavy: and if you try to do that you're just going to end up with some psycho conclusions like negative fees on some blocks. :)
 18 2014-05-22 01:22:26 <harding> cbeams: thanks.  bugs with the docs from now on should go to the bitcoin/bitcoin.org repository.  (but leave that bug where it is)
 19 2014-05-22 01:22:39 <cbeams> harding: good to know, thanks.
 20 2014-05-22 02:26:03 <gmaxwell> https://air.mozilla.org/rust-meetup-may-2014/ at 14 minutes pretty scarry, ubuntu shipped a patched gcc at one point that made signed char x =1; unsigned char y = 255; return x>y;  compile incorrectly.
 21 2014-05-22 02:26:27 <Luke-Jr> gmaxwell: for C?
 22 2014-05-22 02:26:42 <coryfields> wumpus: I have a working signature detacher/attacher. I need to get with gavin and have him verify that a real apple cert behaves the same as a self-signed one. Assuming i can get in touch with him, I'll try to have a pull req up tomorrow
 23 2014-05-22 02:27:26 <Luke-Jr> gmaxwell: at least GCC warns if you even try to do that..
 24 2014-05-22 02:27:37 <gmaxwell> Luke-Jr: yea, in C.
 25 2014-05-22 02:29:01 <coryfields> gmaxwell: along the same lines, it's interesting to check out the bugs that musl libc reported to glibc
 26 2014-05-22 02:29:10 <coryfields> it's more than a handful :)
 27 2014-05-22 02:30:12 <gmaxwell> (I've reported my share of compiler bugs, but never one as trivial as that. And amazingly ubuntu managed to compile the whole distro with that compiler.)
 28 2014-05-22 02:30:17 <Luke-Jr> coryfields: how many of those are closed WONTFIX? :p
 29 2014-05-22 02:30:44 <Luke-Jr> gmaxwell: probably signed > unsigned isn't in any code since it's been a warning for a while
 30 2014-05-22 02:31:08 <gmaxwell> well I'm sure thats not true, but indeed perhaps not in much code. :)
 31 2014-05-22 02:32:46 <coryfields> Luke-Jr: yea, they're likely the kind of edge-cases that usually default to "keep doing it how we've always done it"
 32 2014-05-22 02:32:56 <Luke-Jr> gmaxwell: everyone doesn't use -Werror ? :p
 33 2014-05-22 02:33:13 <gmaxwell> hell no, because the compilers keep changing what they warn on. :P
 34 2014-05-22 02:33:42 <coryfields> Luke-Jr: check out clang's -Weverything if you want some serious noise :)
 35 2014-05-22 02:33:46 <Luke-Jr> gmaxwell: I don't think I've seen a contradiction, just improved warnings ;p
 36 2014-05-22 02:33:52 <gmaxwell> "Warning: Statement with less than 50 parentheses."
 37 2014-05-22 02:35:56 <gmaxwell> Luke-Jr: uninitialized analysis has been pretty unstable the last couple years... though its mostly improved, it's also become common for compilers to emit varrious style warnings like assuming you don't know the order of operations. e.g. warning about a+b<<x+y without parens. Which might be fine and all, but not when it breaks the build for a _user_ who happens to have a newer/older compiler than you.
 38 2014-05-22 02:36:38 <gmaxwell> (what I mean wrt uninitialized analysis, is that you write code that is correct and your compiler likes it but then a user with a compiler 6 months older fails the build because its uninit analysis is less smart)
 39 2014-05-22 02:36:51 <Luke-Jr> gmaxwell: I'm not advocating *users* build with -Werror, just developers while they work on code.
 40 2014-05-22 02:37:15 <Luke-Jr> coryfields: 1019 warnings generated. holy cow
 41 2014-05-22 02:37:29 <gmaxwell> Luke-Jr: oh derp. yea sure.
 42 2014-05-22 02:37:34 <Luke-Jr> warning: no previous extern declaration for non-static variable 'schedstart' [-Wmissing-variable-declarations]
 43 2014-05-22 02:37:39 <Luke-Jr> why is this a warning at all? XD
 44 2014-05-22 02:37:43 <coryfields> Luke-Jr: it's actually worth taking a look...
 45 2014-05-22 02:38:15 <coryfields> i typically go through and turn off the really stupid ones that amount to 90% of the noise. But I've found a few legit bugs that way
 46 2014-05-22 02:40:39 <Luke-Jr> ./logging.h:55:38: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
 47 2014-05-22 02:40:40 <Luke-Jr> no crap
 48 2014-05-22 02:40:42 <Luke-Jr> <.<
 49 2014-05-22 02:41:52 <coryfields> Luke-Jr: iirc virtual function shadowing was one of the helpful ones
 50 2014-05-22 02:42:05 <Luke-Jr> coryfields: no virtual functions in C :P
 51 2014-05-22 02:42:07 <coryfields> not sure why regular warnings didn't catch em, though. you'd think they would
 52 2014-05-22 02:42:39 <coryfields> oh, heh
 53 2014-05-22 02:42:52 <Luke-Jr> warning: passing 'void (void *, double)' to parameter of type 'void *' converts between void pointer and function pointer [-Wpedantic]
 54 2014-05-22 02:42:56 <Luke-Jr> wait, is that really a problem?
 55 2014-05-22 02:43:03 <Luke-Jr> how am I supposed to say "any function pointer"? :/
 56 2014-05-22 02:44:11 <wumpus> coryfields: great, let's hope that works
 57 2014-05-22 02:44:51 <wumpus> Luke-Jr: a warning that annoys me is the 'unused return value warning'... there is no way to avoid it, even if you really want to ignore the result
 58 2014-05-22 02:46:30 <coryfields> wumpus: can you not cast it to void like you can with an unused param?
 59 2014-05-22 02:46:37 <wumpus> coryfields: no
 60 2014-05-22 02:46:53 <wumpus> that's the first thing anyone would try, and that doesn't foil it
 61 2014-05-22 02:48:25 <wumpus> in an everlasting battle between developers and compilers who is more obnoxious :)
 62 2014-05-22 02:52:36 <Peezr> Can anyone help answer a question about version/protocol handshake?
 63 2014-05-22 02:53:35 <Peezr> Is there anything that would prevent an older client (ex. version 0.6.3) from talking to a newer client (0.8.7)?
 64 2014-05-22 02:58:07 <gmaxwell> 0.6.3 no, unless your date is wrong, versions prior to 0.2.10 won't connect to the current network.
 65 2014-05-22 02:59:21 <Peezr> gmaxwell: I figured as well but I'm having an issue with a client connecting.
 66 2014-05-22 02:59:25 <Peezr> What exactly do you mean by date?
 67 2014-05-22 02:59:40 <Peezr> I thought it was based on client,protocol,wallet version?
 68 2014-05-22 03:00:20 <gmaxwell> the protocol changed after a particlar date in 2012.
 69 2014-05-22 03:00:39 <gmaxwell> and old versions will speak the old protocol prior to that date.
 70 2014-05-22 03:00:57 <gmaxwell> (which is the reason 0.2.10 cant connect anymore)
 71 2014-05-22 03:06:56 <Peezr> Do you have a second to check my debug.log?
 72 2014-05-22 03:06:56 <Peezr> http://pastebin.com/yhy7yVLY
 73 2014-05-22 03:06:56 <Peezr> This is the first time I have tried to connect and will be building a new leveldb blockchain.
 74 2014-05-22 03:06:59 <Peezr> My compilations work fine, seems that genesis hash is found and started.  Just can't connect to peer
 75 2014-05-22 03:07:22 <Peezr> It sends version req to IP. but shortly disconnects after no response
 76 2014-05-22 03:09:22 <Peezr> So any theories why I can't get my new version (0.8) to connect to current version 0.6 of Cannacoin?
 77 2014-05-22 03:09:36 <Peezr> My debug seems pretty normal
 78 2014-05-22 03:09:37 <wumpus> not really, you're on your own there
 79 2014-05-22 03:09:40 <Peezr> just simply not getting a response.
 80 2014-05-22 03:09:41 <justanotheruser> Peezr: scamcoins are offtopic
 81 2014-05-22 03:10:14 <Peezr> justanotheruser: im referring to bitcoin version checking, regardless if its for another coin.
 82 2014-05-22 03:10:53 <wumpus> if it's for another coin it's off-topic here
 83 2014-05-22 03:13:09 <Peezr> So any ideas why my bitcoin 0.6 wont connect to 0.8 if the version isn't out of scope?
 84 2014-05-22 03:13:21 <Peezr> Ports etc has all stayed the same.
 85 2014-05-22 03:13:31 <justanotheruser> Peezr: probably a database problem
 86 2014-05-22 03:13:41 <Peezr> It's a fresh install
 87 2014-05-22 03:13:45 <Peezr> never downloaded the chain before
 88 2014-05-22 03:13:52 <justanotheruser> Peezr: yep. Don't run v0.6
 89 2014-05-22 03:14:09 <Peezr> Im trying to connect to a node running 0.6
 90 2014-05-22 03:14:16 <Peezr> From my current version of 0.8
 91 2014-05-22 03:14:27 <Peezr> Im not downgrading, rather upgrading
 92 2014-05-22 03:14:31 <Peezr> but still trying to keep my peers
 93 2014-05-22 03:14:40 <justanotheruser> people shouldn't run v0.6
 94 2014-05-22 03:14:56 <wumpus> I suggest you try to debug your own problems
 95 2014-05-22 03:15:19 <Peezr> I've been trying wumpus, thats why I came here to ask more about version handshakes.
 96 2014-05-22 03:15:25 <Peezr> If there should be anything else I should consider...
 97 2014-05-22 08:59:49 <wumpus> so, darkcoin is basically bitcoin core on an altchain with a coinjoin implementation slapped on top, but it seems they don't release the source of the coinjoin part (at least I wasn't able to find it in their repository...).. that tactic smells a bit fishy to me, although they're probably afraid of the ease with which it could be backported to bitcoin :-)
 98 2014-05-22 09:00:25 <wumpus> but everyone gets to copy our stuff
 99 2014-05-22 09:02:17 <Eliel> sounds somewhat like "we want to keep our pump&dump for as long as possible"
100 2014-05-22 09:04:05 <Luke-Jr> wumpus: wanna GPL BCCore? :P
101 2014-05-22 09:04:07 <wumpus> so instead of collaboration, development gets perverted into *add some feature, hype it up as a new coin*... it's one dev business model I suppose
102 2014-05-22 09:06:03 <wumpus> Luke-Jr: I don't think switching licenses is a good idea, but in retrospect it makes some sense
103 2014-05-22 09:06:34 <Luke-Jr> wumpus: we can't really complain if we explicitly allow it :x
104 2014-05-22 09:06:56 <Luke-Jr> wumpus: BTW, I PM'd you (in case you don't see PMs automatically)
105 2014-05-22 09:07:03 <sipa_> if people are silly enough to use an altcoin (and by use, i mean as a currency) that is closed source...
106 2014-05-22 09:16:01 <wumpus> it's baffling indeed
107 2014-05-22 09:16:16 <Hasimir> Luke-Jr, you'd need to consider lib impications for those projects using parts of bitcoind as a library ... probably need to dual-license it for that
108 2014-05-22 09:17:01 <Hasimir> maybe gpl & lgpl
109 2014-05-22 09:17:02 <Luke-Jr> Hasimir: relicensing (at least with free licenses) is never retroactive
110 2014-05-22 09:17:10 <wumpus> nah the consensus part should really be MIT
111 2014-05-22 09:17:13 <Hasimir> true
112 2014-05-22 09:17:13 <Luke-Jr> Hasimir: besides, GPL is just fine for libraries ;)
113 2014-05-22 09:17:30 <Hasimir> heh
114 2014-05-22 09:17:50 <Luke-Jr> wumpus: I think I agree. Just because GPL causes problems with other free licenses.
115 2014-05-22 09:17:55 <Hasimir> you ever met RMS?
116 2014-05-22 09:18:09 <Luke-Jr> Hasimir: no, but I ran an email relay for him once when LKML banned his email server :p
117 2014-05-22 09:18:35 <Hasimir> ah, yeah, he's an interesting guy
118 2014-05-22 09:19:08 <Luke-Jr> 
ACTION wonders if that's actually still setup O.o

119 2014-05-22 09:19:09 <Hasimir> my advice, if you ever go to dinner with him, don't sit directly opposite him and expect to maintain your appetite
120 2014-05-22 09:19:18 <Hasimir> but otherwise he's a cool guy
121 2014-05-22 09:19:42 <Luke-Jr> he's wrong about everything but software though ;p
122 2014-05-22 09:19:58 <Hasimir> heh
123 2014-05-22 09:20:23 <Hasimir> not quite everything, but pretty close
124 2014-05-22 09:20:34 <Luke-Jr> heh, of course I didn't mean that literally ;)
125 2014-05-22 09:20:50 <Hasimir> I know  :)
126 2014-05-22 09:56:52 <sipa_> Hasimir: i actually have had lunch with him, and he actually acknowledged that for some cases more permissive (well, from a point of view) licenses may make sense... for example when the value of getting a protocol adopted outweighs the value of having a free implementation
127 2014-05-22 09:57:50 <Hasimir> well, that is why he allowed the lgpl in the first place, so it makes sense
128 2014-05-22 09:59:37 <Hasimir> anyway, I gotta "go dark" for a bit, got a national council meeting on the other network about to start shortly
129 2014-05-22 10:09:36 <netg_> wumpus: is there a > 5% chance you/btc devs would backport darkcoins coinjoin?
130 2014-05-22 10:09:49 <netg_> or other complete, tested coinjoin implementations
131 2014-05-22 10:12:55 <dizko> has anything changed with the 0.9 release which would allow spent outputs to still get listed in listunspent ?
132 2014-05-22 10:15:18 <dizko> is there a wallet format change at all?  i can revert back to 0.8.x right?
133 2014-05-22 10:16:00 <warren> wallet should work, but your index won't be compatible with 0.8.x
134 2014-05-22 10:16:22 <warren> there's no reason to downgrade though
135 2014-05-22 10:16:41 <netg_> wumpus: btw, darkcoins release schedule says: release of darksend (coinjoin) on 25. may, then a bit (some days) of testing  then open sourcing
136 2014-05-22 10:18:46 <dizko> warren: listunspent is giving me spent outputs
137 2014-05-22 10:19:15 <warren> dizko: are you sure you don't have corruption?
138 2014-05-22 10:19:43 <dizko> how can i be sure?
139 2014-05-22 10:19:48 <warren> reindex
140 2014-05-22 10:20:09 <michagogo> Did they come up with a decentralized coinjoin?
141 2014-05-22 10:22:14 <netg_> yeah, more or less decentralized
142 2014-05-22 10:22:21 <netg_> mixing will be done by so called "masternode"
143 2014-05-22 10:22:30 <netg_> s
144 2014-05-22 10:22:31 <warren> ...
145 2014-05-22 10:22:48 <warren> it's decentralized except for the part that is centralized?
146 2014-05-22 10:23:27 <netg_> i cant the judge this, the target is 1000 masternodes
147 2014-05-22 10:23:36 <netg_> so i guess depends on you POV then
148 2014-05-22 10:24:02 <wumpus> netg_: sure, if their implementation makes sense
149 2014-05-22 10:24:37 <netg_> is this a policy change, with you taking over?
150 2014-05-22 10:24:43 <netg_> i thought andressen was against it
151 2014-05-22 10:24:47 <wumpus> a policy change?
152 2014-05-22 10:25:46 <wumpus> there has been an open issue for it for months https://github.com/bitcoin/bitcoin/issues/3226
153 2014-05-22 10:25:53 <netg_> opinion change, new direction
154 2014-05-22 10:26:22 <wumpus> in my opinion what is holding it back is that no one implemented it, nothing else
155 2014-05-22 10:26:26 <netg_> ok sorry, seems like i remember wrong, sorry
156 2014-05-22 10:26:43 <Luke-Jr> netg_: is it coinjoin or mixing?
157 2014-05-22 10:27:27 <Luke-Jr> two very different things
158 2014-05-22 10:27:33 <wumpus> and as bitcoin core's wallet is not very actively being developed I would bet on almost all other wallets having it first  :)
159 2014-05-22 10:28:07 <dizko> warren: will there be anything to see in the log which would make it clear that there had been corruption from the reindex?
160 2014-05-22 10:28:14 <wumpus> Amir's darkwallet already has coinjoin right?
161 2014-05-22 10:29:27 <buZz> yes
162 2014-05-22 10:30:08 <wumpus> I should try it out some time
163 2014-05-22 10:30:11 <netg_> Luke-Jr: "Darksend" is an implementation of coinjoin
164 2014-05-22 10:37:45 <wumpus> Luke-Jr: the confusing thing there is that at least the darkwallet guys call coinjoin 'mixing'
165 2014-05-22 10:38:16 <wumpus> the implementation is here https://github.com/darkwallet/darkwallet/blob/develop/js/backend/services/mixer.js
166 2014-05-22 10:39:09 <wumpus> wallets coordinate the join on a websockets chat server
167 2014-05-22 10:39:22 <Luke-Jr> sigh
168 2014-05-22 12:17:24 <graingert> BlueMatt: bitcoin uses Kademlia for DHT right?
169 2014-05-22 12:20:44 <sipa> lol
170 2014-05-22 12:22:07 <graingert> sipa: :(
171 2014-05-22 12:22:48 <sipa> graingert: in case you're not joking: bitcoin doesn't use a DHT, and for good reason
172 2014-05-22 12:23:07 <graingert> sipa: ah yes. Don't auto ban me
173 2014-05-22 12:23:24 <buZz> DONT TAZE ME BRO
174 2014-05-22 12:23:52 <graingert> sipa: ah bitcoin is randomly wired
175 2014-05-22 12:24:01 <sipa> yes, and every node has all data
176 2014-05-22 12:25:10 <graingert> DNS bootstrap, I remember now
177 2014-05-22 12:25:29 <sipa> uh yes, but that is completely orthogonal
178 2014-05-22 12:25:50 <sipa> bootstrapping is the process of learning initial nodes to connect to
179 2014-05-22 12:25:58 <graingert> yes
180 2014-05-22 12:25:59 <graingert> I know
181 2014-05-22 12:26:10 <graingert> maybe I was thinking of CJDNS...
182 2014-05-22 12:26:20 <graingert> I've clearly been dummed down by webdev
183 2014-05-22 12:26:22 <graingert> oh well
184 2014-05-22 12:32:22 <graingert> sipa: all the peers know everything?
185 2014-05-22 12:33:21 <sipa> yes
186 2014-05-22 12:33:48 <sipa> bitcoin uses a zero-trust model (for almost everything), so it needs all data to be able to verify what peers say
187 2014-05-22 12:34:06 <graingert> sipa: I know it needs all the blockchain data
188 2014-05-22 12:34:35 <sipa> the only thing that is not verified is the order of otherwise valid transactions, as order is not well defined in an asynchronous distributed network
189 2014-05-22 12:34:58 <sipa> (not every node will always agree on which version of a conflicting transaction was first)
190 2014-05-22 12:48:27 <volante> if my function does TRY_LOCK() which success, and then it calls another function that does LOCK() on the same lock, will that be fine so long as they're the same thread?
191 2014-05-22 12:49:43 <sipa> volante: discouraged, but it will work
192 2014-05-22 12:49:59 <sipa> (we use recursive locks)
193 2014-05-22 12:50:40 <volante> sipa: i want to call GetNodeStateStats(), but I don't want it to block on the lock
194 2014-05-22 12:50:51 <volante> so im doing TRY_LOCK first and then calling GetNodeStateStats() if i have the lock
195 2014-05-22 12:50:59 <sipa> ok
196 2014-05-22 12:51:44 <volante> is there a better way to do it, or is that acceptable?
197 2014-05-22 12:51:53 <sipa> go for it
198 2014-05-22 12:53:09 <volante> sweet, cos this will end up in a pull request :)
199 2014-05-22 12:54:03 <sipa> are you working on the GUI view of node stats?
200 2014-05-22 12:54:16 <volante> yep
201 2014-05-22 12:54:19 <sipa> cooL!
202 2014-05-22 12:54:42 <volante> im making it not block on any locks as suggested by wumpus
203 2014-05-22 13:01:33 <devthink_> Hello, I have a transaction that I will be sending to multiple participants for signature.  However, when I pass it to the first participant, he will be able to change the outputs to his addresses.  Is there anything I can do, like signing a 0.00 input, that will cause the transaction to fail if the outputs are changed?  Thanks.
204 2014-05-22 13:02:56 <sipa> either use SIGHASH_ANYONECANSIGN
205 2014-05-22 13:03:10 <sipa> or you use two iterations... one for adding all inputs/outputs, one for signing
206 2014-05-22 13:15:45 <devthink_> I have three iterations, one adding the inputs, one adding the outputs, and one for signing. If it came back to me after all the signatures then I could recheck the outputs. How would SIGHASH_ANYONECANSIGN work?
207 2014-05-22 13:18:57 <michagogo> ANYONECANSIGN?
208 2014-05-22 13:19:17 <michagogo> I don't think I've ever heard of that, unless you mean -PAU
209 2014-05-22 13:19:19 <michagogo> PAY*
210 2014-05-22 13:21:27 <devthink_> found SIGHASH_ANYONECANPAY in the wiki
211 2014-05-22 13:31:35 <michagogo> Right. Basically, it doesn't sign the inputs.
212 2014-05-22 14:39:16 <maaku> hrm.. serializing hashes does not preserve their lexigraphical sort order... that's annoying
213 2014-05-22 14:42:47 <sipa> lexicographic == big endian
214 2014-05-22 17:54:21 <shadowbroker> anyone use cryptocoinjs? it looks legit, but there doesnt seem to be so many watchers on github...
215 2014-05-22 18:31:27 <maaku> sipa: c++ question -- how evil would it be to use const_cast to overwrite a reference?
216 2014-05-22 18:32:37 <coryfields> sipa: ping
217 2014-05-22 18:32:43 <coryfields> maaku: yikes, very
218 2014-05-22 18:33:13 <maaku> the "value_type" of the hash trie container is std::pair<const Key, Data&>, and I'm storing it in the iterator
219 2014-05-22 18:33:48 <maaku> I want operator++() on the iterator to update these values
220 2014-05-22 18:34:12 <maaku> the alternative is making and returning throwaway pairs instead of returning a reference...
221 2014-05-22 18:35:26 <maaku> in other words its all data I control, but my concern would be having technically undefined behavior in consensus code
222 2014-05-22 18:44:54 <coryfields> maaku: seems the most reasonable thing would be to switch the value_type from a typedef to a class and give it an operator++, no?
223 2014-05-22 18:45:08 <coryfields> *from a pair
224 2014-05-22 18:51:21 <maaku> well the operator++ would be on the iterator not the value type, but yes a smart class with a pair-like interface is probably better
225 2014-05-22 18:51:29 <maaku> thanks
226 2014-05-22 18:52:41 <ajweiss> do any of the folks from blockchain.info hang out on here?  i've been parsing the blockchain and comparing my stats to theirs and i've found a few problems in their data...
227 2014-05-22 18:52:57 <pigeons> no one is suprised ;)
228 2014-05-22 18:56:56 <coryfields> sipa: ping me when you're around please. I'm starting on the libsecp integration, want to make sure I'm doing it as you intended
229 2014-05-22 19:11:32 <mtgox555> ajweiss blockchain.info is generally known to have errors all over the place. Their database is wrong all the time.
230 2014-05-22 19:29:19 <ajweiss> is there a better source for general blockchain statistics?
231 2014-05-22 19:33:11 <mtgox555> I havnt used them myself but helloblock is trying to become the go-to place for blockchain api. there is also blockr.io
232 2014-05-22 20:58:22 <lianj> 
ACTION wants testnet4. testnet3 is so spammed

233 2014-05-22 21:09:53 <maaku> ajweiss: the block chain and your own analysis:
234 2014-05-22 21:33:14 <CoinHeavy> For transactions, as a convention, to what does the ‘v’ in ‘vin’ and ‘vout’ refer?
235 2014-05-22 21:37:27 <CoinHeavy> vector is the most reasonable thing I can come up with but that’s just speculation
236 2014-05-22 21:50:20 <sipa> CoinHeavy: indeed
237 2014-05-22 22:05:43 <maaku> CoinHeavy: vector as in std::vector
238 2014-05-22 22:14:31 <davout> how do i get the scriptPubKey value for a multisig address i created w/ addmultisigaddress ?
239 2014-05-22 22:33:06 <harding> davout: The RPC `validateaddress <address>` will return the redeemScript in the "hex" field.
240 2014-05-22 22:34:11 <davout> harding: ty, i already have the redeemScript tho
241 2014-05-22 22:34:19 <davout> apparently i need both -> a914f815b036d9bbbce5e9f2a00abd1bf3dc91e9551087
242 2014-05-22 22:34:23 <davout> whoops
243 2014-05-22 22:34:28 <davout> meant https://gist.github.com/gavinandresen/3966071
244 2014-05-22 22:35:16 <harding> davout: this looks like a support issue.  I recommend you switch to #bitcoin (I'm in there too).
245 2014-05-22 23:22:25 <stephenreed> mtgox555: thanks for the info. I registered at helloblock.
246 2014-05-22 23:47:38 <coryfields> wumpus: around?
247 2014-05-22 23:50:08 <sipa> unlikely at this hour :)
248 2014-05-22 23:51:22 <coryfields> thought i might catch him before bed, looks like i have to wait another cycle now :)