1 2013-11-11 00:16:24 <gavinandresen> Luke-Jr: I fixed the struct/class mismatch warnings and pushed to master
  2 2013-11-11 00:17:48 <dobry-den> oh, script encodes numbers with OpenSSL's BN_bn2mpi
  3 2013-11-11 00:37:34 <dobry-den> did openssl make up "mpi encoding"?
  4 2013-11-11 00:39:18 <sipa> i don't think so
  5 2013-11-11 00:39:39 <sipa> maybe it comes from here: http://en.wikipedia.org/wiki/Message_Passing_Interface
  6 2013-11-11 00:41:52 <dobry-den> thanks. i wouldve never found that
  7 2013-11-11 00:42:15 <sipa> ;;google MPI
  8 2013-11-11 00:42:16 <gribble> Meeting Professionals International: <http://www.mpiweb.org/>; Message Passing Interface - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Message_Passing_Interface>; Open MPI: Open Source High Performance Computing: <http://www.open-mpi.org/>
  9 2013-11-11 00:42:53 <dobry-den> i was all up in 'mpi encoding' and derivatives because surely 'mpi' would be too broad
 10 2013-11-11 00:42:55 <dobry-den> damn
 11 2013-11-11 00:44:13 <dobry-den> i had to look at how bitcoinj handling numbers in its script code to arrive here
 12 2013-11-11 00:46:45 <BlueMatt> heh, writing that was...fun...or something
 13 2013-11-11 00:47:13 <dobry-den> BlueMatt: that's your project?
 14 2013-11-11 00:47:34 <BlueMatt> no, but i wrote that particular code
 15 2013-11-11 00:51:36 <BlueMatt> 
