1 2013-06-05 00:09:48 <TheUni> sipa_: ping
2 2013-06-05 00:10:23 <sipa_> TheUni: looking at your pull now
3 2013-06-05 00:10:32 <TheUni> great, thanks
4 2013-06-05 00:11:18 <warren> URL?
5 2013-06-05 00:11:39 <sipa_> #2700
6 2013-06-05 00:19:19 <TheUni> sipa_: thanks
7 2013-06-05 00:24:02 <BCB> ;;rated KoSoVaR
8 2013-06-05 00:24:02 <gribble> You rated user KoSoVaR on Sat Mar 30 16:51:07 2013, giving him a rating of 1, and supplied these additional notes: small Chase quickpay to bitcoin trade. Smooth..
9 2013-06-05 00:25:59 <BCB> ;;rate KosoVar 3 Multiple Trades. Smooth.
10 2013-06-05 00:26:00 <gribble> Rating entry successful. Your rating for user KosoVar has changed from 1 to 3.
11 2013-06-05 00:26:05 <sipa_> BCB: not here
12 2013-06-05 00:26:12 <BCB> what's up with gribble
13 2013-06-05 00:27:13 <BCB> opps sorry
14 2013-06-05 01:25:51 <phantomcircuit> lol most useless heap profile ever
15 2013-06-05 01:26:00 <phantomcircuit> start bitcoind with testnet and a default wallet
16 2013-06-05 01:26:06 <phantomcircuit> allocates almost nothing on the heap
17 2013-06-05 01:26:24 <sipa_> huh?
18 2013-06-05 01:26:35 <maaku> verifying blocks on startup takes ~1 min for me on a new macbook pro (no SSD). is this normal and is 288 blocks still an acceptable default?
19 2013-06-05 01:26:55 <phantomcircuit> sipa_, yeah it's weird
20 2013-06-05 01:27:10 <phantomcircuit> tcmalloc with HEAPPROFILE shows only 0.2MB allocated on the heap
21 2013-06-05 01:27:15 <sipa_> lol
22 2013-06-05 01:27:20 <sipa_> that's ridiculous
23 2013-06-05 01:27:30 <phantomcircuit> not sure if super efficient
24 2013-06-05 01:27:32 <phantomcircuit> or totally wrong
25 2013-06-05 01:27:49 <sipa_> how many blocks is testnet?
26 2013-06-05 01:27:56 <phantomcircuit> 83k
27 2013-06-05 01:27:57 <sipa_> oh, is it synced?
28 2013-06-05 01:28:01 <phantomcircuit> yeah it is
29 2013-06-05 01:28:10 <sipa_> ;;calc 83000*130
30 2013-06-05 01:28:11 <gribble> 10790000
31 2013-06-05 01:28:12 <phantomcircuit> and this is after it verifies everything and loads
32 2013-06-05 01:28:22 <sipa_> at least the block headers should be 10 MB
33 2013-06-05 01:28:26 <phantomcircuit> ok so horribly inaccurate it is
34 2013-06-05 01:28:31 <phantomcircuit> wonder why that is
35 2013-06-05 01:28:44 <sipa_> the dbcache is likely more
36 2013-06-05 01:28:57 <phantomcircuit> lol
37 2013-06-05 01:29:03 <phantomcircuit> totally unrelated
38 2013-06-05 01:29:12 <phantomcircuit> girl wants to have a drink near were i live
39 2013-06-05 01:29:16 <phantomcircuit> "can you drive me home?"
40 2013-06-05 01:29:17 <phantomcircuit> wat
41 2013-06-05 01:29:18 <phantomcircuit> no
42 2013-06-05 01:29:29 <phantomcircuit> drinks
43 2013-06-05 01:29:30 <phantomcircuit> drive
44 2013-06-05 01:29:33 <phantomcircuit> *head asplodes*
45 2013-06-05 01:29:53 <sipa_> maaku: there are a few steps involved, and i'm not sure which is the slowest (for you)
46 2013-06-05 01:29:59 <warren> sipa_: should I abort my pre-autotools patches and just wait?
47 2013-06-05 01:30:20 <maaku> ok, i'll profile it when i get the chance
48 2013-06-05 01:30:51 <phantomcircuit> sipa_, i should also note that the google-perftools cpuprofile appears to completely lock up when loading a large wallet
49 2013-06-05 01:30:56 <maaku> btw sipa_ do you ever sleep ;)
50 2013-06-05 01:31:06 <sipa_> maaku: i'm weirdly jetlagged
51 2013-06-05 01:31:19 <sipa_> i slept from 10pm to 4am
52 2013-06-05 01:32:20 <maaku> yeah that travel takes time to adjust
53 2013-06-05 01:32:44 <maaku> you're still on USA pacific time if IRC is any judge ;)
54 2013-06-05 01:33:09 <sipa_> that would mean i've slept from 1pm to 7pm...
55 2013-06-05 01:35:02 <maaku> i'll track down the slow verification. if it annoys me, it probably annoys newbies too
56 2013-06-05 01:35:13 <sipa_> yeah, i've noticed it here too
57 2013-06-05 01:35:21 <maaku> of course multi-day IBD is probably a more pressing problem :P
58 2013-06-05 01:35:39 <sipa_> but i rarely use Qt, so it bothers me less
59 2013-06-05 01:36:54 <grau> In case IL is 0 or >=n, the master key is invalid.
60 2013-06-05 01:36:54 <grau> Use IL (mod n) as master secret key, and IR as master chain code.
61 2013-06-05 01:36:59 <grau> sipa_: a minor node to BIP32 doc: The Master key generation is ambigous:
62 2013-06-05 01:37:18 <grau> sipa_: Hi see above
63 2013-06-05 01:37:32 <sipa_> aha, the mod n should go away
64 2013-06-05 01:37:39 <sipa_> thanks for pointing that out
65 2013-06-05 01:38:01 <sipa_> if that's what you meant?
66 2013-06-05 01:38:10 <grau> sipa_: yes
67 2013-06-05 01:38:42 <grau> sipa_: For my own benefit: "Bitcoin seed" would be replaced by pasphrase in practice and seed is some entropy?
68 2013-06-05 01:39:35 <sipa_> i didn't intend the string to be changeable
69 2013-06-05 01:39:56 <sipa_> if you want a password-protected system, the seed should be encrypted with it
70 2013-06-05 01:40:19 <grau> I mean if master key is a brain wallet
71 2013-06-05 01:41:23 <grau> the seed would provide sufficient randomness and the key would be memorized
72 2013-06-05 01:41:49 <sipa_> if the seed is generated randomly, there's no need to have extra entropy from the key
73 2013-06-05 01:42:19 <sipa_> and using a passphrase directly as the hmac key sounds like a very weak key derivation mechanism
74 2013-06-05 01:42:56 <sipa_> you're much better off using scrypt or something like that to turn the passphrase into a key in a hard/slow way, and then use that key to encrypt the seed
75 2013-06-05 01:43:35 <sipa_> but i'm not sure what you want to do: you say brainwallet, but there's still a random seed involved?
76 2013-06-05 01:43:45 <sipa_> so there's two things to remember?
77 2013-06-05 01:44:02 <grau> I mean the following use: the seed would be derived from some unique device property of sufficient quantity and key would be the passphrase to reconstruct the wallet.
78 2013-06-05 01:44:21 <grau> I think of the brain wallet in a mobile
79 2013-06-05 01:44:53 <sipa_> you mean let people choose a passphrase themself, and have the wallet be directly derived from that?
80 2013-06-05 01:44:56 <sipa_> that sounds terrible
81 2013-06-05 01:45:26 <grau> not just from passphrase, but some unique property linked to the device that has sufficient randomness
82 2013-06-05 01:45:33 <sipa_> such as?
83 2013-06-05 01:46:10 <grau> it could be PRNG generated even and the user would be asked to store it elsewhere to be able to reconstruct on an other mobile.
84 2013-06-05 01:47:02 <grau> the point is to have a simple passphrase to enter and some p random seed to make it string enough for thse have no access to the device
85 2013-06-05 01:47:03 <sipa_> i'm not following at all anymore
86 2013-06-05 01:47:21 <sipa_> where is this p stored?
87 2013-06-05 01:47:31 <grau> on the device
88 2013-06-05 01:47:38 <sipa_> ok, so it's not a brainwallet
89 2013-06-05 01:47:50 <sipa_> just a password-protected seed
90 2013-06-05 01:47:55 <grau> in between since the passphrase is brain
91 2013-06-05 01:48:09 <grau> ok, if thats the correct term
92 2013-06-05 01:48:13 <sipa_> but the passphrase is not enough to reconstruct the wallet
93 2013-06-05 01:48:23 <sipa_> it's only used to protect the stored seed
94 2013-06-05 01:48:24 <grau> no, you need the seed to
95 2013-06-05 01:48:34 <sipa_> so, what i would suggest is this:
96 2013-06-05 01:49:12 <sipa_> you generate a random byte string (16-64 bytes), as random as you can
97 2013-06-05 01:49:19 <sipa_> you ask for a passphrase
98 2013-06-05 01:49:39 <sipa_> you use scrypt or another KDF to turn the passphrase into an encryption key
99 2013-06-05 01:49:53 <sipa_> then encrypt the random byte string using that encryption key, and store it
100 2013-06-05 01:50:06 <sipa_> and use the random byte string as BIP32 seed
101 2013-06-05 01:51:21 <sipa_> you could just encrypt the root node, or even known subnodes as well of course, if you want to save recomputation time
102 2013-06-05 01:51:28 <grau> why would I store the encrypted byte string? I can ask for the passphrase to recreate it on the fly
103 2013-06-05 01:51:46 <sipa_> well it replaces the p value that you wanted to store before
104 2013-06-05 01:52:40 <grau> I start with a random byte string already, right?
105 2013-06-05 01:53:11 <sipa> the scheme i gave above is all you need
106 2013-06-05 01:53:31 <sipa> there's of course other possibilities, but please don't directly use a passphrase to derive keys
107 2013-06-05 01:53:43 <sipa> humans are ridiculously bad at estimating their own randomness
108 2013-06-05 01:53:44 <tumak> sipa: neat, i'm trying to extract it (_fe_/_ge_) to work without using gmp/ssl bignum
109 2013-06-05 01:53:57 <tumak> and i'm kind of confused since _num_ is haunting all over the place
110 2013-06-05 01:54:05 <sipa> tumak: fe and ge don't use num
111 2013-06-05 01:54:09 <tumak> yup
112 2013-06-05 01:54:20 <tumak> however the upper level mixes _fe_/_ge_ with bignum :(
113 2013-06-05 01:54:25 <sipa> of course
114 2013-06-05 01:54:38 <sipa> private keys are scalares, not field or group elements
115 2013-06-05 01:55:11 <sipa> grau: you say "I start with a random byte string" -> you mean from a PRNG?
116 2013-06-05 01:55:24 <grau> sipa: yes
117 2013-06-05 01:55:29 <sipa> so that's fine
118 2013-06-05 01:56:11 <grau> What I do not get is why "Bitcoin seed" is fixed and is not derived from passphrase
119 2013-06-05 01:56:24 <sipa> there's no need
120 2013-06-05 01:56:30 <sipa> it could have been an empty string as well
121 2013-06-05 01:56:50 <sipa> it's just that HMAC has a key and a message as input, but we don't need a key
122 2013-06-05 01:57:01 <sipa> we're just reusing it as a hash function
123 2013-06-05 01:57:26 <grau> I want to split the information to stored and memorized. There it is handy to store the seed and memorize the key.
124 2013-06-05 01:57:39 <tumak> sipa: meaning that code is only useful to verify signatures, but not for signing as that involves scalar add/sub (easy), and modmul/inverse (where i guess i'd need to implement modmul with hardcoded secp256k1 order)
125 2013-06-05 01:58:06 <sipa> grau: and that's exactly what you're doing, when you encrypt the seed with a passphrase
126 2013-06-05 01:58:18 <sipa> grau: the inputs to reconstruction become the stored encrypted key, and the passphrase
127 2013-06-05 01:58:19 <grau> now I get you.
128 2013-06-05 01:58:32 <sipa> and either one is useless
129 2013-06-05 01:58:50 <sipa> except the passphrase may be guessable, the encrypted key shouldn't ever be
130 2013-06-05 01:59:36 <sipa> tumak: so if you want the entire library to be dependency-free, you'll need a new native num implementation from scratch
131 2013-06-05 02:00:07 <sipa> but especially for things like modular inverses, it's very hard to beat libraries like GMP
132 2013-06-05 02:00:38 <sipa> performance-wise
133 2013-06-05 02:03:08 <grau> sipa: what algorithm do you suggest if I use derive properties instead of PRNG to derive the seed?
134 2013-06-05 02:03:25 <sipa> grau: PRNG and nothing else
135 2013-06-05 02:03:34 <sipa> the seed should be random
136 2013-06-05 02:03:44 <grau> Assuming is have some device properties.
137 2013-06-05 02:04:03 <sipa> you could add those device properties implicitly to the passphrase
138 2013-06-05 02:04:52 <sipa> so the real passphrase fed to scrypt/kdf would be the entered passphrase concatenated with whatever properties you can use (those effectively become a salt)
139 2013-06-05 02:06:49 <sipa> maaku: regarding startup time, a) is a second startup right after the first faster (to exclude disk cache effects), b) does lowering -checklevel help, or does -checkblocks matter more. c) is it CPU bound?
140 2013-06-05 02:08:58 <sipa> grau: so perhaps to address what you wanted to do: i know it's tempting to see the HMAC key in the master generation as a way to tweak the keys, and it would be good for that if what you add is actually a real fully random key
141 2013-06-05 02:10:25 <sipa> grau: but since that's not the case (if it was, you'd just use it as seed instead), it's not a good solution, and you should see the (seed -> HMACSHA512(key="Bitcoin seed", msg=seed) operation as a black box, and do anything to tweak it on the seed before passing it to the master generation
142 2013-06-05 02:15:18 <grau> sipa: OK, here is my plan (following your advice): 1. generate PRNG seed R. 2. get passphrase P. 3 create key K = KDF(P). 4. encrypt and store seed as S = E(K,R). 5. Use Master key as M = HMACSHA512("Bitcoin seed", R). 6. Recreate: M = HMACSHA512("Bitcoin seed",D(KDF(P),S))
143 2013-06-05 02:15:38 <sipa> grau: bingo
144 2013-06-05 02:15:44 <grau> thanks a lot
145 2013-06-05 02:16:33 <sipa> you could use KDF(P + salt) too, where salt is derived from hardware properties
146 2013-06-05 02:16:54 <grau> yep.
147 2013-06-05 02:17:58 <grau> and KDF will be scrypt to frustrate brute force if device is stolen
148 2013-06-05 02:19:09 <grau> do you have a feel of scrypt parameters sufficient to frustrate but suitable for key derivation in a mobile?
149 2013-06-05 02:19:53 <sipa> that's always a hard thing, since your attackers will likely have very different hardware
150 2013-06-05 02:20:07 <sipa> but mobiles have relatively large amounts of RAM these days, i think
151 2013-06-05 02:20:40 <grau> I know, but could not yet find a pointer of how to interpret and tune parameters. Do you have some source?
152 2013-06-05 02:20:57 <sipa> i'd have to look it up myself
153 2013-06-05 02:21:09 <grau> ok, never mind I keep googling
154 2013-06-05 02:23:26 <maaku> sipa: it appears to be disk, not CPU bound, and relaunching is faster, but not by much. say, 50s instead of 60. i haven't made precise timings yet.
155 2013-06-05 02:24:00 <maaku> 16G of ram, with 12G free, so that's not the issue
156 2013-06-05 02:24:34 <sipa> maaku: you have txindex enabled?
157 2013-06-05 02:24:50 <sipa> that shouldn't matter much actually
158 2013-06-05 02:25:19 <maaku> running default 0.8.2 launch options (just rpc information set)
159 2013-06-05 02:25:46 <maaku> i'll try messing with -checklevel or -checkblocks tomorrow if i can
160 2013-06-05 02:27:01 <maaku> btw if this is just my machine than I'm not concerned; i just wouldn't want this to be the default user experience
161 2013-06-05 02:29:38 <sipa> maaku: unlikely that it's just you
162 2013-06-05 02:55:37 <arruah1> hi ppl
163 2013-06-05 02:56:20 <arruah1> any professionals on ruby here?
164 2013-06-05 02:56:38 <sipa> i don't do drugs
165 2013-06-05 02:57:08 <arruah1> sipa: i don't understand
166 2013-06-05 02:57:17 <sipa> arruah1: silly joke, sorry :)
167 2013-06-05 02:57:37 <arruah1> sipa: i have to try open exchange in KAzakhstan
168 2013-06-05 02:57:58 <sipa> i wish you good luck, but ruby will be the least of your problems
169 2013-06-05 02:58:57 <arruah1> sipa: i find this https://github.com/davout/bitcoin-central
170 2013-06-05 02:59:51 <sipa> arruah1: i mean: i expect security and legal issues to be much larger concerns than implementation
171 2013-06-05 03:00:07 <tumak> in .kz? somehow i doubt it :)
172 2013-06-05 03:00:29 <arruah1> .kz
173 2013-06-05 03:01:45 <gmaxwell> A Glorious Market of Bitcoin!
174 2013-06-05 03:02:41 <gmaxwell> arruah1: You can probably hire people to help you with the technical stuff on bitcointalk, but as sipa said??? the technical problems are the easiest.
175 2013-06-05 03:04:02 <owowo> so what are the hardest? ;o)
176 2013-06-05 03:04:45 <gmaxwell> Coming up with a name.
177 2013-06-05 03:04:48 <gmaxwell> ACTION ducks
178 2013-06-05 03:05:47 <sipa> "The Gmaxwell Ducks: A new Bitcoin exchange!"
179 2013-06-05 03:05:49 <owowo> Nasarbarbit.kz :P
180 2013-06-05 03:06:23 <arruah1> owowo: :)
181 2013-06-05 03:06:47 <arruah1> owowo: you know our Prezident it is good
182 2013-06-05 03:07:07 <gmaxwell> Ducks for bucks, a fowl business plan if I've ever heard of it.
183 2013-06-05 03:07:10 <grau> sipa: Is there are reason to encrypt the PRNG seed in the first place. Could I not just assume that PRNG result is an encrypted seed?
184 2013-06-05 03:07:49 <sipa> grau: and only decrypt the randomly-generated date to get the seed?
185 2013-06-05 03:07:56 <grau> yes
186 2013-06-05 03:08:16 <arruah1> owowo: President*
187 2013-06-05 03:08:21 <gmaxwell> grau: I may be missing context here, but then you could not change passwords. Key management is important.
188 2013-06-05 03:08:25 <sipa> grau: that sounds safe to me, but the encryption done at generation time is not likely to be a bottleneck, is it?
189 2013-06-05 03:08:47 <grau> no, it is just superflus code :)
190 2013-06-05 03:08:48 <sipa> gmaxwell: actually, you can :)
191 2013-06-05 03:09:04 <grau> like the o in superflous
192 2013-06-05 03:09:21 <sipa> superfluous?
193 2013-06-05 03:09:25 <gmaxwell> sipa: hah. by reencrypting.. I suppose. go go permutation.. BUT.
194 2013-06-05 03:09:38 <gmaxwell> sipa: at that point no code would have been saved at all. :)
195 2013-06-05 03:12:53 <sipa> true
196 2013-06-05 03:13:30 <arruah1> sipa: why ruby is bad choice?
197 2013-06-05 03:13:54 <sipa> arruah1: eh, i never intended to say that
198 2013-06-05 03:14:07 <sipa> (i don't know ruby at all, so i cannot judge)
199 2013-06-05 03:14:22 <arruah1> sipa: ok
200 2013-06-05 03:14:26 <sipa> i just said that you should worry about more than just programming the site, when creating an exchange
201 2013-06-05 03:14:41 <arruah1> sipa: i realize that
202 2013-06-05 03:14:55 <arruah1> sorry for my English
203 2013-06-05 03:15:26 <arruah1> sipa: but first of all i need programmer
204 2013-06-05 03:16:43 <maaku> arruah1: the trading engine itself probably shouldn't be in ruby for performance reasons
205 2013-06-05 03:17:23 <maaku> but the trading engine shouldn't be the same application as the website either
206 2013-06-05 03:17:28 <arruah1> 1.9 is good by speed now as i know
207 2013-06-05 03:17:46 <maaku> not nearly good enough
208 2013-06-05 03:17:54 <maaku> but best to let your programmer make those decisions
209 2013-06-05 03:17:56 <Diablo-D3> arruah1: ruby is a bad choice because its a shit backwards language for hipsters
210 2013-06-05 03:17:58 <arruah1> maaku: hm
211 2013-06-05 03:18:23 <Diablo-D3> anyone who thinks ruby is a good choice for something is simply wrong and should be beaten with a crowbar
212 2013-06-05 03:18:25 <arruah1> maaku: what about bitcoin-central.net, bitcoin-24.com
213 2013-06-05 03:18:48 <arruah1> maaku: bitcoin-24.com was good for me
214 2013-06-05 03:38:44 <warren> Do all commits into bitcoin require a pull request, or do a select few push directly? Just understanding policy.
215 2013-06-05 03:39:08 <warren> not seeing pull requests for some things
216 2013-06-05 03:39:28 <sipa> very simple things are sometimes pushed directly
217 2013-06-05 03:40:36 <maaku> warren: if you're trusted with a commit bit, it also means you are trusted to know when something is controversial (pull-request) or not
218 2013-06-05 03:40:39 <Luke-Jr> very rarely
219 2013-06-05 03:40:56 <Luke-Jr> even if it's not controversial, peer review is important for the quality needed in a Bitcoin node
220 2013-06-05 03:41:10 <maaku> Luke-Jr: agreed
221 2013-06-05 03:41:16 <sipa> i generally always use pullreqs, even if it's for something i merge immediately myself
222 2013-06-05 03:43:16 <Luke-Jr> ACTION would use pull requests for BFGMiner or Eloipool if there were actual other contributors to review them :/
223 2013-06-05 03:43:55 <warren> Pools just copy random code from github. They don't understand it.
224 2013-06-05 03:44:04 <warren> Hilarity ensues.
225 2013-06-05 03:44:19 <Luke-Jr> dunno, at least 3 others have expressed that they would contribute if I rewrite it in C/C++, so I might do that
226 2013-06-05 03:45:13 <Luke-Jr> (Eloipool, that is)
227 2013-06-05 03:45:31 <maaku> really? please don't
228 2013-06-05 03:45:43 <Luke-Jr> ???
229 2013-06-05 03:45:46 <maaku> well do whatever you have to do, but that's a shame
230 2013-06-05 03:46:07 <Luke-Jr> well, ~nobody else is contributing to it in Python..
231 2013-06-05 03:46:44 <maaku> there is much better ecosystem for http services in Python
232 2013-06-05 03:46:47 <warren> Luke-Jr: I was referring to a major exploit among the litecoin pools this past week. People figured out how to make a CPU miner steal shares as if it were a large massive GPU farm. Massive fail. Most of the little pools across multiple coins were using that software.
233 2013-06-05 03:47:17 <maaku> well I'll make and push Freicoin/demurrage+budgets support one of these days
234 2013-06-05 03:49:30 <Luke-Jr> maaku: libcurl is pretty good for a HTTP client, and libjansson is nice for JSON
235 2013-06-05 03:49:43 <Luke-Jr> maaku: I'd need to write a HTTP server myself, sure, but I had to do that for Python too
236 2013-06-05 03:50:26 <CodeShar_> python has httplib2
237 2013-06-05 03:50:31 <CodeShar_> for client operations
238 2013-06-05 03:50:33 <CodeShar_> which isn't bad
239 2013-06-05 03:50:45 <Luke-Jr> CodeShar_: yeah, but libcurl is good too
240 2013-06-05 03:50:59 <maaku> python as gunicorn, Werkzeug et al
241 2013-06-05 03:51:28 <Luke-Jr> "It's a pre-fork worker model ported from Ruby's Unicorn project."
242 2013-06-05 03:52:04 <maaku> but it's more about other stuff - templating, caching, etc., (e.g, if you are looking to add features to the front end)
243 2013-06-05 03:52:23 <Luke-Jr> eh, I don't want frontend stuff in the backend :p
244 2013-06-05 03:57:53 <pjorrit> that sounds so dirty Luke-Jr O=)
245 2013-06-05 03:57:59 <Luke-Jr> ????????????.
246 2013-06-05 03:58:28 <Luke-Jr> only if you have a dirty mind
247 2013-06-05 03:58:56 <pjorrit> ACTION couldnt be more innocent
248 2013-06-05 04:10:59 <john_z> hooray! we received yesterday our USB Block Eruptors!! :)
249 2013-06-05 04:11:09 <john_z> srry, wrong channel
250 2013-06-05 04:12:56 <grau> sipa: superfluous ... in fact, we ned a lang w les reddcy
251 2013-06-05 04:13:09 <sipa> ttly agr
252 2013-06-05 04:13:30 <sipa> wh d w vn nd vwls n wrds t ll?
253 2013-06-05 04:14:23 <maaku> http://www.plainlanguage.gov/examples/humor/marktwain.cfm
254 2013-06-05 04:16:05 <Kireji> attacks are coming http://www.forbes.com/sites/harrybinswanger/2013/06/04/dont-be-silly-the-entitlement-state-wont-allow-bitcoin/
255 2013-06-05 04:21:28 <pjorrit> http://www.wm-center.com/index.html that's already taken down
256 2013-06-05 06:34:26 <sydna> is there any known occurrence of a miner assigning themselves a less than maximum block reward?
257 2013-06-05 06:35:07 <sipa> yes
258 2013-06-05 06:35:45 <sydna> time to go find it, that sounds like fun
259 2013-06-05 06:36:03 <sipa> i can't give you exact examples, but the total current amount of unspent outputs is 11246389.80331183
260 2013-06-05 06:36:28 <sipa> which would be an exact multiple of 25, if all subsidy/fees were always claimed
261 2013-06-05 06:36:52 <sydna> heh, 135BTC short
262 2013-06-05 06:37:11 <sipa> the genesis block has no spendable output
263 2013-06-05 06:37:31 <sipa> i believe there have been 1 or 2 cases of duplicate coinbases (which "overwite" existing coins)
264 2013-06-05 06:37:32 <sydna> I subtracted that already
265 2013-06-05 06:37:34 <pjorrit> but it's an unspent output isnt it? :)
266 2013-06-05 06:37:57 <sydna> I wasn't aware of that behaviour
267 2013-06-05 06:38:05 <sipa> pjorrit: it's an output, and it's unspent, but it's not in any UTXO set from the point of view of the verification mechanism
268 2013-06-05 06:38:14 <pjorrit> no that makes sense :)
269 2013-06-05 06:38:16 <sipa> sydna: since BIP30 it's impossible
270 2013-06-05 06:38:44 <jouke> duplicate coinbases? Transaction with the same hash?
271 2013-06-05 06:38:53 <sipa> yes
272 2013-06-05 06:38:59 <sydna> oh, of course
273 2013-06-05 06:39:39 <grau> sipa: just implemented blockchain scan with lookahead for a BIP32 public key. It takes just a few secs on my server
274 2013-06-05 06:40:13 <sydna> grau: you must have one crazy fast SSD
275 2013-06-05 06:40:30 <grau> no I has coding
276 2013-06-05 06:40:36 <grau> :)
277 2013-06-05 06:40:59 <grau> It is a service you can rent ;)
278 2013-06-05 06:41:09 <sipa> grau: just the UTXO set, or the entire chain?
279 2013-06-05 06:41:16 <grau> entire chain
280 2013-06-05 06:41:21 <sydna> you'd still have to be reading 9GB of block files though
281 2013-06-05 06:41:34 <sydna> presumably that's where your bottleneck is?
282 2013-06-05 06:41:35 <sipa> impressive; you're using an address-based index?
283 2013-06-05 06:41:41 <grau> I do have indices sydna
284 2013-06-05 06:41:58 <sydna> ah, again, I'm being stupid
285 2013-06-05 06:42:05 <grau> I use bloom filters to locate candidate blocks then parse and scan them
286 2013-06-05 06:42:32 <grau> The index is a precomputed bloom filter per block
287 2013-06-05 06:42:33 <jouke> grau: does it matter how far you look ahead?
288 2013-06-05 06:42:55 <grau> jouke: it does a since increases the number of patterns I match for
289 2013-06-05 06:43:29 <grau> it is however handy that keys are used in consecutive order, so most of the time is spent in finding the first key use
290 2013-06-05 06:44:38 <sipa> knowing a key's birthdate is very useful for that (at least, if it's not very old already)
291 2013-06-05 06:44:48 <grau> 3.5 secs to look ahead with 10
292 2013-06-05 06:45:05 <grau> java is so slow :)
293 2013-06-05 06:47:03 <grau> 9.8 secs for lookahead with 100
294 2013-06-05 06:48:35 <jouke> grau: ah, bip32 specifies that?
295 2013-06-05 06:49:09 <grau> sipa: it is a single pass search assuming that first key used is one in the lookahead window, then keys are used consecutive with gaps smaller than the window
296 2013-06-05 06:49:23 <grau> jouke: yes it is BIP32 public key you pass to the scan
297 2013-06-05 06:49:54 <jouke> I mean that you use the keys in consecutive order.
298 2013-06-05 06:50:02 <jouke> Or do you scan the whole chain for all the keys?
299 2013-06-05 06:50:06 <grau> sipa: it picks up all transactions spending to those addresses and also all transactions spending them
300 2013-06-05 06:50:31 <sipa> there are 2^32 subnodes for each BIP32 node
301 2013-06-05 06:50:40 <sipa> scanning them all would be wasteful
302 2013-06-05 06:50:45 <grau> jouke: I scan the full chain but assume that key i+1 is only used after i
303 2013-06-05 06:50:53 <jouke> No, you say you first scan the key for first use.
304 2013-06-05 06:50:58 <jouke> grau: yes, ok, clear.
305 2013-06-05 06:51:13 <grau> sipa: I am not scanning for subnodes. just descendands of an extended public
306 2013-06-05 06:51:33 <sipa> technically not part of bip32, but i think a "best practices" section could suggest behaviour like that
307 2013-06-05 06:51:58 <grau> the best practice should suggest avoid gaps in key use
308 2013-06-05 06:52:03 <MrGuy> Are there any pure PoS coins out there, or are all the current PoS coins hybrid (maybe going pure PoS after initial minting)...?
309 2013-06-05 06:52:06 <jouke> But still, I don't think it will be used like that
310 2013-06-05 06:52:22 <sipa> grau: for internal keys, that's possible, but for not for external ones
311 2013-06-05 06:52:47 <grau> what do you mean with external/internal?
312 2013-06-05 06:52:57 <sipa> internal: change-only
313 2013-06-05 06:53:11 <sipa> external: used to derive addresses you give out to receive coins on
314 2013-06-05 06:53:38 <sipa> for internal chains you can use a very low gap
315 2013-06-05 06:53:51 <grau> even for external you should attempt recycle if not received
316 2013-06-05 06:54:11 <sipa> that has slight privacy problems, but it's possible
317 2013-06-05 06:54:41 <grau> yes but having big gaps is definitely expensive in audit scan or wallet reconstruction
318 2013-06-05 06:54:55 <sipa> (but with the payment protocol, the time between selecting the address and creation of the transactions becomes limited and short, so gaps can become much smaller)
319 2013-06-05 06:55:56 <jouke> yes, but you will have addresses that you give out that you don't have control over when it will first be used.
320 2013-06-05 06:56:07 <jouke> Look at all the donation-addresses on btctalk
321 2013-06-05 06:57:24 <sydna> yeah, half of them will never be used
322 2013-06-05 06:58:16 <gwillen> so you can always send some coins to yourself every N addresses
323 2013-06-05 06:58:21 <gwillen> so the max gap will never exceed N
324 2013-06-05 06:58:32 <sipa> gwillen: "meh"
325 2013-06-05 06:58:38 <gwillen> yeah, I know
326 2013-06-05 07:00:08 <grau> What about using a sub account for receivables with a fixed pool size, then sweep them to "internal" accounts as received without gaps.
327 2013-06-05 07:00:08 <sipa> the observed behaviour when your gap is too small is that you stop receiving *all* transactions
328 2013-06-05 07:00:43 <sipa> or in case of a backup restore: failing to receive transactions after a certain point in time
329 2013-06-05 09:02:41 <pjorrit> why doest compiling this stuff take forever? like wow...
330 2013-06-05 09:02:43 <pjorrit> does*
331 2013-06-05 09:02:53 <pjorrit> uh ww
332 2013-06-05 10:46:42 <warren> how do I git pull directly from a github pull request again?
333 2013-06-05 10:47:29 <CodeShark> git pull <remote> <branch>
334 2013-06-05 10:48:20 <CodeShark> if you haven't cloned it yet, clone it first with git clone <remote>
335 2013-06-05 10:48:33 <lianj> git remote add
336 2013-06-05 10:48:43 <lianj> also, unlearn pull please :P
337 2013-06-05 10:48:53 <lianj> fetch + merge|rebase
338 2013-06-05 10:48:59 <warren> I mean, there's a hidden trick for github
339 2013-06-05 10:49:05 <CodeShark> or fetch, then checkout
340 2013-06-05 10:49:18 <lianj> warren: no, why
341 2013-06-05 10:49:28 <CodeShark> why would you want a hidden trick?
342 2013-06-05 10:49:32 <warren> where you can add a remote that has convenient access to pull requests
343 2013-06-05 10:49:43 <warren> to quickly test code that's in a pull request
344 2013-06-05 10:49:56 <CodeShark> that's not specific to github
345 2013-06-05 10:50:02 <sipa> CodeShark: it is
346 2013-06-05 10:50:06 <CodeShark> oh?
347 2013-06-05 10:50:09 <lianj> git remote add ...; git fetch --all
348 2013-06-05 10:50:12 <CodeShark> I've never used it then :)
349 2013-06-05 10:50:28 <sipa> there's a special remote you can add that gives you a view to all pull requests as branches
350 2013-06-05 10:50:30 <warren> someone told me to add this earlier:
351 2013-06-05 10:50:31 <warren> fetch = +refs/pull/*:refs/remotes/origin-pull/*
352 2013-06-05 10:50:31 <warren> [remote "origin-pull"]
353 2013-06-05 10:50:31 <warren> url = git://github.com/bitcoin/bitcoin.git
354 2013-06-05 10:50:43 <sipa> yeah, that
355 2013-06-05 10:50:46 <lianj> sipa: oh really? sounds kinda nice
356 2013-06-05 10:50:53 <warren> I don't remember the syntax to pull directly from pull requests though.
357 2013-06-05 10:51:05 <sipa> git fetch origin-pull
358 2013-06-05 10:51:22 <sipa> git checkout origin-pull/pullreqnumber/merge
359 2013-06-05 10:51:26 <lianj> git fetch --all; git merge origin-pull/foobar then
360 2013-06-05 10:52:28 <warren> sipa: do I need to check it out to see the commit ids to be able to cherry-pick from it?
361 2013-06-05 10:52:35 <sipa> no
362 2013-06-05 10:52:49 <sipa> git log origin-pull/pullreqnum/merge
363 2013-06-05 10:52:55 <warren> ahhhh
364 2013-06-05 10:53:13 <lianj> tig origin-pull/pullreqnum/merge :P
365 2013-06-05 10:53:21 <warren> I've been such a fool to use git like cvs all these years. =)
366 2013-06-05 10:53:22 <sipa> tig?
367 2013-06-05 10:53:29 <lianj> sipa: try it
368 2013-06-05 10:53:49 <warren> bash: tig: command not found
369 2013-06-05 10:53:49 <warren> [warren@newcaprica failcoin]$ tig
370 2013-06-05 10:53:58 <lianj> well install and try
371 2013-06-05 10:54:09 <warren> oops, I leaked my new honest scamcoin
372 2013-06-05 11:41:18 <jgarzik> ACTION frowns at freenode
373 2013-06-05 11:43:24 <TD> good morning jgarzik
374 2013-06-05 11:43:26 <TD> how is atlanta?
375 2013-06-05 11:43:42 <BlueMatt> s/atlanta/hotlanta/
376 2013-06-05 11:43:54 <jgarzik> TD, fun! This is where I attended university, so lots of old friends here.
377 2013-06-05 11:43:58 <jgarzik> And lots of traffic :/
378 2013-06-05 11:44:04 <TD> it will always be ATL to me. too many years of the only references to atlanta in my world being datacenter codes :-)
379 2013-06-05 11:44:06 <jgarzik> Drive 30 minutes to $anywhere :)
380 2013-06-05 11:44:20 <TD> it's cool that the location worked out so well there
381 2013-06-05 11:44:30 <TD> how is bitpay? working on anything cool
382 2013-06-05 11:44:39 <jgarzik> It's ATL to us, too. Being an airport hub, everybody calls the "the ATL" etc.
383 2013-06-05 11:44:48 <TD> heh
384 2013-06-05 11:45:41 <sipa> jgarzik: you had to move for your new job, or not?
385 2013-06-05 11:45:46 <jgarzik> TD, Still getting settled, breaking in the new environment. A bunch of projects, but most stuff you know or might guess: "keep bitcoind reliable and scaling", child pays for parent, the OP_RETURN pull req just posted last night etc.
386 2013-06-05 11:45:58 <jgarzik> sipa, yes, big move @ last minute
387 2013-06-05 11:46:04 <TD> what's bitpays interest in OP_RETURN? or is it just in the bucket of general scalability things?
388 2013-06-05 11:46:13 <TD> child pays for parent === yes pleeeeeease! :)
389 2013-06-05 11:46:23 <jgarzik> TD, attaching metadata to transactions is thought useful for many purposes
390 2013-06-05 11:46:25 <sipa> needs moar puppyeyes
391 2013-06-05 11:46:48 <BlueMatt> using OP_RETURN to add data to txn means you're doing something wrong
392 2013-06-05 11:46:48 <TD> we seem to have built up a backlog of pull reqs, and merge speed == opening new reqs speed
393 2013-06-05 11:46:51 <TD> so the number isn't going down
394 2013-06-05 11:47:11 <BlueMatt> merge speed << new pull req speed
395 2013-06-05 11:47:13 <sipa> BlueMatt: agree, but it's better than many alternatives that can't be prevented
396 2013-06-05 11:47:34 <jgarzik> BlueMatt: Not really. That was the IRC consensus: if you are going to do it, it's better than unspendable addresses
397 2013-06-05 11:47:35 <BlueMatt> sipa: well, at a minimum OP_RETURN should come out the same version as payment protocol, or one later
398 2013-06-05 11:47:50 <BlueMatt> otherwise it means people dont adopt payment protocol and use OP_RETURN because its the path of least resistance
399 2013-06-05 11:47:52 <jgarzik> BlueMatt: The choice is OP_RETURN, one per TX or OP_DROP, one per txout
400 2013-06-05 11:48:02 <jgarzik> BlueMatt: op_return is provably prunable
401 2013-06-05 11:48:08 <TD> i'm hoping gavin will return to the payment protocol work soon. he seems to have made a big pile of changes recently that deleted my review comments, but i didn't figure out yet if they were actually addressed.
402 2013-06-05 11:48:10 <BlueMatt> no, no, we should absolutely include it
403 2013-06-05 11:48:12 <TD> as i no longer remember what they were :)
404 2013-06-05 11:48:18 <BlueMatt> I wasnt disagreeing on it in general
405 2013-06-05 11:48:30 <BlueMatt> but it more specifically that bitpay shouldnt be using it :p
406 2013-06-05 11:48:39 <BlueMatt> <jgarzik> TD, attaching metadata to transactions is thought useful for many purposes
407 2013-06-05 11:48:54 <jgarzik> BitPay is also very interested in escrow transactions and multi-sig
408 2013-06-05 11:49:06 <jgarzik> bigger merchants are going to want better security for spending
409 2013-06-05 11:49:22 <BlueMatt> if bitpay starts using OP_RETURN to publish data, I will blame jgarzik
410 2013-06-05 11:50:51 <jgarzik> a while ago, I mentioned wanting to write a simple python tool that interacts with bitcoind's JSON-RPC API, and provides a simple UI for advanced or esoteric transaction building, such as collecting signatures for multi-sig
411 2013-06-05 11:51:26 <jgarzik> Looks like BitPay is interested in that, though, in node.js rather than python
412 2013-06-05 11:51:31 <jgarzik> so time to learn a new language ;p
413 2013-06-05 11:51:47 <lianj> BlueMatt: doesn't OP_RETURN invalidate a script anyway?
414 2013-06-05 11:52:52 <CodeShark> jgarzik: rebase complete
415 2013-06-05 11:53:07 <jgarzik> CodeShark, awesome :)
416 2013-06-05 11:53:09 <Vinnie_win_j> CodeShark: I've been following your work, you've been doing some really great stuff keep it up!
417 2013-06-05 11:53:17 <jgarzik> CodeShark, one small step on the road to a cleaner codebase
418 2013-06-05 11:53:20 <CodeShark> heya, Vinnie :)
419 2013-06-05 11:53:21 <jgarzik> which we sorely need
420 2013-06-05 11:53:34 <grau_> jgarzik: is there a page explaining what the OP_RETURN change is?
421 2013-06-05 11:53:36 <Vinnie_win_j> jgarzik: goto cleanCode;
422 2013-06-05 11:54:12 <BlueMatt> lianj: yes, thats what "proveably pruneable" means
423 2013-06-05 11:54:50 <jgarzik> grau_, the pull request. Summary: makes a new transaction template standard: one and only one output may be OP_RETURN<data>, where data is <= 80 bytes in length
424 2013-06-05 11:54:51 <lianj> BlueMatt: ah sorry didn't read the other backlog
425 2013-06-05 11:55:31 <jgarzik> The pull request: https://github.com/bitcoin/bitcoin/pull/2738
426 2013-06-05 11:55:43 <jgarzik> grau_, ^
427 2013-06-05 11:55:54 <jgarzik> Vinnie_win_j, hehe
428 2013-06-05 11:56:16 <TD> jgarzik: maybe you can help out with code review too
429 2013-06-05 11:56:22 <CodeShark> : goto CodeShark;
430 2013-06-05 11:56:23 <grau_> jgarzik: thanks. Any discussion on what this is for or review?
431 2013-06-05 11:56:29 <CodeShark> stack overflow
432 2013-06-05 11:56:29 <Vinnie_win_j> Please...just Vinnie_win...damn NICKSERV
433 2013-06-05 11:56:56 <jgarzik> grau_, long running discussion about metadata, timestamping, etc.
434 2013-06-05 11:57:03 <jgarzik> (it's worth reviewing here)
435 2013-06-05 11:57:14 <jgarzik> grau_, people are currently putting data into unspendable addresses
436 2013-06-05 11:57:27 <jgarzik> grau_, separately, there are many uses for attaching a hash or two to a transaction
437 2013-06-05 11:58:13 <sipa> ^ +1
438 2013-06-05 11:58:13 <sipa> jgarzik: what BlueMatt means (i think) is that for many use cases it's not actually necessary to attach any data to transactions, but that will only be convenient with a payment protocol
439 2013-06-05 11:58:13 <TD> but it's still a simple scalability win
440 2013-06-05 11:58:13 <TD> implementation cost < potential benefit
441 2013-06-05 11:58:13 <TD> payment protocol will solve poverty and war, but it's also more effort :-)
442 2013-06-05 11:58:13 <TD> yes, sure
443 2013-06-05 11:58:16 <jgarzik> grau_, the current proposals are: (1) per txout, permit OP_DROP<data> as a standard transaction, or (2) one per transaction, permit an additional trout OP_RETURN<data>
444 2013-06-05 11:58:41 <jgarzik> either change is simply making a new transaction template standard
445 2013-06-05 11:59:05 <grau_> thanks
446 2013-06-05 11:59:22 <jgarzik> er, txout
447 2013-06-05 11:59:24 <jgarzik> not trout
448 2013-06-05 11:59:29 <jgarzik> ACTION kicks OSX autocorrect
449 2013-06-05 11:59:33 <CodeShark> I'd like to use bitcoin to send trout
450 2013-06-05 11:59:45 <BlueMatt> well in any case, as long as payment protocol gets merged in 0.9, my point is that I'd prefer to not see OP_RETURN before then
451 2013-06-05 11:59:47 <jgarzik> my transaction has 990 trouts! :)
452 2013-06-05 12:00:07 <TD> lol. i hate OS X autocorrect
453 2013-06-05 12:00:17 <TD> BlueMatt: yeah i doubt we'll see bitpay using it for messages or anything like that
454 2013-06-05 12:00:18 <BlueMatt> a desktop os...with autocorrect.......
455 2013-06-05 12:00:23 <CodeShark> just turn it off :)
456 2013-06-05 12:00:24 <helo> does gavin not feel that OP_RETURN is devaluing the payment protocol?
457 2013-06-05 12:00:31 <TD> they aren't really related
458 2013-06-05 12:00:42 <jgarzik> BitPay is all about bitcoin-the-currency
459 2013-06-05 12:00:54 <jgarzik> little interest in bitcoin-as-shitty-messaging-platform :)
460 2013-06-05 12:00:59 <TD> jgarzik: i think things like multisig aren't features themselves, they're components of features that need to be part of higher level protocols.
461 2013-06-05 12:01:02 <TD> like you say, escrow
462 2013-06-05 12:01:08 <TD> but do you really mean, dispute mediation? they're not the same
463 2013-06-05 12:01:48 <jgarzik> TD, mostly higher level things that employ multi-sig. ex.: requiring 3-of-5 managers at a firm holding lots of bitcoins to sign, before spending
464 2013-06-05 12:02:08 <TD> ok. so group wallets, for instance
465 2013-06-05 12:02:11 <jgarzik> "bitcoin storage" -- reliably and securely storing $millions worth of bitcoins -- is becoming an issue
466 2013-06-05 12:02:14 <jgarzik> TD, yep
467 2013-06-05 12:02:14 <TD> that's the kind of thing that needs some UI design first
468 2013-06-05 12:02:19 <jgarzik> yep
469 2013-06-05 12:02:29 <jgarzik> TD, it's mostly UI work, not low level work, agreed
470 2013-06-05 12:02:51 <jgarzik> "partial transaction support" -- most wallets have little or not support for passing around incomplete transactions, signing them, etc.
471 2013-06-05 12:03:08 <jgarzik> Armory is a lot further along in that regard, than others
472 2013-06-05 12:03:08 <TD> yeah. i'm going to write some documentation on how to do that at the api level with bitcoinj soon
473 2013-06-05 12:03:12 <TD> as it's a common question
474 2013-06-05 12:03:13 <TD> yeah
475 2013-06-05 12:03:42 <sipa> TD: what do you think is correct behaviour when a payment request is processed, but the payment_uri can't be reached?
476 2013-06-05 12:03:46 <grau_> any output with OP_RETURN will be un-spendable, right? Should that then not rather be 0 output.
477 2013-06-05 12:04:15 <jgarzik> grau_, provably unspendable, yes
478 2013-06-05 12:04:20 <jgarzik> grau_, thus, provably prunable
479 2013-06-05 12:04:37 <grau_> thus wasted forever.
480 2013-06-05 12:04:42 <jgarzik> grau_, I cannot parse your "should that then?" question
481 2013-06-05 12:05:04 <grau_> I mean if the purpose is the message only why spend BTC with it.
482 2013-06-05 12:05:05 <sipa> grau_: provably unspendable == don't need to be stored at all
483 2013-06-05 12:05:17 <TD> grau_: can be for fees
484 2013-06-05 12:05:25 <jgarzik> grau_, yes, but less so than currently methods (unspendable addresses, bloating UTXO forever), never needs to be stored in UTXO
485 2013-06-05 12:05:33 <jgarzik> *current
486 2013-06-05 12:07:23 <CodeShark> I believe sooner or later there will have to be a way to rid the UTXO set of bloat
487 2013-06-05 12:07:29 <CodeShark> forcibly if necessary
488 2013-06-05 12:07:33 <TD> ACTION shrugs
489 2013-06-05 12:07:41 <TD> wallets that auto-defragment is the next step
490 2013-06-05 12:07:47 <TD> but a few hundred megs in a database isn't going to kill anyone.
491 2013-06-05 12:08:03 <TD> the 0.8.2 fee changes should stop it bloating up by too much more, i'd hope. the payment protocol, once deployed, even more.
492 2013-06-05 12:08:15 <sipa> agree
493 2013-06-05 12:08:44 <grau_> TD: you mean if provably un-spendable then it can enter the coinbase?
494 2013-06-05 12:09:03 <sipa> ... what does the coinbase have to do with anything?
495 2013-06-05 12:09:08 <jgarzik> ACTION wonders, too
496 2013-06-05 12:09:18 <TD> it was a reply to my comment, which upon being revisited, actually made no sense
497 2013-06-05 12:09:20 <sipa> ah, you mean claim as fee?
498 2013-06-05 12:09:23 <CodeShark> perhaps grau is talking about some demurrage scheme
499 2013-06-05 12:09:31 <sipa> that'd be a hard fork
500 2013-06-05 12:09:39 <TD> grau_: you're right, i'm not sure we should allow destruction of money via OP_RETURN outputs. but jgarzik's patch doesn't allow it
501 2013-06-05 12:09:41 <TD> i think
502 2013-06-05 12:09:45 <grau_> I mean if it is an unspeandable output, then it could be included as fee into coinbase
503 2013-06-05 12:10:55 <jgarzik> my patch just makes one transaction type nonstandard -> standard
504 2013-06-05 12:11:29 <CodeShark> I sorta like the idea of a fee for keeping unprunable data in the UTXO set based on the size of the data, the size of the UTXO set, and the length of time the data remains unprunable
505 2013-06-05 12:11:30 <grau_> jgarzik: should it not be standard only in conjunction with zero output?
506 2013-06-05 12:11:50 <CodeShark> if the fee exceeds the output, it gets automatically pruned
507 2013-06-05 12:12:46 <jgarzik> grau_, that's a protocol change
508 2013-06-05 12:12:47 <jgarzik> grau_, not contemplating that
509 2013-06-05 12:13:02 <CodeShark> rather than devaluing the coin (i.e. fee proportional to the amount of coin), the fee should be based on the amount of data we need to keep around
510 2013-06-05 12:13:12 <grau_> zero output can be mined right? It is only the relay that would change.
511 2013-06-05 12:13:34 <CodeShark> so effectively you "rent" UTXO space from the network
512 2013-06-05 12:14:00 <The_Fly> interesting...
513 2013-06-05 12:18:25 <CodeShark> and you buy block chain space
514 2013-06-05 12:18:35 <CodeShark> via fees, like we do now
515 2013-06-05 12:21:21 <t7> CodeShark: sounds sensible
516 2013-06-05 12:24:16 <helo> will there be a MAX_UTXO_SIZE to make it scarce?
517 2013-06-05 12:24:43 <jgarzik> grau_, lost bitcoins are not a problem for bitcoin
518 2013-06-05 12:24:52 <jgarzik> grau_, if people want to throw away bitcoins, that's just fine
519 2013-06-05 12:24:58 <jgarzik> helo, no
520 2013-06-05 12:26:02 <grau_> jgarzik: I know it is not a problem. Just do not like it.
521 2013-06-05 12:26:05 <CodeShark> UTXO rent could be effectively a relay fee
522 2013-06-05 12:26:12 <CodeShark> or hmmm
523 2013-06-05 12:26:17 <CodeShark> not sure how that could work
524 2013-06-05 12:27:35 <CodeShark> there's gotta be a way to make it work, though :)
525 2013-06-05 12:29:45 <jgarzik_> ACTION looks at jgarzik suspiciously
526 2013-06-05 12:30:23 <CodeShark> a rule which states that the sum of outputs of a transaction must never exceed the inputs minus some number calculated from 1) the amount of space taken by the outputs claimed, 2) the number of blocks separating the block that creates the output from the block that claims it, 3) the total UTXO size at the time it is claimed - and if claiming an output ever costs the same amount or more than the value, it becomes in
527 2013-06-05 12:30:23 <CodeShark> valid
528 2013-06-05 12:30:28 <CodeShark> *invalid
529 2013-06-05 12:31:57 <CodeShark> but there are other issues here - like reorgs and drastic sudden changes in UTXO size
530 2013-06-05 12:32:14 <CodeShark> which make it hard to just categorically consider a UTXO forever invalid