1 2014-03-01 00:56:33 <lechuga_> lianj: are you the author of the btc ruby lib?
  2 2014-03-01 01:18:24 <tlrobinson> has anyone bothered to look for 750k BTC worth of malleability in the blockchain yet? it's possible to look for txs that aren't normally generated by wallets, right?
  3 2014-03-01 01:19:43 <tlrobinson> i was thinking of parsing the blockchain looking for all these https://gist.github.com/sipa/8907691 forms of malleability, just wanted to make sure no one has already done it
  4 2014-03-01 01:20:20 <wilsonnl> trying to compile bitcoin(and qt) on windows7 64bit. when running C:/deps/boost1_55_0>bootstrap.bar mingw i'm getting: not recognize. fuild to build Boost.Build eingine. Any help?
  5 2014-03-01 01:22:56 <Luke-Jr> wilsonnl: only one person does that regularly, and he's not on IRC often
  6 2014-03-01 01:23:25 <wilsonnl> hehe dammit, windows is such a pain to compile on
  7 2014-03-01 01:23:51 <Luke-Jr> official builds are built on Linux
  8 2014-03-01 01:23:54 <wilsonnl> spamming litecoin and bitcoin now :D
  9 2014-03-01 01:24:20 <Luke-Jr> wilsonnl: are you trying to build bitcoin-qt or litecoin?
 10 2014-03-01 01:24:29 <wilsonnl> litecoin
 11 2014-03-01 01:24:35 <Luke-Jr> then it's off-topic here
 12 2014-03-01 01:25:00 <wilsonnl> true, sorry
 13 2014-03-01 01:46:40 <Ad0> can't one index everything in a relational database?
 14 2014-03-01 01:47:41 <sipa> sure
 15 2014-03-01 01:51:20 <Ad0> maybe blockchain.info already does that
 16 2014-03-01 01:51:34 <sipa> seems likely
 17 2014-03-01 01:51:36 <Ad0> or jsut have it in-memory :)
 18 2014-03-01 01:51:56 <sipa> one does not exclude the other
 19 2014-03-01 01:52:02 <Ad0> guess not
 20 2014-03-01 01:56:56 <Cheena> is Satoshi Nakamoto amongst us ?
 21 2014-03-01 01:57:07 <sipa> who knows
 22 2014-03-01 01:57:12 <sipa> does it matter?
 23 2014-03-01 01:57:28 <Cheena> yes
 24 2014-03-01 01:57:36 <Cheena> maybe to some
 25 2014-03-01 01:57:59 <sipa> what difference does it make?
 26 2014-03-01 01:59:05 <Cheena> It would be great knowing more about him from the man himself
 27 2014-03-01 01:59:48 <sipa> that's a very different question
 28 2014-03-01 02:00:08 <sipa> he's clearly chosen to disappear from public
 29 2014-03-01 02:00:22 <Cheena> oh well
 30 2014-03-01 02:00:22 <sipa> whether he's still watching or not doesn't matter in practice
 31 2014-03-01 02:00:31 <Cheena> i guess you are right
 32 2014-03-01 02:00:48 <Cheena> meanwhile when i compile it throws this to me
 33 2014-03-01 02:00:49 <Cheena>         CBlock block;PUBKEY_ADDRESS
 34 2014-03-01 02:00:49 <Cheena> main.cpp:2087:22: error: use of undeclared identifier 'PUBKEY_ADDRESS'
 35 2014-03-01 02:01:46 <sipa> there is no PUBKEY_ADDRESS in main.cpp
 36 2014-03-01 02:02:33 <Cheena> silly me i corrupted the code
 37 2014-03-01 02:03:24 <Cheena> the scriptPubKey in main.cpp does it have to be generated or it stays the same ?
 38 2014-03-01 02:03:35 <Cheena> for every alt coin ?
 39 2014-03-01 02:03:43 <sipa> this is not #altcoin-dev
 40 2014-03-01 02:04:11 <Cheena> altcoin-dev does not exist
 41 2014-03-01 02:04:36 <kanzure> you can make it
 42 2014-03-01 02:04:45 <sipa> (i say this, not because i find altcoins uninteresting, but because i'm very tired of the hundreds of altcoins who don't experiment with any interesting changes, and just change a few constants without understanding the code)
 43 2014-03-01 02:04:47 <kanzure> freenode allows for users to join a channel to create it
 44 2014-03-01 02:05:40 <Cheena> @sipa how do you understand the code ? is it documented somewhere ?
 45 2014-03-01 02:05:58 <sipa> Cheena: i spent a few years time working on it
 46 2014-03-01 02:06:30 <Cheena> @sipa i better start from learning C and then understand the code
 47 2014-03-01 02:17:50 <Cheena> sips are you from Belgium ?
 48 2014-03-01 02:17:54 <Cheena> sipa
 49 2014-03-01 02:56:08 <rasmuzen> test
 50 2014-03-01 02:56:11 <rasmuzen> woo
 51 2014-03-01 03:03:55 <todamoon> is there a list of cryptocurrency related white papers somewhere? stuff like satoshi's paper, zerocoin paper, etc.
 52 2014-03-01 03:22:32 <rasmuzen> is this channel actually active at all?
 53 2014-03-01 03:23:09 <copumpkin> it varies
 54 2014-03-01 03:24:58 <rasmuzen> if I want to check the balance of a public address programmatically, I'm assuming I'll need to run bitcoind or bitcoin-qt, yeah?
 55 2014-03-01 03:25:01 <anton000> since what version did the comprssed pubkey got used as standard?
 56 2014-03-01 03:25:24 <gmaxwell> 40k messages in 2014 so far…
 57 2014-03-01 03:25:42 <rasmuzen> gmaxwell: pretty good actually, thanks
 58 2014-03-01 03:26:00 <gmaxwell> anton000: 0.6.0
 59 2014-03-01 03:27:59 <rasmuzen> anybody?
 60 2014-03-01 03:29:14 <gmaxwell> rasmuzen: addresses don't have balances in the bitcoin system, and there is no straightforward way of computing all the coins spendable by a non-wallet key using bitcoind.
 61 2014-03-01 03:30:48 <rasmuzen> gmaxwell: thanks for the reply, how do addresses not have balances? can't I send bitcoins to any public address and then that public address has a balance of whatever I sent it?
 62 2014-03-01 03:31:57 <jrick> addresses don't have an inherit balance, but access to the private key used to generate the address can result in you signing outputs others sent
 63 2014-03-01 03:32:17 <jrick> you have to track those transaction outputs (called utxos)
 64 2014-03-01 03:32:31 <gmaxwell> rasmuzen: That doesn't actually reflect how the bitcoin system works. The system tracks spendable txout in utxo by transaction ID/vout. Whenever you send it coins you destroy some of your txouts and create new txouts which are spendable by the other person.
 65 2014-03-01 03:33:09 <gmaxwell> You can go and compute whats spendable by a particular scriptpubkey, but that requires having an (rather large) index by scriptpubkey which we do not have and do not need for normal operations.
 66 2014-03-01 03:34:23 <rasmuzen> gmaxwell: sorry I need to clarify that I'm talking about developing a third party application that would check balances for a given public address, nothing to do with core bitcoin software
 67 2014-03-01 03:34:39 <rasmuzen> gmaxwell: is this the right place for that kind of discussion?
 68 2014-03-01 03:35:29 <gmaxwell> rasmuzen: Apparently not.
 69 2014-03-01 03:35:51 <rasmuzen> gmaxwell: what do you mean apparently...
 70 2014-03-01 03:36:49 <gmaxwell> Well, you're asking questions that don't actually make sense in the context of Bitcoin, and when I explain why you start asking if you're in the right place, so I suppose you must not be.
 71 2014-03-01 03:38:31 <rasmuzen> gmaxwell: excuse my naivety for how Bitcoin actually works, my understanding of the implementation is pretty minimal, didn't mean to offend anyone.
 72 2014-03-01 03:39:07 <CodeShark> I so much wish the term "address" had NEVER been applied to this
 73 2014-03-01 03:39:07 <CodeShark> it's bitcoin's most horrible misnomer
 74 2014-03-01 03:39:16 <CodeShark> confuses the hell out of ordinary users
 75 2014-03-01 03:39:32 <rasmuzen> codeshark: gmaxwell: so when I go to https://blockchain.info/address/1F1f9TcJam2CZG5uvDKewJGsrhsyP7awUP and it tells me a balance associated with a public address, what is actually going on?
 76 2014-03-01 03:39:43 <CodeShark> it has a large index
 77 2014-03-01 03:39:45 <rasmuzen> or what is the proper terminology
 78 2014-03-01 03:39:52 <CodeShark> keeps track of balances in a large database
 79 2014-03-01 03:40:04 <CodeShark> it's a custom database
 80 2014-03-01 03:40:13 <gmaxwell> rasmuzen: bc.i maintains a database hundred of gigabytes in size that traces transaction history and provides a variety of aggregated views of it based on analysis of the transactions.
 81 2014-03-01 03:40:39 <rasmuzen> so it calculates balances by iterating through the entire block chain (which is basically a list of transactions) and maintaining it as it updates live?
 82 2014-03-01 03:40:40 <CodeShark> invoice ID would have been a great name, perhaps
 83 2014-03-01 03:40:40 <gmaxwell> (and some of this data is somewhat misleading or inaccurate, though coins assigned to addreses aren't one of the things that are)
 84 2014-03-01 03:40:57 <gmaxwell> CodeShark: yea, "order number"
 85 2014-03-01 03:41:33 <gmaxwell> rasmuzen: or something morally equivalent to that.
 86 2014-03-01 03:41:48 <CodeShark> rasmuzen, blockchain maintains a huge custom database which it updates continuously
 87 2014-03-01 03:42:05 <CodeShark> these functions are NOT essential to the functioning of a bitcoin node
 88 2014-03-01 03:42:45 <rasmuzen> CodeShark: absolutely correct, but I'm in the business of providing consumer-facing bitcoin applications
 89 2014-03-01 03:42:50 <gmaxwell> rasmuzen: we don't current have eqivilent functionality available in bitcoind as its not required for the functionality of the system, it encourages non-scalable designs that can usually be avoided, and it currently would add about 20GBytes storage over what a full node with pruning would take up... though once we have pruning available will probably make such an index available optionally.
 90 2014-03-01 03:43:08 <CodeShark> although having said that, it wouldn't be so terrible to add an optional switch to allow txout indexing in bitcoind
 91 2014-03-01 03:44:12 <CodeShark> gmaxwell beat me to it :p
 92 2014-03-01 03:44:23 <gmaxwell> Did I beat you to http://canibuildasitehandlingotherpeoplesmoney.com/
 93 2014-03-01 03:45:01 <rasmuzen> gmaxwell: CodeShark: thanks a ton for chatting with me guys, this is really useful and it's fascinating to see the differences in terminology between core developers and general public
 94 2014-03-01 03:45:04 <CodeShark> is that mt gox's new domain?
 95 2014-03-01 03:46:00 <gmaxwell> rasmuzen: by "general public" what that generally means is "blockchain.info"— the service is handy but it creates some pretty substantial misunderstandings about how things actually work under the hood. (some of which have resulted in money loss)
 96 2014-03-01 03:46:18 <gmaxwell> Navigating thats hard. Making things easy often requires abstractions that fail in the edge cases.
 97 2014-03-01 03:46:37 <rasmuzen> gmaxwell: could you elaborate on those misunderstandings
 98 2014-03-01 03:47:48 <gmaxwell> There are many of them, the one responsible for the most actual funds loss is the notion that transactions have a well defined "from". (which results in funds loss when people 'refund' money to an estimated from and the funds go to a third party or into some black hole)
 99 2014-03-01 03:48:05 <gmaxwell> More benign is the belief that transactions carry a sender IP.
100 2014-03-01 03:49:09 <rasmuzen> gmaxwell: what all do transactions contain?
101 2014-03-01 03:49:36 <CodeShark> the fact of the matter is bc is a wonderful tool for debugging and checking the operation of the bitcoin network - but it isn't particularly helpful to most end users
102 2014-03-01 03:49:44 <gmaxwell> the format of a transaction is here https://en.bitcoin.it/wiki/Transaction
103 2014-03-01 03:50:10 <gmaxwell> CodeShark: not always wonderful... e.g. they display some invalid transactions as though they were perfectly valid, which is super confusing.
104 2014-03-01 03:50:20 <gmaxwell> (e.g. send a spend of an immature coinbase directly to them)
105 2014-03-01 03:51:27 <rasmuzen> gmaxwell: can I use "public key", "public address", and "Bitcoin address" interchangeably?
106 2014-03-01 03:51:29 <CodeShark> hmm, seems like a simple enough fix - have you let them know about this?
107 2014-03-01 03:51:41 <gmaxwell> CodeShark: it's a feature, not a bug.
108 2014-03-01 03:51:53 <CodeShark> lol
109 2014-03-01 03:52:47 <gmaxwell> rasmuzen: probably not. often "public key" is used to refer to the ECDSA point encoded inside a bitcoin scriptPubKey and represented by a bitcoin address.
110 2014-03-01 03:53:25 <CodeShark> an "address" is actually a specific encoding for a specific type of script
111 2014-03-01 03:53:50 <jrick> addresses don't exist at the network level
112 2014-03-01 03:54:05 <gmaxwell> indeed.
113 2014-03-01 03:54:12 <rasmuzen> gmaxwell: so a wallet consists of a "private key" and a "bitcoin address"
114 2014-03-01 03:54:33 <jrick> an address is a nework id + pubkey hash + checksum
115 2014-03-01 03:54:42 <jrick> the pubkey hash appears in txout scripts
116 2014-03-01 03:55:04 <gmaxwell> No, typical wallets are a collection of many private keys— normally a distinct one is used for every transaction for security, privacy, and accounting reasons... the wallet also typically contains transactions related to the wallet and additional metadata.
117 2014-03-01 03:55:57 <gmaxwell> If you have a private key there isn't a particular need to seperately store a public key or address since you can generate them on the fly but I believe most wallets do (bitcoin-qt does) just to save cpu.
118 2014-03-01 03:56:15 <CodeShark> you need a lookahead
119 2014-03-01 03:56:35 <CodeShark> I suppose you could just keep a lookahead in RAM
120 2014-03-01 03:56:42 <jrick> need to save whether it's a compressed pubkey or not too
121 2014-03-01 03:56:51 <jrick> a single pubkey can give you 2 addresses
122 2014-03-01 03:56:57 <jrick> er
123 2014-03-01 03:57:06 <jrick> yeah pubkey
124 2014-03-01 03:57:15 <jrick> or thus, a single privkey
125 2014-03-01 03:57:18 <gmaxwell> jrick: thats not really correct. In bitcoin the information about using point compression is effectively part of the private key.
126 2014-03-01 03:57:42 <CodeShark> in the base58check encoding it is
127 2014-03-01 03:57:44 <gmaxwell> (It's information you need to know to spend— definitionally everything you need to know to spend should be stored with the private key)
128 2014-03-01 03:57:47 <CodeShark> but in the DER encoding it is not
129 2014-03-01 03:58:21 <gmaxwell> There is no DER encoding of a bitcoin private key.
130 2014-03-01 03:58:40 <gmaxwell> (yes, it _also_ shows up in the public point.)
131 2014-03-01 03:59:30 <rasmuzen> gmaxwell: but from a consumer standpoint, you give your bitcoin address out and people can send bitcoins to it, and you can access/send those bitcoins only with your private key
132 2014-03-01 03:59:39 <rasmuzen> gmaxwell: correct?
133 2014-03-01 03:59:43 <CodeShark> gmaxwell, you do need to keep your keys indexed by address for things like getreceivedbyaddress :)
134 2014-03-01 03:59:57 <gmaxwell> CodeShark: well, if you don't care about speed… :P
135 2014-03-01 04:00:41 <gmaxwell> rasmuzen: again, normally you have many addresses and private keys (otherwise how would you know who paid you?, for one example). But yes, thats how it works.
136 2014-03-01 04:01:04 <jrick> gmaxwell: ah that makes sense, at least with armory's format it just saves it as a 32-byte number
137 2014-03-01 04:01:31 <CodeShark> rasmusen: a wallet typically contains many keys - from a private key it is possible to generate a public key, from a public key it is possible to generate an address
138 2014-03-01 04:01:39 <CodeShark> but neither of these two steps can be taken in reverse
139 2014-03-01 04:01:56 <kanzure> what was one of the steps?
140 2014-03-01 04:02:07 <CodeShark> private key -> public key -> address
141 2014-03-01 04:03:11 <rasmuzen> CodeShark: so you give a different bitcoin address to each person who's going to send you coins so that you know who's sending to you, then once you receive those coins you send them to your main bitcoin address, then you can send from there because you know the private key associated with your mail bitcoin address
142 2014-03-01 04:03:23 <gmaxwell> jrick: last I checked armory never used point compression. .. I suppose you could imagine the flag is an extra 33rd byte which is omitted for uncompressed keys. :P  (don't laugh, thats actually how the base58 check encoding used for WIF works)
143 2014-03-01 04:03:31 <CodeShark> there's no such thing as "your main bitcoin address"
144 2014-03-01 04:03:50 <jrick> gmaxwell: armory doesn't support compressed pubkeys at all so that's not surprising
145 2014-03-01 04:03:53 <rasmuzen> how do you associate multiple bitcoin addresses with a single private key?
146 2014-03-01 04:03:56 <rasmuzen> codeshark:
147 2014-03-01 04:04:02 <jrick> I had to extend their format
148 2014-03-01 04:04:07 <jrick> to add a compressed flag
149 2014-03-01 04:04:08 <CodeShark> bitcoin isn't a post office - it's a bunch of glass boxes with keys on them
150 2014-03-01 04:04:26 <CodeShark> a transaction opens up some boxes and moves the contents into new boxes
151 2014-03-01 04:04:39 <CodeShark> the old boxes can never be used again
152 2014-03-01 04:04:49 <embicoin> hi
153 2014-03-01 04:04:59 <embicoin> do you know what this message means?
154 2014-03-01 04:05:01 <embicoin> ===
155 2014-03-01 04:05:10 <CodeShark> anyone can see what's inside the box, but only someone who knows the private key can open it
156 2014-03-01 04:05:35 <CodeShark> everytime you send a transaction, you create one or more brand new boxes
157 2014-03-01 04:05:37 <embicoin> everytime freenode drops me i have the same problem, i must leave #bitcoin-dev, change nick then join again
158 2014-03-01 04:05:39 <gmaxwell> embicoin: it means you must be registered with nickserv to talk in here, or to change your nick while you are in here.
159 2014-03-01 04:05:51 <rasmuzen> CodeShark: so once you send bitcoins with a private key, you can never send bitcoins using that private key again?
160 2014-03-01 04:06:13 <gmaxwell> set your client to correct with the correct nickname. Or authenticate with your nickname before switching. Nickserve can take the name as an argument as well as the password.
161 2014-03-01 04:06:33 <CodeShark> rasmuzen: someone can always create another box that requires the same key to open
162 2014-03-01 04:06:36 <CodeShark> but it's a different box
163 2014-03-01 04:06:59 <rasmuzen> codeshark: what's different about it? doesn't it have the same bitcoin address and private key?
164 2014-03-01 04:07:16 <embicoin> gmaxwell: thanks for the help, the problem is that almost everytime when it reconnects my "alter-ego" is still connected to the network, i must msg nickserv ghost to kick it
165 2014-03-01 04:07:35 <gmaxwell> (Though generally reusing keys is discouraged for security, privacy, and accounting purposes. E.g. if you reuse an address you can't tell which party was paying you)
166 2014-03-01 04:07:55 <CodeShark> is it the same to have $10 in one locked box as it is to have $1 locked up in ten different boxes, each which can be opened with the same key?
167 2014-03-01 04:08:23 <CodeShark> in bitcoin, the case of multiple boxes being openable with the same key should not be treated as the norm
168 2014-03-01 04:08:40 <CodeShark> you should generally assume that not very many boxes will be possible to open with the same key
169 2014-03-01 04:09:25 <CodeShark> a wallet is much more likely to keep those $10 as a bunch of boxes, perhaps one has $1.12, another has $3.16, another has $.84, etc...
170 2014-03-01 04:09:44 <CodeShark> and each of those boxes might require a different key to open
171 2014-03-01 04:09:59 <embicoin> btw gmaxwell my grateful for your hard work with the client :D
172 2014-03-01 04:10:03 <CodeShark> to spend $5, the wallet will select a set of those boxes such that the total contents is $5 or more
173 2014-03-01 04:10:16 <rasmuzen> CodeShark: so to clarify: every bitcoin address is associated with exactly one glass box
174 2014-03-01 04:10:34 <CodeShark> if it's more than $5, it will create a brand new box containing the change which can be opened with yet another key
175 2014-03-01 04:11:07 <CodeShark> no, rasmuzen - a bitcoin address is associated with a public key which is associated with a private key
176 2014-03-01 04:11:28 <rasmuzen> CodeShark: aware, but where do the metaphorical glass boxes fit in?
177 2014-03-01 04:11:30 <CodeShark> point is, the "balance" in the wallet is the sum of the contents of all the boxes the wallet is capable of opening
178 2014-03-01 04:11:45 <CodeShark> regardless of whether or not they share the same key
179 2014-03-01 04:12:18 <rasmuzen> CodeShark: how can two boxes share the same private key?
180 2014-03-01 04:12:56 <CodeShark> if someone sends bitcoins to the same address twice, they have effectively created two boxes that can be opened using the same private key
181 2014-03-01 04:13:29 <rasmuzen> CodeShark: why? why not just put the second stuff into the first box?
182 2014-03-01 04:13:36 <CodeShark> because that's not how bitcoin works :p
183 2014-03-01 04:13:46 <CodeShark> once a box is opened, it can never be used again
184 2014-03-01 04:14:30 <rasmuzen> CodeShark: why is bitcoin implemented this way? wouldn't it be simpler to just have one box associated with each private key?
185 2014-03-01 04:14:52 <rasmuzen> CodeShark: then let those with knowledge of bitcoin address deposit and those with knowledge of private key withdraw?
186 2014-03-01 04:15:41 <CodeShark> that's the "intuitive" sense for how it should work according to most people - and one of the reasons the term "address" is so damn annoying
187 2014-03-01 04:16:43 <rasmuzen> CodeShark: right, but why isn't it implemented that way?
188 2014-03-01 04:17:07 <cysm> because rabbits
189 2014-03-01 04:17:10 <CodeShark> lol
190 2014-03-01 04:17:19 <rasmuzen> wat
191 2014-03-01 04:17:22 <venzen> rasmuzen: consider that the glass boxes need to be recorded in the blockchain, going back and changing the same box with every tx will require changing old blocks
192 2014-03-01 04:18:13 <rasmuzen> can't the blockchain just contain a list of transactions from glass box with bitcoin address A to glass box with bitcoin address B (and amount)
193 2014-03-01 04:18:56 <CodeShark> in principle, the block chain could track changes in account balances
194 2014-03-01 04:19:02 <CodeShark> but that's not how bitcoin was designed
195 2014-03-01 04:19:32 <jrick> blockchain needs less bloat, not more
196 2014-03-01 04:19:39 <rasmuzen> CodeShark: I understand that this isn't how bitcoin was designed, I'm trying to understand why because it seems overcomplicated to me and I'm pretty sure that it is this way for a good reason, a reason I'm trying to discover
197 2014-03-01 04:20:46 <CodeShark> rasmuzen, the block chain actually stores transitions, not state
198 2014-03-01 04:21:05 <CodeShark> the reason is because the blockchain is fundamentally a timestamping mechanism
199 2014-03-01 04:21:19 <gmaxwell> rasmuzen: because the system is not instantaneously consistent and must reliably handle reordering of history in a determinstic, predictable, and controllable manner.
200 2014-03-01 04:21:49 <CodeShark> the key problem that bitcoin sets out to solve is the doublespend problem
201 2014-03-01 04:21:58 <gmaxwell> with just state storage it would become impossible to avoid paying someone twice if you needed to replace a transaction paying them with one with a higher fee, for example.
202 2014-03-01 04:22:05 <CodeShark> the doublespend problem is easily defined in the context of these glass boxes
203 2014-03-01 04:22:18 <CodeShark> has the box been opened before? if yes it's a doublespend
204 2014-03-01 04:22:53 <CodeShark> the blockchain serves to establish consensus as to which box existed first
205 2014-03-01 04:23:13 <CodeShark> once the box gets into the blockchain, its contents cannot be changed
206 2014-03-01 04:23:14 <jcorgan> rasmuzen: bitcoin transactions are more general than "send bitcoin to address A".  It is actually "whoever can satisfy this output script can spend these bitcoins onward."  The most common (by far) type of output script is "whoever can prove they have the private key that corresponds to this address can spend these onward", but it doesn't have to be the case.
207 2014-03-01 04:23:52 <jcorgan> so the only thing to do is to track the unspent outputs (UTXOs)
208 2014-03-01 04:24:32 <jrick> you can publish an output that anyone can spend and I bet you almost no wallets will pick it up
209 2014-03-01 04:25:04 <gmaxwell> Thats also an important point.  Consider a transaction that can be recovered by keys {A and B} or any two out of {C,D,E} or F but only if he provides a value that hashes to 0xDEADBEEF.
210 2014-03-01 04:25:15 <helo> all of them will likely pick it up, assuming it gets mined... i think
211 2014-03-01 04:25:54 <gmaxwell> jrick: of course none will pick it up, it would be highly insecure to display such a transaction to the user.
212 2014-03-01 04:26:02 <jrick> :)
213 2014-03-01 04:26:07 <jrick> just illustrating the point
214 2014-03-01 04:26:34 <rasmuzen> hmmmmmmmmmmm
215 2014-03-01 04:26:50 <gmaxwell> a wallet should never display transactions sent to a scriptpubkey that they wouldn't have plausably (or did actually) request funds be sent to.
216 2014-03-01 04:26:51 <CodeShark> rasmuzen: also as jcorgan points out, the lock on the box is actually a challenge in the form of a script
217 2014-03-01 04:27:11 <rasmuzen> so there's a glass box with some stuff in it, I know the private key associated with that box, I spend *half* of the contents, what happens to the other half?
218 2014-03-01 04:27:23 <CodeShark> boxes don't need to all have the same type of lock - the lock is actually a computer program which you must complete
219 2014-03-01 04:27:33 <CodeShark> if you can add the missing piece that opens the lock, you can open the box
220 2014-03-01 04:28:03 <jcorgan> rasmuzen: you can't spend only half
221 2014-03-01 04:28:21 <CodeShark> rasumzen: to spend half, you'd create a new box and stick the other half into it
222 2014-03-01 04:28:37 <CodeShark> and you'd never use the old box again
223 2014-03-01 04:28:42 <rasmuzen> jcorgan: so any time you spend box contents, you specify where *all* of the contents go, and that can be multiple destination boxes
224 2014-03-01 04:29:02 <jcorgan> right, and some of those destination boxes can be your own (new) ones
225 2014-03-01 04:29:12 <rasmuzen> okay
226 2014-03-01 04:29:22 <rasmuzen> and a box can be opened with exactly one private key?
227 2014-03-01 04:29:37 <rasmuzen> *hopeful*
228 2014-03-01 04:29:40 <CodeShark> there exists a specific type of lock that requires exactly one private keyt
229 2014-03-01 04:29:44 <jcorgan> most boxes are designed to be opened by one private key, but you can make different types of locks
230 2014-03-01 04:29:53 <CodeShark> but in general, the lock is actually a computer program which you must complete
231 2014-03-01 04:29:54 <rasmuzen> I see
232 2014-03-01 04:30:17 <rasmuzen> so is mining bitcoins just completing computer programs that are associated with boxes with coins in them?
233 2014-03-01 04:30:30 <CodeShark> nope :)
234 2014-03-01 04:30:35 <rasmuzen> aslk ejaljkh
235 2014-03-01 04:30:44 <CodeShark> mining is more like a lottery
236 2014-03-01 04:31:20 <CodeShark> you pick a bunch of random numbers, stick them through a black box, see what comes out - if the number that comes out is sufficiently small, you win
237 2014-03-01 04:31:31 <CodeShark> the more numbers you try, the more likely you are to win
238 2014-03-01 04:31:31 <rasmuzen> okay, let's leave mining aside for now then
239 2014-03-01 04:31:55 <jcorgan> if you win, you get a free box that has some bitcoin already in it, that didn't come from somewhere else but is newly 'minted'
240 2014-03-01 04:32:10 <rasmuzen> mkay
241 2014-03-01 04:32:21 <rasmuzen> is there a more technical term for these glass boxes?
242 2014-03-01 04:32:27 <CodeShark> txout
243 2014-03-01 04:32:29 <jcorgan> unspent transaction outputs
244 2014-03-01 04:32:35 <rasmuzen> okay
245 2014-03-01 04:33:22 <rasmuzen> what's the diff between txout and utxos
246 2014-03-01 04:33:34 <CodeShark> unspent means the box hasn't been opened yet
247 2014-03-01 04:33:57 <CodeShark> the u in utxo
248 2014-03-01 04:33:57 <jrick> rasmuzen: utxo is an unspent txout
249 2014-03-01 04:34:04 <rasmuzen> awesome
250 2014-03-01 04:34:08 <rasmuzen> it's coming together slowly, thanks a ton guys
251 2014-03-01 04:34:50 <jrick> if there's a validating tx that references that txout (by txsha and txout index) that output is spent
252 2014-03-01 04:35:39 <jcorgan> rasmuzen: and now your understanding is likely better than that of a certain recently defunct bitcoin exchange operator
253 2014-03-01 04:35:55 <rasmuzen> so if I generate a random private key and spend bitcoins to the associated bitcoin address, I'm effectively creating a glass box where the lock is knowing that private key, who's contents are the bitcoins I just spent
254 2014-03-01 04:36:09 <rasmuzen> jcorgan: ^_^
255 2014-03-01 04:36:24 <CodeShark> precisely, rasmuzen :)
256 2014-03-01 04:36:40 <rasmuzen> CodeShark: YES, is that how you would state that sentence or did i f** up the terminology?
257 2014-03-01 04:37:06 <CodeShark> in essence I think you nailed it :)
258 2014-03-01 04:39:05 <rasmuzen> CodeShark: so I am very interested in abstracting this and letting people who know nothing about bitcoin store bitcoins in glass boxes that only they have access to via the private key associated with each glass box
259 2014-03-01 04:39:12 <rasmuzen> in a web application
260 2014-03-01 04:39:44 <jcorgan> rasmuzen: that raises a number of issues you should be aware of
261 2014-03-01 04:40:10 <CodeShark> as a visualization/educational tool that would be really cool
262 2014-03-01 04:40:37 <CodeShark> but for typical use case scenarios, all these details are hidden by the wallet
263 2014-03-01 04:40:38 <rasmuzen_> hey sorry I got booted somehow
264 2014-03-01 04:40:50 <CodeShark> I just said two things
265 2014-03-01 04:40:56 <CodeShark> as a visualization/educational tool that would be really cool
266 2014-03-01 04:40:56 <rasmuzen_> I got the "but for typical..>"
267 2014-03-01 04:41:04 <CodeShark> but for typical use case scenarios, all these details are hidden by the wallet
268 2014-03-01 04:41:09 <rasmuzen_> I see
269 2014-03-01 04:42:34 <CodeShark> most users never have to look at these boxes directly - the wallet takes care of selecting boxes to open and creating new ones as needed - and just shows the user a balance
270 2014-03-01 04:42:36 <rasmuzen_> CodeShark: so how does one create a wallet?
271 2014-03-01 04:43:06 <CodeShark> you mean as in write the software?
272 2014-03-01 04:43:13 <rasmuzen_> CodeShark: lemme back up
273 2014-03-01 04:43:38 <rasmuzen_> hmm
274 2014-03-01 04:44:04 <rasmuzen_> CodeShark: no I mean create a bitcoin wallet and store bitcoins there and see my balance, how do I do that?
275 2014-03-01 04:44:47 <jrick> the wallet itself, at a bare minimum (list of private keys), is simple
276 2014-03-01 04:45:01 <jrick> but you'll want to save the utxos cooresponding to wallet keys
277 2014-03-01 04:46:09 <rasmuzen> jrick: but how do I make one? do I need bitcoin-qt or something?
278 2014-03-01 04:46:31 <jrick> software can create a wallet for you
279 2014-03-01 04:46:39 <jrick> each may use a different format
280 2014-03-01 04:46:43 <jcorgan> rasmuzen: there are several different types of wallet software packages you can use
281 2014-03-01 04:46:46 <jrick> there's no standard wallet per se
282 2014-03-01 04:48:12 <jcorgan> a wallet is usually just a portion of it.  For example, bitcoin-qt is actually a wallet + bitcoin network node + query server, while Electrum is just a wallet and relies on 3rd party servers
283 2014-03-01 04:48:34 <rasmuzen> jcorgan: jrick: I think what I want to do is give people a way to create a wallet, store bitcoins there, send and receive bitcoins, and check their balance without ever having to know that there exists a wallet or utxos
284 2014-03-01 04:49:02 <rasmuzen> abstract away all the implementation details of bitcoin
285 2014-03-01 04:49:03 <CodeShark> all wallet software works to that end to some extent or another :)
286 2014-03-01 04:49:03 <jcorgan> rasmuzen: i presume you want to do this via a web interface?
287 2014-03-01 04:49:09 <rasmuzen> jcorgan: right
288 2014-03-01 04:49:14 <fanquake> ;;blocks
289 2014-03-01 04:49:15 <gribble> 288397
290 2014-03-01 04:49:16 <jcorgan> so here is the critical issue
291 2014-03-01 04:49:27 <jcorgan> where are the private keys created and stored?
292 2014-03-01 04:49:59 <jcorgan> the answer to that question drives the entire architecture of your service
293 2014-03-01 04:50:08 <jcorgan> and also the security aspects you'll have to manage
294 2014-03-01 04:50:26 <CodeShark> if you want to write a wallet yourself, I suggest you start simple
295 2014-03-01 04:50:42 <CodeShark> implement key generation and transaction signing
296 2014-03-01 04:51:20 <rasmuzen> jcorgan: I would like to make it so that the glass box that, at the end of the day, contains all of the coins, is only known by the user OR it is in a database owned by me but encrypted with a password only known to the user
297 2014-03-01 04:51:32 <rasmuzen> sorry, the private key for the glass box*
298 2014-03-01 04:52:01 <CodeShark> in general there is no box that contains all the coins at the end of the day
299 2014-03-01 04:52:11 <jcorgan> all the glass boxes are public knowledge
300 2014-03-01 04:52:28 <rasmuzen> or a set of glass boxes that are all associated with a single private key that is only known by the user
301 2014-03-01 04:52:37 <CodeShark> in general your bitcoins are strewn about a bunch of boxes all over the block chain
302 2014-03-01 04:52:39 <rasmuzen> (but they don't know there's more than one)
303 2014-03-01 04:52:40 <CodeShark> at any given moment
304 2014-03-01 04:52:41 <jcorgan> it is only the private keys that open them to store bitcoin or open them to retrieve them that must be secured
305 2014-03-01 04:53:09 <rasmuzen> right, but I control where they're stored once they are put into a glass box that I know about
306 2014-03-01 04:53:22 <CodeShark> no, miners are the ones who determine that
307 2014-03-01 04:53:36 <jcorgan> and where and how those keys are generated and stored (user's machine?, web server? elsewhere?) that is the very first thing you need to decide
308 2014-03-01 04:53:43 <CodeShark> miners are the ones who stick your boxes into the block chain
309 2014-03-01 04:54:21 <CodeShark> the wallet itself doesn't really care about where it's stored - it just cares whether or not it exists and whether or not it's been opened
310 2014-03-01 04:54:47 <CodeShark> it might care about how long ago it was stored
311 2014-03-01 04:54:54 <CodeShark> the older, the more secure
312 2014-03-01 04:54:56 <rasmuzen> are you guys typically on here? I gotta run but this is really educational for me
313 2014-03-01 04:55:20 <rasmuzen> and I think I'm really close to finally getting the answer I came here for
314 2014-03-01 04:55:21 <rasmuzen> haha
315 2014-03-01 04:55:23 <jcorgan> there are many people typically on here that can answer your questions, so if we aren't someone else should be able to help you
316 2014-03-01 04:56:17 <rasmuzen> gmaxwell: codeshark: jcorgan: alright, thank you so much guys. cheers.
317 2014-03-01 04:56:18 <jcorgan> i can't emphasize enough, however, that the most critical design aspect of a service you are wanting to create is how the private keys get generated and stored
318 2014-03-01 04:56:43 <rasmuzen> there would only be a single private key
319 2014-03-01 04:56:54 <rasmuzen> and it would be *effectively* generated on client side
320 2014-03-01 04:56:57 <jrick> bad bad bad bad
321 2014-03-01 04:57:02 <rasmuzen> why
322 2014-03-01 04:57:12 <jrick> you need private keys for each address
323 2014-03-01 04:57:22 <CodeShark> if you want to use a single master key, I highly recommend you look into deterministic keychain generation
324 2014-03-01 04:57:28 <rasmuzen> why do I need more than one address
325 2014-03-01 04:57:33 <jrick> privacy
326 2014-03-01 04:57:48 <rasmuzen> is it bad to tell people your public address?
327 2014-03-01 04:57:56 <rasmuzen> for a glass box where coins are stored
328 2014-03-01 04:58:09 <CodeShark> it's bad to use the word "address" in this context, period :p
329 2014-03-01 04:58:17 <jrick> maybe, once you spend from an address the pubkey is revealed (before then, the only thing public is the pubkey hash)
330 2014-03-01 04:58:27 <rasmuzen> hah
331 2014-03-01 04:58:40 <jrick> but if you send change back to the same address you know who is the recipient and who was the sender
332 2014-03-01 04:59:11 <rasmuzen> what's so wrong with having a single private key and having all your glass boxes locked with that private key?
333 2014-03-01 04:59:26 <rasmuzen> then people send to the pubkey of that private key
334 2014-03-01 04:59:35 <jrick> you can encrypt all your private keys with the same secret
335 2014-03-01 04:59:43 <jcorgan> it reduces the privacy of all the other people who send bitcoin to that address
336 2014-03-01 04:59:58 <rasmuzen> what if I don't care who's sending to me?
337 2014-03-01 05:00:07 <rasmuzen> then does it matter?
338 2014-03-01 05:00:14 <CodeShark> rasmuzen, it is generally recommended to issue a different receiving address for each payment - the only significant exception right now is donation addresses
339 2014-03-01 05:00:14 <jcorgan> the other people who send to you might care
340 2014-03-01 05:00:30 <rasmuzen> jcorgan: why would they care
341 2014-03-01 05:01:14 <jrick> if some controversial site was taking donations and I donated to them I wouldn't want others to know that
342 2014-03-01 05:01:16 <jcorgan> bad guy A sends you bitcoin to an address, now everyone else who sends bitcoin to that address are one hop away in an investigation of bad buy A
343 2014-03-01 05:01:20 <CodeShark> rasmuzen, you can either encrypt your keys with the same secret as jrick says  - or you can use a deterministic keychain
344 2014-03-01 05:01:33 <jrick> CodeShark: you can do both
345 2014-03-01 05:01:54 <jrick> in fact you can encrypt the private keys and chain pubkeys
346 2014-03-01 05:01:56 <CodeShark> you can use multiple deterministic keychains and encrypt the master keys with the same secret :)
347 2014-03-01 05:01:57 <jrick> (armory does that)
348 2014-03-01 05:01:58 <CodeShark> sure, why not?
349 2014-03-01 05:02:05 <rasmuzen> well I'm not doing sketchy things, I'm just running a bank system basically, why would anyone care if who they send money to is public?
350 2014-03-01 05:02:27 <jcorgan> it's not about you
351 2014-03-01 05:02:46 <jcorgan> by reusing addresses, you provide a linkage between everyone spending to you
352 2014-03-01 05:03:23 <rasmuzen> and people don't want other people to know who their spending to
353 2014-03-01 05:03:41 <jcorgan> that could be one reason someone wouldn't like it
354 2014-03-01 05:03:48 <rasmuzen> is there another ?
355 2014-03-01 05:03:55 <gmaxwell> rasmuzen: e.g. because of address reuse your customers can see what you pay your suppliers, and what each other pay. Your competition can see your prices and sales volume. In personal use your landlord can see what your income is, and the mugger who works part time at the coffee shop can figure out how much he can earn if it mugs you.
356 2014-03-01 05:04:59 <rasmuzen> I see, really gotta run, thanks a ton guys, I'll be back :)
357 2014-03-01 05:05:06 <jcorgan> take care
358 2014-03-01 05:06:28 <todamoon> hola
359 2014-03-01 05:07:01 <olalonde> good morning / afternoon / evening
360 2014-03-01 05:07:22 <jcorgan> it's nice sometimes to be able to educate an intelligent but uninformed person, with them actually listening and digesting what you are telling them.  so rare :)
361 2014-03-01 05:07:49 <fanquake> Anyone building master with QT 5.2?
362 2014-03-01 07:52:05 <wumpus> fanquake: yes
363 2014-03-01 07:53:40 <fanquake> wumpus compiling fine? Last time I checked 5.2.1 was giving me trouble.
364 2014-03-01 07:53:51 <wumpus> works fine for me
365 2014-03-01 07:54:08 <wumpus> I only test ubuntu linux and windows (through gitian) though
366 2014-03-01 07:55:13 <wumpus> hm windows gitian dependencies are 5.2.0, not 5.2.1, so not sure about .1
367 2014-03-01 07:55:19 <fanquake> No worries, I'll try building again this arvo.
368 2014-03-01 07:55:33 <wumpus> what platform?
369 2014-03-01 07:55:51 <fanquake> osx 10.8.5
370 2014-03-01 07:56:02 <wumpus> ohhh osx, gavin is having big trouble with that too
371 2014-03-01 07:56:34 <fanquake> with QT specifically?
372 2014-03-01 07:56:39 <wumpus> as it look now we're going to ship the OSX build against qt4
373 2014-03-01 07:56:40 <wumpus> any qt5
374 2014-03-01 07:56:49 <fanquake> :(
375 2014-03-01 07:56:59 <wumpus> nothing deep, just some build system issue
376 2014-03-01 07:57:19 <fanquake> Just tried compiling now with 5.2.1, I see
377 2014-03-01 07:57:22 <fanquake> In file included from ./../paymentserver.h:34:
378 2014-03-01 07:57:23 <fanquake> ../../../src/qt/paymentrequestplus.h:12:10: fatal error: 'QByteArray' file not found
379 2014-03-01 07:57:37 <wumpus> that's a problem in the pkgconfig files IIRC
380 2014-03-01 07:57:47 <wumpus> the include path is not correct
381 2014-03-01 07:58:08 <wumpus> I remember someone was going to file an upstream issue for that, not sure if that happened
382 2014-03-01 07:58:59 <fanquake> hmm ok. I'll take a look
383 2014-03-01 08:03:18 <jcrubino> how can I uncompress a hex_compressed public key?
384 2014-03-01 08:11:41 <wumpus> by computing the y coordinate for the EC point, usually your crypto lib will handle this, why do you want to do this manually?
385 2014-03-01 08:16:32 <jcrubino> wumpus: I am working on multisig and would like to be able to sue what ever format the user inputs
386 2014-03-01 08:16:45 <jcrubino> be able to use
387 2014-03-01 08:18:05 <jcrubino> can bitcoinjs do this?
388 2014-03-01 08:18:32 <wumpus> this topic describes the maths behind it https://bitcointalk.org/index.php?topic=162805
389 2014-03-01 08:19:00 <wumpus> w/ openssl you can simply use EC_KEY_set_conv_form to change the key representation
390 2014-03-01 08:25:18 <jcrubino> thanks
391 2014-03-01 08:27:38 <jcrubino> the bitcointalk thread is a gem
392 2014-03-01 09:31:16 <CodeShark> been thinking a lot about BIP0032, wondering whether it might not be a good idea to use two separate child functions - one for constructing signing keys, another for derivation, so we can keep these two things separate
393 2014-03-01 09:31:47 <CodeShark> right now, each HD key is dual-use - it can either serve to as a signing key or as a derivation key
394 2014-03-01 09:33:14 <CodeShark> this means that in practice, each node is either a leaf in the derivation tree (but a parent to signing keys) or is a nonleaf in the derivation tree (but generates no signing keys directly)
395 2014-03-01 09:33:53 <CodeShark> or you can mix these two functions within the same generation, but it makes things much more complicated and error prone when developing applications
396 2014-03-01 09:34:18 <wumpus> well let's not make BIP0032 even more complicated, even right now people are implementing subsets at most
397 2014-03-01 09:34:34 <CodeShark> one of the reasons it's so complicated to use, IMHO, is because this distinction is not made clearly
398 2014-03-01 09:34:51 <CodeShark> I've been racking my brain trying to make good use of the H part of HD
399 2014-03-01 09:35:09 <CodeShark> and I still can't really come up with a good core data model
400 2014-03-01 09:35:49 <CodeShark> by splitting up these two functions, it's much easier to make good use of the H because you can always keep adding deeper derivation layers to any node even if you've already been using the node to generate signing keys
401 2014-03-01 09:36:05 <wumpus> yeah in retrospect we should have went with a BIP for the D (just private, hardened derivation) first, and then add the H optionally for people that need it
402 2014-03-01 09:36:52 <CodeShark> trying to find a good workaround to this issue
403 2014-03-01 09:37:04 <CodeShark> you could preallocate a certain range, I suppose
404 2014-03-01 09:37:21 <CodeShark> i.e. only the first half of the children will be used for signing keys, the rest are used for derivation
405 2014-03-01 09:37:54 <CodeShark> 2 billion signing keys should still probably be sufficient for most applications
406 2014-03-01 09:38:04 <CodeShark> or actually, sorry, one billion
407 2014-03-01 09:38:28 <CodeShark> or I guess you could allocate more to signing keys
408 2014-03-01 09:38:55 <CodeShark> problem is that unless we standardize this, interoperability might be an issue
409 2014-03-01 09:40:10 <CodeShark> and it's a pain that signing keys can also be used as derivation keys
410 2014-03-01 09:40:48 <CodeShark> would be nice when given an extkey to know it is a node and not a signing key
411 2014-03-01 09:41:31 <CodeShark> perhaps we could still develop a BIP for the D part
412 2014-03-01 09:41:53 <CodeShark> and keep BIP0032 exclusive to generating derivation trees and not signing keys
413 2014-03-01 09:44:07 <CodeShark> the way I see it, real-world organizational hierarchies are apt to change and grow organically - as such, it is near impossible to get the organizational structure correct when first creating an account
414 2014-03-01 09:44:54 <CodeShark> the more that the organizational hierarchy is mixed up with individual signing key generation, the less flexible the structure becomes
415 2014-03-01 09:46:44 <CodeShark> say you create an organization - at first it's just you - so you just have a single node that creates signing keys. Then you create two separate departments in your organization - so you simply branch off the root node. the signing keys you had initially created have no bearing on this decision at all
416 2014-03-01 09:47:19 <CodeShark> you don't need to plan for creating two departments up front
417 2014-03-01 09:50:21 <CodeShark> with the current approach, the workaround might be to always reserve the first child strictly for node derivation and always make node derivations two generations
418 2014-03-01 09:50:31 <CodeShark> but that seems ugly :)
419 2014-03-01 09:50:49 <CodeShark> would be much nicer to have a solid D implementation that's seeded with the node
420 2014-03-01 09:51:37 <CodeShark> and we can still do it, wumpus :)
421 2014-03-01 09:54:42 <CodeShark> the issue isn't really whether H is optional - but the fact that the current approach requires deciding up front what your organizational structure will look like
422 2014-03-01 09:55:25 <CodeShark> this is what makes the current approach (without some workaround) essentially unworkable for usabilitywise
423 2014-03-01 09:57:49 <CodeShark> the workaround of always reserving a particular child exclusively for hierarchichal derivation faces the further complication that a child with a particular index has a tiny but finite probability of being invalid :)
424 2014-03-01 09:58:51 <CodeShark> it would be nice for the D part to ensure that the map between the integers and the signing keys is always well-defined
425 2014-03-01 09:59:28 <CodeShark> otherwise, trying to figure out what the nth key in the sequence is technically requires going through all the previous keys
426 2014-03-01 09:59:37 <CodeShark> unless you're willing to chance it :)
427 2014-03-01 10:01:53 <CodeShark> for the hierarchy, this isn't as big an issue as generally speaking you won't be dealing in thousands upon thousands of children at each level - and the association between a department and a particular node needs to be documented and indexed somewhere anyhow
428 2014-03-01 10:02:17 <CodeShark> but signing keys need to be generated on the fly, on demand, and in large numbers
429 2014-03-01 10:23:34 <wumpus> right, there are lots of ways a real world hierarchy could work -- to be honest I think we first need a few examples of people actually using the hierarchical part, it feels to be like classical overdesign, remember that most wallets at this point don't even support determinism yet
430 2014-03-01 10:27:33 <CodeShark> I'm trying to be one of those first few examples - this isn't just hypothetical stuff - I have a real product using this right now
431 2014-03-01 10:28:09 <CodeShark> and I can tell you that the hierarchical part is a pain to manage from a usability standpoint if it's mixed with the deterministic signing keys
432 2014-03-01 10:29:11 <wumpus> that's because you are the first to get there
433 2014-03-01 10:30:12 <wumpus> it makes sense to adapt BIP0032 (or create new BIP even) after there are a few real, useable implementations
434 2014-03-01 10:30:26 <wumpus> this is happening with the payment request stuff too
435 2014-03-01 10:32:50 <wumpus> I suggest writing a post to the mailing list
436 2014-03-01 10:33:38 <wumpus> I don't think all wallet authors frequent here
437 2014-03-01 10:33:56 <Jere_Jones> What is the use case for so many signing keys?
438 2014-03-01 10:35:36 <wumpus> lots of transactions
439 2014-03-01 10:37:01 <Jere_Jones> Oh. I was thinking message signing. That makes MUCH more sense.
440 2014-03-01 10:40:03 <wumpus> after all if you handle things properly for every invoice / change transaction you need a new key (multiple keys if you use some scheme to break up coins)
441 2014-03-01 10:42:49 <Jere_Jones> It was my misunderstanding. I thought he wanted different keys for performing transactions and signing messages. Which made no sense to me. Signing as in signing transactions is completely understandable.
442 2014-03-01 10:45:10 <wumpus> right
443 2014-03-01 11:40:52 <chichov> is there any lower bound on the target? (Bits field)
444 2014-03-01 11:41:50 <chichov> according to the wiki it's 0x008000, but there seems to be a byte missing and when plugged into the formula it results in 1/2
445 2014-03-01 11:45:59 <chichov> it seems rather that 0x03000001 could be a valid lower bound, as it would result in 0x1
446 2014-03-01 14:22:43 <gavinandresen> wumpus jgarzik sipa : I'm going to tag v0.9.0rc2 and create a 0.9.0 branch, our 0.9.0 milestone issues list is empty