ACTION goes back to fixing that particular code

 16 2013-11-11 00:51:50 <dobry-den> what was the solution before it?
 17 2013-11-11 00:52:00 <dobry-den> i unfortunately have to borrow that code
 18 2013-11-11 00:52:10 <BlueMatt> before it, bitcoinj didnt implement full script execution
 19 2013-11-11 00:52:40 <BlueMatt> its oss for a reason
 20 2013-11-11 00:52:50 <BlueMatt> though you're probably better off not copy/pasting but depending on it
 21 2013-11-11 00:53:23 <BlueMatt> considering tiny bugs could be very dangerous
 22 2013-11-11 00:54:47 <dobry-den> it's pretty nebulous
 23 2013-11-11 00:57:35 <dobry-den> not referring to your code, but what mpi is, even reading this wiki. could JNI be a solution?
 24 2013-11-11 00:57:42 <dobry-den> ive never used it before
 25 2013-11-11 00:57:52 <BlueMatt> what are you actually trying to do?
 26 2013-11-11 00:59:18 <dobry-den> i dont understand how numbers are encoded/decoded in scripts
 27 2013-11-11 00:59:28 <BlueMatt> if you're talking about just the mpi stuff, thats not too complicated, Im pretty sure its pretty reliable
 28 2013-11-11 00:59:36 <sipa> dobry-den: sign bit + data
 29 2013-11-11 00:59:53 <sipa> the highest bit of the first pushed byte is the size (0: positive, 1: negative)
 30 2013-11-11 01:00:01 <sipa> the rest of the bits encode the data
 31 2013-11-11 01:00:41 <sipa> eh
 32 2013-11-11 01:00:43 <sipa> s/size/sign/
 33 2013-11-11 01:00:46 <dobry-den> then what's mpi for
 34 2013-11-11 01:01:02 <sipa> that's how MPI encoding works, apparently
 35 2013-11-11 01:01:23 <sipa> oh, but bitcoin does it little-endian, instead of big-endian
 36 2013-11-11 01:01:26 <sipa> don't ask me why
 37 2013-11-11 01:01:41 <BlueMatt> huh?
 38 2013-11-11 01:01:44 <BlueMatt> are you sure about that?
 39 2013-11-11 01:02:08 <sipa> i'm looking at the code, which says "swap data to big endian", before calling MPI
 40 2013-11-11 01:02:24 <dobry-den> BlueMatt: bitcoinj itself has that reverseBytes incantation before every encodeMPI
 41 2013-11-11 01:04:06 <BlueMatt> ahh, yes
 42 2013-11-11 01:04:33 <sipa> also, MPI uses a 4-byte length prefix
 43 2013-11-11 01:04:50 <sipa> while bitcoin uses its weird mix of push operators to denote size
 44 2013-11-11 01:05:10 <BlueMatt> bitcoin scripts are quite a mix of different encodings
 45 2013-11-11 01:05:15 <sipa> yeah..
 46 2013-11-11 01:05:21 <BlueMatt> well, all of bitcoin
 47 2013-11-11 01:05:22 <dobry-den> yeah
 48 2013-11-11 01:05:34 <dobry-den> fortunately i figured out der
 49 2013-11-11 01:05:58 <dobry-den> well, enough other noobs on stackoverflow
 50 2013-11-11 01:06:01 <sipa> it's not that bad... it's really little endian everywhere, and all crypto stuff is consider as byte arrays (which internally may use big endian)
 51 2013-11-11 01:06:27 <BlueMatt> sipa: its not that bad, until you're reimplementing ig...
 52 2013-11-11 01:06:31 <BlueMatt> dobry-den: thats what you think
 53 2013-11-11 01:06:43 <BlueMatt> but with bitcoin, you have to use openssl's specific der en/decoding
 54 2013-11-11 01:06:50 <sipa> which leads to weird things like sha256 being applied to the block header, the result being encoded as little endian in a 32-byte arrays, which then gets interpreted as little-endian 256-bit number
 55 2013-11-11 01:07:00 <BlueMatt> which accepts some marginally invalid things
 56 2013-11-11 01:07:04 <BlueMatt> and rejects others
 57 2013-11-11 01:07:04 <sipa> eh, encoded as big-endian in 32-byte arrays
 58 2013-11-11 01:07:14 <sipa> quite some invalid things, really
 59 2013-11-11 01:07:20 <sipa> you can just put junk inside
 60 2013-11-11 01:07:25 <sipa> or use negative numbers
 61 2013-11-11 01:07:43 <BlueMatt> well, ok, yes
 62 2013-11-11 01:10:38 <dobry-den> this is the final prong of my rough implementation
 63 2013-11-11 01:12:10 <BlueMatt> what are you doing with this implementation?
 64 2013-11-11 01:12:26 <dobry-den> having fun
 65 2013-11-11 01:13:11 <dobry-den> id like to polish it over time, but ive started experimenting with people's ideas
 66 2013-11-11 01:13:12 <BlueMatt> ok, as long as you're not building an exchange on a barely-tested implementation :p
 67 2013-11-11 01:13:50 <BlueMatt> (there's far too much of that already...)
 68 2013-11-11 01:14:03 <dobry-den> at the very least, ive stolen every test suite i could find
 69 2013-11-11 01:46:01 <michagogo> cloud|grn_home: That thing with some clients signing in a way that doesn't match other clients (or the reference implementation) rings a bell
 70 2013-11-11 01:46:14 <michagogo> cloud|I don't remember the details, but there *was* something
 71 2013-11-11 01:52:06 <grn_home> michagogo|cloud - Here's my sample...  http://www.grnbrg.org/blockchain-problem.html
 72 2013-11-11 01:52:21 <grn_home> Very strange.
 73 2013-11-11 01:52:29 <michagogo> cloud|already saw that
 74 2013-11-11 01:52:40 <michagogo> cloud|I can't remember, though, what was causing it :-/
 75 2013-11-11 01:53:25 <grn_home> I see.  Weird that it should produce a signature that verifies with a different address on other clients, though.
 76 2013-11-11 01:54:16 <michagogo> cloud|grn_home: Not particularly
 77 2013-11-11 01:54:42 <michagogo> cloud|Something about the way ecdsa sigs work
 78 2013-11-11 01:56:05 <grn_home> Yeah, I suppose.  Multiple solutions to the same problem.
 79 2013-11-11 01:59:09 <michagogo> cloud|I wish I could remember the details :-/
 80 2013-11-11 02:40:44 <hanihani> im building a small exchange and I was looking into using Armory's cold storage and hot wallet. Im developing in Java also. I know Armory uses bitcoind and I have used it quite a bit before. What I am trying to figure out is how I can build my webapp around armory, that is, how I can communicate with it. It dosent seem to have a daemon :P
 81 2013-11-11 02:50:39 <warren> gmaxwell: I'm testing and reviewing the externalip patch, adding debug prints everywhere to make sure it's DTRT.  Where in the code does the bitcoind handle the receiving end of AdvertizeLocalNode()?
 82 2013-11-11 03:20:41 <dobry-den> finally figured out mpi
 83 2013-11-11 03:21:26 <dobry-den> will definitely devote tomorrow working on a fun aspect of the project
 84 2013-11-11 03:21:28 <dobry-den> encoding isnt
 85 2013-11-11 04:40:41 <lachesis> can i build with libdb 5 instead of 4.8?
 86 2013-11-11 04:41:09 <BlueMatt> yes, but wallets touched by that build will no longer open on other 4.8-based builds
 87 2013-11-11 05:21:10 <lachesis> what am i doing wrong here?
 88 2013-11-11 05:21:12 <lachesis> checking whether the Boost::System library is available... yes
 89 2013-11-11 05:21:12 <lachesis> configure: error: Could not find a version of the library!
 90 2013-11-11 05:22:16 <warren> toffoo: downloading from that server you uploaded the blockchain is taking me 16 hours =)
 91 2013-11-11 05:26:44 <lianj> warren: a bootstrap file?
 92 2013-11-11 05:28:15 <warren> lianj: toffoo's personal blockchain that he has been using since 0.3.x works with 0.7.2 but corrupts after imported into 0.8.x, clean shutdown, and restart.
 93 2013-11-11 05:28:38 <lianj> ah k
 94 2013-11-11 05:28:54 <warren> lianj: we still have corruption complaints on macos x after the three leveldb-related commits, so looking into this one
 95 2013-11-11 05:37:44 <imton> sipa: hey, I am trying for first time your "addr index" fork over the real bitcoin network and it is really slow. I know you don't love this fork, but there is a use case I still need it.
 96 2013-11-11 05:38:43 <imton> sipa: I'd love to understand why the index is so slow, is it because leveldb is not prepared for such a big index or is it because as you implemented "addr index" is not optimized?
 97 2013-11-11 05:39:20 <imton> sipa: fyi it is taking me more than 20 seconds to look up for an address' transactions
 98 2013-11-11 05:40:57 <gmaxwell> imton: you've given basically no information there. 20 seconds is completely reasonable if you've queried an address inovolved in tens of thousans of transactions and you're on a slow system without a ssd (or worse, on EC2)
 99 2013-11-11 05:43:00 <imton> gmaxwell: good, thanks. I'd like to ask for help/ideas about how could I archive a kind of blockchain.info performance with sipa's 'addr index' fork.
