1 2013-03-10 00:00:40 <weex> hopefully in 20 years there'll be 100 utxo for every person alive
2 2013-03-10 00:03:06 <xjrn> so again, how taxing is it to verify a block per 10 minutes? am i missing something? Ed25519 makes sense to roll into a hard fork i guess, yeilding "A quad-core 2.4GHz Westmere signs 109000 messages per second."
3 2013-03-10 00:07:37 <xjrn> 50,000 tx per block at some ridiculous optimistic 20 bytes per tx unsorted, 100% low entropy trades to the history of the blockchain would be worth the fees, the greater the spam the denser the fees
4 2013-03-10 00:08:28 <xjrn> s/unsorted/sorted/
5 2013-03-10 00:11:16 <xjrn> it seems that trades do not require backrefs over the wire, if noone complains about the bandwidth to relay atomic representations. that wouldn't prevent two competing miners, one using high entropy encoding of a block and one using low entropy to publish on 2 compatibility standards, and the normalized form exported to the de-nromalized form and sent over the wire to UTXO-only nodes
6 2013-03-10 00:12:44 <petertodd> https://github.com/bitcoin/bitcoin/pull/2351 <- new pull-req to prevent creation and relaying of transactions with txouts with value <= fees (uneconomical to spend)
7 2013-03-10 00:13:03 <petertodd> Blocks dead puppies, without specifically blocking dead puppies.
8 2013-03-10 00:16:15 <xjrn> petertodd: "Keeps the UTXO set from being bloated" -- UTXO set doesn't appear in the bitcoin Target
9 2013-03-10 00:17:37 <petertodd> xjrn: huh?
10 2013-03-10 00:17:39 <xjrn> petertodd: I'm pointing this out to note that the wiki docs i read to become familiar with the bitcoin mechanics excluded local caches as a supported feature
11 2013-03-10 00:18:02 <petertodd> xjrn: What do you mean by "local caches"?
12 2013-03-10 00:18:39 <xjrn> I guess i need ot read what UTXO is, if not a local cache of coins\\
13 2013-03-10 00:18:51 <petertodd> xjrn: Yes, that has nothing to do with that...
14 2013-03-10 00:25:02 <nanotube> petertodd: even though a single small txo may be uneconomical to spend, it may be economical to put several of those into a transaction and recover some money. does your patch consider that?
15 2013-03-10 00:25:29 <nanotube> also, it may be that as bitcoins appreciate faster than transaction volume grows, min fees may shrink to make previously 'too small' outputs economical to spend...
16 2013-03-10 00:26:33 <petertodd> nanotube: Yes. Spending a UTXO does require a marginal increase in the amount of bytes a transaction has, always less than a bit under 1000 bytes.
17 2013-03-10 00:27:17 <petertodd> nanotube: It may, but I don't see the block size limit being changed soon, if at all, so we can't expect minimum fees to shrink much if at all.
18 2013-03-10 00:27:20 <gmaxwell> nanotube: I haven't read the latest revision of the patch but if its correctly constructed it should be based on the minimum marginal increase, such that your combining argument never applies.
19 2013-03-10 00:28:12 <gmaxwell> petertodd: uh. your argument there doesn't apply. Say tomorrow bitcoin stared reliably trading at $1000. Fees would go down by 1000/40 ish.
20 2013-03-10 00:28:18 <petertodd> gmaxwell: Exactly. It doesn't figure out the marginal increase explicitly, but because scriptSigs > 500 bytes are non-standard, you can bound that increase pretty easily, so pricing the min amount allowed out as the cost of 1KB in transaction fees is pretty close to correct, and allows for some profit in spending them.
21 2013-03-10 00:28:46 <gmaxwell> petertodd: I think it should probably be conservative in the other direction. E.g. assuming they add about 200 bytes.
22 2013-03-10 00:28:51 <petertodd> gmaxwell: Yes, but in that case people would have to change the DUST constant and MIN_TX_FEE constants, and my patch sets the minimum fees based on that, so it'll work automatically.
23 2013-03-10 00:29:16 <petertodd> gmaxwell: If you want to be conservative, use MIN_RELAY_TX_FEE instead.
24 2013-03-10 00:29:24 <petertodd> (as the absolute minimum)
25 2013-03-10 00:29:43 <gmaxwell> petertodd: using fee/kb * .200 is more adaptive.
26 2013-03-10 00:29:58 <petertodd> gmaxwell: That's what the patch does, but * 1
27 2013-03-10 00:30:22 <gmaxwell> or max(MIN_RELAY_TX_FEE*0.2, fee/kb * .2)
28 2013-03-10 00:30:31 <petertodd> gmaxwell: Go read it...
29 2013-03-10 00:30:37 <gmaxwell> (the .2 is just assuming a conservative marginal increase is 200 bytes, I haven't checked)
30 2013-03-10 00:31:17 <gmaxwell> the reason you want to be conservative here is that to avoid denying valid uses you want to allow just-barely profitable utxo. Only the grossly uneconomical ones should be prohibited.
31 2013-03-10 00:31:41 <nanotube> mmk
32 2013-03-10 00:31:47 <petertodd> gmaxwell: You understand that it's basing the assumption on the actual fee per kb the tx paid, bounded below and above right?
33 2013-03-10 00:31:53 <gmaxwell> nanotube: the other issue you have is that a large fraction of uneconomical utxo will be lost forever even before increase in bitcoin value makes them worth redeeming.
34 2013-03-10 00:32:24 <nanotube> lost forever how?
35 2013-03-10 00:32:25 <gmaxwell> petertodd: I do. Did you ever find the discussion in here where vinny_win proposed that ahead of you and I thought it was fantastic? :P
36 2013-03-10 00:32:59 <petertodd> gmaxwell: Yeah, I went off and wrote the patch rather than wasting time looking it up.
37 2013-03-10 00:33:15 <gmaxwell> nanotube: I've seen a bunch of people in IRC do this: they get a whole bunch of utx adding up to like 0.009 BTC .... and they can't spend them, so they delete the wallet.
38 2013-03-10 00:33:28 <nanotube> ah heh ic.
39 2013-03-10 00:33:29 <gmaxwell> I've successfully talked at least three people into giving me their wallets instead of doing that.
40 2013-03-10 00:33:44 <nanotube> well, that strikes me more of a human problem than a bitcoin problem. :)
41 2013-03-10 00:34:04 <petertodd> gmaxwell: Which is why I don't want to be too conservative, I want the value to be clearly worth spending.
42 2013-03-10 00:34:35 <xjrn> so trading value below the fee gets rejected; what about free tx below the fee?
43 2013-03-10 00:34:52 <gmaxwell> xjrn: MIN_RELAY_TX_FEE is treated as the fee there, right petertodd
44 2013-03-10 00:34:59 <petertodd> xjrn: If you have an output < 0.01 btc, you are forced to pay a fee anyway.
45 2013-03-10 00:35:01 <gmaxwell> (I still haven't looked at the patch :P )
46 2013-03-10 00:35:25 <petertodd> ACTION stops talking to gmaxwell until he reads it
47 2013-03-10 00:35:25 <xjrn> free tx is now a hypothetical, but coerced otherwise
48 2013-03-10 00:35:47 <gmaxwell> xjrn: what are you trolling about?
49 2013-03-10 00:35:59 <gmaxwell> petertodd: part of the sugar in jgarzik's patch was changing that to 0.0001. Thats perhaps something you should retain if you didn't.
50 2013-03-10 00:36:25 <xjrn> did you pay fees on those 3 wallets to close them out?
51 2013-03-10 00:36:55 <gmaxwell> xjrn: no, didn't have to, too their unspent outputs and spent them in other regular transactions I made while doing other things.
52 2013-03-10 00:37:23 <gmaxwell> s/too/took/
53 2013-03-10 00:39:17 <xjrn> gmaxwell so what's your take on raising the entropy of a block's transaction representations to pack more of them side by side?
54 2013-03-10 00:39:26 <gmaxwell> petertodd: in any case, someone may rightfully feel that their really small txout is hardly worth redeeming today, but later it will be worth redeeming.
55 2013-03-10 00:40:19 <gmaxwell> xjrn: if someone wants to write an alternative p2p protcol that seralizes blocks differently in order to take less bandwidth, thats great... and it's something they can do on their own without seeking my approval.
56 2013-03-10 00:40:50 <gmaxwell> (likewise for on disk storage)
57 2013-03-10 00:41:58 <gmaxwell> though also, the assumption that a node has the full history is a terrible one, we've specifically designed the system so that even full validators don't need the whole history. Plus that assumption implies poor locality, which is bad for performance. Fortunately, I'm sure you can do smarter seralization without having those constraints.
58 2013-03-10 00:42:32 <xjrn> gmaxwell: I'm under the impression that the blockchain history and all of its constituent protocols and assemblies are in fact denormalized toa point that can't get further denormalized. just the act of normalizing data seems like a good idea
59 2013-03-10 00:42:36 <gmaxwell> (by 'don't need the whole history' I mean don't need to store it. They can observe it and forget the far past history)
60 2013-03-10 00:43:49 <gmaxwell> oh it's far from denormalized. For example, prior transactions are referenced by their txid and not by their content. It would actually make some things a lot easier if it were less normalized.
61 2013-03-10 00:44:23 <xjrn> new info for me, while i frantically try to find source info on what UTXO is
62 2013-03-10 00:44:34 <gmaxwell> unspent transaction output.
63 2013-03-10 00:45:01 <xjrn> this is now a seperate ledger from the blockchain history with a support system of coders now
64 2013-03-10 00:45:56 <gmaxwell> xjrn: the system has _always_ used an index of unspent transactions. Otherwise computational complexity of verifying transactions is exponential.
65 2013-03-10 00:46:13 <gmaxwell> Previously the same index also had spent transactions. (unspent vs spentness was just a flag).
66 2013-03-10 00:47:16 <xjrn> it doesnt show up in the bitcoin 101 newby pages that describes the basics, from 2010 or whenever they were written. i understand what it is is no diffrent than what existed before, ina diffrent form. it now seems utxo is this z80 processor at the heart of the bitcoin network which is defining reasons to make exxception to the original tx rules
67 2013-03-10 00:47:18 <gmaxwell> Bitcoin-qt now instead no longer indexes spent transactions and uses an optimized datatructure for unspent txn that include inline all the data needed to validate spenders of those input transactions (which is a small fraction of the transaction's size)
68 2013-03-10 00:48:26 <gmaxwell> xjrn: bitcoin 101 pages don't describe anything remotely this tecnial. Don't have a clue what you mean by 'defining reasons to make exxception to the original tx rules'.
69 2013-03-10 00:48:36 <xjrn> don't tax the z80 processor
70 2013-03-10 00:49:11 <gmaxwell> The importance of the utxo set is indicated in the original whitepaper (published long before the system), though we use different language now.
71 2013-03-10 00:49:36 <gmaxwell> See section 7. http://bitcoin.org/bitcoin.pdf
72 2013-03-10 00:51:23 <gmaxwell> The utxo set is just what you get when you carry section 7 to its logical conclusion. Thats what the patch implementing it was called ...
73 2013-03-10 00:51:26 <gmaxwell> ... 'ultraprune'[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C ...
74 2013-03-10 00:51:33 <gmaxwell> ... [C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C.
75 2013-03-10 00:51:38 <gmaxwell> oops sorry about that. weird irc glitch
76 2013-03-10 00:51:45 <xjrn> utxo hamster wheels aside, references which exist as txid's consumeing n bits can be squeezed into coordinate systems of probablistic lookup bits to describe frequent things more tersley than atomic things.
77 2013-03-10 00:51:47 <gmaxwell> was called 'ultraprune'
78 2013-03-10 00:52:32 <gmaxwell> When bitcoin is used correctly virtually all of the high entroy data is atomic.
79 2013-03-10 00:52:59 <gmaxwell> I am unwilling to entertain optimizations which encourage and only work with behavioral changes which undermine the privacy properties of the system.
80 2013-03-10 00:53:02 <xjrn> i guess while my fortune builds at .05 BTC per day i may work on researching where to the low entropy lives
81 2013-03-10 00:55:23 <xjrn> right, you cannot reduce a hash to fewer bits than a certain constant. it's not worth gzipping the hash value though you could refer to prior blocks, a coordinate system, to normalize giant byte counts for recurring scripts and tx's
82 2013-03-10 00:55:57 <xjrn> i don't know how the recurrence of a script from prior blockchain would compromise privacy
83 2013-03-10 00:56:17 <xjrn> it is just re-expressed in the current tx's
84 2013-03-10 00:57:19 <xjrn> if huffman encoding were applied to the occurences of spammers, those spammers would need the fewest bits to represent an event
85 2013-03-10 00:58:17 <xjrn> it seems more elegant than pitchforks and fees with fine print
86 2013-03-10 01:07:27 <gmaxwell> xjrn: a script never reoccurs unless a user reuses a public key. (and even then, most of the data does not reoccur)
87 2013-03-10 01:07:54 <gmaxwell> and doing so compromises everyone's privacy.
88 2013-03-10 01:08:42 <xjrn> at what point does the pubkey get re-generated?
89 2013-03-10 01:09:39 <xjrn> i was under the impression it would live as long as the passphrase assigned
90 2013-03-10 01:10:04 <gmaxwell> As the system was envisioned (section 10 of bitcoin.pdf) every payment pays to a different public key.
91 2013-03-10 01:10:10 <gmaxwell> passphrase ?! no.
92 2013-03-10 01:16:01 <xjrn> gma "The public can see that someone is sending
93 2013-03-10 01:16:03 <xjrn> an amount to someone else, but without information linking the transaction to anyone."
94 2013-03-10 01:17:11 <xjrn> gmaxwell "The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone." does not jive with what's available on blockexplorer, blockchain.info, etc. most of my payments arrive when I'm offline generating no new public keys.
95 2013-03-10 01:19:15 <Luke-Jr> oh great, now gavin is giving SatoshiDice a privileged effective-veto on changes to the codebase?
96 2013-03-10 01:19:30 <xjrn> section 10 seems like an idealism
97 2013-03-10 01:19:39 <gmaxwell> xjrn: huh? you being online doesn't matter.
98 2013-03-10 01:19:55 <Luke-Jr> gmaxwell: did I read that right?
99 2013-03-10 01:19:57 <gmaxwell> xjrn: you have to give the party that pays you an address to pay.
100 2013-03-10 01:20:18 <gmaxwell> Luke-Jr: I think you're reading too much into it.
101 2013-03-10 01:20:58 <gmaxwell> Luke-Jr: he listed a bunch of stuff like "how it affects users who might already have coin dust in their wallets" which the code doesn't effect, but people would have questions about.
102 2013-03-10 01:21:07 <xjrn> and when my friend gives me his address i can see the entire history of that address, likewise for myself, until such time asss i change
103 2013-03-10 01:21:28 <gmaxwell> xjrn: thats your confusion. Have you ever actually used bitcoin? Users don't just have one address.
104 2013-03-10 01:22:03 <xjrn> sureeeeee, i do not keep generating new addresses and pasting them into my miner account, though I could.
105 2013-03-10 01:22:12 <gmaxwell> You normally issue a new address every time you recieve a payment??? thats how you tell who paid you for what. Everytime the software creates a transaction that has change it uses a new address, etc.
106 2013-03-10 01:23:15 <gmaxwell> xjrn: even in that case??? (which should be accomplished with a chain, but thats not implemented yet) you'd still use that address only for that one sender.
107 2013-03-10 01:24:03 <xjrn> so 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB is a wallet but not an address, and you retaaaain this wallet while an address changes?
108 2013-03-10 01:24:54 <gmaxwell> https://en.bitcoin.it/wiki/BIP_0032#Recurrent_business-to-business_transactions:_M.2Fi.2F0 (for the chain stuff)
109 2013-03-10 01:25:06 <gmaxwell> xjrn: no its not a wallet.
110 2013-03-10 01:25:25 <gmaxwell> Actually it's just a private key that isn't even loaded into a node. Every transaction I make involving that I make by hand.
111 2013-03-10 01:25:45 <gmaxwell> Also??? stalk much? :P
112 2013-03-10 01:26:03 <xjrn> http://blockchain.info/address/1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB most certainly does not accord to section 10, all is revealed.
113 2013-03-10 01:26:14 <gmaxwell> xjrn: all of what is revealed.
114 2013-03-10 01:26:15 <gmaxwell> ?
115 2013-03-10 01:26:26 <gmaxwell> And yes, public donation addresses do not accord to section 10.
116 2013-03-10 01:27:45 <xjrn> there was my confusion in that you stated new addresses "are generated each", but i think in the real world, that's probably more popular with a small group than the majority
117 2013-03-10 01:28:46 <xjrn> so in the real world, you, me, Luke-Jr, and a ton of other happless targets use a low entropy blockchain representation over the course of time
118 2013-03-10 01:29:09 <xjrn> searchable by a free tool
119 2013-03-10 01:29:48 <xjrn> it makes sense to consider this apt for a tokenization, and hell, a cheaper fee by virtue of fewer bits
120 2013-03-10 01:31:11 <gmaxwell> xjrn: it's the default behavior of the software. the vast majority of my coins are in one use addresses. The 1GMaxweLLb is special because its a vanity address.
121 2013-03-10 01:31:32 <xjrn> i get that, i didnt get your blankeeet statement before.
122 2013-03-10 01:32:46 <gmaxwell> xjrn: Not sure what you didn't get.
123 2013-03-10 01:33:05 <gmaxwell> bbl
124 2013-03-10 01:36:02 <xjrn> gmaxwell: "You normally issue a new address every time you recieve a payment" -- couldn't reconcile this with what i know.
125 2013-03-10 01:36:20 <xjrn> gmaxwell: cya
126 2013-03-10 01:45:26 <sudofox> Hi! ^-^
127 2013-03-10 01:46:47 <sudofox> Does anyone happen to know how to use grondilu's Bitcoin Bash Tools? I'm struggling, and need to input a SHA256 and have it spit out a Bitcoin ready base58check private key.
128 2013-03-10 01:46:59 <sudofox> ..
129 2013-03-10 01:47:09 <sudofox> There's more steps in there, but..
130 2013-03-10 01:48:57 <oGminor> I lost my bitcoin wallet password, would it be possible/faster to check versions of what I think it is by extracting some function that tries to decrypt from the client over using the json RPC?
131 2013-03-10 01:49:37 <sudofox> What?
132 2013-03-10 01:49:41 <jgarzik> sipa: sigh... vvv
133 2013-03-10 01:49:50 <jgarzik> I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. "
134 2013-03-10 01:49:50 <jgarzik> "The minikey always uses uncompressed public keys.
135 2013-03-10 01:49:51 <jgarzik> https://bitcointalk.org/index.php?topic=150715.msg1604781#msg1604781
136 2013-03-10 01:50:19 <sipa> jgarzik: we need to apply some pressure on him, i think
137 2013-03-10 01:50:28 <sudofox> I use multibit..
138 2013-03-10 01:50:29 <sipa> pressure -> compression... get it?
139 2013-03-10 01:50:34 <jgarzik> ;p
140 2013-03-10 01:50:40 <sudofox> Bwahahaha
141 2013-03-10 01:50:59 <sudofox> @jgarzik # Format: # <Base58 encoded private key>[<whitespace>[<key createdAt>]]
142 2013-03-10 01:51:55 <gmaxwell> Is it sad that I know it's casascius purely by the unfortunateness of the position? :(
143 2013-03-10 01:52:08 <sudofox> @jgarzik Here's a privkey export/import file, the paste will expire in 10 minutes
144 2013-03-10 01:52:09 <sudofox> http://pastebin.com/Y79Vbaq9
145 2013-03-10 01:52:34 <sudofox> The privkeys there won't be used.
146 2013-03-10 01:53:46 <sudofox> Anyways, my question is (probably too trivial to stick on the Stack|Exchange site at the present time): How do I use grondilu's bitcoin-bash-tools ? It's a shell script.
147 2013-03-10 01:55:19 <sudofox> Dang it..
148 2013-03-10 02:09:41 <warren> petertodd: btw, what about discouraging outputs < fee in cases where it is spending 0-conf?
149 2013-03-10 02:10:08 <warren> petertodd: that'd make fewer people concerned
150 2013-03-10 02:11:01 <gmaxwell> warren: that just becomes a lot more complicated to reason about and doesn't actually address the concern of creating uneconomic to spend data. You're overfitting on specific cases.
151 2013-03-10 02:11:30 <warren> ok
152 2013-03-10 02:15:56 <jgarzik> that was a quick close of #2351
153 2013-03-10 02:16:12 <jgarzik> I think I have a looser definition of pull request than Gavin ;p
154 2013-03-10 02:17:17 <jgarzik> A pull request is valid if it _could_ be pulled immediately [if the community / devs / etc. like it]
155 2013-03-10 02:17:37 <jgarzik> Certainly that is a very loose definition that could be abused
156 2013-03-10 02:20:42 <mogri> it's an ok definition jgarzik
157 2013-03-10 02:22:16 <warren> jgarzik: is the decision making process written down anywhere?
158 2013-03-10 02:27:21 <gmaxwell> warren: there are 9 people who can commit to the repository, 5 who do with any frequency. This doesn't require a ton of procedure documentation.
159 2013-03-10 02:28:00 <warren> general consensus then
160 2013-03-10 02:28:14 <sipa> basically, yes
161 2013-03-10 02:32:07 <petertodd> jgarzik: Just definitions of what a pull-req is for; I'll post my full write-up to bitcoin-dev in another hour or two.
162 2013-03-10 02:37:49 <jgarzik> less consensus required for closing a pull req though
163 2013-03-10 02:38:07 <jgarzik> since it is easy to reopne
164 2013-03-10 02:38:09 <jgarzik> *reopen
165 2013-03-10 02:38:27 <jgarzik> easier for a dev to be grumpy ;p
166 2013-03-10 02:39:04 <aethero> What are the plans for Bitcoin when quantum computing becomes mainstream and ECDSA becomes significantly weaker?
167 2013-03-10 02:39:24 <sipa> aethero: die
168 2013-03-10 02:39:37 <aethero> I prefer living, thanks.
169 2013-03-10 02:39:49 <sipa> haha, it was not an imperative!
170 2013-03-10 02:39:55 <asd34sd> hi
171 2013-03-10 02:40:06 <asd34sd> im trying to compile BFGminer but having some issues , says configure error: cannot find install-sh, install.sh, or shtool
172 2013-03-10 02:41:17 <sipa> aethero: more seriously: it won't be a sudden break most likely, and if it becomes apparent that ECDSA would become too weak, a hard fork that introduced a new QC-resistant cryptographic primitive would become significantly easier
173 2013-03-10 02:41:38 <aethero> Why not introduce that into the next fork?
174 2013-03-10 02:42:40 <sipa> QC cryptography has large disadvantages (afaik, i'm no expert), large key sizes for one
175 2013-03-10 02:42:55 <sipa> and at this point there is no reason to assuem that QC will ever be actually possible at that scale
176 2013-03-10 02:45:52 <warren> Worry about other two letter names before QC.
177 2013-03-10 02:48:27 <phantomcircuit> sipa, gigantic key sizes
178 2013-03-10 02:49:45 <gmaxwell> gigantic signature sizes. We can always solve key sizes in our system, keys can never be too gigantic for us. :P
179 2013-03-10 02:53:07 <gmaxwell> 256-bit lamport results 16kbyte signatures. Which is mildly insane, but then if you're assuming QC you probably want 512 bit lamport, which results in 64kbyte signatures. Plus you can't sign multiple times without leaking your private key. (well, it's not all leaked unless the attacker makes you sign data who's hash is the bitwise compliment of the data you signed before)
180 2013-03-10 02:53:41 <aethero> gmaxwell
181 2013-03-10 02:53:47 <aethero> Right now with how Bitcoin implements ECDSA
182 2013-03-10 02:53:52 <gmaxwell> none of the other post QC signature schemes are really any better (and at least lamport is fast and not obviously less secure than anything we use that isn't QC strong)
183 2013-03-10 02:53:54 <aethero> How vulnerable is it to QC?
184 2013-03-10 02:54:11 <gmaxwell> aethero: It's completely secure so long as QC continue to not exist. :P
185 2013-03-10 02:54:18 <aethero> Har har.
186 2013-03-10 02:54:23 <gmaxwell> (well completely secure against QC so long as QC continue to not exist)
187 2013-03-10 02:54:28 <aethero> If QC exists tomorrow
188 2013-03-10 02:54:42 <aethero> How secure is Bitcoin's implementation of ECDSA the day after?
189 2013-03-10 02:54:54 <gmaxwell> Well, funny but it's a serious point. In engineering you don't just get to state what ifs without their preconditions. If you do you make bad decisions.
190 2013-03-10 02:55:17 <aethero> Are we talking about a halving of the keyspace? Or is it basically useless?
191 2013-03-10 02:55:28 <aethero> Halving of a keyspace already so large that halving doesn't mean anything?
192 2013-03-10 02:55:40 <warren> Hmm, interesting, lamport signatures may only be signed by a key once?
193 2013-03-10 02:55:42 <gmaxwell> "QC" isn't good enough, you need a very large quantum computer, with very large coherence times. And then its useless.
194 2013-03-10 02:55:51 <aethero> Define "very large"
195 2013-03-10 02:55:56 <sipa> aethero: ECDSA becomes fundamentally broken in the presence of general-purpose large-qubit QC
196 2013-03-10 02:56:33 <gmaxwell> If the quantum computer is error free then it takes 4 billion operations on about 4k qbits to solve the 256bit DLP.
197 2013-03-10 02:58:12 <aethero> And Bitcoin uses a 256bit DLP?
198 2013-03-10 03:00:19 <gmaxwell> and then a potentially exponential number more operations and bits due to error recovery.
199 2013-03-10 03:00:19 <gmaxwell> (and this is assuming a idealized QC, anything actual would likely need some large constant factor more operations)
200 2013-03-10 03:00:42 <sipa> aethero: EC DLP
201 2013-03-10 03:00:53 <sipa> (which means 128-bit security)
202 2013-03-10 03:01:09 <aethero> Ok then let me rephrase my question even more
203 2013-03-10 03:01:14 <aethero> And I understand the answer is highly hypothetical
204 2013-03-10 03:01:45 <sipa> aethero: given highly idealized general-purpose large-scale QC, ECDSA becomes trivial to crack
205 2013-03-10 03:01:54 <jgarzik> ACTION rebuilds openssl on Fedora, for the nth time
206 2013-03-10 03:02:12 <aethero> But given the current rate of advancement in quantum computing, assuming no massive breakthroughs, assuming no change in Bitcoin, how long would you wildly guestimate it would be until quantum computing gets to the point where bitcoin in it's current state is broken
207 2013-03-10 03:02:26 <gmaxwell> jgarzik: if we merge a sufficiently complete sipa-turbo ecdsa we wouldn't need openssl EC anymore. :P
208 2013-03-10 03:02:47 <aethero> Are we talking 5 years, or 50?
209 2013-03-10 03:03:04 <sipa> aethero: anything between 5 years and 5 million
210 2013-03-10 03:03:25 <aethero> =[
211 2013-03-10 03:03:32 <canoon> is there planned anything to encourage people to spend insignificant outputs that would build up in the unprunable transactions?
212 2013-03-10 03:03:34 <gmaxwell> aethero: right now there are no quantum turing complete computers of any size that can compute anything. None of the proposed mechnisms seem like they'll obviously scale to many qbits, none have coherence times long enough to do more than a couple operations.
213 2013-03-10 03:04:07 <gmaxwell> It's really hard to estimate the time between 0 and complete. perhaps if we had 8 bit quantum turing complete devices it might be easier to guess.
214 2013-03-10 03:04:10 <warren> I'd love a non-openssl EC for Fedora.
215 2013-03-10 03:05:11 <gmaxwell> It may even turn out that subtle physics limits bound the error rate vs size of QCs and keep solving large DLP on one pratically impossible. This stuff is just too far out to talk about for sure.
216 2013-03-10 03:05:51 <gmaxwell> aethero: if it makes you feel better, if you use bitcoin properly??? each address only used once??? the public key is only exposed to QC cracking between the time you announce a transaction and the time it gets mined.
217 2013-03-10 03:06:08 <gmaxwell> So not only would someone need to break ecdsa, they'd need to break it moderately quickly.
218 2013-03-10 03:06:21 <warren> Are there any type-2 deterministic wallets now?
219 2013-03-10 03:06:54 <gmaxwell> on that basis, e.g. 512-768 bit RSA ??? which is crakable now??? would be pratically secure if we were using it in bitcoin. (though we'd be upgrading if thats what it used)
220 2013-03-10 03:07:02 <sipa> warren: Armory and Electrum have them
221 2013-03-10 03:07:12 <warren> oh
222 2013-03-10 03:07:25 <warren> sipa: do they rely on openssl ecdsa too?
223 2013-03-10 03:08:10 <sipa> no idea
224 2013-03-10 03:08:48 <remote> how do you get the address from a public key?
225 2013-03-10 03:09:17 <sipa> remote: you hash it
226 2013-03-10 03:09:55 <remote> how?
227 2013-03-10 03:10:11 <sipa> RIPEMD160(SHA256(pubkey))
228 2013-03-10 03:10:19 <sipa> and encode that in base58
229 2013-03-10 03:11:52 <aethero> Reusing addresses shouldn't be considered improper usage imo
230 2013-03-10 03:12:02 <sipa> it should, imo
231 2013-03-10 03:12:19 <aethero> if ECDSA is broken and people lose coins by re-using an address you wont say "Bitcoin isn't broken!" will you?
232 2013-03-10 03:13:05 <sipa> if ECDSA is broken, Bitcoin - in its current form - is broken
233 2013-03-10 03:13:43 <sipa> you can't rely on the short window in which pubkeys are revealed, even when addresses aren't reused
234 2013-03-10 03:13:58 <sipa> but that doesn't mean that reusing an address is no bad idea for other reasons
235 2013-03-10 03:14:07 <gmaxwell> aethero: it's improper usage for reasons that have nothing to do with ECDSA strength. I don't even think satoshi thought of that advantage, it's just a happy (or irrelevant) accident.
236 2013-03-10 03:14:10 <sipa> wait, too many negations
237 2013-03-10 03:14:34 <aethero> lol
238 2013-03-10 03:15:07 <gmaxwell> I'm just pointing out that the design of the system makes it less brittle than it could be. It means that if you start thinking 'maaayyybbbe ecdsa isn't secure enough' you can work extra hard to avoid reuse and decrease your exposure while an upgrade is deployed.
239 2013-03-10 03:15:19 <warren> sipa: just consider it both + and - at the same time, as long as you don't look.
240 2013-03-10 03:15:33 <canoon> i was thinking if we calculated the size of transactions for the purpose of fees as "size = real_size + (outputs - inputs) * (size of an average transaction input)", the fee would generally just be based on the size of the outputs which is what people would expect (no excessively large fees) and it would encourage people to spend even insignificant amounts of bitcoins and overtime the same amount of fees would be charged
241 2013-03-10 03:15:39 <gmaxwell> (As far as properness goes, I refer to the text at the bottom of section 10 in bitcoin.pdf)
242 2013-03-10 03:16:11 <gmaxwell> canoon: hey, that formula looks familar.
243 2013-03-10 03:16:33 <canoon> lol i thought someone might have already come up with it
244 2013-03-10 03:16:43 <gmaxwell> canoon: the problem is that it's not the economically locally-greedy behavior for miners to prefer based on that. So it's not clear to me that it is all that viable.
245 2013-03-10 03:17:10 <canoon> if you use the same method to calculate block size wouldn't it still work?
246 2013-03-10 03:17:39 <gmaxwell> canoon: it's similar to something that I'd proposed??? which was replacing size in priority with size modified by adding in the change in utxo size, plus some scaling.
247 2013-03-10 03:18:28 <gmaxwell> canoon: that's a rule of the system, not something that can at all be easily changed. But right, if $whatever is also the rule that constrains block size then the incentives are all aligned.
248 2013-03-10 03:21:26 <MrKain> I received 0.001 BTC in address 1Dr3G3utLgzvfdBUX5qpCeB33ZXHUxWkcz ,,, but querying this hash in blockexplorer give an error
249 2013-03-10 03:21:27 <gribble> Error: "," is not a valid command.
250 2013-03-10 03:23:02 <canoon> seems like it would be fairly uncontroversial change as it doesn't really negatively affect anyone though
251 2013-03-10 03:30:06 <remote> MrKain: http://blockchain.info/address/1Dr3G3utLgzvfdBUX5qpCeB33ZXHUxWkcz
252 2013-03-10 03:30:34 <gmaxwell> canoon: we have never had a hardforking change, and such change would be inherently somewhat controversial and risky.
253 2013-03-10 03:30:56 <canoon> wasn't the p2sh change a hardforking change?
254 2013-03-10 03:30:59 <gmaxwell> One problem is that I don't know there there is an obviously right metric.
255 2013-03-10 03:31:03 <gmaxwell> canoon: No sir, absolutely not.
256 2013-03-10 03:31:17 <gmaxwell> (and P2SH wouldn't have been worth making a hardforking change for)
257 2013-03-10 03:32:10 <canoon> but if you had nodes with different rules for validating transactions wouldn't that cause a fork?
258 2013-03-10 03:32:16 <canoon> or is there something else different?
259 2013-03-10 03:32:22 <gmaxwell> I suppose what you suggest could be done as a soft forking change so long as the size was also still limited to a million bytes, but then it would only decrease the effective maximum, which is unlikely to be a popular idea. :P
260 2013-03-10 03:32:28 <sipa> P2SH only introduced a backward-compatible change, "soft fork
261 2013-03-10 03:32:44 <gmaxwell> canoon: No, all the old nodes are perfectly happy to accept a valid p2sh chain.
262 2013-03-10 03:33:19 <canoon> wait do they accept blocks even if they have invalid transactions?
263 2013-03-10 03:33:26 <gmaxwell> They're not invalid.
264 2013-03-10 03:33:27 <sipa> no
265 2013-03-10 03:33:59 <canoon> but if someone spends a p2sh that would be invalid in a non p2sh client wouldn't it?
266 2013-03-10 03:34:03 <gmaxwell> P2SH transactions are valid to old nodes. P2SH only reduced the set of things considered valid, thus its a softforking change.
267 2013-03-10 03:34:06 <sipa> canoon: no
268 2013-03-10 03:34:54 <canoon> hmm...
269 2013-03-10 03:35:16 <sipa> old nodes can't validate the inner script
270 2013-03-10 03:35:32 <sipa> but just call it valid
271 2013-03-10 03:35:50 <canoon> do you mean valid as in like its correctly formatted? it doesn't have to actually verify the input?
272 2013-03-10 03:36:02 <sipa> it does verify the input, according to the old rules
273 2013-03-10 03:36:18 <canoon> wouldn't it pass in one and not pass in the other?
274 2013-03-10 03:36:46 <sipa> and the actual P2SH script - as seen by an old client - is: "push <data representing a script>; hash; check hash == <some value>:"
275 2013-03-10 03:37:07 <sipa> so they validate that the input provides a script whose hash is the P2SH hash
276 2013-03-10 03:37:16 <sipa> but they don't evaluate the inner script
277 2013-03-10 03:38:12 <canoon> ok yeah but what if i send a transaction that is just data that happens to hash to the correct thing?
278 2013-03-10 03:38:27 <sipa> old nodes will consider that valid
279 2013-03-10 03:38:51 <canoon> oh right but there will be enough hashing power on the new chain
280 2013-03-10 03:38:52 <canoon> ok
281 2013-03-10 03:38:56 <canoon> i get it
282 2013-03-10 03:39:04 <sipa> but it doesn't get mined, as P2SH was only introduced when the majority of miners had switched
283 2013-03-10 03:39:07 <sipa> indeed
284 2013-03-10 03:45:11 <gmaxwell> canoon: in any case, I'd suggest improving your metric to size - size_of_txouts_removed + size_of_txouts_created. Effectively that double charges you for bloat you create, or discounts you by bloat you save.
285 2013-03-10 03:45:24 <gmaxwell> And then doesn't have any 'average' armwaving parameter.
286 2013-03-10 03:46:58 <gmaxwell> I think that doesn't create any case where you're encouraged to create bloat just so you can get credit for consuming it later.
287 2013-03-10 03:48:02 <canoon> the problem with that method is it ends up costing more to spend it
288 2013-03-10 03:48:09 <canoon> because you really want the txin size
289 2013-03-10 03:49:49 <canoon> and by average i would have just used the size of a uncompressed pubkey + signature or some other fixed number
290 2013-03-10 03:50:40 <canoon> you couldn't just get credit by creating bloat because you would pay for it before anyway
291 2013-03-10 03:52:31 <gmaxwell> canoon: I think you're confused or I'm confused at what you're saying.
292 2013-03-10 03:52:56 <gmaxwell> We want the data stored in the UTXO. This is the txouts created in this transaction, or the txouts from the prior transaction that we're removing.
293 2013-03-10 03:53:25 <gmaxwell> Signatures and uncomressed pubkeys have nothing to do with this, as they're just part of the size and never go into the UTXO set.
294 2013-03-10 03:55:03 <canoon> its really just the number of txouts out rather than the size thats important there (as the actually transactions could be indexed on disk)
295 2013-03-10 03:55:35 <canoon> the idea was to effectively pay ahead for the effective cost of redeeming the input
296 2013-03-10 03:55:55 <canoon> so a user wasn't punished from using up small outputs
297 2013-03-10 03:58:40 <canoon> so for a standard transaction the cost effective just becomes outputs * some number
298 2013-03-10 04:08:04 <sipa> petertodd: 80 byte signature?
299 2013-03-10 04:08:15 <canoon> hmm i guess actually you could do max of txout and standard input size to counter both
300 2013-03-10 04:08:27 <petertodd> sipa: Oh right, 72 bytes...
301 2013-03-10 04:08:42 <petertodd> Or 71 or 70 or... :P
302 2013-03-10 04:09:35 <gmaxwell> canoon: ... uh. @!*#!( they _are_ on disk.
303 2013-03-10 04:10:30 <gmaxwell> canoon: and longer txouts are possible??? though indeed most are nonstandard, not all are and should very much cost more.
304 2013-03-10 04:11:43 <gmaxwell> canoon: but I see what you're saying wrt prepay.
305 2013-03-10 04:12:03 <canoon> yeah thinking max of txout size and standard input size
306 2013-03-10 04:12:11 <canoon> because then you get both
307 2013-03-10 04:12:21 <gmaxwell> canoon: but at the same time, we do care very much about the actual size of the utxo set and encouraging people to use small utxo (p2sh) even when this means larger scriptsigs.
308 2013-03-10 04:15:51 <gmaxwell> canoon: anything involving an average has a parameter to get wrong. :( I'd say "just don't count the scriptsig size at all" except then you get "I've PUSHED rick astley's greatest hits in this signature" :(
309 2013-03-10 04:17:07 <canoon> yeah i think you got the wrong idea with average i just meant a standard hash160 transaction input
310 2013-03-10 04:17:37 <canoon> so a fixed value
311 2013-03-10 04:17:43 <canoon> it could be larger and wouldn't really matter
312 2013-03-10 04:18:27 <gmaxwell> canoon: great, but what happens when all the scriptsigs are larger people 2of2 multisig p2sh's become common?
313 2013-03-10 04:19:45 <canoon> well the prepay problem is only when it costs more to redeem a transaction than its value
314 2013-03-10 04:20:19 <canoon> unless people start sending 1satoshi 2of2 multisig transactions it won't be a problem
315 2013-03-10 04:21:26 <gmaxwell> It's not a 1satoshi issue. I mean, you'll only get credit for 80 bytes but your sig is really 400 bytes, making it uneconomical to redeem.
316 2013-03-10 04:23:02 <canoon> well unless the transaction was for 0.0001 you'll still redeem it
317 2013-03-10 04:26:20 <remote> how do you get the address from a public key?
318 2013-03-10 04:26:21 <gmaxwell> canoon: hm. So what do you think the effect would be of making the scaling factor be 10,000 (the size of the maximum permitted scriptsig)
319 2013-03-10 04:26:47 <gmaxwell> 20:09 < sipa> and encode that in base58
320 2013-03-10 04:26:47 <gmaxwell> remote: 20:09 < sipa> RIPEMD160(SHA256(pubkey))
321 2013-03-10 04:27:13 <remote> that's what I'm trying to do but I basically have no idea what I'm doing
322 2013-03-10 04:27:52 <gmaxwell> remote: it's complicated. Go find code in your prefered language for this.
323 2013-03-10 04:28:19 <gmaxwell> canoon: I guess having negative fees is generally a problem.
324 2013-03-10 04:28:28 <lianj> remote: def hash160_to_address(hex); hex = address_version + hex; encode_base58(hex + checksum(hex)); end
325 2013-03-10 04:28:31 <lianj> def pubkey_to_address(pubkey); hash160_to_address( hash160(pubkey) ); end
326 2013-03-10 04:28:44 <gmaxwell> canoon: unfortunately there is no scaling factor less than about 36 that will avoid negative sizes. :P
327 2013-03-10 04:29:22 <canoon> gmaxwell, you'd obviously just count negative sizes as 0
328 2013-03-10 04:29:25 <remote> what's address_version?
329 2013-03-10 04:29:44 <canoon> i wouldn't make the sacling factor 10,000 more like 300
330 2013-03-10 04:29:45 <lianj> a totally secret secret
331 2013-03-10 04:30:00 <gmaxwell> canoon: then you can create a pretty rad dos attack by mining a 10GB block with a bunch of zero 'size' txn.
332 2013-03-10 04:30:13 <canoon> no you can't
333 2013-03-10 04:30:21 <canoon> because you would need a lot of outputs
334 2013-03-10 04:30:25 <lianj> remote: 6f for testnet3 and 00 for mainnet
335 2013-03-10 04:30:26 <canoon> and the number of outputs is limited
336 2013-03-10 04:30:39 <grau_> remote: base58(ripem160(hash256(pubkey) + last 4 bytes of hash256(hash256(ripem160(hash256(pubkey))))
337 2013-03-10 04:30:56 <gmaxwell> canoon: if instead your scaling factor is one less than minimum possible marginal txin size then thats not an issue.
338 2013-03-10 04:31:03 <remote> ok let me try that
339 2013-03-10 04:31:11 <gmaxwell> canoon: sure you'd create multiple outputs over time, then redeem them all at once. :)
340 2013-03-10 04:31:35 <canoon> hmm
341 2013-03-10 04:31:35 <sipa> grau_: 0x00 + base58(ripemd160(sha256(pubkeu))) + last 4 bytes of sha256(sha256(0x00 + ripemd160(sha256(pubkey)))
342 2013-03-10 04:31:45 <gmaxwell> canoon: also the non-linearity is bad. Say your size would be negative: it's in your best interest to add more outputs just to 'pay forward' the stored value.
343 2013-03-10 04:32:11 <gmaxwell> canoon: one of the things its important to do is to never perversly incentivize adding more outputs. :P
344 2013-03-10 04:32:16 <grau_> sipa: base58(0x00 + ripemd160(sha256(pubkeu))) + last 4 bytes of sha256(sha256(0x00 + ripemd160(sha256(pubkey)))
345 2013-03-10 04:32:23 <grau_> to be precise :)
346 2013-03-10 04:32:43 <sipa> you're right!
347 2013-03-10 04:32:47 <lianj> for mainnet, yes
348 2013-03-10 04:32:59 <grau_> and for single signature
349 2013-03-10 04:33:17 <lianj> why for a single sig?
350 2013-03-10 04:33:26 <sipa> for a pay-to-pubkey-hash
351 2013-03-10 04:33:28 <grau_> for multisig it is 0x05
352 2013-03-10 04:33:30 <sipa> not pay-to-script-hash
353 2013-03-10 04:33:36 <sipa> grau_: multisig != p2sh
354 2013-03-10 04:34:10 <lianj> grau_: ah true, p2sh == 05 for mainnet and c4 for testnet3
355 2013-03-10 04:34:47 <grau_> I believe to have seen 0x05 for psh AND multisig, searching ...
356 2013-03-10 04:34:56 <lianj> remote brain == melted
357 2013-03-10 04:34:59 <remote> lol
358 2013-03-10 04:35:02 <remote> how did you guess?
359 2013-03-10 04:35:23 <remote> is there existing python code that does pubkey to address?
360 2013-03-10 04:35:31 <lianj> sure
361 2013-03-10 04:35:35 <sipa> remote: about 100 implementations, i think
362 2013-03-10 04:35:42 <lianj> 101 maybe
363 2013-03-10 04:35:49 <sipa> grau_: p2sh is the only way to do multisig in current wallets, but it is not limited to it
364 2013-03-10 04:36:02 <sipa> nor is multisig limited to p2sh
365 2013-03-10 04:36:08 <remote> I looked at a few of them but it's not clear what does pubkey to address and after testing using their code I couldn't succeed doing it
366 2013-03-10 04:36:09 <sipa> at the protocol level
367 2013-03-10 04:36:11 <lianj> sipa: sadly few i have seen that do dynamic testnet/mainnet/testnet3
368 2013-03-10 04:36:25 <lianj> even though its simple to add
369 2013-03-10 04:38:10 <lianj> well, testnet == testnet3 in term of addresses
370 2013-03-10 04:38:12 <canoon> gmaxwell, the dos attack would probably not work and just cause the block to get orphaned if it didn't then so what you just had a 10gb block go across the network successfully. you could do the same thing by spamming transactions with fees
371 2013-03-10 04:39:11 <gmaxwell> canoon: nah, the attack really takes the form of finding a size such that the big block is accepted by 50%+?? of the network. You can make convergence take a very long time.
372 2013-03-10 04:39:47 <canoon> but what problem would it cause?
373 2013-03-10 04:39:58 <gmaxwell> And the perverse incentive exists where you can create more outputs for 'free')
374 2013-03-10 04:40:18 <gmaxwell> canoon: it means that someone could way 6 or whatever confirms and then have their transactions reversed and replaced with doublespends.
375 2013-03-10 04:41:16 <gmaxwell> This would be better, I think: max(size-inputs*scale,1)+outputs*scale
376 2013-03-10 04:41:18 <canoon> wait you mean so its accepted by 50% of the network but not the rest?
377 2013-03-10 04:41:47 <gmaxwell> canoon: right. You find some big size such that it would be accepted by roughly half the hashpower (or better, slightly more than half but not less)
378 2013-03-10 04:42:10 <remote> ex: http://paste.lisp.org/display/135928
379 2013-03-10 04:42:15 <canoon> but why would the rest reject it no storage?
380 2013-03-10 04:42:29 <remote> this is using https://github.com/jtobey/bitcoin-abe/blob/master/Abe/util.py
381 2013-03-10 04:42:49 <gmaxwell> canoon: no storage, not enough bandwidth, an attempt to prevent dos attacks like this (you just said it would be prevented by being orphaned)
382 2013-03-10 04:43:24 <canoon> hmm
383 2013-03-10 04:43:47 <gmaxwell> In any case I think max(size-inputs*scale,1)+outputs*scale eliminates that, and the perverse incentives. perhaps the 1 should be some slightly larger value to prevent block bloat.
384 2013-03-10 04:44:33 <remote> even hash_to_address(pubkey_to_hash(pubkey)) doens't work
385 2013-03-10 04:44:42 <gmaxwell> I guess there is some slightly preverse incentive there... if size-inputs*scale would be negative then you might avoid consuming some utxo you would otherwise consume.
386 2013-03-10 04:45:16 <canoon> is inputs the inputs' output?
387 2013-03-10 04:45:45 <gmaxwell> inputs is just the number of outputs this transaction is consuming.
388 2013-03-10 04:45:45 <lianj> remote: add address version and checksum
389 2013-03-10 04:45:52 <canoon> oh right
390 2013-03-10 04:46:54 <remote> lianj: http://paste.lisp.org/display/135929
391 2013-03-10 04:47:09 <gmaxwell> that residual perversity is why I just like setting the scale to some value such that size-(inputs-outputs)*scale is always postive.
392 2013-03-10 04:47:13 <lianj> remote: add address version and checksum
393 2013-03-10 04:47:38 <canoon> gmaxwell, lol 0?
394 2013-03-10 04:48:17 <gmaxwell> dur. long day. right.
395 2013-03-10 04:48:37 <canoon> well if its 0 its current algorithm
396 2013-03-10 04:49:10 <remote> I'm passing address version to hash_to_address() but I'm not seeing any checksum what is it?
397 2013-03-10 04:49:48 <canoon> hmm that still has the dos problem just blocksize is limited by a scale factor
398 2013-03-10 04:49:51 <gmaxwell> canoon: double dur. There is a scale that is non-zero and keeps it positive.
399 2013-03-10 04:50:25 <canoon> i don't think the perverse incentives is really a problem
400 2013-03-10 04:50:37 <gmaxwell> (because size must increase by some amount per input you consume even if the scriptsig is empty)
401 2013-03-10 04:51:15 <canoon> because its limited how many outputs they can do
402 2013-03-10 04:51:16 <gmaxwell> canoon: I think its a major criteria. Software will act in the users interest and will do things like add extra change outputs to avoid losing uxto juice.
403 2013-03-10 04:51:35 <gmaxwell> lol yes, but it's a large limit (rightfully so!)
404 2013-03-10 04:51:36 <canoon> yeah but its only going to happen when they are already reducing outputs
405 2013-03-10 04:52:02 <gmaxwell> canoon: yes sure but it means that they're not actually incentivized to reduce outputs.
406 2013-03-10 04:52:40 <canoon> well only when they are already reducing outputs
407 2013-03-10 04:52:50 <sipa> always incentivized to reduce outputs, but not always to *maximally* do so
408 2013-03-10 04:53:00 <canoon> yeah
409 2013-03-10 04:53:10 <gmaxwell> What is your complaint with size-(inputs-outputs)*scale such that it's always positive. (if we assume that each input adds 36 bytes, then setting scale to 35 achieves that, for example)
410 2013-03-10 04:53:50 <gmaxwell> (I don't know what the minimum marginal increase is, I know its >33 bytes.. but I'm too lazy right now to check exactly)
411 2013-03-10 04:54:08 <canoon> minimum marginal increase?
412 2013-03-10 04:54:36 <canoon> i think scale should be whatever the cost to redeem a to address transaction
413 2013-03-10 04:54:40 <gmaxwell> canoon: a txin makes a transaction larger even with a 0byte scriptsig... e.g. the txid:vout, sequence number, etc.
414 2013-03-10 04:55:10 <gmaxwell> canoon: as noted before it _can't_ be whatever the cost is, because we don't actually know the cost.
415 2013-03-10 04:55:20 <gmaxwell> Sometimes it will not be enough unless you set the scale to 10,000.
416 2013-03-10 04:55:27 <canoon> no for that specific transaction type
417 2013-03-10 04:55:37 <gmaxwell> you can't tell what transaction type an output is.
418 2013-03-10 04:56:12 <gmaxwell> (and certantly if this were to be a hard protocol rule you wouldn't want to special case a bunch of types even for the ones you can identify)
419 2013-03-10 04:56:44 <canoon> no like a to address one OP_DUP OP_HASH160 XX OP_EQUALVERIFY OP_CHECKSIG
420 2013-03-10 04:57:01 <canoon> specifically how much it costs to redeem that one
421 2013-03-10 04:59:20 <gmaxwell> You can't generally know that even for those script types without a big dumb table. Ugh. That is _not_ going to go in as a protocol rule. And besides: how much does this cost to redeem OP_HASH160 OP_PUSH da39a3ee5e6b4b0d3255bfef95601890afd80709 OP_EQUAL ?
422 2013-03-10 05:00:36 <canoon> gmaxwell, not based on the actual script just the size of a signature + pubkey + txin overhead
423 2013-03-10 05:00:41 <remote> I was passing a 130 char public key, maybe that's the problem
424 2013-03-10 05:00:51 <canoon> but i guess that has problems with a negative size
425 2013-03-10 05:01:27 <gmaxwell> canoon: it has problems with some transactions take much much more than signature + pubkey + txin overhead to redeem... and you can't even tell this from the txout that created them.
426 2013-03-10 05:02:01 <gmaxwell> (arguably P2SH should have had a OP_PUSH_I_PROMISE_TO_NOT_COST_MORE_THAN_THIS_TO_REDEEM, alas)
427 2013-03-10 05:02:55 <canoon> yeah i think we argued that
428 2013-03-10 05:03:22 <canoon> its to prevent someone from ignoring transactions that cost more to redeem
429 2013-03-10 05:03:31 <gmaxwell> ...
430 2013-03-10 05:03:32 <canoon> theres no real incentive to send those transactions in the first place
431 2013-03-10 05:03:47 <gmaxwell> And yet people do for all kinds of odd reasons.
432 2013-03-10 05:03:48 <gmaxwell> 21:54 < gmaxwell> canoon: as noted before it _can't_ be whatever the cost is, because we don't actually know the cost.
433 2013-03-10 05:03:53 <gmaxwell> not the 'as noted before'
434 2013-03-10 05:04:15 <canoon> yeah but mostly to addresses
435 2013-03-10 05:04:18 <gmaxwell> I'm pointing out that nothing you can propose here can prevent txn that cost more to redeem than they're worth, they can only make them more rare.
436 2013-03-10 05:05:00 <gmaxwell> canoon: I think it's very likely that in the future (2+ years from now) most transactions will be multisignature. It's the only way to make wallets on commodity hardware secure. Gavin has long term plans to support them as standard wallet features.
437 2013-03-10 05:05:42 <phantomcircuit> gmaxwell, in most cases multi sig doesn't actually buy you any real security
438 2013-03-10 05:05:45 <gmaxwell> So given that you can only make them more rare, not impossible... why not choose a smaller scale factor so you're always strongly incentivized to unbloat?
439 2013-03-10 05:06:01 <gmaxwell> phantomcircuit: uh. I'm waiting to hear this argument.
440 2013-03-10 05:06:30 <canoon> a larger scale factor increases the incentive no?
441 2013-03-10 05:06:38 <phantomcircuit> gmaxwell, almost all automated interaction with bitcoind follows the basic format of a payment instruction (eg a database record) being processed
442 2013-03-10 05:07:00 <gmaxwell> phantomcircuit: I'm not talking about merchants and automated systems.
443 2013-03-10 05:07:11 <phantomcircuit> gmaxwell, normal users?
444 2013-03-10 05:07:28 <phantomcircuit> bob the wallet man with his 10 btc?
445 2013-03-10 05:07:35 <sipa> canoon: increases the initial incentive, but makes it stop earlier
446 2013-03-10 05:08:03 <canoon> how so?
447 2013-03-10 05:08:09 <gmaxwell> maybe I'm overly fixated on the small scale factor just becuase it removes a free parameter. :(
448 2013-03-10 05:08:12 <phantomcircuit> hmm i guess maybe that would make it more secure
449 2013-03-10 05:08:19 <warren> gmaxwell: you mean like a hardware token you plug in for the second sig?
450 2013-03-10 05:08:22 <sipa> canoon: because you'll hit 0 faster
451 2013-03-10 05:08:25 <gmaxwell> warren: yes. or your phone.
452 2013-03-10 05:08:30 <warren> ah
453 2013-03-10 05:08:34 <canoon> sipa, 0 what?
454 2013-03-10 05:08:39 <phantomcircuit> bob has one bitcoin-qt on his windows 7 desktop and one bitcoin-qt on his os x laptop
455 2013-03-10 05:08:42 <gmaxwell> canoon: zero size.
456 2013-03-10 05:08:51 <phantomcircuit> if he needs to have signatures from both he's probably more secure
457 2013-03-10 05:08:52 <sipa> canoon: size - scale*ntxoutdiff
458 2013-03-10 05:08:57 <warren> phantomcircuit: you're already in trouble if you want the same wallet on both
459 2013-03-10 05:09:01 <canoon> oh right
460 2013-03-10 05:09:13 <sipa> canoon: if scale is larger, you'll sooner hit 0, at which point you have no further incentive to reduce the outputs
461 2013-03-10 05:09:20 <phantomcircuit> warren, not really
462 2013-03-10 05:09:24 <warren> phantomcircuit: unless you have deterministic keys?
463 2013-03-10 05:09:27 <canoon> but the next person who receives that will have incentive
464 2013-03-10 05:09:33 <phantomcircuit> it's only a problem if you dont know what you're doing
465 2013-03-10 05:09:39 <phantomcircuit> which i guess is an issue for bob
466 2013-03-10 05:09:44 <warren> exactly
467 2013-03-10 05:09:49 <warren> unless it is bob the coder
468 2013-03-10 05:10:02 <phantomcircuit> gmaxwell, that reminds me
469 2013-03-10 05:10:03 <Vinnie_win> evoorhees claims SD loss-bet tx is only 16% of network
470 2013-03-10 05:10:04 <warren> bob the coder who reads instructions
471 2013-03-10 05:10:07 <gmaxwell> and if you use plain size - scale*ntxoutdiff instead of max(size-inputs*scale,1)+outputs*scale you'll be incentivized to add more outputputs to 'recover' your lost value. :(
472 2013-03-10 05:10:09 <phantomcircuit> the keypool behaviour should be changed
473 2013-03-10 05:10:16 <Vinnie_win> can someone point me to gavin's post that shows recent blocks and the percent of SD spam?
474 2013-03-10 05:10:39 <phantomcircuit> when the wallet is initial created a larger number of private keys should be generated (think 1,000)
475 2013-03-10 05:10:39 <warren> Vinnie_win: one user is only 16% of the network. sounds great.
476 2013-03-10 05:10:48 <phantomcircuit> then the keypool size set to the normal 100
477 2013-03-10 05:10:55 <Vinnie_win> warren: The real number is like 80%...I'd like to find gavin's post which makes that clear
478 2013-03-10 05:11:01 <warren> Vinnie_win: As long as people hold on to the fantasy that every KB has the same cost to the network, we won't fix this.
479 2013-03-10 05:11:03 <phantomcircuit> if the keypool refills the ui should warn the user to back again
480 2013-03-10 05:11:10 <warren> Vinnie_win: I mean even 16% is bad.
481 2013-03-10 05:11:17 <Vinnie_win> warren: Yeah but do you have any idea where gavin's post is? I'd like to refute evoorhees' claim
482 2013-03-10 05:11:39 <gmaxwell> warren: no thats just the bitdust losses.. SD involved transactions is more like 80% .. but if you say 80% then 50 plays and 50% responses and .. then less than half the responses are losses because more people pay the higher win percentage games.. doesn't sound incorrect, perhaps misleading.
483 2013-03-10 05:11:39 <Vinnie_win> I've got this bastard on the defensive and I'd like to press the advantage
484 2013-03-10 05:12:12 <canoon> theres this its a bit old but has it at 64% https://bitcointalk.org/index.php?topic=80312.0
485 2013-03-10 05:12:24 <gmaxwell> Vinnie_win: I posted a list by block, look at my post history
486 2013-03-10 05:12:36 <Vinnie_win> gmaxwell: I found it...well, I found yours. Didn't find gavin's. Thanks
487 2013-03-10 05:13:08 <warren> gmaxwell: I didn't suggest 16% was right, I said even if it were correct, it's still bad.
488 2013-03-10 05:13:19 <canoon> the size adjustment would fix the bitdust losses :p
489 2013-03-10 05:13:25 <gmaxwell> Vinnie_win: but I think what he's telling you??? that 16% are losses, may well be roughly right.
490 2013-03-10 05:14:03 <Vinnie_win> gmaxwell: how the hell could 16% be anywhere remotely near the correct number?
491 2013-03-10 05:14:33 <Vinnie_win> he says loss confirms are 1/4 of SD traffic, and SD traffic is 1/2 of the network
492 2013-03-10 05:14:35 <gmaxwell> Vinnie_win: if 80% are SD playing, then 40% are bets, and 40% are responses (because there is 1:1 bet and response). And then not all responses are _losses_.
493 2013-03-10 05:14:59 <Vinnie_win> Hmm...
494 2013-03-10 05:15:00 <warren> This ultimately isn't about DP. They should be credited for exposing the UXTO cost problem, we fix it, and move on.
495 2013-03-10 05:15:11 <Vinnie_win> okay I can still spin that
496 2013-03-10 05:15:22 <gmaxwell> Vinnie_win: if he's saying 1/2 / 1/4 what he's probably doing there is not counting the bets. (in which case he's saying sd is ~100% of the network. :P)
497 2013-03-10 05:15:39 <gmaxwell> warren: they didn't expose the utxo cost problem. Firstbits and lots of other things did.
498 2013-03-10 05:15:50 <Vinnie_win> gmaxwell: I think he's right not to count the bets. They are legit tx after all
499 2013-03-10 05:15:59 <gmaxwell> Including petertodd's timestamper than I said "NO STOP!" to and which he then joined in trying to figure out how to improve scalablity.
500 2013-03-10 05:16:17 <Vinnie_win> why'd gavin reject peter's pull req
501 2013-03-10 05:16:45 <warren> Vinnie_win: apparently git pull request isn't a discussion forum
502 2013-03-10 05:16:51 <gmaxwell> Vinnie_win: I don't agree. I mean, they wouldn't exist absent the really inefficient way the site works. You could perhaps try to not count like 1 tx per user of the site per hour, but doing the blockchain analysis to approximate that would be a PITA.
503 2013-03-10 05:17:21 <Vinnie_win> gmaxwell: There is no way to win an argument against high transaction volume which creates spendable outputs
504 2013-03-10 05:18:01 <warren> Even if they were to stop dusting, it would still be a lot of tx's with high fees that others have to compete with. None of my "pollution tax" suggestions would have any effect on that.
505 2013-03-10 05:18:28 <lianj> is this still 1dice talk?
506 2013-03-10 05:18:40 <canoon> warren, isn't that just the free market
507 2013-03-10 05:18:43 <gmaxwell> Vinnie_win: who said anything about winning arguments? His service is responsible for almost all the transactions. Its just how it is. If that doesn't help your argument, bummer.
508 2013-03-10 05:18:58 <gmaxwell> lianj: it wasn't for a long time then Vinnie_win crapped it all up.
509 2013-03-10 05:19:00 <gmaxwell> :P
510 2013-03-10 05:19:09 <Vinnie_win> heh
511 2013-03-10 05:19:12 <warren> canoon: I'd agree, if our current fee calculation formula followed actual costs.
512 2013-03-10 05:19:16 <Vinnie_win> well, SD did raise the output to 5k instead of 1.
513 2013-03-10 05:19:34 <gmaxwell> Vinnie_win: in any case, the percentage of the network that is his un-enconomical-to-spend outputs isn't the relevant metric.
514 2013-03-10 05:19:35 <Vinnie_win> gmaxwell: should I have not brought it up?
515 2013-03-10 05:19:45 <lianj> my bitcoin hating friends started to call bitcoin buttcoins. someone should register that domain
516 2013-03-10 05:19:48 <Vinnie_win> gmaxwell: I mean is Bitcoin better served by staying silent
517 2013-03-10 05:19:56 <gmaxwell> I guess the relevant metric for the argument you're making is what percentage of the UTXO growth his service is responsible for.
518 2013-03-10 05:19:58 <canoon> warren, should it also count the extra output size increase?
519 2013-03-10 05:20:01 <warren> lianj: better yet, start a new alt coin named it.
520 2013-03-10 05:20:10 <Vinnie_win> gmaxwell: Yes that's exactly the metric I'm interested in
521 2013-03-10 05:20:21 <lianj> "buttcoins - 1dice welcome"
522 2013-03-10 05:21:01 <warren> litecoin is almost 5x the USD exchange rate of last week. It makes no sense.
523 2013-03-10 05:21:23 <gmaxwell> Vinnie_win: sounds like a pain to compute. You'd need to get the UTXO size at time X and then again at time Y and then figure out all if all the outputs in Y that are not in X, how many are a result of SD.
524 2013-03-10 05:21:35 <Vinnie_win> "Litecoin is the noise to Bitcoin's signal" - Vinnie
525 2013-03-10 05:21:55 <lianj> "buttcoin" - dongs
526 2013-03-10 05:22:17 <Vinnie_win> gmaxwell: I would just include any tx that comes from 1dice* and has an output less than 100 satoshi
527 2013-03-10 05:23:27 <canoon> gmaxwell, you only need to scan between the two blocks i think
528 2013-03-10 05:23:49 <gmaxwell> canoon: noisy metric.
529 2013-03-10 05:24:05 <gmaxwell> e.g. you hit a block that blocks SD... you won't get much. :P
530 2013-03-10 05:24:32 <canoon> i didn't mean sequential blocks
531 2013-03-10 05:25:01 <gmaxwell> well thats what I mean by time x and time y.
532 2013-03-10 05:25:55 <gmaxwell> (in particular, using a longer window lets you ignore 'bloat' created by spendable transactions that get spent)
533 2013-03-10 05:26:16 <canoon> oh right but i meant you can just scan between the block at x and y, you don't have to calculate the utxo size at x
534 2013-03-10 05:26:26 <warren> gmaxwell: is p2pool's minimum payout big enough to be considered not dust?
535 2013-03-10 05:26:54 <lianj> warren: borderline
536 2013-03-10 05:26:58 <gmaxwell> warren: yes, at least at the current subsidy level.
537 2013-03-10 05:27:31 <gmaxwell> Part of the design is to keep the minimum from being insanely small.
538 2013-03-10 05:29:16 <warren> gmaxwell: if a non-mining node is paid a --fee would that be way below that?
539 2013-03-10 05:40:03 <gmaxwell> warren: if you wanted to do that you could use a lottery instead of a payment.
540 2013-03-10 05:40:18 <gmaxwell> warren: "stochastic micropayment"
541 2013-03-10 05:40:42 <warren> gmaxwell: I was just thinking that
542 2013-03-10 05:40:52 <warren> gmaxwell: it's rather futile though
543 2013-03-10 05:41:07 <gmaxwell> canoon: I think I've solved all my concerns: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas see "Transaction cost prepayment" but I think that form is too different from bitcoin.
544 2013-03-10 05:41:20 <gmaxwell> Transaction cost prepayment: One problem is that it's possible to create UTXO that are unprofitable to redeem.
545 2013-03-10 05:41:23 <gmaxwell> Instead make every output specify a max_size, which is the maximum size of a TX_IN that will be permitted to redeem it. Then for the 'cost' of a transaction use cost = MAX(size-sum_inputs(max_size),minimum_viable_txn_size) + sum_outputs(max_size) In order to economical align cost the blocksize limit should be based on it rather than size.
546 2013-03-10 05:42:01 <gmaxwell> basically let the address specify the prepayment amount. And you can't lowball it because you will just make the txout unredeemable.
547 2013-03-10 05:44:11 <canoon> yeah i think that completely misses the point
548 2013-03-10 05:44:36 <gmaxwell> canoon: ... uh. Please expand on that.
549 2013-03-10 05:45:09 <canoon> because people could just lie and say it takes 1 byte to redeem it and they weren't planning to redeem it anyway
550 2013-03-10 05:45:33 <gmaxwell> canoon: anyone can make unredeemable txn all they want. That can't be prevented.
551 2013-03-10 05:45:40 <canoon> but just using it to message someone else
552 2013-03-10 05:45:56 <gmaxwell> http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE
553 2013-03-10 05:47:00 <gmaxwell> canoon: sure, sorry, well I expected max_size would be seralized as 40+???? (40 being whatever the minimum credible max_size is)
554 2013-03-10 05:47:05 <gmaxwell> if that wasn't obvious I'll add it.
555 2013-03-10 05:48:24 <canoon> hmm actually i guess that makes sense
556 2013-03-10 05:49:07 <canoon> oh so it has a minimum cost anyway?
557 2013-03-10 05:49:59 <gmaxwell> ** max_size is serialized as an unsigned variable length int minus whatever the smallest credible maxsize is, (e.g. something like 40 for bitcoin)
558 2013-03-10 05:51:06 <canoon> ah k
559 2013-03-10 05:52:01 <gmaxwell> basically it means any payment "reserves" the space its redemption will consume.
560 2013-03-10 05:52:53 <gmaxwell> does kinda disincentivize txn that have a large worst case, sadly. but then again those _should_ be disincentivized simply because they may turn out to be harder to spend than expected.
561 2013-03-10 05:53:34 <Vinnie_win> Have you guys thought about shaping the overlay network through peer connection preferencing?
562 2013-03-10 05:53:46 <gmaxwell> overlay network?
563 2013-03-10 05:53:53 <Vinnie_win> The peers
564 2013-03-10 05:54:04 <Vinnie_win> Host connections...whatever you call them
565 2013-03-10 05:54:44 <gmaxwell> What for? For one??? preferencing makes security much harder to analyize. e.g. a simplistic preferencing scheme makes it easy for an attacker to partition the network.
566 2013-03-10 05:55:46 <Vinnie_win> For example, drop any peer which forwards a transaction that has economically unspendable outputs. This could be done probabilistically to prevent creating separate partitions. They effect would be to push the older hosts out, while forming a well connected core of hosts with the new behavior
567 2013-03-10 05:57:04 <warren> gmaxwell: wait a minute, subsidy level? you mean there are still donations to encourage people to use p2pool?
568 2013-03-10 05:59:07 <Vinnie_win> warren: I think we crashed him
569 2013-03-10 05:59:12 <gmaxwell> Vinnie_win: transitive dropping allows an attacker to create partitions easily.
570 2013-03-10 05:59:51 <gmaxwell> Vinnie_win: e.g. I flood all the unspendable forwarders, and then tada, they are paritioned eventually with high probablity.
571 2013-03-10 06:00:00 <Vinnie_win> gmaxwell: It would be probabilistic. Each node generates a permanent static guid and that gets used to decide what fraction of nodes would be dropped (could be zero)
572 2013-03-10 06:00:48 <Vinnie_win> gmaxwell: To prevent partitions, most nodes would drop all forwarders, while some nodes would drop all but one forwarder. This creates a core of new guys with the forwarders as leaves at the border
573 2013-03-10 06:01:14 <gmaxwell> Vinnie_win: There is no value there which is both safe and effective. :P Though hey, I'll offer you a less bad alternative: if you don't like the txn your peer is giving you, ask it to stop fowarding transactions to you (But still exchange blocks)
574 2013-03-10 06:01:27 <warren> Vinnie_win: isn't that assuming the "core" has the majority mining power?
575 2013-03-10 06:01:36 <Vinnie_win> warren: This has nothing to do with mining power, just regular nodes
576 2013-03-10 06:01:58 <warren> Vinnie_win: miners get tx's from regular nodes
577 2013-03-10 06:02:00 <gmaxwell> Vinnie_win: great so them I'm a evil guy and then I run a bunch of nodes that DON'T drop them but do other evil. Then its very likely that your bad nodes will connect to the good nodes via my nodes exclusively.
578 2013-03-10 06:02:47 <gmaxwell> but paritioning for txn forwarding is far less evil than partitioning for blocks.. so having some block only peers might be interesting.
579 2013-03-10 06:02:48 <warren> Vinnie_win: you could also be kicking out mining nodes (and you won't know it), which is quite bad for your desired tx's
580 2013-03-10 06:03:00 <Vinnie_win> There's no way to stop from connecting to bad actors but there's a way to shape the network based on who is running older versions, is what I'm saying
581 2013-03-10 06:03:52 <Vinnie_win> Okay here's a different idea
582 2013-03-10 06:04:43 <Vinnie_win> The flood fill of newly mined blocks can be used to create a directed acyclic graph of the network at a single point in time (the time the block was mined). It would be possible to use the return trip to aggregate statistics about nodes or otherwise communicate information back up the chain to the node that produced the block
583 2013-03-10 06:05:13 <Vinnie_win> i.e. when a block is mined, your "parent" in the graph is whoever you heard the block from first
584 2013-03-10 06:05:53 <canoon> gmaxwell, how about we limit the value of outputs - inputs in each block?
585 2013-03-10 06:06:41 <warren> canoon: even if that were a good idea, how do you set the value?
586 2013-03-10 06:07:06 <canoon> just hardcoded value
587 2013-03-10 06:07:08 <gmaxwell> warren: same way you set a maximum block size.
588 2013-03-10 06:07:21 <canoon> to calculate a good one
589 2013-03-10 06:07:25 <Vinnie_win> "How many forum members does it take to plug in a block size..."
590 2013-03-10 06:08:34 <canoon> just calculate the average number increase in the output from the last 1gb of transactions / 1000
591 2013-03-10 06:08:35 <warren> Vinnie_win: we don't have enough yet, apparently
592 2013-03-10 06:08:36 <gmaxwell> canoon: well doing purely that has the problem that it still allows that giant block dos attack. If you have two constraints, then you make optimal mining income a knapsack problem, and make fees hard to reasona about.
593 2013-03-10 06:09:31 <gmaxwell> canoon: anything based on a blockchain average incentivizes miners to mine dummy transactions to drive up the maximum. With greedy-rational miners all blocks would have exactly the maximum output increase. :P
594 2013-03-10 06:09:34 <canoon> you can already do that with block size thoug no?
595 2013-03-10 06:09:51 <canoon> oh i just meant to calculate an initial one
596 2013-03-10 06:09:53 <gmaxwell> canoon: no. 1MB is small enough that there is no giant block forking attack.
597 2013-03-10 06:10:06 <gmaxwell> canoon: well then you have some magic number that might not reflect future usage. :(
598 2013-03-10 06:10:23 <canoon> you'd tie it to block size
599 2013-03-10 06:11:07 <gmaxwell> You're going to have to explain that to me.
600 2013-03-10 06:11:10 <muhoo> Luke-Jr: looks to me like dnsseed.bitcoin.dashjr.org is down, or perhaps dashjr dns has gone wonky
601 2013-03-10 06:11:27 <muhoo> and, this causes bitcoinj to lock up hard and not talk to any peers :-/
602 2013-03-10 06:11:50 <canoon> well i think the max should be a ratio of the max block size
603 2013-03-10 06:12:10 <canoon> this ofcourse relys on you guys having a good way for deciding block size
604 2013-03-10 06:12:16 <canoon> *max block size
605 2013-03-10 06:12:36 <muhoo> i do think it odd that the canonical nameservers for dashjr.org are on dashjr.org, that's usually a no-no (use static IP addresses or a name that resolves on a different domain)
606 2013-03-10 06:13:14 <canoon> regardless if you limit it to say 100 that means you know the max entries that will be in your uxto later
607 2013-03-10 06:15:00 <canoon> gmaxwell, btw what is the plan for adjusting max block size?
608 2013-03-10 06:15:05 <canoon> or none?
609 2013-03-10 06:15:31 <gmaxwell> canoon: there isn't currently a plan. It's complicated.
610 2013-03-10 06:16:58 <petertodd> canoon: What has to happen is off-chain transaction systems get developed, so the block size doesn't have to grow much, or perferably not at all, for the forseeable future.
611 2013-03-10 06:17:14 <muhoo> like ripple?
612 2013-03-10 06:17:17 <muhoo> ACTION ducks
613 2013-03-10 06:17:33 <canoon> petertodd, you kinda lose the universality of bitcoin then
614 2013-03-10 06:17:37 <gmaxwell> Gavin has proposed just removing the maximum. I believe that Jeff, Sipa, and I all believe this is an unacceptably bad idea. (though I think no one argues that it should never be increased at all). There has been a lot of discussion and argument on the forum, mostly by uninformed people (by sheer count), though a number of interesting thoughts have been expressed.
615 2013-03-10 06:17:38 <petertodd> muhoo: Lol, as gmaxwell would say, like Genuine Ripple (not that shitty thing that actually happened)
616 2013-03-10 06:18:21 <petertodd> canoon: Universality is a tradeoff between centralization and decentralization. The larger the blocksize is, the fewer people can afford to run a full, validating node.
617 2013-03-10 06:18:56 <petertodd> canoon: Bitcoin simply can-not scale to even handling a tiny, tiny fraction of the worlds finance and be decentralize at the same time if every transaction goes on the blockchain itself.
618 2013-03-10 06:19:21 <muhoo> sad, but true.
619 2013-03-10 06:19:33 <gmaxwell> As sipa says, "if the size is very small everyone will validate but no one will transact (and bitcoin is worthless), if the size is very large everyone will transact but no one will validate (and bitcoin is worthless)"
620 2013-03-10 06:20:04 <gmaxwell> A well calibrated system has a size which maximizes both of those things.
621 2013-03-10 06:20:10 <muhoo> Hard Problem.
622 2013-03-10 06:20:29 <petertodd> Visa does thousands of transactions a second; you just can't run a validating node processing all those transactions and stay anonymous at the same time.
623 2013-03-10 06:20:39 <petertodd> Even right now it's tough to run Bitcoin on Tor, doable, but tough.
624 2013-03-10 06:20:45 <canoon> anyone for having the block size such that real transaction fees stay the same?
625 2013-03-10 06:20:48 <zveda> i dont think you can assume miners are both greedy and rational. miners also want the btc system to succeed.
626 2013-03-10 06:21:14 <petertodd> canoon: Also hopeless, because you still run into the scaling issue. The demand for 1 cent secure transactions is utterly enormous.
627 2013-03-10 06:21:16 <warren> petertodd: due to latency or slowness of exit nodes? can bitcoind run directly as a hidden service?
628 2013-03-10 06:21:17 <zveda> if they're rational enough to optimize their greedy behavior they're rational enough to realise that
629 2013-03-10 06:21:27 <gwillen> 23:06:40 < muhoo> i do think it odd that the canonical nameservers for dashjr.org are on dashjr.org, that's usually a no-no (use static IP addresses or a name that resolves on a different domain)
630 2013-03-10 06:21:31 <gwillen> muhoo: offtopic, but what you say is not true
631 2013-03-10 06:21:33 <warren> petertodd: hidden service speeds aren't that bad
632 2013-03-10 06:21:38 <gwillen> muhoo: NS records must have names, they cannot have IPs
633 2013-03-10 06:21:45 <petertodd> warren: Bandwidth, specifically you have a high orphan rate when you mine because it takes too long to download 1MB, at least in my tests.
634 2013-03-10 06:21:48 <muhoo> gwillen: but not on the same domain as they are serving
635 2013-03-10 06:21:52 <gwillen> muhoo: and if you want the names to be in third party domains, consider what would happen if everyone did that
636 2013-03-10 06:21:58 <warren> petertodd: yeah, you're nuts if you mine on tor
637 2013-03-10 06:22:02 <gwillen> indeed they _ought_ to be in the domain they are serving
638 2013-03-10 06:22:33 <petertodd> warren: But at the same time, being able to run a pool on tor could be a very good thing in the future, so it's good for us to ensure it remains possible, even if it's hard too.
639 2013-03-10 06:22:35 <gwillen> if everyone pointed at some other domain.... you'd never be able to resolve any domain
640 2013-03-10 06:22:35 <muhoo> gwillen: ok, well then i've got it wrong. but dashjr.org does appear down.
641 2013-03-10 06:22:38 <canoon> petertodd, so how much? 5c? i don't see why that isn't possible
642 2013-03-10 06:22:38 <gwillen> ACTION nods
643 2013-03-10 06:25:02 <petertodd> canoon: Well, lets assume you paid for the block subsidy with fees from transactions right now, at current volumes fees would need to be $3 USD per transaction.
644 2013-03-10 06:26:10 <petertodd> canoon: Now, lets say you stick with 1MB blocks, and pay fees from the 7 transactions a second that happen, then with the current amount of network security, you'd be paying $0.25 per transaction.
645 2013-03-10 06:27:32 <canoon> yeah guess it depends how much network security you want
646 2013-03-10 06:27:44 <petertodd> Yup, and god only knows how much is enough.
647 2013-03-10 06:28:15 <petertodd> Keep in mind that anyone who can short a large amount of Bitcoins can use it to fund a 51% attack: you short Bitcoin, attack it, then take advantage of the fact that the price has dropped like a stone.
648 2013-03-10 06:29:47 <canoon> i wonder if there would be a better system based of trusted signatures
649 2013-03-10 06:29:59 <petertodd> That's called the banking system...
650 2013-03-10 06:30:23 <canoon> lol true
651 2013-03-10 06:31:22 <petertodd> The good thing is coming up with such a large short position is hard, the bad thing is the attacker may not even be economically rational.
652 2013-03-10 06:32:01 <petertodd> Anyway, 51% attacks don't worry me, centralization does.
653 2013-03-10 06:32:13 <canoon> whats the difference?
654 2013-03-10 06:32:42 <canoon> (what are you worried about centralisation?)
655 2013-03-10 06:32:57 <petertodd> Centralization is something that can be done slowly, without looking like you are attacking anything.
656 2013-03-10 06:33:19 <petertodd> Keep in mind, the entities that might do a 51% attack, really wouldn't want to be known to be doing a 51% attack.
657 2013-03-10 06:33:42 <canoon> hmm
658 2013-03-10 06:34:04 <warren> 50.99% Corp.
659 2013-03-10 06:34:14 <canoon> 50.99?
660 2013-03-10 06:34:22 <warren> It isn't 51%.
661 2013-03-10 06:34:26 <warren> I get goofy when i'm tired.
662 2013-03-10 06:34:28 <petertodd> Tagline: "We are the 51%"
663 2013-03-10 06:34:32 <xjrn> it's hard to pinpoint from this discussion whether increasing tx throughput is a goal or liability
664 2013-03-10 06:34:47 <warren> ACTION resisting the urge to reply to him.
665 2013-03-10 06:35:02 <petertodd> warren: New troll I don't know about?
666 2013-03-10 06:35:10 <warren> petertodd: no, same old troll
667 2013-03-10 06:35:38 <xjrn> i have warren and Luke-Jr on ignore, sorry if i don't play in the sand
668 2013-03-10 06:35:55 <warren> petertodd: it looks like folks gave up "DP" today huh?
669 2013-03-10 06:36:24 <petertodd> warren: They did? Aww
670 2013-03-10 06:36:34 <petertodd> warren: (I was busy getting real work done)
671 2013-03-10 06:36:52 <canoon> dp?
672 2013-03-10 06:37:26 <warren> canoon: http://pastebin.com/ng9nF4K3
673 2013-03-10 06:38:14 <gmaxwell> Ex0deus: yes, I did??? so that I could write up that explanation first.
674 2013-03-10 06:38:34 <gmaxwell> oops wrong window
675 2013-03-10 06:38:54 <canoon> so... wah?
676 2013-03-10 06:52:25 <muhoo> i knew it would happen, someone grabbed the vanity address 1FUCK
677 2013-03-10 06:52:52 <warren> you can't really own a vanity address, can you?
678 2013-03-10 06:53:09 <warren> I mean, prefix
679 2013-03-10 06:53:56 <muhoo> and, related, scrolling, "DP" makes me laugh, because (sorry) it will always mean "double penetration" to me.
680 2013-03-10 06:54:19 <muhoo> warren: true, there doesn't appear to be any registry for them.
681 2013-03-10 06:54:59 <warren> muhoo: there is no registry, you can't own a prefix
682 2013-03-10 06:55:00 <muhoo> ok, the dashjr.org dns issue appears to have been local, and transient.
683 2013-03-10 06:55:45 <muhoo> still disconcerted that bitcoinj just locked up because one seed domain out of 4 failed to resolve.
684 2013-03-10 07:01:30 <gmaxwell> warren: some crazy people announced some 'service' to 'register' prefixes by making the first transaction paying it, called "firstbits" which caused an orgy of flooding transactions as people tried to claimjump prefixes which was probably only bounded by the vanitygen computational cost.
685 2013-03-10 07:02:02 <gmaxwell> warren: of course the whole idea is moronic: you can't do a secure efficient proof that a particular address was the first user of a prefix.
686 2013-03-10 07:02:06 <warren> gmaxwell: sounds like win.
687 2013-03-10 07:02:23 <gmaxwell> Which means that to use that resolution people will have to trust central servers.. and if you're going to do that you might as well skip the txn spam.
688 2013-03-10 07:02:36 <gwillen> gmaxwell: the efficiency problem being that you have to search the entire blockchain to look for counterexamples?
689 2013-03-10 07:02:51 <gmaxwell> fortunately the claim jumping means that it's unattractive "all the good prefixes are taken"
690 2013-03-10 07:03:06 <gmaxwell> gwillen: correct!
691 2013-03-10 07:03:14 <gwillen> ACTION nods
692 2013-03-10 07:03:19 <gmaxwell> or at least the whole blockchain prior to the first example you know of.
693 2013-03-10 07:04:34 <gwillen> right
694 2013-03-10 07:05:48 <gmaxwell> of course as soon as we (folks here) saw it we were like "nooo donnnnt!" but the orgy had started, and the proof of it being a good idea was the flood of transactions producing 200+ 1e-8 outputs.
695 2013-03-10 07:06:06 <gmaxwell> (which is like .. totally stupid, since it's not like anyone wants to buy a private key from you)
696 2013-03-10 07:07:06 <gmaxwell> total idea of pruning and proofs, or computational complexity and indexes and such are lost on the php jockies (sorry those of you who are php + clue) promoting stuff like that.
697 2013-03-10 07:07:19 <gwillen> hahahahah
698 2013-03-10 07:07:26 <gwillen> I laugh because I was forced to write PHP recently
699 2013-03-10 07:07:34 <warren> AT GUNPOINT
700 2013-03-10 07:07:52 <warren> This is a clear sign to go to sleep. g'nite.
701 2013-03-10 07:07:56 <gwillen> haha
702 2013-03-10 07:08:40 <gmaxwell> gwillen: it was even more awesome that the first firstbits lookup site forever registered the name at the first confirm. So when reorgs changed the rightful 'firstbits' they gave wrong results.
703 2013-03-10 07:08:54 <gmaxwell> meaning you could tell people your firstbits address and then they'd send funds elsewhere.
704 2013-03-10 07:09:13 <gwillen> hah, oh dear
705 2013-03-10 07:09:49 <gmaxwell> they later made it 6, which only makes the problem less likely... and in doing so??? a problem created by the fundimental suckyness of the idea??? they still didn't seem to realize that it was sucky. :P
706 2013-03-10 07:10:14 <gmaxwell> perhaps they actually believe a six deep reorg is impossible. :P
707 2013-03-10 07:11:23 <warren> doesn't mtgox assume that?
708 2013-03-10 07:11:32 <warren> oh right. sleep.
709 2013-03-10 07:12:49 <gmaxwell> No,??? they don't. Just unlikely enough to be worth the risks..... (also noting that if a reorg >6 happens they will likely freeze all trading and withdraws)
710 2013-03-10 07:13:06 <gwillen> yeah, I think if a 6-block reorg happens, we will have enough to worry about besides firstbits
711 2013-03-10 07:13:32 <gmaxwell> But with something like firstbits the risk is infinite and unbounded. A reorg of 6 happens and a bunch of firstbits change and forver money is sent to the wrong ones. :P
712 2013-03-10 07:14:00 <gmaxwell> well we've had 4 that I'm aware of. Maybe 5. (and this isn't including the really huge one for the overflow bug)
713 2013-03-10 07:14:24 <gmaxwell> 6 will happen at some point, but it probably won't reverse any txn.
714 2013-03-10 07:16:50 <gmaxwell> perhaps in the future bitcoin will forward the blockheaders of competing forks that a node considers valid but late... then you could augment your acceptance criteria based on that. (wouldn't stop a malicious reorg, but might make 2-3 confirm acceptance more safe aganst reorg by chance.)
715 2013-03-10 07:58:10 <gmaxwell> would be nice if someone would make a pretty chart of bitcoin days destroyed / txn volume (in bytes, txn count, whatever).
716 2013-03-10 08:59:51 <Wayward> In the bitcoin-qt console, isn't there a command to expand the keypool?
717 2013-03-10 09:00:06 <Wayward> or would I have to close bitcoin-qt and restart it with a command line param?
718 2013-03-10 09:27:32 <weex> Wayward: bitcoind is the way
719 2013-03-10 09:28:14 <Wayward> isn't that interface just a UI for bitcoind?
720 2013-03-10 09:38:09 <weex> in a way but it doesn't implement everything in bitcoind
721 2013-03-10 09:39:38 <gmaxwell> Wayward: it's just a config / commandline argument.
722 2013-03-10 09:39:53 <gmaxwell> weex: the GUI implements everything in bitcoind.
723 2013-03-10 09:40:07 <gmaxwell> -keypool=<n> Set key pool size to <n> (default: 100)
724 2013-03-10 09:40:18 <gmaxwell> or keypool=n in bitcoin.conf
725 2013-03-10 09:40:20 <Wayward> here's the thing
726 2013-03-10 09:40:30 <Wayward> I want to pre-generate 10,000 keys
727 2013-03-10 09:40:33 <Wayward> and not a penny more
728 2013-03-10 09:40:48 <weex> oh i'm just thinking of what can be done from menus
729 2013-03-10 09:41:04 <gmaxwell> if you set it to 10,000 and let it do that then set it to 100 then thats what it should do until you get to 10,000-100.
730 2013-03-10 09:41:08 <Wayward> so my wallet backup doesn't become outdated because bitcoin-qt decided to continue generating new keys that entered circulation
731 2013-03-10 09:41:32 <gmaxwell> if you also lock the wallet then it won't be able to generate more until it is unlocked.
732 2013-03-10 09:41:32 <Wayward> so I have to quit, edit config, restart, quit, edit config, restart?
733 2013-03-10 09:41:36 <Wayward> ACTION blehs
734 2013-03-10 09:41:50 <Wayward> you have to unlock the wallet to use it
735 2013-03-10 09:41:53 <Wayward> not to create backups
736 2013-03-10 09:42:15 <gmaxwell> you have to unlock it to send coins. I didn't know your application, some people want to precalculate to put it on a system as an address source.
737 2013-03-10 09:42:28 <gmaxwell> You're really blehing about restarting it twice?
738 2013-03-10 10:35:00 <Wayward> btw, you have to start bitcoin-qt with -keypool=10,000
739 2013-03-10 10:35:32 <Wayward> then you have to open the GUI console window, and type "keypoolrefill"
740 2013-03-10 10:36:11 <Wayward> kind of silly that half the options exist as config/commandline params, and the other half exist as console commands.
741 2013-03-10 10:36:19 <Wayward> and never the twain shall meet.
742 2013-03-10 11:04:42 <Luke-Jr> fwiw, restarted dnsseed for the lulz, but it looked fine
743 2013-03-10 11:37:32 <ciphermonk> Can I use locked outputs (locked with lockunspent) in raw transactions?
744 2013-03-10 15:41:01 <licnep> is there any technical primer on the current bitcoin implementation? Something like the bitcoin paper but specific to the current implementation
745 2013-03-10 15:42:02 <Luke-Jr> the source code of bitcoind!
746 2013-03-10 15:43:41 <licnep> Luke-Jr: genius! why didn't i think of that? hehe
747 2013-03-10 15:43:49 <licnep> anyway i think i've found something
748 2013-03-10 15:48:53 <wumpus> you could try reading the BIPs; the most sigificant functional changes to the network have been documented in one
749 2013-03-10 15:51:05 <licnep> wumpus: yea i'll check those out too
750 2013-03-10 16:07:24 <muhoo> are there any known instances of someone executing a preimage atyack against a pubkey, or is that mostly a theoretical possibility still?
751 2013-03-10 16:10:23 <moarrr> lol i hope not
752 2013-03-10 16:10:46 <moarrr> i assume if it was possible it woudl be attempted, probably on one of the wealthier addresses
753 2013-03-10 16:14:03 <Luke-Jr> muhoo: theoretical impossibility, more like
754 2013-03-10 16:14:44 <sipa> muhoo: by preimage attack again pubkey, you mean finding pubkeys given the address?
755 2013-03-10 16:32:54 <HM> hmm
756 2013-03-10 16:34:04 <HM> 1 million RPC calls in 35 seconds. that's not too great
757 2013-03-10 17:27:03 <frac> hello, i'm trying to use -loadblock to load an existing blk....dat file and it doesnt seem to be loading
758 2013-03-10 17:27:17 <frac> im using version 0.8
759 2013-03-10 17:27:41 <Prattler> How much RAM does 1 unspent output take?
760 2013-03-10 17:27:55 <Prattler> (assuming UTXO is stored in RAM)
761 2013-03-10 17:28:32 <sipa> Prattler: it's not really stored in RAM, just cached
762 2013-03-10 17:28:39 <sipa> in several places even
763 2013-03-10 17:28:55 <Prattler> so how much data is that? ~100 bytes?
764 2013-03-10 17:29:14 <sipa> that order of magnitude yes, i'd say a bit more
765 2013-03-10 17:29:31 <sipa> also, depends what you're comparing with
766 2013-03-10 17:29:38 <frac> hey sipa, if im starting a new instance of bitcoin but have a bunch of blk000.dat files, whats the fastest way to get that read into bitcoin
767 2013-03-10 17:29:54 <frac> if i use the -rescan or -reindex command, where must these blk....dat files be located
768 2013-03-10 17:29:55 <Prattler> well I'd like to calculate how much 1 unspent output costs to the network
769 2013-03-10 17:30:35 <sipa> Prattler: it depends whether it's a new transaction, or just a UTXO being added to an already transaction
770 2013-03-10 17:30:52 <sipa> frac: in blocks/blk00000.dat, blk00001.dat, ...
771 2013-03-10 17:30:57 <Luke-Jr> Prattler: also note most of the network is using pre-0.8 versions, which doesn't do UTXO db
772 2013-03-10 17:30:58 <Prattler> sipa, oh? explain please
773 2013-03-10 17:31:24 <sipa> Prattler: UTXO's are stored in a tree, first indexed by txid, then by output#
774 2013-03-10 17:31:26 <frac> sipa if there is no index folder in blocks, will it still pick it up?
775 2013-03-10 17:31:33 <Prattler> Luke-Jr, well the calculation would be to evaluate future system costs, assuming nodes are most efficient
776 2013-03-10 17:31:35 <sipa> frac: -reindex should
777 2013-03-10 17:31:50 <Prattler> sipa, thanks! Let me think on that
778 2013-03-10 17:32:00 <sipa> Prattler: so if you add a tx with a UTXO, you need a new entry in the top tree
779 2013-03-10 17:32:07 <sipa> while otherwise it's just an output being added
780 2013-03-10 17:32:11 <Prattler> I understand
781 2013-03-10 17:32:21 <sipa> Prattler: if you assume maximal efficiency, i think you should just count on-disk storage
782 2013-03-10 17:32:23 <Prattler> how much space would each of those be?
783 2013-03-10 17:32:34 <sipa> anything above will be caches, which can be small or large, but don't have a permanent cosr
784 2013-03-10 17:32:43 <sipa> Prattler: let me count that for you
785 2013-03-10 17:33:23 <Prattler> I'd think that assuming bitcoin is super popular and is pushing around 10+ MB blocks, most (50%?) of the UTXO should be cached in RAM.
786 2013-03-10 17:34:52 <ciphermonk> One output is 34 byte ( standard pubkeyhash output )
787 2013-03-10 17:35:07 <sipa> ciphermonk: the UTXO on disk uses a custom format which compressed such outputs
788 2013-03-10 17:35:45 <ciphermonk> oh cool, so it basically just stores the value and the pubkeyhash ?
789 2013-03-10 17:36:12 <frac> thanks again sipa you are always helpful
790 2013-03-10 17:36:19 <frac> 10 internet points awarded to you
791 2013-03-10 17:36:26 <ciphermonk> I'll go read the code ;-)
792 2013-03-10 17:37:42 <sipa> Prattler: should be 41.5 bytes for each transactions which is not entirely spent (excluding any of its outputs)
793 2013-03-10 17:38:14 <sipa> plus 23 bytes for each unspent output
794 2013-03-10 17:38:29 <Prattler> oh that's cool :) Thanks!
795 2013-03-10 17:38:49 <sipa> in-memory it's a lot more, but that's just the lowest-level cache
796 2013-03-10 17:39:02 <sipa> the on-disk format also gets cached, which has the same space characteristics
797 2013-03-10 17:39:59 <sipa> Prattler: the gettxoutsetinfo RPC commands calculates some statistics
798 2013-03-10 17:40:26 <Prattler> nice, will check it out, thanks
799 2013-03-10 17:41:07 <xjrn> sipa: is it fair to consider the UTXO the same as a shared simulation? e.g. symetrical on all nodes, and eventually consistent based on new inputs
800 2013-03-10 17:41:30 <Happzz> is samba capable of indexing stuff for windows clients to effectively search through?
801 2013-03-10 17:41:37 <Happzz> i know a windows server can do that
802 2013-03-10 17:41:44 <Happzz> if it can, how?
803 2013-03-10 17:42:12 <sipa> Happzz: maybe ask in #samba? :)
804 2013-03-10 17:42:44 <Happzz> #samba is dead :(
805 2013-03-10 17:42:55 <Happzz> i asked that question there like a dozen times just today
806 2013-03-10 17:43:01 <Happzz> oh oops
807 2013-03-10 17:43:07 <Happzz> lol i thought it's #samba-dev!
808 2013-03-10 17:43:28 <Happzz> samba-technical even
809 2013-03-10 17:43:33 <Happzz> sorry.
810 2013-03-10 17:47:08 <Prattler> Is it ok to assume UTXO data has to be on RAM or at least on an SSD drive. Assuming bitcoin gets big, there are lots of transactions, blocks are big, etc. Considering an attack like this https://bitcointalk.org/?topic=144122
811 2013-03-10 17:47:14 <Prattler> ?
812 2013-03-10 17:48:02 <remote> how many blocks currently exist?
813 2013-03-10 17:48:22 <sipa> ;;bc,blocks
814 2013-03-10 17:48:28 <gribble> timed out
815 2013-03-10 17:48:30 <remote> ;;bc,blocks
816 2013-03-10 17:48:31 <gribble> 225226
817 2013-03-10 17:48:35 <remote> not bad
818 2013-03-10 17:48:41 <remote> hey sipa
819 2013-03-10 17:49:01 <remote> i'm about to resume trying to convert pub key to address again ;-)
820 2013-03-10 17:49:25 <remote> there must be something silly I'm doing wrong
821 2013-03-10 17:51:11 <HM> remote: what language?
822 2013-03-10 17:53:37 <remote> HM: python