1 2013-02-22 00:42:27 <etotheipi_> bitcoin devs:   nice f***ing job with 0.8!  I can't believe how fast I just sync'd the blockchain from scratch!
  2 2013-02-22 00:44:45 <doublec> Luke-Jr: different vince: https://bitcointalk.org/index.php?topic=6017.0
  3 2013-02-22 01:11:23 <gmaxwell> etotheipi_: hurrah.
  4 2013-02-22 01:11:55 <gmaxwell> etotheipi_: It was mostly sipa's work??? but I'm still personally happy to hear responses like that (esp since mostly you just hear the flaws)
  5 2013-02-22 01:12:09 <etotheipi_> gmaxwell: yeah... I know the feeling
  6 2013-02-22 01:12:25 <etotheipi_> 90% of people are happy, but 90% of what you hear is bug reports and complaints
  7 2013-02-22 01:13:24 <etotheipi_> gmaxwell:  is it understood what is bottlenecking the sync-from-scratch speed?  I wasn't paying attention the other day when you mentioned it
  8 2013-02-22 01:13:37 <etotheipi_> I ask, because I sync'd competely in about 3-4 hours
  9 2013-02-22 01:13:44 <etotheipi_> but it's on a pretty fast SSD
 10 2013-02-22 01:16:36 <gmaxwell> etotheipi_: 'network' now on most systems unless you sync from a file.  I mean network in a very broad sense.
 11 2013-02-22 01:18:08 <gmaxwell> Network means: you're limited by your bandwidth, pulling from a single peer, who may not be very fast, sequentially with round trip serialization delays every megabyte or so, and (for more recent blocks) with validation delays interleaved.
 12 2013-02-22 01:18:56 <gmaxwell> when network isn't a factor (loadblock, bootstrap, or -connect from a peer on a gigabit lan) ECDSA is the primary bottleneck.
 13 2013-02-22 01:19:42 <gmaxwell> Our ecdsa is threaded now, but only within block, and doesn't scale super well beyond 4-8 cores.
 14 2013-02-22 01:30:00 <etotheipi_> gmaxwell: what do you know about tty logins, say via serial ports?
 15 2013-02-22 01:30:39 <etotheipi_> I'm not all that familiar with them, but I am told I should be able to detect the system configurations that allow tty logins, and then disable them
 16 2013-02-22 01:33:35 <gmaxwell> etotheipi_: look in inittab. see if there are gettys.
 17 2013-02-22 01:33:44 <gmaxwell> At least on some systems??? depends on the OS.
 18 2013-02-22 01:35:03 <etotheipi_> gah, newer Ubuntus don't have inittab
 19 2013-02-22 01:38:49 <gmaxwell> etotheipi_: look in /etc/init for scripts invoking /sbin/getty
 20 2013-02-22 01:39:36 <Diablo-D3> gmaxwell: the correct line is "in a row?!"
 21 2013-02-22 01:40:44 <gmaxwell> Yes, I've seen clerks but you got the number wrong.
 22 2013-02-22 01:43:40 <gmaxwell> ;;ticker
 23 2013-02-22 01:43:41 <gribble> BTCUSD ticker | Best bid: 30.25000, Best ask: 30.47000, Bid-ask spread: 0.22000, Last trade: 30.47000, 24 hour volume: 46215.21407307, 24 hour low: 29.31100, 24 hour high: 30.65000, 24 hour vwap: 29.78242
 24 2013-02-22 01:53:54 <sipa> etotheipi_: thanks :P
 25 2013-02-22 01:54:46 <sipa> 00:58:22 < HM> cool someone on github has created a self balancing rb-merkle-tree   <-  amiller?
 26 2013-02-22 02:01:07 <sipa> any interesting discussion i missed?
 27 2013-02-22 02:01:14 <Diablo-D3> wait
 28 2013-02-22 02:01:20 <Diablo-D3> HM: I want the url of that
 29 2013-02-22 02:02:20 <sipa> etotheipi_: actually, i think the pre-checkpoint part of the chain should be doable in 10 minutes or so
 30 2013-02-22 02:02:30 <sipa> so there's still a lot of room for improvement :p
 31 2013-02-22 02:02:56 <gmaxwell> Jeff's all in memory no script validation stuff was that fast.
 32 2013-02-22 02:05:11 <HM> sipa: yeah amiller
 33 2013-02-22 02:05:36 <HM> Diablo-D3: google amiller + merkle + github + bitcoin
 34 2013-02-22 02:05:52 <Diablo-D3> oh, its for bitcoin?
 35 2013-02-22 02:06:04 <HM> not really
 36 2013-02-22 02:06:09 <HM> he just mentions bitcoin in the readme
 37 2013-02-22 02:06:18 <HM> i lost interest pretty quickly
 38 2013-02-22 02:07:13 <HM> i hate red black trees
 39 2013-02-22 02:07:43 <HM> also you would think with a pseudo random hash value that  a regular binary tree would suffice
 40 2013-02-22 02:07:59 <sipa> the problem is an attacker can skew the tree in that case
 41 2013-02-22 02:08:04 <sipa> *everyone's* tree
 42 2013-02-22 02:08:41 <HM> *shrug*, i'm not really aware of how the merkle tree is used in bitcoin
 43 2013-02-22 02:10:43 <HM> i may have to read satoshis paper again soon
 44 2013-02-22 02:10:56 <HM> i read it last over a year ago
 45 2013-02-22 02:13:05 <sipa> HM: before BIP37 it was actually not used at all
 46 2013-02-22 02:13:47 <sipa> the merkle root hash in the block header was calculated as the *tudum* root of the merkle hash tree of transaction hashes
 47 2013-02-22 02:18:43 <HM> so the merkle tree lets you verify a tx is part of a block without having the entire block
 48 2013-02-22 02:19:51 <sipa> yeah
 49 2013-02-22 02:19:57 <sipa> assume 8 transactions
 50 2013-02-22 02:20:23 <sipa> so the merkle root is h(h(h(a,b),h(c,d)),h(h(e,f),h(g,h)))
 51 2013-02-22 02:20:49 <sipa> if i want to prove to you that e belongs to the block, and you already have the block header
 52 2013-02-22 02:21:29 <HM> but for t transactions you still have t/2 hashes?
 53 2013-02-22 02:21:46 <sipa> where?
 54 2013-02-22 02:21:56 <HM> what good is the root + e
 55 2013-02-22 02:21:59 <HM> you don't have f
 56 2013-02-22 02:22:04 <HM> or h(c,d)
 57 2013-02-22 02:22:07 <HM> etc
 58 2013-02-22 02:22:28 <sipa> in addition to e itself, i can give you f (so you can calculate h(e,f)), give you h(g,h), so you can calculate h(h(e,f),h(g,h)), and i give you h(h(a,b),h(c,d)), you can calculate the root again
 59 2013-02-22 02:22:55 <sipa> so i need to give you 3 hashes (in addition to the tx itself) to prove it belongs to the block (for which you already have the header)
 60 2013-02-22 02:23:05 <HM> right, so it's logarithmic
 61 2013-02-22 02:23:09 <sipa> indeed
 62 2013-02-22 02:23:21 <HM> makes sense, but how is this used at the protocol level?
 63 2013-02-22 02:23:29 <sipa> BIP37 uses it
 64 2013-02-22 02:23:34 <sipa> for sending filtered blocks
 65 2013-02-22 02:23:35 <HM> and that only works within a single block?
 66 2013-02-22 02:23:39 <sipa> yes
 67 2013-02-22 02:24:24 <HM> so i can store all the block headers and then ask a remote server for the block contain a txid + the hashes to prove it
 68 2013-02-22 02:24:36 <sipa> yup
 69 2013-02-22 02:25:22 <sipa> unfortunately, you can't ask it to prove that it didn't leave out a tx you wanted
 70 2013-02-22 02:25:36 <HM> leave it out?
 71 2013-02-22 02:25:50 <sipa> yeah, you ask for transactions matching some criterion
 72 2013-02-22 02:25:51 <HM> you mean it may have brute forced the hashes for that block independently?
 73 2013-02-22 02:26:01 <sipa> the server can say "nope, no matches!"
 74 2013-02-22 02:26:09 <HM> right
 75 2013-02-22 02:27:45 <HM> there was a debate earlier about block sizes sipa
 76 2013-02-22 02:28:21 <HM> i suppose block sizes can scale quite well now you have a functioning block filter
 77 2013-02-22 02:31:07 <sipa> client side it's much less of an issue
 78 2013-02-22 02:31:11 <gmaxwell> HM: that doesn't actually help??? you can't verify a block you recieved a filtered copy of.
 79 2013-02-22 02:31:22 <sipa> but the block size debate is about nodes mining & validating
 80 2013-02-22 02:32:06 <HM> gmaxwell: no but doubling the blocksize just means adding a hash to the merkle path
 81 2013-02-22 02:32:13 <HM> so for clients it scales
 82 2013-02-22 02:32:30 <HM> header only clients
 83 2013-02-22 02:32:31 <sipa> sure, they're cheap and don't care about the big world
 84 2013-02-22 02:32:49 <sipa> but that's the problem: the big world could be toying with them :)
 85 2013-02-22 02:33:22 <gmaxwell> HM: yea sure, but if thats how it works??? where everyone just trusts something and doesn't validate, the incentives to be honest go away. If you're going to trust??? paypal is a lot simpler and doesn't involve all this hashing stuff. :)
 86 2013-02-22 02:33:47 <gmaxwell> HM: thats where we go back to this tangent you didn't understand earlier about if the limit is gone, what incentive is there to validate.
 87 2013-02-22 02:34:09 <gmaxwell> HM: all the users would be forced by praticality to not actually validate??? and just get filtered blocks and trust that the validation was done.
 88 2013-02-22 02:34:14 <sipa> the incentive is the same, whether the limit is there or not
 89 2013-02-22 02:34:26 <sipa> it's just a lot more expensive
 90 2013-02-22 02:34:34 <HM> i don't see how block size makes one iota of difference, the other variables will counter it
 91 2013-02-22 02:34:42 <gmaxwell> HM: what other variables?
 92 2013-02-22 02:34:57 <HM> the economy wants X transactions in a day right
 93 2013-02-22 02:35:09 <HM> thats a constant, out of your control
 94 2013-02-22 02:35:13 <sipa> that will depend on the price of such transactions
 95 2013-02-22 02:35:19 <HM> that's true
 96 2013-02-22 02:35:25 <sipa> and the price of such transactions will depend on the security wanted for them
 97 2013-02-22 02:35:40 <HM> the current rule is 1 block every 10 minutes, as massaged by the difficultly
 98 2013-02-22 02:35:49 <HM> that's your goal
 99 2013-02-22 02:35:49 <sipa> so if there's a lot of space, that may be many low-security low-cost transactions