100 2013-11-11 05:43:40 <imton> gmaxwell: where should i start optimizing? is it leveldb ? should I use another db for the index? is only about the hardware?
101 2013-11-11 05:44:17 <gmaxwell> You're continuing to give no information.
102 2013-11-11 05:44:31 <imton> gmaxwell: i imagine that with a cache layer only strategy i won't be able to archive blockchain.info almost realtime knowledge of address txs
103 2013-11-11 05:44:57 <imton> gmaxwell: sorry, which info would you like to know?
104 2013-11-11 05:45:32 <gmaxwell> What sorts of addresses are you seeing 20 second performance on? how many results are they returning? What hardware are you running on (memory, cpu, disk type, OS?)
105 2013-11-11 05:47:34 <imton> gmaxwell: well, I was testing on testnet and it was working almost realtime, and when I switched to real network I started testing with "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" address, If I am not wrong it is the first used address. It has around 850 txs
106 2013-11-11 05:48:03 <imton> I am testing in a Ubuntu Azure instance (like ec2) , 1.7gb ram and 2 cores.
107 2013-11-11 05:50:28 <imton> gmaxwell: sorry, 1 core. Yeah, it's small. But that's exactly what I'd like to know, where do I start optimizing? it's just a matter of hardware resources? or is it that sipa's implementation is not optimized for full blockchain search like blockchain.info?
108 2013-11-11 05:52:11 <gmaxwell> imton: I dunno about about "Ubuntu Azure instance" but a lot of VPS services have _astonishingly_ slow IO. So yes thats your problem.
109 2013-11-11 05:52:56 <gmaxwell> (or at least very likely your problem)
110 2013-11-11 05:52:56 <warren> I'm guessing blockchain.info has more than a tiny VM of hardware.
111 2013-11-11 05:53:31 <gmaxwell> warren: a different design that used hundreds of gigs of additional storage could be faster.
112 2013-11-11 05:53:56 <gmaxwell> (even on limited hardware)
113 2013-11-11 05:54:34 <imton> gmaxwell: what do you mean with "a different design" , could you elaborate that?
114 2013-11-11 05:59:39 <gmaxwell> imton: one that duplicated all the data many times, instead of having to go gather it scattered from the blockchain. I don't believe we'd ever consider shipping that in any case. If you want that, you should build it externally to bitcoin.
115 2013-11-11 06:02:08 <firepacket> does anyone know if its possible to get rid of the -blocknotify DOS window that comes up on windows?
116 2013-11-11 06:03:16 <imton> gmaxwell: great, really need this so I think I should start studying bitcoin-qt code. do you think sipas 'addr index' brach is a good start?
117 2013-11-11 07:06:18 <midnightmagic> uh. when getrawtransaction doesn't have any information about a txid, what other mechanism might there be to retrieve the raw tx itself?
118 2013-11-11 07:06:42 <midnightmagic> (gettransaction seems to work just fine)
119 2013-11-11 07:07:03 <phantomcircuit> midnightmagic, iirc getrawtransaction doesn't try to look in the wallet
120 2013-11-11 07:07:17 <phantomcircuit> midnightmagic, you could also rig it to do a bruteforce search of all the blocks
121 2013-11-11 07:07:20 <midnightmagic> phantomcircuit: It's a broadcast, accepted, and confirmed tx..
122 2013-11-11 07:07:30 <midnightmagic> gettransaction even tells me the block it lives in
123 2013-11-11 07:07:32 <phantomcircuit> midnightmagic, running with -txindex=1 ?
124 2013-11-11 07:07:45 <midnightmagic> no. should I?
125 2013-11-11 07:08:14 <midnightmagic> ah. I should.
126 2013-11-11 07:08:17 <midnightmagic> 
ACTION re-runs.