100 2013-02-22 02:36:01 <sipa> or few high-security high-cost transactions
101 2013-02-22 02:36:40 <sipa> for some value of high and low
102 2013-02-22 02:37:16 <sipa> except the latter allows the world (which doesn't get paid for it) to validate, and the former doesn't
103 2013-02-22 02:37:27 <sipa> or to a different extent at least
104 2013-02-22 02:37:49 <gmaxwell> HM: you seem to keep thinking the time between blocks is a free parameter? it's not. It's fixed by the system.
105 2013-02-22 02:38:00 <HM> yes exactly
106 2013-02-22 02:38:12 <HM> number of transactions per day = constant (or atleast outside your control)
107 2013-02-22 02:38:21 <sipa> ehhh i'm talking nonsense
108 2013-02-22 02:38:23 <HM> block rate = constant (set by adaptive difficulty)
109 2013-02-22 02:38:53 <HM> so the only variable left is block size
110 2013-02-22 02:39:01 <HM> and difficulty
111 2013-02-22 02:39:03 <sipa> and exchange rate
112 2013-02-22 02:39:07 <gmaxwell> Blocksize is fixed too.
113 2013-02-22 02:39:09 <sipa> and security needed
114 2013-02-22 02:39:14 <HM> at the moment it is yeah
115 2013-02-22 02:39:23 <HM> so changing the blocksize will change the difficultly
116 2013-02-22 02:39:29 <sipa> maybe
117 2013-02-22 02:39:36 <gmaxwell> HM: whats the formula for that?
118 2013-02-22 02:39:47 <HM> fewer blocks
119 2013-02-22 02:39:49 <HM> same block rate
120 2013-02-22 02:39:54 <sipa> ??
121 2013-02-22 02:40:02 <gmaxwell> changing the difficulty doesn't change the number of blocks!
122 2013-02-22 02:40:05 <gmaxwell> ugh.
123 2013-02-22 02:40:15 <HM> no, changing the block size changes the number of blocks
124 2013-02-22 02:40:20 <gmaxwell> There is some deep misunderstanding of bitcoin in your head. Lets find it.
125 2013-02-22 02:40:20 <sipa> ??
126 2013-02-22 02:40:35 <gmaxwell> HM: Do you know that a block can have no transactions? (well, none beyond the coinbase)
127 2013-02-22 02:40:37 <HM> 10000 transactions a day
128 2013-02-22 02:40:41 <HM> 100 transactions a block
129 2013-02-22 02:40:41 <sipa> if the block rate is fixed, how can the number of blocks change?
130 2013-02-22 02:40:53 <HM> 100 blocks  a day
131 2013-02-22 02:40:58 <sipa> 144
132 2013-02-22 02:41:12 <HM> yes, i was using round numbers
133 2013-02-22 02:41:36 <sipa> so, 144 blocks per day
134 2013-02-22 02:41:40 <sipa> this won't change
135 2013-02-22 02:41:44 <HM> yep
136 2013-02-22 02:41:52 <HM> but the blocks will be bigger if you allow them to be bigger
137 2013-02-22 02:42:01 <sipa> so what do you mean by "changes the number of blocks"
138 2013-02-22 02:42:13 <HM> hmm
139 2013-02-22 02:43:57 <gmaxwell> 307 txn per block on average in the last 1000 blocks, FWIW.
140 2013-02-22 02:43:57 <HM> i see what you mean
141 2013-02-22 02:44:05 <HM> block size also doesn't really change pow difficulty does it? because adding transactions is relatively cheap
142 2013-02-22 02:44:13 <sipa> indeed
143 2013-02-22 02:44:18 <gmaxwell> Not the way you were thinking at least.
144 2013-02-22 02:44:31 <HM> errm, but difficulty i mean for the cpu, not the actual difficulty
145 2013-02-22 02:44:37 <HM> by*
146 2013-02-22 02:44:42 <sipa> still, indeed
147 2013-02-22 02:44:47 <sipa> (i understood you)
148 2013-02-22 02:45:04 <sipa> it doesn't make blocks harder to mine
149 2013-02-22 02:45:28 <gmaxwell> also, if you expect difficulty to come from the raw txn handling instead of POW then miners could get an advantage by not performing it.
150 2013-02-22 02:45:30 <sipa> except the transactions need a) to be validated (but that happens asynchronously to the mining process) and b) transmitted
151 2013-02-22 02:45:32 <HM> because they work on the root hash, right
152 2013-02-22 02:46:14 <gmaxwell> HM: right. POW and txn processing are totally seperate.
153 2013-02-22 02:46:14 <HM> this is what i don't get though. the incentive for miners is to mine the most lucrative transactions with the highest fees
154 2013-02-22 02:46:42 <gmaxwell> HM: that incentive only exists if they can't just mine all with any fee at all.
155 2013-02-22 02:47:02 <HM> you mean the block reward?
156 2013-02-22 02:47:10 <gmaxwell> (well, ignoring that there is some per txn marginal cost, but it's very low)
157 2013-02-22 02:47:31 <HM> in the future it'll all be about fees
158 2013-02-22 02:47:37 <sipa> maybe
159 2013-02-22 02:47:46 <gmaxwell> HM: no??? I mean you say that miners "is to mine the most lucrative transactions with the highest fees" but if they can fit all transactions, they'll make more income by taking all transactions.
160 2013-02-22 02:48:09 <gmaxwell> if they have room and leave out some transactions, then some later miner will snatch them up.
161 2013-02-22 02:48:27 <HM> yep, and that relates to block size
162 2013-02-22 02:48:37 <HM> (maximum block size)
163 2013-02-22 02:48:41 <sipa> yup
164 2013-02-22 02:49:07 <gmaxwell> Assuming miners don't form a chain external conspiracy to exclude some transactions. ... but even doing that is hard because its hard to enforce except by orphaning blocks... and then you have to have some way of getting a consensus over what the rules are.
165 2013-02-22 02:49:14 <gmaxwell> HM: right.
166 2013-02-22 02:49:52 <HM> right, so the way i see it. when block rewards go extinct, miners will start preferring transactions from people they know are 'good for it'
167 2013-02-22 02:50:08 <HM> otherwise they risk wasting work on potentially dud transactions
168 2013-02-22 02:50:27 <HM> does that not make sense?
169 2013-02-22 02:50:51 <gmaxwell> good for it? dud?
170 2013-02-22 02:51:14 <HM> what's to stop me creating a transaction that leaves a 100 BTC fee and sending it to a miner right now
171 2013-02-22 02:51:22 <gmaxwell> Nothing, it happens.
172 2013-02-22 02:51:51 <HM> so if there's only room for 1000 transactions in a block and i flood said miner with such transactions?
173 2013-02-22 02:51:56 <HM> and there are no block rewards
174 2013-02-22 02:52:34 <gmaxwell> HM: he'd take 1000 of them??? unless he other txn that were even higher fees per space consumed.
175 2013-02-22 02:52:43 <sipa> then he'll be rich when he mines them, and you'll be poor
176 2013-02-22 02:52:53 <gmaxwell> yea, whats the question? :)
177 2013-02-22 02:52:54 <HM> how so?
178 2013-02-22 02:52:56 <HM> they might not be valid
179 2013-02-22 02:53:05 <sipa> he won't accept invalid ones
180 2013-02-22 02:53:16 <HM> so miners verify all transactions
181 2013-02-22 02:53:20 <sipa> of course
182 2013-02-22 02:53:24 <gmaxwell> all bitcoin nodes verify all transactions.
183 2013-02-22 02:53:24 <HM> gmaxwell said otherwise earlier today
184 2013-02-22 02:53:24 <sipa> that's their purpose
185 2013-02-22 02:53:42 <sipa> light clients don't verify
186 2013-02-22 02:53:46 <gmaxwell> HM: ::sigh:: as I said earlier you were confused about what we were talking about, and I was confused about what you understood.
187 2013-02-22 02:53:46 <sipa> full clients do
188 2013-02-22 02:54:11 <sipa> and miners are certainly full ones, or they'll risk spending work on blocks that other nodes don't accept
189 2013-02-22 02:54:14 <gmaxwell> HM: what we were talking about was anticipated end results if there is no limit.
190 2013-02-22 02:54:52 <gmaxwell> HM: the argument there is that the nash equlibrium (the state at which no one can get an advantage over competition) is when all fees are 1e-8, and the blocks are absolutely enormous, and the difficulty is 1 and all the effort is spent processing blocks and none on POW.
191 2013-02-22 02:54:58 <sipa> yes, in a situation where there are just a few miners left, and they are the only ones able to verify transactions, they don't have to anymore
192 2013-02-22 02:55:05 <sipa> as noone will notice if they cheat
193 2013-02-22 02:55:18 <gmaxwell> but thats not a concern if the block size is limited by rule.
194 2013-02-22 02:55:26 <sipa> and that is when bitcoin becomes paypal
195 2013-02-22 02:55:47 <HM> oh i see
196 2013-02-22 02:56:03 <HM> so block size grows huge which cripples most miners except the big iron
197 2013-02-22 02:56:06 <sipa> so the purpose of keeping blocks small, is keeping the ability for the community to verify miners
198 2013-02-22 02:56:09 <HM> the difficulty falls
199 2013-02-22 02:56:14 <HM> and they essentially dominate
200 2013-02-22 02:56:21 <sipa> even worse
201 2013-02-22 02:56:34 <HM> worse?
202 2013-02-22 02:56:39 <gmaxwell> HM: and it cripples all the _non-miners_ first, whos validation currently helps keep the miners honest.  They get crippled first because unlike miners they don't get paid for their work.
203 2013-02-22 02:56:47 <sipa> the fact that this end result is possible, gives big miners (in theory) an incentive to make blocks as large as possible
204 2013-02-22 02:56:59 <sipa> to push competitors and other non-mining validation nodes out
205 2013-02-22 02:57:14 <jgarzik> ACTION deletes another "you are a bitcoin developer; you must have so much money you can give it away for free!" email
206 2013-02-22 02:57:22 <HM> how do big blocks screw up non-mining validators?
207 2013-02-22 02:57:33 <sipa> HM: because they're expensive to validate
208 2013-02-22 02:57:38 <Diablo-D3> ACTION deletes another "you are the author of diablominer; you must have so much money you can give it away for free!" email
209 2013-02-22 02:57:48 <sipa> jgarzik: weird, never got one of those
210 2013-02-22 02:57:49 <HM> by validate you mean validate all the tx's right?
211 2013-02-22 02:57:52 <sipa> yes
212 2013-02-22 02:57:56 <sipa> though i've seen very weird ones :)
213 2013-02-22 02:58:02 <jgarzik> hehe
214 2013-02-22 02:58:06 <HM> but if you're a full node, you do that on all tx's regardless of block size
215 2013-02-22 02:58:07 <gmaxwell> HM: if the next block is 1GB, how could you participate in its validation??? it'll be burried in the chain before you could decide if it was good or not?
216 2013-02-22 02:58:08 <jgarzik> I'm sure Gavin gets hit with a bunch
217 2013-02-22 02:58:25 <HM> hmm
218 2013-02-22 02:58:34 <gmaxwell> HM: you do! if you can. Not hard when blocks are 1MB or less. Not possible if blocks are 1GB unless you have a big cluster. :)
219 2013-02-22 02:58:42 <sipa> HM: yes, so at some size, it becomes impossible for a casual full node to validate
220 2013-02-22 02:58:53 <sipa> that size may be large
221 2013-02-22 02:59:00 <HM> but 1000 blocks of 1000 tx's still requires 1 million validations
222 2013-02-22 02:59:07 <HM> as 1 block with 1 million
223 2013-02-22 02:59:14 <sipa> the block rate is fixed
224 2013-02-22 02:59:19 <gmaxwell> HM: yes, but none of this changes the blockrate.
225 2013-02-22 02:59:22 <sipa> so just look at it per unit of time
226 2013-02-22 02:59:42 <HM> oh dear
227 2013-02-22 02:59:46 <sipa> but there is some limit, where those you get paid for doing so (miners) have reason to invest in validation, while all others (economically) don't
228 2013-02-22 02:59:56 <HM> so change the damn block rate as well? :S
229 2013-02-22 02:59:57 <gmaxwell> jgarzik: did you get one about an old man in a wheelchair?
230 2013-02-22 03:00:10 <gmaxwell> HM: that wouldn't make anyone happy who wants to change the blocksize.
231 2013-02-22 03:00:10 <sipa> HM: the reason for the block rate is the speed of light
232 2013-02-22 03:00:21 <sipa> HM: it doesn't change a thing otherwise
233 2013-02-22 03:00:22 <jgarzik> gmaxwell: Yeah; I'm meeting the group in France
234 2013-02-22 03:00:28 <jgarzik> gmaxwell: we disband at the RV point
235 2013-02-22 03:00:46 <gmaxwell> jgarzik: The eagle hashes on tuesday.
236 2013-02-22 03:00:46 <sipa> HM: it doesn't matter at all
237 2013-02-22 03:01:03 <HM> well 1 GB every hour is better than 1 GB every 10 mintues
238 2013-02-22 03:01:04 <sipa> what matters in the rate of transactions that end up in the chain
239 2013-02-22 03:01:18 <sipa> whether that's few large blocks or many small ones
240 2013-02-22 03:01:34 <sipa> there is just some rate of transactions that casual validators can't keep up with
241 2013-02-22 03:01:43 <gmaxwell> HM: the argument for uncapping blocks is to process more transactions. ... rather than letting the rate of transactions get naturally ratelimited by high fees that come from competing for scarce block space.
242 2013-02-22 03:02:09 <gmaxwell> if you slow blocks to keep the total txn count the same then that goal isn't accomplished.
243 2013-02-22 03:02:10 <HM> so what you're saying is, the free market for transaction fees isn't going to work
244 2013-02-22 03:02:13 <jgarzik> gmaxwell: (I was referencing http://www.imdb.com/title/tt0122690/ FWIW :_)
245 2013-02-22 03:02:15 <sipa> maybe
246 2013-02-22 03:02:32 <sipa> ACTION likes that word
247 2013-02-22 03:02:33 <gmaxwell> HM: it should work totally fine, so long as block space is scarce. If blockspace is not scarce, I don't know how it could work.
248 2013-02-22 03:02:52 <HM> but block space = transaction space
249 2013-02-22 03:02:57 <sipa> yes
250 2013-02-22 03:03:02 <HM> and we all want to send granny petty cash
251 2013-02-22 03:03:12 <HM> so we're boned
252 2013-02-22 03:03:15 <sipa> but do we need to do it in-chain?
253 2013-02-22 03:03:22 <gmaxwell> HM: No??? because you're not forced to do it in-chain.
254 2013-02-22 03:03:47 <gmaxwell> Granny probably would be happier to not wait an hour for a confirmation before she can respend it, for example.
255 2013-02-22 03:03:51 <HM> right, so you end up with bitcoin as an inter-bank transfer service
256 2013-02-22 03:03:59 <gmaxwell> So there are reasons totally seperate from scale.
257 2013-02-22 03:04:08 <sipa> HM: yes, but *verifiable* banks
258 2013-02-22 03:04:17 <sipa> and everyone can become their own bank
259 2013-02-22 03:04:19 <HM> verifiable, as long as you can keep up
260 2013-02-22 03:04:40 <gmaxwell> HM: well, or serving the purpose of checks and wiretransfers instead of credit cards. And as sipa says, cryptographically verifyable banks that can not cheat without it being obvious to all.
261 2013-02-22 03:04:51 <HM> wait what. how does everyone become their own bank if it's out of a chain.
262 2013-02-22 03:04:57 <sipa> simplified: if the block space if very large, everyone will be their own bank, but nobody will be able to validate it (except a central big miner/clearinghouse)
263 2013-02-22 03:05:02 <gmaxwell> HM: you don't have to keep up with all the banks in the world??? only the ones you use.
264 2013-02-22 03:05:13 <sipa> if the block space is very large, there will be few banks, but everyone can validate them
265 2013-02-22 03:05:36 <sipa> for very extreme values of small and large
266 2013-02-22 03:05:50 <HM> validate them using merkle you mean
267 2013-02-22 03:05:54 <HM> and block headers
268 2013-02-22 03:05:58 <sipa> no, fully validate
269 2013-02-22 03:06:08 <sipa> verifying headers will always be cheap
270 2013-02-22 03:06:10 <gmaxwell> No, ??? completely. And know that there is no inflation, that all trades are asset backed, etc.
271 2013-02-22 03:06:16 <sipa> headers are 80 bytes per 10 minutes
272 2013-02-22 03:06:53 <HM> I'm lost
273 2013-02-22 03:06:56 <sipa> my abacus can keep up with that
274 2013-02-22 03:07:11 <sipa> HM: if blocks are small, it's obvious that they're easy to validate
275 2013-02-22 03:07:16 <jgarzik> "The reference to the "man in the wheelchair" is referencing the book "The Bourne Identity" (1980) by Robert Ludlum; not the 2002 movie. The Man In The Wheelchair was M. Chernak, a mercenary broker that Jason Bourne killed.
276 2013-02-22 03:07:17 <sipa> since they contain few transactions
277 2013-02-22 03:07:18 <jgarzik> huh
278 2013-02-22 03:07:28 <sipa> HM: agree?
279 2013-02-22 03:07:41 <HM> sure, take the transactions and validate them. O(n), n = number of trannies
280 2013-02-22 03:07:46 <sipa> bingo
281 2013-02-22 03:07:47 <HM> something like that
282 2013-02-22 03:08:08 <sipa> so small transactions = everyone can easily be a miner/validator
283 2013-02-22 03:08:20 <HM> small blocks
284 2013-02-22 03:08:37 <sipa> but there will be space for only few transactions, so it will be transactions with very high value, among a small number of players only
285 2013-02-22 03:08:39 <gmaxwell> (well, O(n*log(number of coins)) but if we deny 0 value coins the maximum number of coins has an upper bound of 21e14)
286 2013-02-22 03:08:46 <HM> so they have 10 minutes to validate n transactions in
287 2013-02-22 03:08:47 <sipa> = few banks
288 2013-02-22 03:08:53 <HM> otherwise they'll never keep up
289 2013-02-22 03:09:08 <sipa> all transactions happen off-chain, and only the big inter-bank transfers happen on the chain
290 2013-02-22 03:09:24 <sipa> and those can be validated by everyone
291 2013-02-22 03:09:32 <sipa> agree?
292 2013-02-22 03:09:53 <HM> yeah
293 2013-02-22 03:10:02 <sipa> so, now the opposite, if blocks are very large
294 2013-02-22 03:10:16 <sipa> then it means there are only a few players able to verify them fully
295 2013-02-22 03:10:18 <HM> clients can't process n transactions in 10 mintues
296 2013-02-22 03:10:21 <HM> cant; keep up
297 2013-02-22 03:10:30 <sipa> but everyone can create on-chain transactions
298 2013-02-22 03:10:37 <HM> it's problematic at both extremes then
299 2013-02-22 03:10:44 <sipa> but need to send them to one of the very few miners/clearinghouses
300 2013-02-22 03:10:47 <gmaxwell> sipa: to be fair, even with our current block sizes a 'big interbank transfer' might only be??? say $1000 in current value, and paying a $20 compariable fee.  Indiviguals may still be their own banks for savings and for large transaction purposes even in that model.
301 2013-02-22 03:11:00 <gmaxwell> (that was an aside, hm: don't let that derail you)
302 2013-02-22 03:11:00 <sipa> gmaxwell: i'm talking extremes
303 2013-02-22 03:11:23 <sipa> not saying what sizes those correspond to (they may indeed correspond to a block size even smaller than we have today)
304 2013-02-22 03:11:32 <gmaxwell> right. Fair enough.
305 2013-02-22 03:11:36 <HM> small blocks = few transactions = huge transactions = inter-bank
306 2013-02-22 03:11:50 <HM> huge blocks = many transactions = few miners/players = big banks
307 2013-02-22 03:11:54 <sipa> HM: so my opinion is that we should at least think about which compromise in between is acceptable
308 2013-02-22 03:12:01 <gmaxwell> for some sufficiently small value of huge and small.
309 2013-02-22 03:12:06 <sipa> centralized mining, or centralized banking
310 2013-02-22 03:12:23 <HM> what you need is a way to maximise the number of verifiers
311 2013-02-22 03:12:26 <HM> i propose socialism
312 2013-02-22 03:13:03 <sipa> well, if i think about it, trying to get the number of validators equal to the number of on-chain entities would seem nice in the middle between the two extremes
313 2013-02-22 03:13:11 <gmaxwell> sipa: though it should be pointed out that intra-bank doesn't imply fully-centeralized banks. For example, the banks could all be 5 party multsignature distributed entities.
314 2013-02-22 03:13:14 <HM> but you can't
315 2013-02-22 03:13:23 <HM> you can't prove the number of off-chain verifiers
316 2013-02-22 03:13:31 <HM> off-chain as in, unpaid
317 2013-02-22 03:13:31 <sipa> of course you can't
318 2013-02-22 03:13:55 <gmaxwell> sipa: well we can outright maximize validator by just minimizing validation cost. There is some cost level where people will validate if we make it a software default because they're too lazy to turn it off.
319 2013-02-22 03:14:00 <gmaxwell> er s/sipa/hm/
320 2013-02-22 03:14:19 <HM> hmm
321 2013-02-22 03:14:24 <sipa> gmaxwell: what did you think i tried to do the past months :p
322 2013-02-22 03:14:36 <gmaxwell> sipa: absolutely.
323 2013-02-22 03:14:46 <sipa> ACTION sleeps
324 2013-02-22 03:14:58 <HM> sipa: thank you for your help and patience
325 2013-02-22 03:15:00 <HM> sleep well
326 2013-02-22 03:15:15 <HM> gmaxwell: you too :)
327 2013-02-22 03:15:25 <gmaxwell> Mostly I think we're near the victory point for that for the current block size limits. IBD needs to get fixed... but I have no fear for there being an ample supply of validators under the current system rules.
328 2013-02-22 03:15:31 <gmaxwell> sipa: Goodnight.
329 2013-02-22 03:15:44 <HM> IBD?
330 2013-02-22 03:16:21 <gmaxwell> initial block download.
331 2013-02-22 03:16:36 <gmaxwell> Right now the system is _plenty_ fast, but the initial wait gets in your way.
332 2013-02-22 03:17:11 <gmaxwell> so we need to make it so validing the chain doesn't demand that you wait until it finishes before you can even use bitcoin.
333 2013-02-22 03:17:42 <gmaxwell> (because then some people will be irritated and opt out of validating by running software that doesn't make them wait)
334 2013-02-22 03:17:58 <HM> well any tx you want to verify could depend on blocks you don't have,
335 2013-02-22 03:18:08 <HM> whatever order you download them in you're boned
336 2013-02-22 03:18:21 <gmaxwell> HM: nah, you operate in client mode (SPV) until you've caught up.
337 2013-02-22 03:18:43 <HM> so why does it matter
338 2013-02-22 03:18:50 <gmaxwell> Why does what matter?
339 2013-02-22 03:18:54 <HM> the IBD
340 2013-02-22 03:19:12 <gmaxwell> Because it doesn't operate in client mode today. It needs to gain that functionality, then IBD won't matter.
341 2013-02-22 03:19:20 <HM> oh i see
342 2013-02-22 03:19:41 <gmaxwell> right now it does, and some people get a couple hour delay (to sync _years_ of data) and then give up and use a webwallet.
343 2013-02-22 03:20:24 <HM> your average joe doesn't like installing software
344 2013-02-22 03:20:39 <HM> just look at email client -> webmail over the last decade
345 2013-02-22 03:20:50 <HM> webwallets will probably be the #1 choice for most people
346 2013-02-22 03:21:41 <HM> phone wallets will be crippled as well  until 4G takes off in the next decade
347 2013-02-22 03:22:23 <novusordo> phone wallets... as in full bitcoin nodes on phones?
348 2013-02-22 03:22:30 <HM> sure why not
349 2013-02-22 03:22:38 <gmaxwell> HM: web wallets??? well perhaps, but we can't do anything about that. I assume that after some hostil force takes over blockchain.info and gives 80,000 bitcoin users a bad day, that people will be a bit more thoughtful about webwallets.
350 2013-02-22 03:23:01 <novusordo> "a bad day"
351 2013-02-22 03:23:04 <novusordo> lol
352 2013-02-22 03:23:16 <HM> as long as the company backing the wallet is accountable and takes the heat users won't care
353 2013-02-22 03:23:27 <gmaxwell> novusordo: at least SPV clients on phones is totally reasonable now. Even a full node could work, but considering connectivity is probably somewhat pointless.
354 2013-02-22 03:23:57 <gmaxwell> HM: how can they be if they've been busy in court because the site also operates a gambling front end and a coin laundery?
355 2013-02-22 03:24:10 <HM> do they?
356 2013-02-22 03:24:16 <gmaxwell> B.i? yes.
357 2013-02-22 03:24:33 <novusordo> satoshidice is linked to directly from their wallet page
358 2013-02-22 03:24:37 <gmaxwell> Note that I said 'bad day' the way b.i wallets work a large number of people could likely recover their coins, but they'd be extremely inconvienced.
359 2013-02-22 03:24:45 <HM> oh well, maybe if they're screwing gamblers they won't feel the need to rade my webwallet
360 2013-02-22 03:24:53 <HM> raid*
361 2013-02-22 03:25:47 <gmaxwell> generally webwallets??? at least popular ones??? for great big systemic risks like central banks. We'll learn??? but probably the hardway.
362 2013-02-22 03:26:16 <gmaxwell> took people a couple months to forget mtgox getting hacked... the next big bank like thing getting hacked or shut down will be remembered for at least twice as long. :)
363 2013-02-22 03:26:26 <HM> I'm pretty cynical about all  things security
364 2013-02-22 03:26:50 <HM> people generally want accountability and a refund if shit goes wrong
365 2013-02-22 03:27:04 <gmaxwell> sure, thats an argument for off-chain payments too...
366 2013-02-22 03:27:13 <HM> and they'll moan about stupid banking passwords, and annoying security questions
367 2013-02-22 03:27:25 <HM> people don't care
368 2013-02-22 03:27:54 <gmaxwell> There is a little paradox here: j-random-user is best off outsourcing his security to some mega entity, but the whole community of users is better off if he doesn't because the mega entity is a systemic risk.
369 2013-02-22 03:28:03 <novusordo> maybe have a little opt-out button next to passwords and security requirements, and have that opt-out button link to a news story about mybitcoin.com.
370 2013-02-22 03:28:40 <gmaxwell> novusordo: hah. people will read it and still opt out. sadly. hyperbolic discounting and all that.. people's reasoning about security is terrible.
371 2013-02-22 03:28:58 <HM> it's complex morally
372 2013-02-22 03:29:28 <gmaxwell> I like to use the example of the guy running silk road happily emailing people without bothering to use pgp... even while he got the email addresses he was sending to from a page that listed the pgp keys. :P
373 2013-02-22 03:30:11 <novusordo> nice, hadn't heard about that one...
374 2013-02-22 03:30:33 <HM> was the email important
375 2013-02-22 03:30:38 <gmaxwell> personal expirence... but yea, the point is that even people with the most need in the world to use that stuff, don't.
376 2013-02-22 03:30:45 <X-Scale> https://news.ycombinator.com/item?id=5262120
377 2013-02-22 03:31:16 <HM> incidentally there's a nice kde desktop widget for price ticketing
378 2013-02-22 03:36:15 <andytoshi> anyone here with a PhD looking to work for dwave?
379 2013-02-22 03:37:37 <HM> you'd think a bunch of guys with PhDs would come up with a better name than dwave
380 2013-02-22 03:37:51 <HM> (and girls)
381 2013-02-22 03:40:54 <ThomasV_> does the d in dwave mean disentangled?
382 2013-02-22 03:42:23 <ThomasV_> http://spectrum.ieee.org/computing/hardware/loser-dwave-does-not-quantum-compute
383 2013-02-22 03:44:21 <andytoshi> ThomasV_: that's a silly article, dwave has been pretty public about what kind of "quantum computer" they hve
384 2013-02-22 03:44:47 <andytoshi> and it's not what the article seems to believe
385 2013-02-22 03:45:57 <ThomasV_> heh, qbitcoins anyone?
386 2013-02-22 03:45:59 <HM> one for doing double sha? :P
387 2013-02-22 03:46:46 <gmaxwell> andytoshi: well, kinda. Their marketing / PR / investor relations have been QUANTUM COMPUTING and letting people google up what quantum computers do and draw the wrong conclusions.
388 2013-02-22 03:47:22 <gmaxwell> andytoshi: judging by what I see in bitcoin channels and other technical forum they are lying by omission to an extreme degree, even if you can dig into the fine print and find a pretty honest description.
389 2013-02-22 03:47:33 <HM> you don't have to be an einstein looking at their website to see they're 90% fluff
390 2013-02-22 03:47:34 <andytoshi> gmaxwell: that's true, and even in the job advert i've got here the first paragraph is marketing drivel
391 2013-02-22 03:47:41 <HM> lots of ceo videos showing nothing but faces
392 2013-02-22 03:47:48 <gmaxwell> andytoshi: but maybe thats what you have to do to get funding.
393 2013-02-22 03:47:49 <HM> cruddy stock design
394 2013-02-22 03:47:50 <andytoshi> and it says "requires Ph. D." two lines later, so i dunno who they think they're fooling
395 2013-02-22 03:48:01 <andytoshi> PhDs, i guess
396 2013-02-22 03:48:19 <gmaxwell> nah, investors who check out the job postings to make sure they don't have slots open for conmen. :P
397 2013-02-22 03:48:48 <ThomasV_> PhD in bitcoinology...
398 2013-02-22 03:49:25 <novusordo> so... upgrading to 0.8.0
399 2013-02-22 03:49:27 <novusordo> wat do
400 2013-02-22 03:50:08 <andytoshi> novusordo: install it, start it
401 2013-02-22 03:50:14 <novusordo> that's it?
402 2013-02-22 03:50:30 <novusordo> no lube or anything?
403 2013-02-22 03:50:35 <HM> lmao
404 2013-02-22 03:51:53 <novusordo> Error initializing database environment /home/novusordo/.bitcoin! To recover, BACKUP THAT DIRECTORY, then remove everything from it except for wallet.dat.
405 2013-02-22 03:52:10 <gmaxwell> novusordo: did you cleanly shut down the old one first?
406 2013-02-22 03:52:25 <novusordo> hmm, perhaps it wasn't a clean shutdown last time
407 2013-02-22 03:52:32 <novusordo> does "clean" also mean "synced"?
408 2013-02-22 03:52:52 <gmaxwell> no. just not crashed or power offed.
409 2013-02-22 03:53:35 <novusordo> ok, i'll try a clean shutdown
410 2013-02-22 04:15:57 <phantomcircuit> gmaxwell, i got the same error but since im benchmarking initial sync time i just deleted it
411 2013-02-22 04:16:27 <phantomcircuit> 2013-02-22 02:41:47 SetBestChain: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048  height=1  work=8590065666  tx=2  date=2009-01-09 02:54:25
412 2013-02-22 04:16:27 <phantomcircuit> 2013-02-22 05:15:48 SetBestChain: new best=00000000000006df51ae4722a2ec9fccdf7e7a4e3ae24c7dde2c8511e6314b3a  height=184730  work=355972803560495932401  tx=4154391  date=2012-06-16 00:57:57
413 2013-02-22 04:17:07 <phantomcircuit> that's on a mirrored lvm setup with a mirrored log so ~2x write amplification
414 2013-02-22 04:32:54 <novusordo> damnit bitcoin-qt, y u no quit?
415 2013-02-22 04:34:20 <novusordo> closed it, but it keeps spiking to ~50% cpu usage before going back down to ~3% for a bit, then repeating seemingly for infinity
416 2013-02-22 04:40:00 <jgarzik> Interesting that blockchain.info trolls the forum for well known addresses
417 2013-02-22 04:40:18 <jgarzik> and attaches that knowledge to its real time transactions
418 2013-02-22 04:40:38 <jgarzik> so you see "jgarzik!" whenever I spent something, that happens to include donation money etc.
419 2013-02-22 04:41:36 <ThomasV_> troll the forum? or crawl the forum?
420 2013-02-22 04:44:48 <gmaxwell> phantomcircuit: if you're syncing from the network??? not a very useful benchmark, you're just telling me how lucky your peer selection was.
421 2013-02-22 04:46:05 <phantomcircuit> gmaxwell, shh
422 2013-02-22 04:46:25 <andytoshi> ;;bc,blocks
423 2013-02-22 04:46:26 <gribble> 222472
424 2013-02-22 04:46:55 <andytoshi> cool, my hidden service bitcoind is synced
425 2013-02-22 04:54:59 <gmaxwell> phantomcircuit: so syncing from a local node:   (with txindex=1 so its doing a lot more work, and on my laptop on battery)
426 2013-02-22 04:55:02 <gmaxwell> 2013-02-22 05:49:24 SetBestChain: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048  height=1  work=8590065666  tx=2  date=2009-01-09 02:54:25
427 2013-02-22 04:55:05 <gmaxwell> 2013-02-22 05:53:07 SetBestChain: new best=0000000000000519cebad29361ca4fc7ed09da654cc35027acaa2b2cfdeb9269  height=180480  work=326387307918473057046  tx=3221856  date=2012-05-17 12:13:20
428 2013-02-22 04:56:08 <gmaxwell> phantomcircuit: four minutes looks pretty funny next to your 2.5 hours...
429 2013-02-22 05:00:00 <novusordo> gmaxwell: "local node" as in, a machine on the same network as you?
430 2013-02-22 05:00:06 <gmaxwell> yes.
431 2013-02-22 05:00:10 <novusordo> wow
432 2013-02-22 05:00:31 <novusordo> and completely from scratch?
433 2013-02-22 05:00:46 <novusordo> nvm, yes obviously
434 2013-02-22 05:01:09 <gmaxwell> oh not exactly the same height as phantom, I dyslexia fail. one sec.
435 2013-02-22 05:01:32 <novusordo> last 4000 or so blocks
436 2013-02-22 05:01:39 <gmaxwell> 2013-02-22 05:54:17 SetBestChain: new best=00000000000006df51ae4722a2ec9fccdf7e7a4e3ae24c7dde2c8511e6314b3a  height=184730  work=355972803560495932401  tx=4154391  date=2012-06-16 00:57:57
437 2013-02-22 05:01:52 <novusordo> still
438 2013-02-22 05:01:54 <gmaxwell> okay, so like .. one more minute.
439 2013-02-22 05:02:27 <novusordo> what type of storage does your laptop have? SSD?
440 2013-02-22 05:02:40 <novusordo> any encryption?
441 2013-02-22 05:03:00 <gmaxwell> ssd, w/ dmcrypt. I don't know that it should matter that much though.
442 2013-02-22 05:03:30 <gmaxwell> Its not mostly IO limited. I expect its largely memory bandwidth limited.
443 2013-02-22 05:04:17 <gmaxwell> also a lot of time spent on sha256 no doubt.
444 2013-02-22 05:05:25 <andytoshi> what are your ram specs then
445 2013-02-22 05:05:36 <andytoshi> i've got 4gb DDR2, 800mhz i think :P
446 2013-02-22 05:07:04 <gmaxwell> no idea, cpu in this thing is a i7-3520M, 8gb ram.
447 2013-02-22 05:08:51 <andytoshi> cool, it's always neat to see what specs are out there
448 2013-02-22 05:09:04 <andytoshi> especially with the murmurs about moore's law running out getting so loud
449 2013-02-22 05:10:06 <novusordo> ACTION murmurs something about moore's law running out
450 2013-02-22 05:17:10 <phantomcircuit> gmaxwell, disk speed still matters
451 2013-02-22 05:17:17 <phantomcircuit> but mostly because im doing other things
452 2013-02-22 05:17:30 <phantomcircuit> i wasn't looking for a consistent benchmark just a sort of reasonable average
453 2013-02-22 05:18:21 <gmaxwell> it really depends a lot as you can see, the range for sync can be from something like an hour to all day depending on luck... even wider if you allow for slow and busted client configs.
454 2013-02-22 05:20:10 <jgarzik> factoid: June 9, 2011: 6,475,000 bitcoins in circulation at $29.57 apiece. Today: 10,811,850 bitcoins @ $29.90.
455 2013-02-22 05:20:25 <Diablo-D3> jgarzik: we didnt break the peak though
456 2013-02-22 05:20:27 <Diablo-D3> $31.xx
457 2013-02-22 05:24:52 <gmaxwell> Diablo-D3: well, time for you to go and buy about 5kBTC.
458 2013-02-22 05:25:05 <Diablo-D3> why do you say that?
459 2013-02-22 05:25:36 <gmaxwell> because thats about what it would take to get it up to $31.10
460 2013-02-22 05:26:17 <novusordo> gmaxwell: mind elaborating on "slow and busted client configs"?
461 2013-02-22 05:26:37 <Diablo-D3> gmaxwell: heh, I just sold 107 btc
462 2013-02-22 05:27:59 <gmaxwell> novusordo: e.g. everyone once in a while someone shows up with a failing disk and bitcoin is insanely slow... and their disk is going kachinkkachinkkachink.
463 2013-02-22 05:28:02 <jgarzik> ;;asks 32.0
464 2013-02-22 05:28:04 <gribble> There are currently 15533.05 bitcoins offered at or under 32.0 USD, worth 488066.228577 USD in total.
465 2013-02-22 05:28:18 <gmaxwell> ;;asks 31.99999
466 2013-02-22 05:28:20 <gribble> There are currently 12438.801 bitcoins offered at or under 31.99999 USD, worth 388936.597617 USD in total.
467 2013-02-22 05:28:29 <jgarzik> ;;asks 31.2
468 2013-02-22 05:28:31 <gribble> There are currently 6182.6562 bitcoins offered at or under 31.2 USD, worth 190473.21361 USD in total.
469 2013-02-22 05:28:39 <Diablo-D3> hrm, bitinstant accepts paypal for out
470 2013-02-22 05:29:09 <jgarzik> Diablo-D3: I always thought BTC->paypal would be lucrative for the brave soul who took up the challenge
471 2013-02-22 05:29:20 <Diablo-D3> well
472 2013-02-22 05:29:26 <Diablo-D3> worse case is, I become paypal's worse nightmare
473 2013-02-22 05:29:40 <Diablo-D3> all other cases is, paypal doesnt give a shit
474 2013-02-22 05:29:57 <Diablo-D3> I cant do a wire transfer from mtgox, nor use dwolla
475 2013-02-22 05:29:59 <jgarzik> paypal api has a great masspay feature, which makes it trivial to implement, programmatically
476 2013-02-22 05:30:02 <andytoshi> lol, more likely paypal freezes all your USD and doesn't reply for months on end
477 2013-02-22 05:30:15 <Diablo-D3> andytoshi: yes, and then they wonder what that burning smell is
478 2013-02-22 05:30:21 <andytoshi> that'd be wonderful
479 2013-02-22 05:30:22 <jgarzik> andytoshi: hence "brave soul" -- you need to get inside the AML/KYC loop, simply put
480 2013-02-22 05:30:26 <jgarzik> not rocket science
481 2013-02-22 05:30:39 <Diablo-D3> jgarzik: bitinstant still offers paypal out though
482 2013-02-22 05:30:59 <jgarzik> Diablo-D3: nod -- and paypal-out must be inside the AML/KYC loop
483 2013-02-22 05:31:03 <jgarzik> bitinstant handles that
484 2013-02-22 05:31:11 <Diablo-D3> wtf is this loop you speak of?
485 2013-02-22 05:31:56 <jgarzik> Diablo-D3: the sender and receiver of money need to make sure you're not a North Korean money launderer etc.
486 2013-02-22 05:32:08 <Diablo-D3> yeah, but mtgox is fucking nuts
487 2013-02-22 05:32:12 <Diablo-D3> he wants a photograph of my id
488 2013-02-22 05:32:12 <gmaxwell> Fwiw, the full sync to current was 05:49:24 -> 06:23:59
489 2013-02-22 05:32:24 <jgarzik> Diablo-D3: they are required to file reports with the government
490 2013-02-22 05:32:27 <Diablo-D3> banks dont ask that because _they know better_
491 2013-02-22 05:32:35 <Diablo-D3> the only thing he needs is the id off that card
492 2013-02-22 05:32:59 <jgarzik> Diablo-D3: most banks don't ask because you opened the bank account in person (there are very specific banking regulations relating to this)
493 2013-02-22 05:33:13 <Diablo-D3> jgarzik: nope, I didnt open them in person.
494 2013-02-22 05:33:16 <jgarzik> some internet banks skate along
495 2013-02-22 05:33:27 <jgarzik> Diablo-D3: hence "most"
496 2013-02-22 05:34:18 <Diablo-D3> wtf and mtgox caps me to withdrawing 1000 a day
497 2013-02-22 05:34:31 <jgarzik> Diablo-D3: just AML/KYC harder, for a bigger limit :)
498 2013-02-22 05:34:34 <novusordo> even more ridiculous is that mtgox requires AML/KYC verification to withdraw any amount of funds after logging in from a different geographic location
499 2013-02-22 05:35:04 <Diablo-D3> jgarzik: yes, but mtgox is a foreigner
500 2013-02-22 05:35:04 <novusordo> I've got 2 damn BTC that have been stuck in gox for about a year...
501 2013-02-22 05:35:12 <Diablo-D3> jgarzik: he doesnt even have a right to even look at my id.
502 2013-02-22 05:35:16 <jgarzik> if you need fiat connectivity, you gotta dance to the tune of fiat regulators :)
503 2013-02-22 05:35:24 <jgarzik> mtgox doesn't just make up the rules
504 2013-02-22 05:35:26 <Diablo-D3> infact, he should bow before me and pray that I dont bomb his country. again.
505 2013-02-22 05:35:47 <egecko> its the same hoops for everyone.. there are rules, this isn't 'nam.
506 2013-02-22 05:35:56 <Diablo-D3> egecko: yes, and mtgox better start following them
507 2013-02-22 05:36:09 <Diablo-D3> mtgox is a foreign entity probably involved in identity theft
508 2013-02-22 05:36:23 <egecko> and requiring proof of identity is part of that process
509 2013-02-22 05:36:32 <Diablo-D3> yes, which is the id on that card.
510 2013-02-22 05:36:39 <Diablo-D3> not a photo of that card
511 2013-02-22 05:36:47 <jgarzik> oh, good grief.  Don't make me break out /ignore
512 2013-02-22 05:36:59 <Diablo-D3> jgarzik: hey man, Im just following the law here
513 2013-02-22 05:37:07 <X-Scale> Diablo-D3: unfortunately, it's the same with most online betting...if you win over a certain $ amount (like $1000 or $2000), they will ask you for detailed ID and proof of residence. Very annoying indeed.
514 2013-02-22 05:37:08 <Luke-Jr> Diablo-D3: you trolling again?
515 2013-02-22 05:37:09 <Diablo-D3> reproductions of this card cannot be used as identification under US Federal law.
516 2013-02-22 05:37:21 <Diablo-D3> ergo, mtgox is not following US Federal law
517 2013-02-22 05:37:42 <Diablo-D3> X-Scale: $500 iirc
518 2013-02-22 05:38:06 <Diablo-D3> X-Scale: and they will also haul you off to jail for illegal gambling
519 2013-02-22 05:38:12 <CodeShark> at least as annoying is the minimum $15-30 transfer fees to US banks via ACH
520 2013-02-22 05:38:21 <phantomcircuit> <Diablo-D3> infact, he should bow before me and pray that I dont bomb his country. again.
521 2013-02-22 05:38:21 <phantomcircuit> rofl
522 2013-02-22 05:38:28 <phantomcircuit> that is wrong in soooo many ways
523 2013-02-22 05:39:19 <Diablo-D3> well, I'd send it by wire, but what the fuck are all those strange numbers it wants
524 2013-02-22 05:39:24 <Diablo-D3> none of them look like ACH numbers
525 2013-02-22 05:39:34 <jgarzik> dwolla works great
526 2013-02-22 05:39:53 <Diablo-D3> jgarzik: yes, and dwolla has already identified me
527 2013-02-22 05:39:59 <Diablo-D3> except mtgox claims thats not enough
528 2013-02-22 05:40:01 <Diablo-D3> when it clearly is
529 2013-02-22 05:40:09 <gmaxwell> I logged in once and they told me that I'd have to bind my account to a facebook account to continue.
530 2013-02-22 05:40:13 <gmaxwell> I've never logged into it since.
531 2013-02-22 05:40:24 <Diablo-D3> gmaxwell: they never asked me that
532 2013-02-22 05:40:31 <Diablo-D3> because I would have actually sued them for that
533 2013-02-22 05:40:37 <jgarzik> I was asked that, and clicked 'no thanks'
534 2013-02-22 05:40:50 <Diablo-D3> even just asking must violate some law somewhere
535 2013-02-22 05:41:05 <jgarzik> ahhhhhhhhh.  like a cool, refreshing breeze.
536 2013-02-22 05:41:21 <CodeShark> lol - did jgarzik pull an /ignore?
537 2013-02-22 05:41:23 <Diablo-D3> jgarzik is trolling me again =/
538 2013-02-22 05:41:59 <CodeShark> don't abuse important terms like "trolling"
539 2013-02-22 05:42:11 <CodeShark> it debases them and then we lack appropriate terms when we need them
540 2013-02-22 05:42:13 <Diablo-D3> CodeShark: he keeps claiming he has me on ignore
541 2013-02-22 05:42:17 <Diablo-D3> then forgets that he does
542 2013-02-22 05:44:40 <CodeShark> taken to its true potential, trolling is an artform
543 2013-02-22 05:44:42 <jgarzik> ;;asks 31.2
544 2013-02-22 05:44:44 <gribble> There are currently 5966.4059 bitcoins offered at or under 31.2 USD, worth 183851.218401 USD in total.
545 2013-02-22 05:45:13 <gribble> 186151.68
546 2013-02-22 05:45:13 <jgarzik> ;;calc 31.2 * 5966.4
547 2013-02-22 05:45:24 <CodeShark> have we just reached peak?
548 2013-02-22 05:45:31 <Diablo-D3> yes
549 2013-02-22 05:45:33 <Diablo-D3> I already sold
550 2013-02-22 05:45:39 <CodeShark> I sold at 30
551 2013-02-22 05:45:53 <andytoshi> i sold at 16.5..
552 2013-02-22 05:45:57 <CodeShark> lol
553 2013-02-22 05:46:01 <CodeShark> I bought at 16.5
554 2013-02-22 05:46:02 <Diablo-D3> I sold at 30 too
555 2013-02-22 05:46:04 <andytoshi> haha
556 2013-02-22 05:46:05 <jgarzik> under $200k to all time high...  not a lot, considering daily volume
557 2013-02-22 05:46:23 <Diablo-D3> so how the hell do I use wire transfer?
558 2013-02-22 05:46:39 <CodeShark> "wire transfer" is such an archaic term
559 2013-02-22 05:46:45 <CodeShark> it should be put out of its misery :)
560 2013-02-22 05:46:51 <CodeShark> outlived its utility
561 2013-02-22 05:46:51 <Diablo-D3> its an actual wire transfer, not an ach
562 2013-02-22 05:46:59 <andytoshi> yeah, if one of the manipulative maurauders makes a massive movement, we may manage a new maximum..
563 2013-02-22 05:47:24 <CodeShark> "wire transfer" evokes an image of a telegraph operator
564 2013-02-22 05:47:26 <Diablo-D3> _heh_
565 2013-02-22 05:47:40 <CodeShark> we have network cards to do that for us now :)
566 2013-02-22 05:47:52 <CodeShark> billions of times faster
567 2013-02-22 05:55:16 <Diablo-D3> okay so wait
568 2013-02-22 05:55:23 <Diablo-D3> how do I get my money out of mtgox then?
569 2013-02-22 05:55:55 <CodeShark> without being strip searched and charged an arm and a leg?
570 2013-02-22 05:56:13 <Diablo-D3> yeah, because apparently I cant send myself wire transfers because mtgox doesnt support ach
571 2013-02-22 05:56:27 <CodeShark> ripple?
572 2013-02-22 05:56:30 <andytoshi> Diablo, move BTC to canada and withdraw through cavirt
573 2013-02-22 05:56:38 <SomeoneWeird> ripple is lol
574 2013-02-22 05:56:49 <Diablo-D3> ripple doesnt even exist anymore
575 2013-02-22 05:56:54 <Diablo-D3> that collapsed before bitcoin was created
576 2013-02-22 05:57:09 <CodeShark> ripple is now a new project
577 2013-02-22 05:57:29 <weex> when -dev starts to look like -otc, it might be time to sell :P
578 2013-02-22 05:57:37 <CodeShark> lol
579 2013-02-22 05:57:51 <SomeoneWeird> yeah lol
580 2013-02-22 05:57:53 <X-Scale> I see money flowing on #ripple-watch
581 2013-02-22 05:58:13 <gribble> Next Price Estimate: 33.108889 | Next Price In About 2 days, 22 hours, 57 minutes, and 4 seconds
582 2013-02-22 05:58:13 <weex> ;;bc,price
583 2013-02-22 05:58:18 <weex> lol
584 2013-02-22 05:59:47 <gmaxwell> Diablo-D3: jed got bored of suing bitcoinica and bought the ripple name, told the ripple guy to buzz off, and now it's time to pump pump pump a new cryptocurrency.  Sources isn't even out, just some JS webwallet, and they're already promoting their world domination.
585 2013-02-22 06:00:06 <Diablo-D3> gmaxwell: thats lame
586 2013-02-22 06:00:44 <jgarzik> gmaxwell: if they want to devolve into an optional trust layer on top of bitcoin, that's fine :)
587 2013-02-22 06:00:49 <CodeShark> actually, strictly speaking, ripple is not a cryptocurrency (in the way bitcoin is)
588 2013-02-22 06:01:01 <gmaxwell> CodeShark: sure it is.
589 2013-02-22 06:01:09 <jgarzik> gmaxwell: ripple nerds will have their currency like GPG nerds have keysigning parties
590 2013-02-22 06:01:11 <CodeShark> it's a trust network
591 2013-02-22 06:01:16 <gmaxwell> CodeShark: the IOU stuff is purely optional and not even implemented yet.
592 2013-02-22 06:01:23 <CodeShark> actually, it is implemented
593 2013-02-22 06:01:30 <andytoshi> ..then what is it? i thought it was pure IOUs
594 2013-02-22 06:01:30 <gmaxwell> CodeShark: show me?
595 2013-02-22 06:01:41 <gmaxwell> Joel told me today that it wasn't implemented yet.
596 2013-02-22 06:01:52 <Diablo-D3> I wonder why none of these like support popmoney
597 2013-02-22 06:03:41 <gmaxwell> CodeShark: I think it would be fair to say that it's not actually a consensus system, since there seems to be no way to guarantee global convergence with high probablity. ... but at the moment the XRP stuff is certantly a currency, and people are paying bunches of bitcoin for it.
598 2013-02-22 06:05:38 <phantomcircuit> gmaxwell, unfortunately he hasn't gotten bored enough to drop the suit
599 2013-02-22 06:07:42 <phantomcircuit> Diablo-D3, popmoney is just ACH and they dont have an api or anything
600 2013-02-22 06:07:48 <phantomcircuit> why would anybody support that
601 2013-02-22 06:07:58 <Diablo-D3> phantomcircuit: the only reason I have a popmoney account is because if bitcoin
602 2013-02-22 06:07:58 <gmaxwell> I note that the ripple pre-mine is worth $1,500,000,000 at the current XRP/BTC/USD exchange rates.
603 2013-02-22 06:09:47 <phantomcircuit> gmaxwell, most successful scam in the history of the world
604 2013-02-22 06:10:01 <phantomcircuit> hey maybe if jed is rich he can reimburse bitcoinica
605 2013-02-22 06:10:48 <SomeoneWeird> lmao
606 2013-02-22 06:10:54 <andytoshi> hahaha
607 2013-02-22 06:11:09 <phantomcircuit> otoh if he's in jail for operating an illegal securities issuance/exchange and money transmitting platform all in one
608 2013-02-22 06:11:12 <phantomcircuit> well then who knows
609 2013-02-22 06:11:38 <andytoshi> the dark knight had a similar subplot, as i recall
610 2013-02-22 06:11:49 <SomeoneWeird> lols
611 2013-02-22 06:16:18 <gmaxwell> phantomcircuit: is he actually involved with it? seems to mostly be people on trolltalk saying that.
612 2013-02-22 06:16:42 <phantomcircuit> gmaxwell, is jed mccaleb actually involved in ripple? yes
613 2013-02-22 06:31:12 <jgarzik> gmaxwell: Jed?  He's definitely inside that Ripple project's adminisphere
614 2013-02-22 06:31:51 <jgarzik> not just talk
615 2013-02-22 06:34:43 <doublec> is that the same jed who originally started mtgox?
616 2013-02-22 06:37:21 <SomeoneWeird> yes
617 2013-02-22 06:41:59 <jouke> Why is the .8 client that much faster in syncing with the blockchain?
618 2013-02-22 06:52:52 <jgarzik> if the block size must change, here is my proposal:  double the maximum block size every (144 * 365) blocks.
619 2013-02-22 06:53:07 <jgarzik> nothing complex or history driven
620 2013-02-22 06:56:14 <jouke> I was thinking that nodes might implement a max block relay delay to discourage miners to make big blocks
621 2013-02-22 06:57:29 <Luke-Jr> jgarzik: I'd think huge leaps should be avoided
622 2013-02-22 06:58:43 <jgarzik> Luke-Jr: works for block subsidy
623 2013-02-22 06:58:51 <jgarzik> Luke-Jr: it is a highly predictable event
624 2013-02-22 06:59:10 <Luke-Jr> jgarzik: does it?
625 2013-02-22 06:59:19 <Luke-Jr> we've had one drop, and it wasn't exactly uneventful
626 2013-02-22 06:59:38 <jouke> it wasn't? :o
627 2013-02-22 07:00:27 <jgarzik> For the vast majority of people who were not Luke-Jr, it was uneventful
628 2013-02-22 07:00:35 <jouke> :)
629 2013-02-22 07:00:52 <Luke-Jr> jgarzik: sipa's graphs show otherwise ;)
630 2013-02-22 07:00:57 <jgarzik> Bitcoin value did not move much, and bitcoins were just as spendable and secure at 25 BTC as at 50 BTC
631 2013-02-22 07:01:31 <Luke-Jr> difficulty dropped, so not just as secure
632 2013-02-22 07:01:51 <Luke-Jr> only reason we bounced back is ASICs
633 2013-02-22 07:02:43 <jgarzik> hair splitting.  to the average bitcoin user, just as secure.
634 2013-02-22 07:04:07 <Luke-Jr> so in 4 years when it halves again, and we don't have ASICs to bail us out, you really think it will go unnoticed by end users?
635 2013-02-22 07:05:27 <jouke> Shit, there will be no more technical innovation in the coming four years?
636 2013-02-22 07:18:59 <jgarzik> Luke-Jr: <shrug> either the fees slowly rise to support the system, or they don't, as the block reward slowly decreases
637 2013-02-22 07:19:08 <jgarzik> won't know 'til we get there
638 2013-02-22 07:52:59 <jgarzik> another interesting idea from the forums: one unlimited size block per difficulty adjustment period
639 2013-02-22 07:53:16 <jgarzik> not endorsing the idea, but it's fun to think about
640 2013-02-22 07:59:58 <Scrat> in a hypothetical world where there are millions of active users and there is a need for more than 3 tps and a bigger block size, why is there a need to store the blockchain millions of times? can't each full node only store a percentage of the chain in a deterministic way that can be easily be verified?
641 2013-02-22 08:32:08 <jouke> My 0.8 crashed with a new install: http://pastebin.com/NStnjXL9
642 2013-02-22 09:08:29 <CodeShark> you have any memory shortages?
643 2013-02-22 09:09:10 <CodeShark> looks like you ran out of memory
644 2013-02-22 09:28:22 <grau> CodeShark: you forked bitsofproof on github. Please beware that I merged supernode and supernode-api repositories. You better resync
645 2013-02-22 09:28:40 <CodeShark> grau: ok, thanks
646 2013-02-22 09:28:54 <grau> supernode-api is gone
647 2013-02-22 12:08:05 <ThomasV> why does signrawtransaction still require "redeemScript"once a multisig transaction is partially signed?
648 2013-02-22 12:58:45 <HM> Maybe there's a half way house between full validation and header only clients
649 2013-02-22 12:59:09 <HM> If you split large blocks up in to smaller blocks and each node randomly validated a subset of transactions, reporting bad things to the network
650 2013-02-22 12:59:16 <HM> too easy to manipulate i guess though
651 2013-02-22 13:07:43 <diki> What is this blocksize issue I keep reading about?
652 2013-02-22 13:07:50 <diki> I've been away from the bitcoin scene for a while.
653 2013-02-22 13:09:24 <lianj> diki: the max block size is fixed at 1MB
654 2013-02-22 13:09:38 <diki> and?
655 2013-02-22 13:10:41 <lianj> even if you only have small (500 byte) txs, bitcoin can only process 2000 txs at max every 10 minutes
656 2013-02-22 13:10:58 <diki> so..slow txes?
657 2013-02-22 13:12:10 <lianj> slow or maybe never fully flushed tx queue if much more than 2000 txs are greated each 10 minutes
658 2013-02-22 13:12:26 <lianj> i can be wrong, but thats how i understand it
659 2013-02-22 13:12:27 <diki> I suppose that with SatoshiDice,price boom and future users, it can take more than 2-3
660 2013-02-22 13:12:52 <lianj> or much more
661 2013-02-22 13:13:44 <lianj> but no surprise, its known that its not scale to for example paypal tx volume currently
662 2013-02-22 13:22:07 <treb> jrmithdobbs: hi, around? =)
663 2013-02-22 13:22:37 <treb> how does BitcoinD run on OpenBSD now? not for mining but just in general
664 2013-02-22 13:23:20 <HM> lianj, diki: yeah, sipa and gmaxwell were explaining this to me last night. the problem is for high tx rates only people with lots of resources will be able to validate all the transactions in a block, so there's nobody to keep them honest
665 2013-02-22 13:50:07 <helo> i'm happy to see that perspective so popular
666 2013-02-22 13:51:39 <helo> there are a great many people who think bitcoin should scale up to compete with credit cards
667 2013-02-22 13:52:31 <lianj> some do, other think it will be like gold, which other currencies are then based on
668 2013-02-22 13:52:43 <HM> even credit cards had scaleability issues once upon a time
669 2013-02-22 13:52:47 <HM> you had offline transactions
670 2013-02-22 13:53:16 <treb> here is BitcoinD's API / RPC API documented?
671 2013-02-22 13:53:29 <treb> as for a local OS process to make use of it, like, make it do transactions or listen for new events
672 2013-02-22 13:57:36 <helo> i really like the idea of bitcoin having as-low-as-possible overhead so everyone (including mobile in time) can fully validate
673 2013-02-22 13:58:15 <lianj> youre to late :P
674 2013-02-22 13:58:16 <helo> with bitcoin-backed currencies existing in a way that allows everyone to validate the legitimacy of the backing
675 2013-02-22 13:59:07 <helo> taking advantage of the ease of validating and keeping up with the bitcoin blockchain
676 2013-02-22 14:00:19 <lianj> the full validation is not that easy or lightweight
677 2013-02-22 14:00:32 <gmaxwell> lianj: sure it is.
678 2013-02-22 14:00:40 <helo> with 1MB blocks, it should be easy enough in time
679 2013-02-22 14:00:57 <helo> my phone could probably run a full node if i didn't worry about battery life
680 2013-02-22 14:01:08 <gmaxwell> helo: correct.
681 2013-02-22 14:01:23 <lianj> gmaxwell: then why do many people suggest to only use the reference implementation?
682 2013-02-22 14:01:56 <gmaxwell> lianj: I'm not sure what you are asking, or at least how it relates to the discussion.
683 2013-02-22 14:02:22 <HM> helo: backing your own currency with bitcoin and proving you have bitcoins in reserve as backup doesn't gain you anything
684 2013-02-22 14:02:37 <HM> helo: you can still double spend your own currency if it sucks
685 2013-02-22 14:02:50 <helo> with a "lean" blockchain, colored coin starts to be viable for managing ownership of all kinds of things
686 2013-02-22 14:03:14 <gmaxwell> helo: yea??? wrt bitcoin backed. No provably bitcoin backed processing system can be lighter weight to prove than bitcoin itself, but they can be faster and most scalable. So if bitcoin is made fat, nothing backed by it can be validated without a lot of work.
687 2013-02-22 14:04:17 <gmaxwell> HM: who said anything about "your own currency"?  Go look at petertodd's fidelity banks for an example of the sort of thing that can be done.
688 2013-02-22 14:04:48 <HM> helo mentioned "bitcoin-backed currencies"
689 2013-02-22 14:04:54 <HM> i'm not familiar with fidelity banks
690 2013-02-22 14:05:09 <sipa> bitcoin-backed does not mean it has to be based on the same technology
691 2013-02-22 14:05:44 <sipa> hell, mtgox vouchers can be considered to be a bitcoin-backed currency
692 2013-02-22 14:05:58 <HM> and they could be double spent if mtgox get it wrong
693 2013-02-22 14:06:05 <helo> a rich ecosystem of currencies with various properties backed with bitcoin seems pretty ideal
694 2013-02-22 14:06:06 <HM> they're not verifiable at all to outsiders
695 2013-02-22 14:06:11 <sipa> HM: yes, from a technology, it sucks
696 2013-02-22 14:06:14 <gmaxwell> indeed, though a centeralized one??? but highly performant and already existing.
697 2013-02-22 14:06:14 <sipa> point
698 2013-02-22 14:06:19 <lianj> gmaxwell: i was talking about "so everyone (including mobile in time) can fully validate"
699 2013-02-22 14:06:29 <helo> currency competition on that level would be pretty revolutionary, i think
700 2013-02-22 14:06:59 <HM> diverse currencies treating bitcoin as a reserve currency doesn't get you anywhere
701 2013-02-22 14:07:15 <gmaxwell> lianj: a current gen smartphone running the reference client can _currently_ keep up with the blockchain. ... not that you'd necessarily want to do this, but it already works.
702 2013-02-22 14:07:51 <sipa> HM: if it's a full reserve system that can be verifiable, why not?
703 2013-02-22 14:08:19 <helo> HM: with a market of competing currencies, it gets you (i.e. the market) whatever there is demand for
704 2013-02-22 14:08:38 <sipa> i think it's wrong to call it competing currencies, the currency is always bitcoin
705 2013-02-22 14:08:40 <helo> an obvious benefit is to get rid of inflation
706 2013-02-22 14:08:41 <HM> the fed could claim full reserve and even make the amount of gold reserves they have public and audited, it doesn't stop them printing unlimited $ers secretly
707 2013-02-22 14:08:46 <helo> sipa: yeah, you're right
708 2013-02-22 14:08:47 <sipa> the payment processing differs
709 2013-02-22 14:09:11 <gmaxwell> hm: gold is not subjectable to instantly machine verifyable cryptographic proof.
710 2013-02-22 14:09:15 <helo> HM: the validation of bitcoin backing would keep them from printing unlimited dollars
711 2013-02-22 14:09:23 <HM> the Fed could move to Bitcoin, that wouldn't make $ers any better because nobody can verify how many there are
712 2013-02-22 14:10:02 <gmaxwell> HM: e.g. in petertodd's fidelity banks every transaction would be proven to be backed by bitcoin, and any misbehavior by the bank would cause it to lose its bond.
713 2013-02-22 14:10:07 <HM> just like you have no idea if MtGox holds the Bitcoins for every voucher they issue
714 2013-02-22 14:10:24 <HM> gmaxwell: i'll have to read up on that
715 2013-02-22 14:10:28 <gmaxwell> HM: thats a flaw in mtgox, not anything fundimental??? they could certantly prove it if they wanted to.
716 2013-02-22 14:10:56 <HM> you can create a provable voucher system without making something like the blockchain public?
717 2013-02-22 14:10:57 <helo> HM: mtgox isn't provably bitcoin backed, it's just a 100%-mtgox-trust-based voucher
718 2013-02-22 14:11:58 <gmaxwell> HM: Yes. likewise you can do them by making something like the blockchain public, but seperate so that it scales better.
719 2013-02-22 14:12:00 <helo> HM: if any entity could start their own bitcoin backed currency, there would be competition and incentive to provide proof
720 2013-02-22 14:12:28 <HM> we were talking about ways around scaling the blockchain, making it more course grained
721 2013-02-22 14:12:35 <HM> your solution is basically have alternative more localised chains
722 2013-02-22 14:12:37 <HM> yes?
723 2013-02-22 14:12:56 <gmaxwell> who says there is a chain?
724 2013-02-22 14:13:07 <gmaxwell> When you have a hammer must all things be nails? :P
725 2013-02-22 14:13:08 <HM> well something that is public, disseminated and verifiable
726 2013-02-22 14:14:29 <gmaxwell> E.g. the simple way to do that is for mtgox to publish the hash of every voucher and its value, and signmessages for all the backing coins, and signatures on all vouchers, and you check if your newly issued voucher is in the public list and that the sum of vouchers is less than their proven balance. If anyone gets a voucher which isn't on the list, then you publish proof of it.
727 2013-02-22 14:14:38 <Scrat> in a hypothetical world where there are millions of active users and there is a need for more than 3 tps and a bigger block size, why is there a need to store the blockchain millions of times? can't each full node only store a percentage of the chain in a deterministic way that can be easily be verified?
728 2013-02-22 14:15:49 <gmaxwell> Petertodd's idea is more complicated but more powerful??? in petertodd's case the bank (which could be a distributed system) uses blinded tokens so they can't tell who is trading with who...  and if proof of misbehavior is published then the bank loses its fidelity bond???  an expensive asset which must be equal in value to their deposits which is created by provably paying coin to bitcoin miners.
729 2013-02-22 14:16:25 <gmaxwell> Scrat: storing the history isn't too exciting. But to validate the chain you must store the utxo set, and perform lots of ecdsa.
730 2013-02-22 14:16:45 <HM> gmaxwell: so lock up some bitcoins in the blockchain, then publish a list of associated vouchers (hashed) so voucher holders can prove it's backed by something? how does that stop the existance of more than 1 such list?
731 2013-02-22 14:16:54 <gmaxwell> Scrat: and fwiw, you can fit over 4000 transactions in a block.
732 2013-02-22 14:17:51 <HM> gmaxwell: i'm reading his forum post now but it's not entirely clear how it works
733 2013-02-22 14:17:53 <gmaxwell> HM: you sign the lists, and people rumor the hash of the lists externally. If there is a discrepency they compare notes.
734 2013-02-22 14:18:14 <lianj> gmaxwell: how to fit over 4000 in a block?
735 2013-02-22 14:18:17 <helo> rumor as a verb ftw
736 2013-02-22 14:18:33 <HM> how does a one define  a 'misbehaviour' and how is it determined?
737 2013-02-22 14:18:45 <sipa> lianj: one transaction is 250 bytes or so
738 2013-02-22 14:18:55 <sipa> even less
739 2013-02-22 14:19:42 <lianj> whats the avg tx size, i doubt its below 400
740 2013-02-22 14:20:21 <gavinandresen> median transaction size is under 300 bytes, if I recall correctly
741 2013-02-22 14:20:29 <gmaxwell> who knows, I'm just pointing out that there can be more transactions then were claimed above.
742 2013-02-22 14:20:59 <gmaxwell> And the average transaction size is distorted by the non-use of compressed keys as well as inefficient transaction practices.
743 2013-02-22 14:21:21 <gmaxwell> it's not an important point??? just pedantry... but it was the second time I'd seen the low claim made.
744 2013-02-22 14:21:23 <gavinandresen> lianj: it's pretty easy to use getblock/getrawtransaction to calculate transaction size over the last N blocks, so you don't have to doubt you can know...
745 2013-02-22 14:21:42 <lianj> in good cases, yes. but tx using many inputs or creating lots of outputs are common too and they dont fit in 250bytes
746 2013-02-22 14:22:24 <gavinandresen> is there anyplace on the internet where people go out and get facts before speculating?
747 2013-02-22 14:22:36 <lianj> haha
748 2013-02-22 14:22:37 <SomeoneWeird> WIKIPEDIA
749 2013-02-22 14:22:56 <sipa> gavinandresen: there's this weird place called the real world, but most internet people find it disconforting in many ways
750 2013-02-22 14:23:09 <jgarzik> hah
751 2013-02-22 14:23:15 <gavinandresen> sipa:  I've heard of this "real world" place???. I think there was a TV show about it
752 2013-02-22 14:23:49 <helo> they say that's what created our universe... even that it's all around us
753 2013-02-22 14:24:10 <gmaxwell> (for i in {222552..222542} ; do ./bitcoind getblock `./bitcoind getblockhash $i` | grep '       "' | cut -d'"' -f2 ; done)  | xargs -n1 -iblah ./bitcoind getrawtransaction blah | awk '{aa+=length($0)/2} END {print aa/NR}'
754 2013-02-22 14:24:43 <gavinandresen> gmaxwell: yeah, that.  Although I think I wrote a little throwaway python script that did it
755 2013-02-22 14:25:56 <gmaxwell> (limitations of that command??? counts coinbases too)
756 2013-02-22 14:26:08 <HM> just says no information about transaction for me
757 2013-02-22 14:26:21 <gmaxwell> HM: you're not running txindex=1
758 2013-02-22 14:26:37 <gmaxwell> you cant getrawtransaction on spent transactions without the optional txindex.
759 2013-02-22 14:27:11 <HM> why is that the default? is indexing transactions really that expensive?
760 2013-02-22 14:27:13 <Scrat> I've seen 7 tps being thrown around.. just low balled it to 3
761 2013-02-22 14:27:32 <sipa> HM: it's mostly unnecessary
762 2013-02-22 14:27:55 <gavinandresen> a good principle of non-bloaty software design is "a feature shouldn't cost you anything if you don't use it."
763 2013-02-22 14:28:04 <sipa> and it costs some storage and processing
764 2013-02-22 14:28:32 <sipa> plus, it may make people depend on that feature being always available, which would for example prevent pruning strategies later on
765 2013-02-22 14:29:13 <sipa> as a principle, you should attempt to create systems that do not require forever history to be present, much less it being fully indexed
766 2013-02-22 14:29:16 <HM> prune satoshidice
767 2013-02-22 14:29:31 <HM> by default :P consider that a feature request :P
768 2013-02-22 14:29:40 <sipa> you can prune everything that is old enough
769 2013-02-22 14:29:46 <SomeoneWeird> yeah what would happen if you added a "bug" that ignored SD
770 2013-02-22 14:29:47 <SomeoneWeird> >.>
771 2013-02-22 14:29:57 <sipa> SomeoneWeird: you'd find yourself on a hard fork
772 2013-02-22 14:30:01 <sipa> immediately
773 2013-02-22 14:30:12 <SomeoneWeird> i mean transparently in the next major update :P
774 2013-02-22 14:30:14 <gmaxwell> HM: because it's only needed for geeks to investigate things- otherwise useless.. and it adds a bunch of required storage (700mb or so now?) and slows down block processing a bit.
775 2013-02-22 14:30:53 <HM> another way of looking at it is i'm already storing the data, why not index it?
776 2013-02-22 14:31:07 <HM> may as well not have it if i can't query it
777 2013-02-22 14:31:08 <gavinandresen> HM: that's what -txindex is for
778 2013-02-22 14:31:10 <gmaxwell> because doing so slows things down and adds 700mb of storage.
779 2013-02-22 14:31:21 <sipa> HM: the point is that in the future, you'll probably NOT be storing the data anymore
780 2013-02-22 14:31:34 <sipa> because of historical reasons, making that change now is hard
781 2013-02-22 14:31:40 <HM> ok
782 2013-02-22 14:31:42 <gmaxwell> HM: having it without an index still allows you to serve the blockchain to other nodes, or add the index later, or to find the data with a rescan.
783 2013-02-22 14:31:44 <Scrat> gmaxwell: would storing the utxo of the entire chain also imply storing it?
784 2013-02-22 14:31:45 <gavinandresen> HM: ??? might as well ask "why not index it by transaction amount?  I might want to look up all 11 BTC transactions, because 11 is my favorite number"
785 2013-02-22 14:32:17 <sipa> Scrat: 0.8 always maintains the full UTXO set, explicitly
786 2013-02-22 14:32:18 <gavinandresen> we've got the data...
787 2013-02-22 14:32:18 <gmaxwell> Scrat: imply storing what?  would storing the utxo imply storing the utxo? yes.
788 2013-02-22 14:32:36 <sipa> Scrat: a transaction index is completely independent of that
789 2013-02-22 14:32:37 <Scrat> sipa: just talking future
790 2013-02-22 14:32:43 <gmaxwell> gavinandresen: don't give people ideas! :P
791 2013-02-22 14:33:01 <sipa> the *only* thing the txindex is used and useful for, is for implementing getrawtransaction
792 2013-02-22 14:33:13 <HM> gavinandresen: i think looking up 11 BTC transactions is a bit niche :P
793 2013-02-22 14:33:17 <sipa> it's unrelated to block validation
794 2013-02-22 14:33:22 <gmaxwell> HM: as for why not make it default, not only is it somewhat costly and not needed, but features that depend on it are incompatible with pruning... so the cost ratio of having it on and off will increase in the future.
795 2013-02-22 14:33:49 <gmaxwell> also the txindex grows faster than the utxo set by definition.
796 2013-02-22 14:33:57 <Scrat> all I'm saying that if in the far future you want to keep decentralization you have to split the blockchain. here
797 2013-02-22 14:34:06 <Scrat> oops pressed enter ;p
798 2013-02-22 14:34:11 <gmaxwell> Scrat: 'split' ?
799 2013-02-22 14:35:26 <sipa> Scrat: the _current_ 0.8 code does actually not require the block chain data to be present at all (well, there's certainly some checks and operational stuff that would need to change to not throw errors when data is missing, but no algorithm depends on the block chain being there)
800 2013-02-22 14:35:36 <gmaxwell> Scrat: the storage is (now) already structured so that nodes don't need the history except for serving to other nodes. Once we figure out a safe way for new nodes to find the blocks they need then we could pretty easily implement fractional storage.
801 2013-02-22 14:35:38 <helo> HM: just like a tx index is niche :)
802 2013-02-22 14:35:38 <Scrat> here's a stupid way but just so that you get the idea: each node has a unique number 0 to 15 (generated on install) and it only stores blocks who's hash ends in that number
803 2013-02-22 14:35:38 <sipa> all that is required is the UTXO set really
804 2013-02-22 14:35:56 <sipa> you can throw away anything you like, in whatever scheme you want
805 2013-02-22 14:36:21 <Scrat> since everyone is bringing up the blockchain size and bandwidth requirement on the forums
806 2013-02-22 14:36:23 <gmaxwell> Scrat: very stupid, because locality matters. :P  .... in any case, the only barrier is that we need a robust way to go _find_ the data again.
807 2013-02-22 14:36:32 <gmaxwell> Scrat: thats really pretty orthorgonal.
808 2013-02-22 14:36:42 <HM> Anyway, back to block size
809 2013-02-22 14:38:11 <HM> If you had 1 GB blocks, and 1 million nodes. could they not each randomly select a bunch of 1 MB chunks of the block to verify?
810 2013-02-22 14:38:23 <gmaxwell> or at least even with the systems defined rules you need to do that ... the forum noise is over increasing the max blocksize, which no amount of what you're describing can make work for arbitrarily small validators.  ... and for the most part storage requirements aren't that interesting at least not today. (the scaling law on storage appears to be faster than bandwidth and cpu)
811 2013-02-22 14:38:26 <HM> statistically a bad block would be caught but each node does less work
812 2013-02-22 14:38:48 <sipa> HM: you could do that with signature checks
813 2013-02-22 14:38:59 <sipa> HM: but each needs to maintain its own UTXO set
814 2013-02-22 14:39:01 <helo> HM: doesn't verification require sequential access on initial sync?
815 2013-02-22 14:39:22 <HM> sipa: right, but that's just a storage problem, not a processing one
816 2013-02-22 14:39:38 <HM> i thought the bottleneck was verifying 1 billion transactions every 10 minutes :P
817 2013-02-22 14:40:05 <sipa> if the UTXO set grows, so will the cost per transaction to lookup things in it and update them
818 2013-02-22 14:40:07 <helo> there is a much more severe bottleneck than that
819 2013-02-22 14:40:46 <sipa> basic problem is that signature checking can be parallellized, but block connection can't (or much harder)
820 2013-02-22 14:41:05 <sipa> and we can expect parallellism in hardware to go up in the future faster than sequential speed
821 2013-02-22 14:41:17 <HM> block connection?
822 2013-02-22 14:41:45 <Scrat> this microtransaction convenience vs. decentralization problem is such a brainfuck
823 2013-02-22 14:41:47 <helo> HM: the biggest problem with big blocks imho is the amount of data new nodes have to go through to get up to date
824 2013-02-22 14:41:52 <sipa> block connections == patching the UTXO set with the changes a particular block implies (remove inputs and add outputs)
825 2013-02-22 14:42:00 <HM> ah
826 2013-02-22 14:42:41 <HM> and if you don't have the full UTXO then whenever you deal with someone new you need to download their records
827 2013-02-22 14:45:30 <Scrat> gmaxwell: a simplified version of DHT should be enough for finding the data, no?
828 2013-02-22 14:45:49 <HM> lol
829 2013-02-22 14:47:46 <Scrat> HM: i'm a web developer, not my fault
830 2013-02-22 14:48:06 <Scrat> javascript has done away with most of my functional neurons
831 2013-02-22 14:49:18 <HM> no it's not the idea, it's the fact that the last time i mentioned a DHT there was another tally mark carved in the bed post
832 2013-02-22 14:49:25 <HM> *here
833 2013-02-22 14:49:51 <gavinandresen> too bad we can't set a landmine sound effect to go off when "DHT" is mentioned in this channel