127 2013-11-11 07:09:33 <midnightmagic> phantomcircuit: You wouldn't happen to know how long a -reindex takes do you?
128 2013-11-11 07:12:31 <phantomcircuit> midnightmagic, ages
129 2013-11-11 07:13:06 <midnightmagic> doh
130 2013-11-11 07:13:36 <phantomcircuit> midnightmagic, you're basically doing initial block sync except without having the round trip times to the network
131 2013-11-11 07:14:13 <midnightmagic> oh that's not too bad. I have a fast lots of ram + ssd machine that eats up an initial sync
132 2013-11-11 07:54:24 <BlueMattBot> Project Bitcoin build #442: ABORTED in 7 hr 34 min: http://jenkins.bluematt.me/job/Bitcoin/442/
133 2013-11-11 07:56:10 <BlueMatt> appears to have gotten stuck with no obvious explanation
134 2013-11-11 07:56:24 <BlueMatt> moving jenkins on the new scripts to "beta" status and going to bed...
135 2013-11-11 08:37:52 <BlueMattBot> Project Bitcoin build #443: SUCCESS in 43 min: http://jenkins.bluematt.me/job/Bitcoin/443/
136 2013-11-11 08:59:11 <imton> guys, getrawtransaction is not working for the very first tx
137 2013-11-11 08:59:17 <imton> i know sipa is aware of it because he commented here back in april http://goo.gl/r1pn2Z
138 2013-11-11 08:59:27 <imton> should i open an issue?
139 2013-11-11 08:59:55 <phantomcircuit> im honestly not sure anybody is going to care enough to fix it unless you submit a patch
140 2013-11-11 08:59:58 <phantomcircuit> imton, ^
141 2013-11-11 09:00:56 <imton> phantomcircuit: I do not master c++, I could do it but... it would be a shame :p
142 2013-11-11 09:01:17 <phantomcircuit> shrug
143 2013-11-11 09:01:29 <phantomcircuit> if you make an attempt maybe someone will just fix it up
144 2013-11-11 09:02:01 <gmaxwell> imton: it is not an issue.
145 2013-11-11 09:02:14 <lianj> its unspendable anyway
146 2013-11-11 09:02:15 <imton> should this be hardcoded? because according to sipa's comment he says that the 1st block is not valid
147 2013-11-11 09:02:21 <gmaxwell> imton: that transaction doesn't exist in the system.
148 2013-11-11 09:03:49 <imton> ok. shouldn't be better to answer a better error to this particular tx other than "No information available about transaction"
149 2013-11-11 09:03:58 <imton> it was driving me crazy
150 2013-11-11 09:05:06 <gmaxwell> imton: what, so there is yet another special case that the calling code needs to handle? .. which they'll likely never discover?
151 2013-11-11 09:06:14 <imton> gmaxwell: is there any other special case or does it happen only in this particular?
152 2013-11-11 09:06:35 <imton> it is that I was testing my system with this transaction and I never thought it was not valid.
153 2013-11-11 09:06:51 <imton> i thought it was a problem with my index, and rebuild it twice :s
154 2013-11-11 09:09:14 <gmaxwell> imton: just this transaction.
155 2013-11-11 09:10:06 <imton> gmaxxwell: great. I don't know why I did choose to test my system with this particular transaction. #badluck
156 2013-11-11 09:14:24 <michagogo> cloud|imton: yeah, the enemies block is a bad thing for testingjust about anything
157 2013-11-11 09:14:32 <michagogo> cloud|and by enemies I mean genesis
158 2013-11-11 09:15:52 <imton> michagogo|cloud: Well, I have the bad habit of loving testing in limit/extreme scenarios. I think that if in extreme scenarios work, it should work in normal too... at least I understood why this was an exception
159 2013-11-11 09:17:35 <michagogo> cloud|Yeah, the genesis block isn't considered part of the blockchain for most intents and purposes
160 2013-11-11 09:17:52 <michagogo> cloud|Not indexed, etc
161 2013-11-11 09:18:38 <gmaxwell> imton: if it returned then it would be leading you to think there was an extra spendable output that doesn't really exist and isn't really spendable.
162 2013-11-11 09:18:44 <gmaxwell> I wouldn't call that working.
163 2013-11-11 09:20:10 <imton> gmaxwell: wait... I did not mention that I am using -txindex=1
164 2013-11-11 09:20:26 <imton> gmaxwell: which I supposed it will index *everything*
165 2013-11-11 09:21:58 <michagogo> cloud|imton: everything that's a tea sanction in the system
166 2013-11-11 09:23:03 <michagogo> cloud|Like I said, for most purposes, the genesis block isn't a block and the genesis coinbase transaction isn't a transaction
167 2013-11-11 09:24:59 <gmaxwell> imton: the transaction doesn't exist. It never existed.
168 2013-11-11 09:25:12 <gmaxwell> It's not that it existed and was spent. It was not spent. It can never be spent.
169 2013-11-11 09:25:30 <gmaxwell> If it returned it, and you used that functionality to build an external index, you'd conclude there were 50 more spendable BTC than there are.
170 2013-11-11 09:25:40 <gmaxwell> (because there is no txn spending that unspendable coin)
171 2013-11-11 09:26:25 <imton> ok, I think I get it...
172 2013-11-11 09:26:51 <gmaxwell> warren: https://bugzilla.redhat.com/show_bug.cgi?id=1021897
173 2013-11-11 09:26:53 <imton> https://blockchain.info/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
174 2013-11-11 09:26:53 <imton> so blockchain.info report is wrong reporting "Total Received 65" right?
175 2013-11-11 09:27:04 <gmaxwell> warren: Fixed In Version: openssl-1.0.1e-31.fc21
176 2013-11-11 09:27:15 <imton> it takes into account 50btcs from 1st tx
177 2013-11-11 09:27:30 <gmaxwell> Yes.
178 2013-11-11 09:28:36 <imton> might i know why that 1st tx can not be spent?
179 2013-11-11 09:28:59 <imton> (i'd like to understand the underlaying motive)
180 2013-11-11 09:29:11 <warren> gmaxwell: what's the difference between r1 and k1?
181 2013-11-11 09:29:23 <sipa> imton: a bug, or intentional
182 2013-11-11 09:29:33 <sipa> imton: it doesn't matter, we can't change it
183 2013-11-11 09:29:51 <sipa> there are 11974664.79461179 BTC spendable now
184 2013-11-11 09:30:01 <gmaxwell> imton: because the block was hardcoded instead of being created the normal way— may have been an accident, or not.
185 2013-11-11 09:30:39 <gmaxwell> warren: they closed the secp256k1 bug with a fixed-by that bug.
186 2013-11-11 09:30:51 <warren> gmaxwell: tested it yet?
187 2013-11-11 09:31:23 <warren> gmaxwell: if so, this means we need to respond in the bitcoin package review to prevent dumb things from being shipped
188 2013-11-11 09:31:43 <gmaxwell> warren: you now know all that I know.
189 2013-11-11 09:31:57 <gmaxwell> I'm going to bed now, but perhaps you'd like to go look at the rawhide package?
190 2013-11-11 09:32:10 <warren> I need to be up early myself.
191 2013-11-11 09:32:55 <imton> sipa, gmawell: so can't the creator of block 0 (i suppose satoshi) spend it? i don't why sipa says "can't change it now", can't a code patch allow it? (again, I just want to understand this).
192 2013-11-11 09:33:49 <sipa> imton: the rules of the network are fixed
193 2013-11-11 09:33:54 <sipa> of course software can change
194 2013-11-11 09:34:12 <sipa> but that would mean a potential hard fork if he decided to spend the genesis block
195 2013-11-11 09:34:24 <sipa> as old software would not accept the change
196 2013-11-11 09:34:45 <sipa> so the reason doesn't matter, we must make sure that new software behaves the same way as the old
197 2013-11-11 09:35:33 <imton> what would happen today if he makes a transaction from that block, bitcoind will not accept it right?
198 2013-11-11 09:35:41 <sipa> indeed
199 2013-11-11 09:35:47 <sipa> no bitcoind ever would accept it
200 2013-11-11 09:36:08 <imton> great, I still not understand why that would cause a hard fork if we'd allow it...
201 2013-11-11 09:36:38 <sipa> because old software would not accept his transaction, and new software would
202 2013-11-11 09:36:48 <sipa> so we'd end up with two block chains
203 2013-11-11 09:36:57 <sipa> each software version ignoring the other
204 2013-11-11 09:38:09 <imton> oh ok. I get it now. The first versions of bitcoind (which he started) hardcoded did not allowed and we know have to still forbidding it. But he *could* have allowed it without any problem, right?
205 2013-11-11 09:38:29 <imton> *now
206 2013-11-11 09:38:48 <sipa> it would be possible to change, if we required everyone to change their software yes
207 2013-11-11 09:39:19 <sipa> but that,s an extraordinarily hard thing to do, and this small things, which may have been intentional even, is certainly not worth it
208 2013-11-11 09:39:44 <imton> sipa: that was what I wanted to know. I was thinking that there might be any problem that for some other specific reason if we allowed it that txs to be spendable bitcoin would not work. But I see that's not the case and only because of legacy.
209 2013-11-11 09:40:04 <sipa> right, indeed
210 2013-11-11 09:40:24 <sipa> that's what i meant with "the teason doesn't matter, we can't change it now"
211 2013-11-11 09:40:32 <sipa> we don't even know what the reason was
212 2013-11-11 09:40:36 <imton> as always, thanks sipa, gmaxwell, michagogo|cloud for your patient :)
213 2013-11-11 09:40:37 <warren> gmaxwell: eh?  the secp256k1 bug was not closed.
214 2013-11-11 09:40:46 <warren> gmaxwell: https://bugzilla.redhat.com/show_bug.cgi?id=1021898
215 2013-11-11 09:40:58 <michagogo> cloud|UTXO*
216 2013-11-11 09:40:58 <michagogo> cloud|Well, the issue is that the way the genesis block is coded in, it doesn't get processed like a block so it's transaction isn't part of the ITXO set
217 2013-11-11 09:41:13 <sipa> right now, it is
218 2013-11-11 09:41:26 <sipa> and there is just a special case for the geneaia block to not add it
219 2013-11-11 09:41:28 <michagogo> cloud|
ACTION dislikes being on a slow/spotty connection

220 2013-11-11 09:41:50 <sipa> but otherwise, the genesis block is now mostly processed in the same way as other blocks
221 2013-11-11 09:50:28 <imton> sipa: wrote you on private
222 2013-11-11 11:03:26 <Anduck> if i have a database to keep users balances and their associated addresses, when using sendmany, is it a risk that the change amount gets sent to one of customer-associated address?
223 2013-11-11 11:04:14 <gmaxwell> no.
224 2013-11-11 11:04:29 <Anduck> so sendmany will generate a new address every time?
225 2013-11-11 11:04:39 <Anduck> for change
226 2013-11-11 11:05:05 <gmaxwell> send* uses a new address from the address pool every time.
227 2013-11-11 11:05:10 <Anduck> and i mean customer-associated addresses by database, not bitcoind accounts system
228 2013-11-11 11:05:16 <Anduck> aight
229 2013-11-11 11:05:38 <Anduck> thanks
230 2013-11-11 11:06:58 <TD> helo
231 2013-11-11 11:07:22 <Anduck> how many keys does the keypool keep? 100?
232 2013-11-11 11:07:27 <DonnchaC> Hi, I'm trying to create tx's spending from multisig address in python. I'm pretty sure I am generating my raw transaction correctly but I'm not sure whats going wrong (possibily with signing). When I try broadcast the fully signed tx blockchain.info tells me "Unable To find all tx inputs" - https://gist.github.com/anonymous/ac6b28a729b595d06c53
233 2013-11-11 11:07:46 <Anduck> keypoolrefill will make new addresses to there are 100 in keypool?
234 2013-11-11 11:08:18 <DonnchaC> I asked a few days ago but noone in the channel was able to help me.
235 2013-11-11 11:08:59 <DonnchaC> Anyone see anything obvious wrong with my tx. I have spent far too long trying to figure this out already :) Or where would be the best place to go for help?
236 2013-11-11 11:37:43 <HaltingState> lampert siguratures make no sense; wikipedia page is horrible written, wtf
237 2013-11-11 11:38:27 <HaltingState> like "alive creates her private key and never uses it agains and should probably throw it away" lol
238 2013-11-11 11:44:12 <gmaxwell> HaltingState: huh, it doesn't say that.
239 2013-11-11 11:54:37 <iceTwy> Hey there
240 2013-11-11 11:54:43 <iceTwy> How could I generate my own bootstrap.dat file
241 2013-11-11 11:58:59 <gmaxwell> contrib/linearize
242 2013-11-11 11:59:07 <gmaxwell> in git.
243 2013-11-11 11:59:11 <gmaxwell> Dunno if it currently works.
244 2013-11-11 12:00:23 <arioBarzan> Who came up with the idea of compressed form of bitcoin addresses, Nakamoto or other developers?
245 2013-11-11 12:01:34 <warren> gmaxwell: fedora python appears to be busted, I ended up making bootstrap.dat with a fresh IBD with the do-not-store-orphans patch
246 2013-11-11 12:01:47 <warren> and a hack to stop sync at a particular height
247 2013-11-11 12:04:01 <HaltingState> gmaxwell, " Then for each bit in the hash sum she picks the corresponding number from her private key.","Note that now that Alice's private key is used, it should never be used again. The other 256 random numbers that she did not use for the signature she must never publish or use. Preferably she should delete them; otherwise, others gaining access to them would later be able to create false signatures."
248 2013-11-11 12:04:18 <HaltingState> ahh so she only deletes half the numbers in private key
249 2013-11-11 12:07:12 <sipa> arioBarzan: addresses are not compressed, really
250 2013-11-11 12:07:36 <HaltingState> sipa, how do i hash a compressed address to get bitcoin address? do i have to expand it first or can i just hash it
251 2013-11-11 12:07:54 <sipa> HaltingState: an address is the hash of the public key
252 2013-11-11 12:07:58 <sipa> that's all you need to know
253 2013-11-11 12:08:09 <HaltingState> so compressed public key, just hash it and its fine
254 2013-11-11 12:08:16 <sipa> indeed
255 2013-11-11 12:08:19 <HaltingState> awesome
256 2013-11-11 12:08:47 <HaltingState> lampert signatures make sense now; but are sort of stupid
257 2013-11-11 12:10:45 <arioBarzan> I could not find how a signature for a public key with prefix 0x02 or 0x03 is validated, specifically how y value could be derived from the x value.
258 2013-11-11 12:11:07 <sipa> arioBarzan: the curve has equation y^2 = x^3 + 7
259 2013-11-11 12:11:13 <arioBarzan> sipa: thanks
260 2013-11-11 12:13:01 <arioBarzan> sipa: Was compressed keys introduced by Nakamoto?
261 2013-11-11 12:13:06 <sipa> no, by me
262 2013-11-11 12:15:13 <arioBarzan> Since y^2 = x^3 + 7 so there would be no security difference between old and compressed versions, right?
263 2013-11-11 12:15:22 <sipa> there is no security difference
264 2013-11-11 12:15:34 <sipa> they're just smaller, and a tiny bit more expensive to verify
265 2013-11-11 12:21:16 <imton> guys, what did change in 0.8.X  "getblock" RPC response from older versions?
266 2013-11-11 12:21:57 <sipa> nothing
267 2013-11-11 12:22:28 <sipa> (continuing from PM), the text you pasted referred to a much (much!) older patch for bitcoind that added a getblock-like command
268 2013-11-11 12:22:40 <sipa> the one that was actually added (in 0.6 or 0.7 or so) was a bit different
269 2013-11-11 12:23:35 <imton> oh, because there wasn't "get block" RPC call back then?
270 2013-11-11 12:23:44 <sipa> indeed
271 2013-11-11 12:23:49 <imton> this is from 3 months ago
272 2013-11-11 12:23:50 <imton> https://github.com/lirazsiri/blockexplorer-bitcoind
273 2013-11-11 12:25:15 <sipa> yeah, they just seem to have packaged a bunch of outdated code together
274 2013-11-11 12:27:18 <HaltingState> gmaxwell, so if we only use each address once then we can use lambert signatures?
275 2013-11-11 12:27:39 <HaltingState> and if we have massive hard discs and gigabit ethernet to move all these 16 KB signatures...
276 2013-11-11 12:29:15 <gmaxwell> HaltingState: Lamport, not lambert. 12kbytes, since the signatures can be compressed. And if they are merkelized you can get finite reuse. with very small additional overhead (log2(reuse) additional hashes in the signatures)
277 2013-11-11 12:29:31 <HaltingState> sipa, are signatures canonical now? or is there still that transform for producing other valid signatures?
278 2013-11-11 12:29:51 <sipa> HaltingState: which signatures?
279 2013-11-11 12:30:06 <HaltingState> in your library, i am doing compressed signatures in my golang library/wrapper
280 2013-11-11 12:30:24 <gmaxwell> HaltingState: and yea, they're on the order of 128-256 times larger. which doesn't actally result in quite "massive hard discs and gigabit ethernet" if projected onto bitcoin's current usage, but indeed, its' a lot bigger.
281 2013-11-11 12:30:28 <sipa> of course they're canonical
282 2013-11-11 12:30:44 <HaltingState> also, is there way to check that signature is canonical? a compressed non-canonical signature would still be valid right?
283 2013-11-11 12:30:45 <sipa> HaltingState: wait, compressed signatures?
284 2013-11-11 12:31:17 <sipa> compact signatures have nothing to do with that, they're a completely independent non-standard type of signature encoding
285 2013-11-11 12:31:23 <sipa> the word 'canonical' doesn't apply to that
286 2013-11-11 12:32:13 <HaltingState> gmaxwell, miners would love those transaction fees if there was addition for lamport in addition to secp256k1 in the same block chain; /r/bitcoin will be creating NSA quantum computer scare stories ahaha
287 2013-11-11 12:33:22 <HaltingState> sipa, ok; i am doing compact signatures and I want to know; can someone change the signature to get another valid signature for same message without the private key
288 2013-11-11 12:33:45 <HaltingState> because i know they can do that for the normal 72 byte signatures that openssl was putting out
289 2013-11-11 12:33:47 <sipa> HaltingState: if you don't enforce non-malleability, yes
290 2013-11-11 12:34:29 <sipa> HaltingState: if you force the highest bit of the first byte of S to be 0, it's non-malleable
291 2013-11-11 12:35:05 <gmaxwell> HaltingState: wtf does lamport have to do with _secp256k1_ ?! they're totally seperate cryptosystems.
292 2013-11-11 12:35:22 <sipa> "in addition to"
293 2013-11-11 12:36:31 <HaltingState> sipa, hmm; how do i enforce it to be 0? generate nonces until its 0?
294 2013-11-11 12:36:37 <sipa> yes
295 2013-11-11 12:36:39 <sipa> no no
296 2013-11-11 12:36:55 <sipa> it _creates_ signatures that already satisfy that condition
297 2013-11-11 12:37:00 <sipa> but it will accept ones that don't
298 2013-11-11 12:37:05 <sipa> maybe i should change that, and be strict
299 2013-11-11 12:37:37 <HaltingState> yes; i want some way to know signature is valid but fails malleability
300 2013-11-11 12:37:57 <sipa> well if the highest bit of S is 1, you can take its complement
301 2013-11-11 12:38:04 <sipa> and end up with a valid signature
302 2013-11-11 12:38:11 <sipa> that is canonical
303 2013-11-11 12:38:20 <HaltingState> so just set highest bit to 0 and its safe?
304 2013-11-11 12:38:27 <sipa> ...