1 2013-03-10 00:00:06 <xjrn> it also paves the way for centralization becomeiiing cheeaper with higher frequency, being no differernt than what is now called spam
2 2013-03-10 00:02:00 <remote> can I easily check the balance of any bitcoin address using the bitcoin api?
3 2013-03-10 00:02:09 <xjrn> i started out worried for my drives getting chewed by spam if i wanted to play the home game, so banning makes sense as a fix that lasts 5 minutes
4 2013-03-10 00:02:31 <sipa> remote: no
5 2013-03-10 00:02:41 <sipa> remote: at the protocol level, there is no such thing as the balance of an address
6 2013-03-10 00:02:51 <remote> i'm more confused now
7 2013-03-10 00:02:57 <CodeShark> I think he's asking about the RPC, sipa
8 2013-03-10 00:03:15 <sipa> CodeShark: i know
9 2013-03-10 00:03:33 <remote> really what I want to know is how to verify the balance of any bitcoin address efficiently
10 2013-03-10 00:03:53 <remote> s/verify/get/
11 2013-03-10 00:03:56 road33 has joined
12 2013-03-10 00:03:59 <CodeShark> there is a formal definition to a bitcoin address balance: the sum of all the unspent outputs redeemable by someone who owns the private key for that address
13 2013-03-10 00:04:10 <CodeShark> it's a higher level construct, of course
14 2013-03-10 00:04:19 <sipa> yes, something at the wallet level
15 2013-03-10 00:04:27 <sipa> so wallets track balances
16 2013-03-10 00:04:42 <remote> so when I said address I ment wallet?
17 2013-03-10 00:04:51 <CodeShark> remote, you could take a look at https://github.com/bitcoin/bitcoin/pull/2121
18 2013-03-10 00:05:02 <CodeShark> but that branch is no longer being maintained
19 2013-03-10 00:05:27 <freewil> how does bitcoind keep track of confirmations for a tx, does it update every single transaction when a new block is received?
20 2013-03-10 00:05:29 <remote> how do sites like blockchain.info report all the info about any bitcoin address?
21 2013-03-10 00:05:41 <sipa> remote: in short: bitcoin doesn't need to know the balance of arbitrary addresses (as that has no meaning at the level of the protocol), and only tracks balances that are relevant to your wallet
22 2013-03-10 00:05:54 <sipa> remote: some sites maintain a huge index to track every single address ever used
23 2013-03-10 00:06:04 <CodeShark> remote: they dump their block chain data to a database that has appropriate indices
24 2013-03-10 00:06:30 <remote> is it easy to maintain a huge index like that?
25 2013-03-10 00:07:01 <CodeShark> either by patching bitcoind to export directly, by connecting a dedicated p2p node for that, or by parsing the bitcoind datadir
26 2013-03-10 00:07:43 <remote> so all the information I want is in the few GBs of data in my .bitcoin folder?
27 2013-03-10 00:07:47 <HM> we have the technology
28 2013-03-10 00:07:48 <remote> I thought you said otherwise
29 2013-03-10 00:07:50 <HM> we can reindex it
30 2013-03-10 00:08:02 <CodeShark> it's there but it's not necessarily accessible via RPC, remote
31 2013-03-10 00:08:09 <remote> great
32 2013-03-10 00:08:11 <CodeShark> nor is it in a format that makes rapid queries feasible
33 2013-03-10 00:09:52 * HM wonders if Apache Thrift has managed to implement actual async rpc yet
34 2013-03-10 00:09:53 <remote> doesnt' matter I'll reindex it :)
35 2013-03-10 00:10:04 <remote> thanks!
36 2013-03-10 00:10:11 <CodeShark> yw
37 2013-03-10 00:10:59 <HM> argh, i hate projects that are ridiculously active but only make minor releases every 78 years
38 2013-03-10 00:12:27 <xjrn> hm which?
39 2013-03-10 00:13:09 <HM> Thrift
40 2013-03-10 00:15:47 <HM> the code is nice though
41 2013-03-10 00:17:49 <xjrn> it's active, so can you pull trunk ?
42 2013-03-10 00:21:01 <HM> yup
43 2013-03-10 00:21:19 <HM> what sucks is they have their own custom JSON RPC format
44 2013-03-10 00:21:54 <HM> I think I also wrote it off previously because you can't do multiplexing, or non-blocking calls at the clientside
45 2013-03-10 00:22:06 grau has joined
46 2013-03-10 00:23:18 <xjrn> sipa: so i should send a submission to the hardfork wishlist?
47 2013-03-10 00:25:16 <sipa> depends what you want to change: blocks themself, or just how they are stored
48 2013-03-10 00:25:26 <sipa> seems you're mainly talking about the latter, and that is easy
49 2013-03-10 00:26:31 B0g4r7 has quit (Ping timeout: 276 seconds)
50 2013-03-10 00:28:52 <xjrn> sipa: storage is cheap, not concerned about that, but rolling up tx in a miner and increasing the amount of tx that a block can accomodate, particularly by relative addressing wins against spammers
51 2013-03-10 00:29:35 <xjrn> the same megabyte can hold a lot more tx if a potential token is ~16 bytes instead of hundreds
52 2013-03-10 00:30:32 <sipa> xjrn: if storage is cheap, we don't care about whether N or 2*N transactions fit in a megabyte?
53 2013-03-10 00:30:48 <xjrn> sipa the number of tx is finite, so more fees can fit in a megabyte
54 2013-03-10 00:32:33 <xjrn> fees also stand to be lower and stay lower longer, if the tx can be trimmed to relative references
55 2013-03-10 00:34:11 B0g4r7 has joined
56 2013-03-10 00:34:36 <xjrn> it doesn't fundamentally change anything about existing blocks, previous blocks, interactions between blocks, or any other procedure that im aware of, to say that wallet 1FooVar is identical to coordinate (hieght -y ,tx +x )
57 2013-03-10 00:35:43 <sipa> except it means you need the block at height-y to be able to understand the block at height
58 2013-03-10 00:36:00 <xjrn> its just normalization. it could be demonstrated on the blockchain storage as a precursor to hardforking acceptable blocks, but i would rather normalize existing things than add anachronistic shitlists to a simple feedback loop
59 2013-03-10 00:36:02 <sipa> which is fine for archive storage, but not really for fast processing
60 2013-03-10 00:36:34 <xjrn> sipa: it implies a cache of hot resolved data
61 2013-03-10 00:36:44 <xjrn> there already is one anyways iiuuc
62 2013-03-10 00:36:58 <xjrn> an index at least
63 2013-03-10 00:37:43 <sipa> the only index in bitcoind 0.8 is one for mapping blockhashes to their disk position
64 2013-03-10 00:37:45 <nanotube> anyone else seeing message clipping like this on the bitcoin-qt startup banner? http://imgur.com/wnJypCB
65 2013-03-10 00:38:35 <xjrn> how does block at height-y which holds first, or most recent occurence of a script token forinstance, require block at hieght?
66 2013-03-10 00:39:13 <sipa> the other way around
67 2013-03-10 00:39:38 <sipa> if you're going to use references to a previous block and tx index in it, you need the referenced block to be present to decode
68 2013-03-10 00:40:04 <xjrn> block at current height would need to jump down to the useable strings in blockchain history, borrow a token, and proceed.
69 2013-03-10 00:40:32 <sipa> so, it needs that block to be present
70 2013-03-10 00:40:35 <xjrn> isn't that more or less doable but not implemented? currently, block at hieght is atomic, potentially redundant
71 2013-03-10 00:40:54 <sipa> yes, for archive that is possible
72 2013-03-10 00:41:08 <sipa> i.e. serving historic blocks
73 2013-03-10 00:41:32 <xjrn> hell, 20 years out that's a job for some rpc service anywaysl
74 2013-03-10 00:41:53 <xjrn> at 52 gigs per year potentnial
75 2013-03-10 00:43:56 <xjrn> someone's going to desire a terrabyte be normalized. someone's going to desire a megabyte of tx to be normalized, it's just currently a fledgling system. noone starts out testing a prototype by locking up representations in data compression
76 2013-03-10 00:44:13 <xjrn> but eventually it makes sense to tweak a fewe things
77 2013-03-10 00:46:30 <xjrn> once you establisha relaible coordinate system of height -y[optional discriminator], tx+x, you can start to apply non-integral offset encodings like huffman trees and markov chains, to encode what is higher frequency data
78 2013-03-10 00:47:07 <sipa> yeah, sure for archive such things make sense
79 2013-03-10 00:47:24 <xjrn> why not to normalize what's in the sacred megabyte as well against same archive?
80 2013-03-10 00:47:33 HM has quit (Read error: Connection reset by peer)
81 2013-03-10 00:47:53 <sipa> because blocks shouldn't need access to previous blocks
82 2013-03-10 00:47:58 HM has joined
83 2013-03-10 00:47:59 <sipa> that would kill verification performance
84 2013-03-10 00:48:07 <sipa> and make pruning impossible
85 2013-03-10 00:48:26 <sipa> and it can't give you more than a constant factor of gain
86 2013-03-10 00:48:29 <xjrn> pruning would be unnecessary as well though
87 2013-03-10 00:48:35 <sipa> wut??
88 2013-03-10 00:48:48 HiWEB has quit (Quit: Gotta Jibboo)
89 2013-03-10 00:49:25 twobitcoins has quit (Quit: Leaving)
90 2013-03-10 00:51:24 <xjrn> what is verification performance on block per 10 minutes?
91 2013-03-10 00:51:36 <xjrn> is that expected to change?
92 2013-03-10 00:52:34 <sipa> just to get things straight: you are proposing to change the block format to a form where reuse of the same script or txid gets replaced by some reference to a previous block?
93 2013-03-10 00:53:16 <sipa> meaning that processing an incoming block would require fast access to every older block, which may hold data to be referenced?
94 2013-03-10 00:53:23 <xjrn> you are saying that while a block is being created you want to avoid the latency of encoding backrefs to increase the tx-width potential of a megabyte?
95 2013-03-10 00:53:38 defunctzombie_zz is now known as defunctzombie
96 2013-03-10 00:53:55 <sipa> latency of encoding, but mostly decoding
97 2013-03-10 00:54:08 <sipa> it would severely impact block propagation speed
98 2013-03-10 00:54:27 <xjrn> who will be verifying tx in 20 years that doesnt have access to the full potential terabyte of blockchain history?
99 2013-03-10 00:54:49 <sipa> you don't need access to the full blockchain history to verify a block!
100 2013-03-10 00:55:07 <sipa> you only need fast access to the UTXO set
101 2013-03-10 00:55:13 BenderCoin has quit (Ping timeout: 257 seconds)
102 2013-03-10 00:55:49 <xjrn> and how fragmented will that UTXO set be in 20 years for 21 million coins?
103 2013-03-10 00:57:56 <Luke-Jr> lol, 20 years
104 2013-03-10 00:58:12 <Luke-Jr> as if we'll reach the total in the next century
105 2013-03-10 01:00:25 <weex> hopefully in 20 years there'll be 100 utxo for every person alive
106 2013-03-10 01:02:50 <xjrn> so again, how taxing is it to verify a block per 10 minutes? am i missing something? Ed25519 makes sense to roll into a hard fork i guess, yeilding "A quad-core 2.4GHz Westmere signs 109000 messages per second."
107 2013-03-10 01:07:21 <xjrn> 50,000 tx per block at some ridiculous optimistic 20 bytes per tx unsorted, 100% low entropy trades to the history of the blockchain would be worth the fees, the greater the spam the denser the fees
108 2013-03-10 01:08:13 <xjrn> s/unsorted/sorted/
109 2013-03-10 01:10:46 copumpkin has quit (Ping timeout: 240 seconds)
110 2013-03-10 01:11:01 <xjrn> it seems that trades do not require backrefs over the wire, if noone complains about the bandwidth to relay atomic representations. that wouldn't prevent two competing miners, one using high entropy encoding of a block and one using low entropy to publish on 2 compatibility standards, and the normalized form exported to the de-nromalized form and sent over the wire to UTXO-only nodes
111 2013-03-10 01:11:22 copumpkin has joined
112 2013-03-10 01:12:28 <petertodd> https://github.com/bitcoin/bitcoin/pull/2351 <- new pull-req to prevent creation and relaying of transactions with txouts with value <= fees (uneconomical to spend)
113 2013-03-10 01:12:48 <petertodd> Blocks dead puppies, without specifically blocking dead puppies.
114 2013-03-10 01:15:59 <xjrn> petertodd: "Keeps the UTXO set from being bloated" -- UTXO set doesn't appear in the bitcoin Target
115 2013-03-10 01:17:18 road33 has quit (Ping timeout: 248 seconds)
116 2013-03-10 01:17:22 <petertodd> xjrn: huh?
117 2013-03-10 01:17:24 <xjrn> petertodd: I'm pointing this out to note that the wiki docs i read to become familiar with the bitcoin mechanics excluded local caches as a supported feature
118 2013-03-10 01:17:46 <petertodd> xjrn: What do you mean by "local caches"?
119 2013-03-10 01:18:23 <xjrn> I guess i need ot read what UTXO is, if not a local cache of coins\
120 2013-03-10 01:18:35 <petertodd> xjrn: Yes, that has nothing to do with that...
121 2013-03-10 01:22:13 MiW has quit (Read error: Connection reset by peer)
122 2013-03-10 01:23:22 BenderCoin has joined
123 2013-03-10 01:24:47 <nanotube> petertodd: even though a single small txo may be uneconomical to spend, it may be economical to put several of those into a transaction and recover some money. does your patch consider that?
124 2013-03-10 01:25:13 HM has quit (Read error: Connection reset by peer)
125 2013-03-10 01:25:14 <nanotube> also, it may be that as bitcoins appreciate faster than transaction volume grows, min fees may shrink to make previously 'too small' outputs economical to spend...
126 2013-03-10 01:25:21 HM has joined
127 2013-03-10 01:26:17 <petertodd> nanotube: Yes. Spending a UTXO does require a marginal increase in the amount of bytes a transaction has, always less than a bit under 1000 bytes.
128 2013-03-10 01:27:02 <petertodd> nanotube: It may, but I don't see the block size limit being changed soon, if at all, so we can't expect minimum fees to shrink much if at all.
129 2013-03-10 01:27:04 <gmaxwell> nanotube: I haven't read the latest revision of the patch but if its correctly constructed it should be based on the minimum marginal increase, such that your combining argument never applies.
130 2013-03-10 01:27:57 <gmaxwell> petertodd: uh. your argument there doesn't apply. Say tomorrow bitcoin stared reliably trading at $1000. Fees would go down by 1000/40 ish.
131 2013-03-10 01:28:03 <petertodd> gmaxwell: Exactly. It doesn't figure out the marginal increase explicitly, but because scriptSigs > 500 bytes are non-standard, you can bound that increase pretty easily, so pricing the min amount allowed out as the cost of 1KB in transaction fees is pretty close to correct, and allows for some profit in spending them.
132 2013-03-10 01:28:31 <gmaxwell> petertodd: I think it should probably be conservative in the other direction. E.g. assuming they add about 200 bytes.
133 2013-03-10 01:28:36 <petertodd> gmaxwell: Yes, but in that case people would have to change the DUST constant and MIN_TX_FEE constants, and my patch sets the minimum fees based on that, so it'll work automatically.
134 2013-03-10 01:29:00 <petertodd> gmaxwell: If you want to be conservative, use MIN_RELAY_TX_FEE instead.
135 2013-03-10 01:29:08 <petertodd> (as the absolute minimum)
136 2013-03-10 01:29:28 <gmaxwell> petertodd: using fee/kb * .200 is more adaptive.
137 2013-03-10 01:29:30 RazielZ has quit (Ping timeout: 256 seconds)
138 2013-03-10 01:29:43 <petertodd> gmaxwell: That's what the patch does, but * 1
139 2013-03-10 01:30:07 <gmaxwell> or max(MIN_RELAY_TX_FEE*0.2, fee/kb * .2)
140 2013-03-10 01:30:15 <petertodd> gmaxwell: Go read it...
141 2013-03-10 01:30:22 <gmaxwell> (the .2 is just assuming a conservative marginal increase is 200 bytes, I haven't checked)
142 2013-03-10 01:31:02 <gmaxwell> the reason you want to be conservative here is that to avoid denying valid uses you want to allow just-barely profitable utxo. Only the grossly uneconomical ones should be prohibited.
143 2013-03-10 01:31:26 <nanotube> mmk
144 2013-03-10 01:31:32 <petertodd> gmaxwell: You understand that it's basing the assumption on the actual fee per kb the tx paid, bounded below and above right?
145 2013-03-10 01:31:38 <gmaxwell> nanotube: the other issue you have is that a large fraction of uneconomical utxo will be lost forever even before increase in bitcoin value makes them worth redeeming.
146 2013-03-10 01:32:09 <nanotube> lost forever how?
147 2013-03-10 01:32:10 <gmaxwell> petertodd: I do. Did you ever find the discussion in here where vinny_win proposed that ahead of you and I thought it was fantastic? :P
148 2013-03-10 01:32:44 <petertodd> gmaxwell: Yeah, I went off and wrote the patch rather than wasting time looking it up.
149 2013-03-10 01:33:00 <gmaxwell> nanotube: I've seen a bunch of people in IRC do this: they get a whole bunch of utx adding up to like 0.009 BTC .... and they can't spend them, so they delete the wallet.
150 2013-03-10 01:33:04 road33 has joined
151 2013-03-10 01:33:13 <nanotube> ah heh ic.
152 2013-03-10 01:33:13 <gmaxwell> I've successfully talked at least three people into giving me their wallets instead of doing that.
153 2013-03-10 01:33:29 <nanotube> well, that strikes me more of a human problem than a bitcoin problem. :)
154 2013-03-10 01:33:49 <petertodd> gmaxwell: Which is why I don't want to be too conservative, I want the value to be clearly worth spending.
155 2013-03-10 01:34:20 <xjrn> so trading value below the fee gets rejected; what about free tx below the fee?
156 2013-03-10 01:34:37 <gmaxwell> xjrn: MIN_RELAY_TX_FEE is treated as the fee there, right petertodd
157 2013-03-10 01:34:44 <petertodd> xjrn: If you have an output < 0.01 btc, you are forced to pay a fee anyway.
158 2013-03-10 01:34:46 <gmaxwell> (I still haven't looked at the patch :P )
159 2013-03-10 01:35:09 * petertodd stops talking to gmaxwell until he reads it
160 2013-03-10 01:35:10 <xjrn> free tx is now a hypothetical, but coerced otherwise
161 2013-03-10 01:35:32 <gmaxwell> xjrn: what are you trolling about?
162 2013-03-10 01:35:44 <gmaxwell> petertodd: part of the sugar in jgarzik's patch was changing that to 0.0001. Thats perhaps something you should retain if you didn't.
163 2013-03-10 01:36:09 <xjrn> did you pay fees on those 3 wallets to close them out?
164 2013-03-10 01:36:40 <gmaxwell> xjrn: no, didn't have to, too their unspent outputs and spent them in other regular transactions I made while doing other things.
165 2013-03-10 01:37:08 <gmaxwell> s/too/took/
166 2013-03-10 01:39:01 <xjrn> gmaxwell so what's your take on raising the entropy of a block's transaction representations to pack more of them side by side?
167 2013-03-10 01:39:11 <gmaxwell> petertodd: in any case, someone may rightfully feel that their really small txout is hardly worth redeeming today, but later it will be worth redeeming.
168 2013-03-10 01:40:03 <gmaxwell> xjrn: if someone wants to write an alternative p2p protcol that seralizes blocks differently in order to take less bandwidth, thats great... and it's something they can do on their own without seeking my approval.
169 2013-03-10 01:40:35 <gmaxwell> (likewise for on disk storage)
170 2013-03-10 01:41:43 <gmaxwell> though also, the assumption that a node has the full history is a terrible one, we've specifically designed the system so that even full validators don't need the whole history. Plus that assumption implies poor locality, which is bad for performance. Fortunately, I'm sure you can do smarter seralization without having those constraints.
171 2013-03-10 01:42:16 <xjrn> gmaxwell: I'm under the impression that the blockchain history and all of its constituent protocols and assemblies are in fact denormalized toa point that can't get further denormalized. just the act of normalizing data seems like a good idea
172 2013-03-10 01:42:20 <gmaxwell> (by 'don't need the whole history' I mean don't need to store it. They can observe it and forget the far past history)
173 2013-03-10 01:42:34 RainbowDashh has joined
174 2013-03-10 01:43:33 <gmaxwell> oh it's far from denormalized. For example, prior transactions are referenced by their txid and not by their content. It would actually make some things a lot easier if it were less normalized.
175 2013-03-10 01:44:08 <xjrn> new info for me, while i frantically try to find source info on what UTXO is
176 2013-03-10 01:44:19 <gmaxwell> unspent transaction output.
177 2013-03-10 01:44:46 <xjrn> this is now a seperate ledger from the blockchain history with a support system of coders now
178 2013-03-10 01:45:10 B0g4r7 has quit (Ping timeout: 276 seconds)
179 2013-03-10 01:45:40 <gmaxwell> xjrn: the system has _always_ used an index of unspent transactions. Otherwise computational complexity of verifying transactions is exponential.
180 2013-03-10 01:45:58 <gmaxwell> Previously the same index also had spent transactions. (unspent vs spentness was just a flag).
181 2013-03-10 01:47:01 <xjrn> it doesnt show up in the bitcoin 101 newby pages that describes the basics, from 2010 or whenever they were written. i understand what it is is no diffrent than what existed before, ina diffrent form. it now seems utxo is this z80 processor at the heart of the bitcoin network which is defining reasons to make exxception to the original tx rules
182 2013-03-10 01:47:03 <gmaxwell> Bitcoin-qt now instead no longer indexes spent transactions and uses an optimized datatructure for unspent txn that include inline all the data needed to validate spenders of those input transactions (which is a small fraction of the transaction's size)
183 2013-03-10 01:47:31 clown690 has joined
184 2013-03-10 01:47:36 gritcoin has joined
185 2013-03-10 01:48:11 <gmaxwell> xjrn: bitcoin 101 pages don't describe anything remotely this tecnial. Don't have a clue what you mean by 'defining reasons to make exxception to the original tx rules'.
186 2013-03-10 01:48:21 <xjrn> don't tax the z80 processor
187 2013-03-10 01:48:56 <gmaxwell> The importance of the utxo set is indicated in the original whitepaper (published long before the system), though we use different language now.
188 2013-03-10 01:49:21 <gmaxwell> See section 7. http://bitcoin.org/bitcoin.pdf
189 2013-03-10 01:51:08 <gmaxwell> The utxo set is just what you get when you carry section 7 to its logical conclusion. Thats what the patch implementing it was called ...
190 2013-03-10 01:51:11 <gmaxwell> ... 'ultraprune'[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C ...
191 2013-03-10 01:51:17 <gmaxwell> ... [C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C.
192 2013-03-10 01:51:22 <gmaxwell> oops sorry about that. weird irc glitch
193 2013-03-10 01:51:30 <xjrn> utxo hamster wheels aside, references which exist as txid's consumeing n bits can be squeezed into coordinate systems of probablistic lookup bits to describe frequent things more tersley than atomic things.
194 2013-03-10 01:51:32 <gmaxwell> was called 'ultraprune'
195 2013-03-10 01:52:16 <gmaxwell> When bitcoin is used correctly virtually all of the high entroy data is atomic.
196 2013-03-10 01:52:44 <gmaxwell> I am unwilling to entertain optimizations which encourage and only work with behavioral changes which undermine the privacy properties of the system.
197 2013-03-10 01:52:47 <xjrn> i guess while my fortune builds at .05 BTC per day i may work on researching where to the low entropy lives
198 2013-03-10 01:53:32 defunctzombie is now known as defunctzombie_zz
199 2013-03-10 01:54:23 B0g4r7 has joined
200 2013-03-10 01:55:08 <xjrn> right, you cannot reduce a hash to fewer bits than a certain constant. it's not worth gzipping the hash value though you could refer to prior blocks, a coordinate system, to normalize giant byte counts for recurring scripts and tx's
201 2013-03-10 01:55:42 <xjrn> i don't know how the recurrence of a script from prior blockchain would compromise privacy
202 2013-03-10 01:56:01 <xjrn> it is just re-expressed in the current tx's
203 2013-03-10 01:57:03 <xjrn> if huffman encoding were applied to the occurences of spammers, those spammers would need the fewest bits to represent an event
204 2013-03-10 01:58:02 <xjrn> it seems more elegant than pitchforks and fees with fine print
205 2013-03-10 01:58:38 JZavala has quit ()
206 2013-03-10 02:02:58 JZavala has joined
207 2013-03-10 02:04:08 Diablo-D3 has quit (Quit: This computer has gone to sleep)
208 2013-03-10 02:05:30 brwyatt is now known as brwyatt|Away
209 2013-03-10 02:07:12 <gmaxwell> xjrn: a script never reoccurs unless a user reuses a public key. (and even then, most of the data does not reoccur)
210 2013-03-10 02:07:39 <gmaxwell> and doing so compromises everyone's privacy.
211 2013-03-10 02:07:44 clown690 has quit (Remote host closed the connection)
212 2013-03-10 02:08:26 <xjrn> at what point does the pubkey get re-generated?
213 2013-03-10 02:09:23 <xjrn> i was under the impression it would live as long as the passphrase assigned
214 2013-03-10 02:09:48 <gmaxwell> As the system was envisioned (section 10 of bitcoin.pdf) every payment pays to a different public key.
215 2013-03-10 02:09:55 <gmaxwell> passphrase ?! no.
216 2013-03-10 02:14:54 road33 has quit (Remote host closed the connection)
217 2013-03-10 02:15:19 road33 has joined
218 2013-03-10 02:15:45 <xjrn> gma "The public can see that someone is sending
219 2013-03-10 02:15:47 <xjrn> an amount to someone else, but without information linking the transaction to anyone."
220 2013-03-10 02:16:55 <xjrn> gmaxwell "The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone." does not jive with what's available on blockexplorer, blockchain.info, etc. most of my payments arrive when I'm offline generating no new public keys.
221 2013-03-10 02:18:39 gritcoin has quit (Quit: gritcoin)
222 2013-03-10 02:19:01 <Luke-Jr> oh great, now gavin is giving SatoshiDice a privileged effective-veto on changes to the codebase?
223 2013-03-10 02:19:15 <xjrn> section 10 seems like an idealism
224 2013-03-10 02:19:24 <gmaxwell> xjrn: huh? you being online doesn't matter.
225 2013-03-10 02:19:40 <Luke-Jr> gmaxwell: did I read that right?
226 2013-03-10 02:19:42 <gmaxwell> xjrn: you have to give the party that pays you an address to pay.
227 2013-03-10 02:20:03 <gmaxwell> Luke-Jr: I think you're reading too much into it.
228 2013-03-10 02:20:43 <gmaxwell> Luke-Jr: he listed a bunch of stuff like "how it affects users who might already have coin dust in their wallets" which the code doesn't effect, but people would have questions about.
229 2013-03-10 02:20:51 <xjrn> and when my friend gives me his address i can see the entire history of that address, likewise for myself, until such time asss i change
230 2013-03-10 02:21:13 <gmaxwell> xjrn: thats your confusion. Have you ever actually used bitcoin? Users don't just have one address.
231 2013-03-10 02:21:26 denisx has quit (Quit: denisx)
232 2013-03-10 02:21:48 <xjrn> sureeeeee, i do not keep generating new addresses and pasting them into my miner account, though I could.
233 2013-03-10 02:21:57 <gmaxwell> You normally issue a new address every time you recieve a paymentâ thats how you tell who paid you for what. Everytime the software creates a transaction that has change it uses a new address, etc.
234 2013-03-10 02:22:21 MiW has joined
235 2013-03-10 02:23:00 <gmaxwell> xjrn: even in that caseâ (which should be accomplished with a chain, but thats not implemented yet) you'd still use that address only for that one sender.
236 2013-03-10 02:23:39 xempew has joined
237 2013-03-10 02:23:47 <xjrn> so 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB is a wallet but not an address, and you retaaaain this wallet while an address changes?
238 2013-03-10 02:24:39 <gmaxwell> https://en.bitcoin.it/wiki/BIP_0032#Recurrent_business-to-business_transactions:_M.2Fi.2F0 (for the chain stuff)
239 2013-03-10 02:24:51 <gmaxwell> xjrn: no its not a wallet.
240 2013-03-10 02:25:10 <gmaxwell> Actually it's just a private key that isn't even loaded into a node. Every transaction I make involving that I make by hand.
241 2013-03-10 02:25:30 <gmaxwell> Alsoâ stalk much? :P
242 2013-03-10 02:25:48 <xjrn> http://blockchain.info/address/1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB most certainly does not accord to section 10, all is revealed.
243 2013-03-10 02:25:59 <gmaxwell> xjrn: all of what is revealed.
244 2013-03-10 02:26:00 <gmaxwell> ?
245 2013-03-10 02:26:11 <gmaxwell> And yes, public donation addresses do not accord to section 10.
246 2013-03-10 02:26:32 D34TH has quit (Quit: Leaving)
247 2013-03-10 02:27:30 <xjrn> there was my confusion in that you stated new addresses "are generated each", but i think in the real world, that's probably more popular with a small group than the majority
248 2013-03-10 02:27:58 ahbritto has quit (Ping timeout: 250 seconds)
249 2013-03-10 02:28:30 <xjrn> so in the real world, you, me, Luke-Jr, and a ton of other happless targets use a low entropy blockchain representation over the course of time
250 2013-03-10 02:28:32 ahbritto_ has quit (Ping timeout: 272 seconds)
251 2013-03-10 02:28:39 xempew has quit (Quit: xempew)
252 2013-03-10 02:28:54 <xjrn> searchable by a free tool
253 2013-03-10 02:29:33 <xjrn> it makes sense to consider this apt for a tokenization, and hell, a cheaper fee by virtue of fewer bits
254 2013-03-10 02:30:55 <gmaxwell> xjrn: it's the default behavior of the software. the vast majority of my coins are in one use addresses. The 1GMaxweLLb is special because its a vanity address.
255 2013-03-10 02:31:16 <xjrn> i get that, i didnt get your blankeeet statement before.
256 2013-03-10 02:32:31 <gmaxwell> xjrn: Not sure what you didn't get.
257 2013-03-10 02:32:49 <gmaxwell> bbl
258 2013-03-10 02:33:12 HM has quit (Read error: Connection reset by peer)
259 2013-03-10 02:35:47 <xjrn> gmaxwell: "You normally issue a new address every time you recieve a payment" -- couldn't reconcile this with what i know.
260 2013-03-10 02:36:04 <xjrn> gmaxwell: cya
261 2013-03-10 02:40:15 HM has joined
262 2013-03-10 02:45:03 sudofox has joined
263 2013-03-10 02:45:10 <sudofox> Hi! ^-^
264 2013-03-10 02:46:31 <sudofox> Does anyone happen to know how to use grondilu's Bitcoin Bash Tools? I'm struggling, and need to input a SHA256 and have it spit out a Bitcoin ready base58check private key.
265 2013-03-10 02:46:44 <sudofox> ..
266 2013-03-10 02:46:54 <sudofox> There's more steps in there, but..
267 2013-03-10 02:48:42 <oGminor> I lost my bitcoin wallet password, would it be possible/faster to check versions of what I think it is by extracting some function that tries to decrypt from the client over using the json RPC?
268 2013-03-10 02:49:21 <sudofox> What?
269 2013-03-10 02:49:26 <jgarzik> sipa: sigh... vvv
270 2013-03-10 02:49:32 hydrogenesis has joined
271 2013-03-10 02:49:35 <jgarzik> "The minikey always uses uncompressed public keys.
272 2013-03-10 02:49:35 <jgarzik> I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. "
273 2013-03-10 02:49:36 <jgarzik> https://bitcointalk.org/index.php?topic=150715.msg1604781#msg1604781
274 2013-03-10 02:50:04 <sipa> jgarzik: we need to apply some pressure on him, i think
275 2013-03-10 02:50:12 <sudofox> I use multibit..
276 2013-03-10 02:50:14 <sipa> pressure -> compression... get it?
277 2013-03-10 02:50:19 <jgarzik> ;p
278 2013-03-10 02:50:24 <sudofox> Bwahahaha
279 2013-03-10 02:50:43 <sudofox> @jgarzik # Format: # <Base58 encoded private key>[<whitespace>[<key createdAt>]]
280 2013-03-10 02:51:39 <gmaxwell> Is it sad that I know it's casascius purely by the unfortunateness of the position? :(
281 2013-03-10 02:51:52 <sudofox> @jgarzik Here's a privkey export/import file, the paste will expire in 10 minutes
282 2013-03-10 02:51:53 <sudofox> http://pastebin.com/Y79Vbaq9
283 2013-03-10 02:52:19 <sudofox> The privkeys there won't be used.
284 2013-03-10 02:53:31 <sudofox> Anyways, my question is (probably too trivial to stick on the Stack|Exchange site at the present time): How do I use grondilu's bitcoin-bash-tools ? It's a shell script.
285 2013-03-10 02:54:04 B0g4r7 has quit (Ping timeout: 276 seconds)
286 2013-03-10 02:55:04 <sudofox> Dang it..
287 2013-03-10 02:56:57 coolsa has quit (Quit: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
288 2013-03-10 02:58:39 zooko has quit (Remote host closed the connection)
289 2013-03-10 03:01:24 Apexseals has quit (Ping timeout: 255 seconds)
290 2013-03-10 03:01:42 JZavala has quit (Ping timeout: 276 seconds)
291 2013-03-10 03:01:47 Apexseals has joined
292 2013-03-10 03:01:53 JZavala has joined
293 2013-03-10 03:01:54 fishfish is now known as fishfish|AFK
294 2013-03-10 03:02:25 rbecker is now known as RBecker
295 2013-03-10 03:02:28 bock has quit (Remote host closed the connection)
296 2013-03-10 03:02:58 B0g4r7 has joined
297 2013-03-10 03:03:26 defunctzombie_zz is now known as defunctzombie
298 2013-03-10 03:05:55 Goonie has quit (Ping timeout: 260 seconds)
299 2013-03-10 03:06:39 xempew has joined
300 2013-03-10 03:08:45 zooko has joined
301 2013-03-10 03:09:20 hydrogenesis has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
302 2013-03-10 03:09:25 <warren> petertodd: btw, what about discouraging outputs < fee in cases where it is spending 0-conf?
303 2013-03-10 03:09:53 <warren> petertodd: that'd make fewer people concerned
304 2013-03-10 03:10:46 <gmaxwell> warren: that just becomes a lot more complicated to reason about and doesn't actually address the concern of creating uneconomic to spend data. You're overfitting on specific cases.
305 2013-03-10 03:11:14 <warren> ok
306 2013-03-10 03:12:06 JZavala has quit (Ping timeout: 276 seconds)
307 2013-03-10 03:15:41 <jgarzik> that was a quick close of #2351
308 2013-03-10 03:15:57 <jgarzik> I think I have a looser definition of pull request than Gavin ;p
309 2013-03-10 03:16:46 HM has quit ()
310 2013-03-10 03:16:51 rg- has quit (Ping timeout: 245 seconds)
311 2013-03-10 03:17:02 <jgarzik> A pull request is valid if it _could_ be pulled immediately [if the community / devs / etc. like it]
312 2013-03-10 03:17:22 <jgarzik> Certainly that is a very loose definition that could be abused
313 2013-03-10 03:17:43 sudofox has quit (Ping timeout: 245 seconds)
314 2013-03-10 03:18:19 RainbowD_ has joined
315 2013-03-10 03:19:12 MrKain has joined
316 2013-03-10 03:19:50 RainbowDashh has quit (Ping timeout: 272 seconds)
317 2013-03-10 03:19:51 RainbowD_ is now known as RainbowDashh
318 2013-03-10 03:20:26 <mogri> it's an ok definition jgarzik
319 2013-03-10 03:22:01 <warren> jgarzik: is the decision making process written down anywhere?
320 2013-03-10 03:24:15 he1kki has quit (Ping timeout: 252 seconds)
321 2013-03-10 03:24:16 ainfo has quit (Ping timeout: 252 seconds)
322 2013-03-10 03:24:55 ainfo has joined
323 2013-03-10 03:25:14 he1kki has joined
324 2013-03-10 03:27:06 <gmaxwell> warren: there are 9 people who can commit to the repository, 5 who do with any frequency. This doesn't require a ton of procedure documentation.
325 2013-03-10 03:27:45 <warren> general consensus then
326 2013-03-10 03:27:58 <sipa> basically, yes
327 2013-03-10 03:31:52 <petertodd> jgarzik: Just definitions of what a pull-req is for; I'll post my full write-up to bitcoin-dev in another hour or two.
328 2013-03-10 03:34:05 fiesh_ has quit (Ping timeout: 276 seconds)
329 2013-03-10 03:34:21 RainbowDashh has quit (Quit: Quit. <redacted> I joked I would replace all her sensitive files on her old computer with ponies so nothing could be recovered.)
330 2013-03-10 03:34:52 RainbowDashh has joined
331 2013-03-10 03:36:31 fiesh has joined
332 2013-03-10 03:37:34 <jgarzik> less consensus required for closing a pull req though
333 2013-03-10 03:37:52 <jgarzik> since it is easy to reopne
334 2013-03-10 03:37:54 aethero has joined
335 2013-03-10 03:37:54 <jgarzik> *reopen
336 2013-03-10 03:38:12 <jgarzik> easier for a dev to be grumpy ;p
337 2013-03-10 03:38:49 <aethero> What are the plans for Bitcoin when quantum computing becomes mainstream and ECDSA becomes significantly weaker?
338 2013-03-10 03:39:09 <sipa> aethero: die
339 2013-03-10 03:39:21 <aethero> I prefer living, thanks.
340 2013-03-10 03:39:33 <sipa> haha, it was not an imperative!
341 2013-03-10 03:39:39 asd34sd has joined
342 2013-03-10 03:39:40 <asd34sd> hi
343 2013-03-10 03:39:50 <asd34sd> im trying to compile BFGminer but having some issues , says configure error: cannot find install-sh, install.sh, or shtool
344 2013-03-10 03:41:02 <sipa> aethero: more seriously: it won't be a sudden break most likely, and if it becomes apparent that ECDSA would become too weak, a hard fork that introduced a new QC-resistant cryptographic primitive would become significantly easier
345 2013-03-10 03:41:23 <aethero> Why not introduce that into the next fork?
346 2013-03-10 03:42:25 <sipa> QC cryptography has large disadvantages (afaik, i'm no expert), large key sizes for one
347 2013-03-10 03:42:40 <sipa> and at this point there is no reason to assuem that QC will ever be actually possible at that scale
348 2013-03-10 03:45:37 <warren> Worry about other two letter names before QC.
349 2013-03-10 03:48:11 <phantomcircuit> sipa, gigantic key sizes
350 2013-03-10 03:48:22 MashRinx has joined
351 2013-03-10 03:49:30 <gmaxwell> gigantic signature sizes. We can always solve key sizes in our system, keys can never be too gigantic for us. :P
352 2013-03-10 03:52:52 <gmaxwell> 256-bit lamport results 16kbyte signatures. Which is mildly insane, but then if you're assuming QC you probably want 512 bit lamport, which results in 64kbyte signatures. Plus you can't sign multiple times without leaking your private key. (well, it's not all leaked unless the attacker makes you sign data who's hash is the bitwise compliment of the data you signed before)
353 2013-03-10 03:52:57 vigilyn2 has joined
354 2013-03-10 03:52:58 vigilyn3 has quit (Read error: Connection reset by peer)
355 2013-03-10 03:53:25 <aethero> gmaxwell
356 2013-03-10 03:53:31 <aethero> Right now with how Bitcoin implements ECDSA
357 2013-03-10 03:53:36 <gmaxwell> none of the other post QC signature schemes are really any better (and at least lamport is fast and not obviously less secure than anything we use that isn't QC strong)
358 2013-03-10 03:53:38 <aethero> How vulnerable is it to QC?
359 2013-03-10 03:53:56 <gmaxwell> aethero: It's completely secure so long as QC continue to not exist. :P
360 2013-03-10 03:54:03 <aethero> Har har.
361 2013-03-10 03:54:07 <gmaxwell> (well completely secure against QC so long as QC continue to not exist)
362 2013-03-10 03:54:13 <aethero> If QC exists tomorrow
363 2013-03-10 03:54:26 <aethero> How secure is Bitcoin's implementation of ECDSA the day after?
364 2013-03-10 03:54:39 <gmaxwell> Well, funny but it's a serious point. In engineering you don't just get to state what ifs without their preconditions. If you do you make bad decisions.
365 2013-03-10 03:55:01 <aethero> Are we talking about a halving of the keyspace? Or is it basically useless?
366 2013-03-10 03:55:12 <aethero> Halving of a keyspace already so large that halving doesn't mean anything?
367 2013-03-10 03:55:24 <warren> Hmm, interesting, lamport signatures may only be signed by a key once?
368 2013-03-10 03:55:26 <gmaxwell> "QC" isn't good enough, you need a very large quantum computer, with very large coherence times. And then its useless.
369 2013-03-10 03:55:36 <aethero> Define "very large"
370 2013-03-10 03:55:41 <sipa> aethero: ECDSA becomes fundamentally broken in the presence of general-purpose large-qubit QC
371 2013-03-10 03:56:18 <gmaxwell> If the quantum computer is error free then it takes 4 billion operations on about 4k qbits to solve the 256bit DLP.
372 2013-03-10 03:57:57 <aethero> And Bitcoin uses a 256bit DLP?
373 2013-03-10 03:58:48 defunctzombie is now known as defunctzombie_zz
374 2013-03-10 04:00:04 <gmaxwell> (and this is assuming a idealized QC, anything actual would likely need some large constant factor more operations)
375 2013-03-10 04:00:04 <gmaxwell> and then a potentially exponential number more operations and bits due to error recovery.
376 2013-03-10 04:00:27 <sipa> aethero: EC DLP
377 2013-03-10 04:00:38 <sipa> (which means 128-bit security)
378 2013-03-10 04:00:54 <aethero> Ok then let me rephrase my question even more
379 2013-03-10 04:00:59 <aethero> And I understand the answer is highly hypothetical
380 2013-03-10 04:01:30 <sipa> aethero: given highly idealized general-purpose large-scale QC, ECDSA becomes trivial to crack
381 2013-03-10 04:01:39 * jgarzik rebuilds openssl on Fedora, for the nth time
382 2013-03-10 04:01:56 <aethero> But given the current rate of advancement in quantum computing, assuming no massive breakthroughs, assuming no change in Bitcoin, how long would you wildly guestimate it would be until quantum computing gets to the point where bitcoin in it's current state is broken
383 2013-03-10 04:02:11 <gmaxwell> jgarzik: if we merge a sufficiently complete sipa-turbo ecdsa we wouldn't need openssl EC anymore. :P
384 2013-03-10 04:02:32 <aethero> Are we talking 5 years, or 50?
385 2013-03-10 04:02:49 <sipa> aethero: anything between 5 years and 5 million
386 2013-03-10 04:03:10 <aethero> =[
387 2013-03-10 04:03:17 <canoon> is there planned anything to encourage people to spend insignificant outputs that would build up in the unprunable transactions?
388 2013-03-10 04:03:19 <gmaxwell> aethero: right now there are no quantum turing complete computers of any size that can compute anything. None of the proposed mechnisms seem like they'll obviously scale to many qbits, none have coherence times long enough to do more than a couple operations.
389 2013-03-10 04:03:51 <gmaxwell> It's really hard to estimate the time between 0 and complete. perhaps if we had 8 bit quantum turing complete devices it might be easier to guess.
390 2013-03-10 04:03:54 <warren> I'd love a non-openssl EC for Fedora.
391 2013-03-10 04:04:56 <gmaxwell> It may even turn out that subtle physics limits bound the error rate vs size of QCs and keep solving large DLP on one pratically impossible. This stuff is just too far out to talk about for sure.
392 2013-03-10 04:05:36 <gmaxwell> aethero: if it makes you feel better, if you use bitcoin properlyâ each address only used onceâ the public key is only exposed to QC cracking between the time you announce a transaction and the time it gets mined.
393 2013-03-10 04:05:53 <gmaxwell> So not only would someone need to break ecdsa, they'd need to break it moderately quickly.
394 2013-03-10 04:06:05 <warren> Are there any type-2 deterministic wallets now?
395 2013-03-10 04:06:39 <gmaxwell> on that basis, e.g. 512-768 bit RSA â which is crakable nowâ would be pratically secure if we were using it in bitcoin. (though we'd be upgrading if thats what it used)
396 2013-03-10 04:06:47 <sipa> warren: Armory and Electrum have them
397 2013-03-10 04:06:56 <warren> oh
398 2013-03-10 04:07:09 <warren> sipa: do they rely on openssl ecdsa too?
399 2013-03-10 04:07:54 <sipa> no idea
400 2013-03-10 04:08:32 <remote> how do you get the address from a public key?
401 2013-03-10 04:08:39 unknown45682 has joined
402 2013-03-10 04:09:02 <sipa> remote: you hash it
403 2013-03-10 04:09:27 road33 has quit (Ping timeout: 256 seconds)
404 2013-03-10 04:09:40 <remote> how?
405 2013-03-10 04:09:56 <sipa> RIPEMD160(SHA256(pubkey))
406 2013-03-10 04:10:04 <sipa> and encode that in base58
407 2013-03-10 04:11:12 unknown45682 has quit (2!~unknown45@pool-98-109-227-214.nwrknj.east.verizon.net|Ping timeout: 246 seconds)
408 2013-03-10 04:11:37 <aethero> Reusing addresses shouldn't be considered improper usage imo
409 2013-03-10 04:11:46 <sipa> it should, imo
410 2013-03-10 04:12:04 <aethero> if ECDSA is broken and people lose coins by re-using an address you wont say "Bitcoin isn't broken!" will you?
411 2013-03-10 04:12:49 <sipa> if ECDSA is broken, Bitcoin - in its current form - is broken
412 2013-03-10 04:13:28 <sipa> you can't rely on the short window in which pubkeys are revealed, even when addresses aren't reused
413 2013-03-10 04:13:43 <sipa> but that doesn't mean that reusing an address is no bad idea for other reasons
414 2013-03-10 04:13:52 <gmaxwell> aethero: it's improper usage for reasons that have nothing to do with ECDSA strength. I don't even think satoshi thought of that advantage, it's just a happy (or irrelevant) accident.
415 2013-03-10 04:13:54 <sipa> wait, too many negations
416 2013-03-10 04:14:19 <aethero> lol
417 2013-03-10 04:14:52 hydrogenesis has joined
418 2013-03-10 04:14:52 <gmaxwell> I'm just pointing out that the design of the system makes it less brittle than it could be. It means that if you start thinking 'maaayyybbbe ecdsa isn't secure enough' you can work extra hard to avoid reuse and decrease your exposure while an upgrade is deployed.
419 2013-03-10 04:15:03 <warren> sipa: just consider it both + and - at the same time, as long as you don't look.
420 2013-03-10 04:15:18 <canoon> i was thinking if we calculated the size of transactions for the purpose of fees as "size = real_size + (outputs - inputs) * (size of an average transaction input)", the fee would generally just be based on the size of the outputs which is what people would expect (no excessively large fees) and it would encourage people to spend even insignificant amounts of bitcoins and overtime the same amount of fees would be charged
421 2013-03-10 04:15:23 Namworld has quit ()
422 2013-03-10 04:15:23 <gmaxwell> (As far as properness goes, I refer to the text at the bottom of section 10 in bitcoin.pdf)
423 2013-03-10 04:15:56 <gmaxwell> canoon: hey, that formula looks familar.
424 2013-03-10 04:16:18 <canoon> lol i thought someone might have already come up with it
425 2013-03-10 04:16:22 hydrogenesis has quit (Client Quit)
426 2013-03-10 04:16:28 <gmaxwell> canoon: the problem is that it's not the economically locally-greedy behavior for miners to prefer based on that. So it's not clear to me that it is all that viable.
427 2013-03-10 04:16:55 <canoon> if you use the same method to calculate block size wouldn't it still work?
428 2013-03-10 04:17:24 <gmaxwell> canoon: it's similar to something that I'd proposedâ which was replacing size in priority with size modified by adding in the change in utxo size, plus some scaling.
429 2013-03-10 04:18:12 <gmaxwell> canoon: that's a rule of the system, not something that can at all be easily changed. But right, if $whatever is also the rule that constrains block size then the incentives are all aligned.
430 2013-03-10 04:19:07 Diablo-D3 has joined
431 2013-03-10 04:20:28 GMP has quit (Remote host closed the connection)
432 2013-03-10 04:21:11 <MrKain> I received 0.001 BTC in address 1Dr3G3utLgzvfdBUX5qpCeB33ZXHUxWkcz ,,, but querying this hash in blockexplorer give an error
433 2013-03-10 04:21:11 <gribble> Error: "," is not a valid command.
434 2013-03-10 04:22:47 <canoon> seems like it would be fairly uncontroversial change as it doesn't really negatively affect anyone though
435 2013-03-10 04:23:06 BTCOxygen has joined
436 2013-03-10 04:23:07 B0g4r7 has quit (Ping timeout: 276 seconds)
437 2013-03-10 04:24:26 t7 has quit (Read error: Connection timed out)
438 2013-03-10 04:25:14 t7 has joined
439 2013-03-10 04:25:22 ByronJohnson has quit (Read error: Operation timed out)
440 2013-03-10 04:25:24 BTCOxygen has quit (Ping timeout: 250 seconds)
441 2013-03-10 04:25:33 BTCOxygen is now known as 1!~BTCOxygen@unaffiliated/mroxy/bot/btcoxygen|BTCOxygen
442 2013-03-10 04:25:46 serp has quit (Ping timeout: 240 seconds)
443 2013-03-10 04:26:17 MobiusL has quit (Remote host closed the connection)
444 2013-03-10 04:26:44 ByronJohnson has joined
445 2013-03-10 04:27:21 MobiusL has joined
446 2013-03-10 04:27:44 serp has joined
447 2013-03-10 04:27:44 serp has quit (Changing host)
448 2013-03-10 04:27:44 serp has joined
449 2013-03-10 04:29:44 RainbowDashh has quit (Quit: Sleep. <redacted> I joked I would replace all her sensitive files on her old computer with ponies so nothing could be recovered.)
450 2013-03-10 04:29:51 <remote> MrKain: http://blockchain.info/address/1Dr3G3utLgzvfdBUX5qpCeB33ZXHUxWkcz
451 2013-03-10 04:30:19 <gmaxwell> canoon: we have never had a hardforking change, and such change would be inherently somewhat controversial and risky.
452 2013-03-10 04:30:41 <canoon> wasn't the p2sh change a hardforking change?
453 2013-03-10 04:30:44 <gmaxwell> One problem is that I don't know there there is an obviously right metric.
454 2013-03-10 04:30:48 <gmaxwell> canoon: No sir, absolutely not.
455 2013-03-10 04:31:02 <gmaxwell> (and P2SH wouldn't have been worth making a hardforking change for)
456 2013-03-10 04:31:12 B0g4r7 has joined
457 2013-03-10 04:31:54 <canoon> but if you had nodes with different rules for validating transactions wouldn't that cause a fork?
458 2013-03-10 04:32:01 <canoon> or is there something else different?
459 2013-03-10 04:32:07 <gmaxwell> I suppose what you suggest could be done as a soft forking change so long as the size was also still limited to a million bytes, but then it would only decrease the effective maximum, which is unlikely to be a popular idea. :P
460 2013-03-10 04:32:13 <sipa> P2SH only introduced a backward-compatible change, "soft fork
461 2013-03-10 04:32:29 <gmaxwell> canoon: No, all the old nodes are perfectly happy to accept a valid p2sh chain.
462 2013-03-10 04:33:04 <canoon> wait do they accept blocks even if they have invalid transactions?
463 2013-03-10 04:33:11 <gmaxwell> They're not invalid.
464 2013-03-10 04:33:11 <sipa> no
465 2013-03-10 04:33:14 twobitcoins has joined
466 2013-03-10 04:33:15 MrKain has quit (Quit: Page closed)
467 2013-03-10 04:33:44 <canoon> but if someone spends a p2sh that would be invalid in a non p2sh client wouldn't it?
468 2013-03-10 04:33:47 <gmaxwell> P2SH transactions are valid to old nodes. P2SH only reduced the set of things considered valid, thus its a softforking change.
469 2013-03-10 04:33:50 <sipa> canoon: no
470 2013-03-10 04:34:39 <canoon> hmm...
471 2013-03-10 04:35:01 <sipa> old nodes can't validate the inner script
472 2013-03-10 04:35:17 <sipa> but just call it valid
473 2013-03-10 04:35:35 <canoon> do you mean valid as in like its correctly formatted? it doesn't have to actually verify the input?
474 2013-03-10 04:35:47 <sipa> it does verify the input, according to the old rules
475 2013-03-10 04:36:03 <canoon> wouldn't it pass in one and not pass in the other?
476 2013-03-10 04:36:31 <sipa> and the actual P2SH script - as seen by an old client - is: "push <data representing a script>; hash; check hash == <some value>:"
477 2013-03-10 04:36:52 <sipa> so they validate that the input provides a script whose hash is the P2SH hash
478 2013-03-10 04:37:01 <sipa> but they don't evaluate the inner script
479 2013-03-10 04:37:57 <canoon> ok yeah but what if i send a transaction that is just data that happens to hash to the correct thing?
480 2013-03-10 04:38:12 <sipa> old nodes will consider that valid
481 2013-03-10 04:38:36 <canoon> oh right but there will be enough hashing power on the new chain
482 2013-03-10 04:38:36 <canoon> ok
483 2013-03-10 04:38:41 <canoon> i get it
484 2013-03-10 04:38:49 <sipa> but it doesn't get mined, as P2SH was only introduced when the majority of miners had switched
485 2013-03-10 04:38:52 <sipa> indeed
486 2013-03-10 04:39:42 RainbowDashh has joined
487 2013-03-10 04:41:43 TheSeven has quit (Disconnected by services)
488 2013-03-10 04:41:52 [7] has joined
489 2013-03-10 04:44:11 mapppum is now known as mappum
490 2013-03-10 04:44:56 <gmaxwell> canoon: in any case, I'd suggest improving your metric to size - size_of_txouts_removed + size_of_txouts_created. Effectively that double charges you for bloat you create, or discounts you by bloat you save.
491 2013-03-10 04:45:00 grau_ has joined
492 2013-03-10 04:45:09 <gmaxwell> And then doesn't have any 'average' armwaving parameter.
493 2013-03-10 04:46:43 <gmaxwell> I think that doesn't create any case where you're encouraged to create bloat just so you can get credit for consuming it later.
494 2013-03-10 04:47:27 grau has quit (Ping timeout: 248 seconds)
495 2013-03-10 04:47:47 <canoon> the problem with that method is it ends up costing more to spend it
496 2013-03-10 04:47:54 <canoon> because you really want the txin size
497 2013-03-10 04:49:34 <canoon> and by average i would have just used the size of a uncompressed pubkey + signature or some other fixed number
498 2013-03-10 04:50:25 <canoon> you couldn't just get credit by creating bloat because you would pay for it before anyway
499 2013-03-10 04:51:03 MashRinx has quit (Ping timeout: 245 seconds)
500 2013-03-10 04:51:05 zoinky has joined
501 2013-03-10 04:52:16 <gmaxwell> canoon: I think you're confused or I'm confused at what you're saying.
502 2013-03-10 04:52:41 <gmaxwell> We want the data stored in the UTXO. This is the txouts created in this transaction, or the txouts from the prior transaction that we're removing.
503 2013-03-10 04:53:10 <gmaxwell> Signatures and uncomressed pubkeys have nothing to do with this, as they're just part of the size and never go into the UTXO set.
504 2013-03-10 04:54:47 <canoon> its really just the number of txouts out rather than the size thats important there (as the actually transactions could be indexed on disk)
505 2013-03-10 04:55:20 <canoon> the idea was to effectively pay ahead for the effective cost of redeeming the input
506 2013-03-10 04:55:40 <canoon> so a user wasn't punished from using up small outputs
507 2013-03-10 04:58:24 <canoon> so for a standard transaction the cost effective just becomes outputs * some number
508 2013-03-10 05:07:49 <sipa> petertodd: 80 byte signature?
509 2013-03-10 05:08:00 <canoon> hmm i guess actually you could do max of txout and standard input size to counter both
510 2013-03-10 05:08:11 <petertodd> sipa: Oh right, 72 bytes...
511 2013-03-10 05:08:27 <petertodd> Or 71 or 70 or... :P
512 2013-03-10 05:08:43 defunctzombie_zz is now known as defunctzombie
513 2013-03-10 05:09:18 FredEE has quit (Quit: FredEE)
514 2013-03-10 05:09:20 <gmaxwell> canoon: ... uh. @!*#!( they _are_ on disk.
515 2013-03-10 05:10:15 <gmaxwell> canoon: and longer txouts are possibleâ though indeed most are nonstandard, not all are and should very much cost more.
516 2013-03-10 05:10:27 FredEE has joined
517 2013-03-10 05:11:28 <gmaxwell> canoon: but I see what you're saying wrt prepay.
518 2013-03-10 05:11:48 <canoon> yeah thinking max of txout size and standard input size
519 2013-03-10 05:11:56 <canoon> because then you get both
520 2013-03-10 05:12:06 <gmaxwell> canoon: but at the same time, we do care very much about the actual size of the utxo set and encouraging people to use small utxo (p2sh) even when this means larger scriptsigs.
521 2013-03-10 05:13:20 Conflict has joined
522 2013-03-10 05:13:57 Garr255_ has quit (Read error: Connection reset by peer)
523 2013-03-10 05:14:23 Garr255_ has joined
524 2013-03-10 05:14:23 Garr255_ has quit (Changing host)
525 2013-03-10 05:14:23 Garr255_ has joined
526 2013-03-10 05:15:36 <gmaxwell> canoon: anything involving an average has a parameter to get wrong. :( I'd say "just don't count the scriptsig size at all" except then you get "I've PUSHED rick astley's greatest hits in this signature" :(
527 2013-03-10 05:16:46 xempew has quit (Quit: xempew)
528 2013-03-10 05:16:51 <canoon> yeah i think you got the wrong idea with average i just meant a standard hash160 transaction input
529 2013-03-10 05:17:22 <canoon> so a fixed value
530 2013-03-10 05:17:27 <canoon> it could be larger and wouldn't really matter
531 2013-03-10 05:18:12 <gmaxwell> canoon: great, but what happens when all the scriptsigs are larger people 2of2 multisig p2sh's become common?
532 2013-03-10 05:18:23 defunctzombie is now known as defunctzombie_zz
533 2013-03-10 05:19:30 <canoon> well the prepay problem is only when it costs more to redeem a transaction than its value
534 2013-03-10 05:20:04 <canoon> unless people start sending 1satoshi 2of2 multisig transactions it won't be a problem
535 2013-03-10 05:21:11 <gmaxwell> It's not a 1satoshi issue. I mean, you'll only get credit for 80 bytes but your sig is really 400 bytes, making it uneconomical to redeem.
536 2013-03-10 05:22:35 FredEE has quit (Quit: FredEE)
537 2013-03-10 05:22:47 <canoon> well unless the transaction was for 0.0001 you'll still redeem it
538 2013-03-10 05:25:26 MashRinx has joined
539 2013-03-10 05:26:05 <remote> how do you get the address from a public key?
540 2013-03-10 05:26:06 <gmaxwell> canoon: hm. So what do you think the effect would be of making the scaling factor be 10,000 (the size of the maximum permitted scriptsig)
541 2013-03-10 05:26:32 <gmaxwell> remote: 20:09 < sipa> RIPEMD160(SHA256(pubkey))
542 2013-03-10 05:26:32 <gmaxwell> 20:09 < sipa> and encode that in base58
543 2013-03-10 05:26:58 <remote> that's what I'm trying to do but I basically have no idea what I'm doing
544 2013-03-10 05:27:37 <gmaxwell> remote: it's complicated. Go find code in your prefered language for this.
545 2013-03-10 05:28:04 <gmaxwell> canoon: I guess having negative fees is generally a problem.
546 2013-03-10 05:28:13 <lianj> remote: def hash160_to_address(hex); hex = address_version + hex; encode_base58(hex + checksum(hex)); end
547 2013-03-10 05:28:16 <lianj> def pubkey_to_address(pubkey); hash160_to_address( hash160(pubkey) ); end
548 2013-03-10 05:28:29 <gmaxwell> canoon: unfortunately there is no scaling factor less than about 36 that will avoid negative sizes. :P
549 2013-03-10 05:29:07 <canoon> gmaxwell, you'd obviously just count negative sizes as 0
550 2013-03-10 05:29:10 <remote> what's address_version?
551 2013-03-10 05:29:29 <canoon> i wouldn't make the sacling factor 10,000 more like 300
552 2013-03-10 05:29:30 <lianj> a totally secret secret
553 2013-03-10 05:29:45 <gmaxwell> canoon: then you can create a pretty rad dos attack by mining a 10GB block with a bunch of zero 'size' txn.
554 2013-03-10 05:29:58 <canoon> no you can't
555 2013-03-10 05:30:06 <canoon> because you would need a lot of outputs
556 2013-03-10 05:30:10 <lianj> remote: 6f for testnet3 and 00 for mainnet
557 2013-03-10 05:30:11 <canoon> and the number of outputs is limited
558 2013-03-10 05:30:24 <grau_> remote: base58(ripem160(hash256(pubkey) + last 4 bytes of hash256(hash256(ripem160(hash256(pubkey))))
559 2013-03-10 05:30:41 <gmaxwell> canoon: if instead your scaling factor is one less than minimum possible marginal txin size then thats not an issue.
560 2013-03-10 05:30:48 <remote> ok let me try that
561 2013-03-10 05:30:56 <gmaxwell> canoon: sure you'd create multiple outputs over time, then redeem them all at once. :)
562 2013-03-10 05:31:20 <canoon> hmm
563 2013-03-10 05:31:20 <sipa> grau_: 0x00 + base58(ripemd160(sha256(pubkeu))) + last 4 bytes of sha256(sha256(0x00 + ripemd160(sha256(pubkey)))
564 2013-03-10 05:31:29 <gmaxwell> canoon: also the non-linearity is bad. Say your size would be negative: it's in your best interest to add more outputs just to 'pay forward' the stored value.
565 2013-03-10 05:31:56 <gmaxwell> canoon: one of the things its important to do is to never perversly incentivize adding more outputs. :P
566 2013-03-10 05:32:01 <grau_> sipa: base58(0x00 + ripemd160(sha256(pubkeu))) + last 4 bytes of sha256(sha256(0x00 + ripemd160(sha256(pubkey)))
567 2013-03-10 05:32:08 <grau_> to be precise :)
568 2013-03-10 05:32:28 <sipa> you're right!
569 2013-03-10 05:32:32 <lianj> for mainnet, yes
570 2013-03-10 05:32:44 <grau_> and for single signature
571 2013-03-10 05:33:01 <lianj> why for a single sig?
572 2013-03-10 05:33:11 <sipa> for a pay-to-pubkey-hash
573 2013-03-10 05:33:13 <grau_> for multisig it is 0x05
574 2013-03-10 05:33:15 <sipa> not pay-to-script-hash
575 2013-03-10 05:33:21 <sipa> grau_: multisig != p2sh
576 2013-03-10 05:33:55 <lianj> grau_: ah true, p2sh == 05 for mainnet and c4 for testnet3
577 2013-03-10 05:34:31 <grau_> I believe to have seen 0x05 for psh AND multisig, searching ...
578 2013-03-10 05:34:37 nouitfvf has quit (Ping timeout: 276 seconds)
579 2013-03-10 05:34:40 <lianj> remote brain == melted
580 2013-03-10 05:34:44 <remote> lol
581 2013-03-10 05:34:47 <remote> how did you guess?
582 2013-03-10 05:35:08 <remote> is there existing python code that does pubkey to address?
583 2013-03-10 05:35:16 <lianj> sure
584 2013-03-10 05:35:20 <sipa> remote: about 100 implementations, i think
585 2013-03-10 05:35:27 <lianj> 101 maybe
586 2013-03-10 05:35:34 <sipa> grau_: p2sh is the only way to do multisig in current wallets, but it is not limited to it
587 2013-03-10 05:35:47 <sipa> nor is multisig limited to p2sh
588 2013-03-10 05:35:53 <remote> I looked at a few of them but it's not clear what does pubkey to address and after testing using their code I couldn't succeed doing it
589 2013-03-10 05:35:54 <sipa> at the protocol level
590 2013-03-10 05:35:56 <lianj> sipa: sadly few i have seen that do dynamic testnet/mainnet/testnet3
591 2013-03-10 05:36:03 MashRinx has quit (Ping timeout: 245 seconds)
592 2013-03-10 05:36:10 <lianj> even though its simple to add
593 2013-03-10 05:37:55 <lianj> well, testnet == testnet3 in term of addresses
594 2013-03-10 05:37:57 <canoon> gmaxwell, the dos attack would probably not work and just cause the block to get orphaned if it didn't then so what you just had a 10gb block go across the network successfully. you could do the same thing by spamming transactions with fees
595 2013-03-10 05:38:56 <gmaxwell> canoon: nah, the attack really takes the form of finding a size such that the big block is accepted by 50%+ε of the network. You can make convergence take a very long time.
596 2013-03-10 05:39:32 <canoon> but what problem would it cause?
597 2013-03-10 05:39:43 <gmaxwell> And the perverse incentive exists where you can create more outputs for 'free')
598 2013-03-10 05:40:03 <gmaxwell> canoon: it means that someone could way 6 or whatever confirms and then have their transactions reversed and replaced with doublespends.
599 2013-03-10 05:41:01 <gmaxwell> This would be better, I think: max(size-inputs*scale,1)+outputs*scale
600 2013-03-10 05:41:03 <canoon> wait you mean so its accepted by 50% of the network but not the rest?
601 2013-03-10 05:41:32 <gmaxwell> canoon: right. You find some big size such that it would be accepted by roughly half the hashpower (or better, slightly more than half but not less)
602 2013-03-10 05:41:55 <remote> ex: http://paste.lisp.org/display/135928
603 2013-03-10 05:42:00 <canoon> but why would the rest reject it no storage?
604 2013-03-10 05:42:11 paraipan has quit (Quit: Saliendo)
605 2013-03-10 05:42:14 <remote> this is using https://github.com/jtobey/bitcoin-abe/blob/master/Abe/util.py
606 2013-03-10 05:42:34 <gmaxwell> canoon: no storage, not enough bandwidth, an attempt to prevent dos attacks like this (you just said it would be prevented by being orphaned)
607 2013-03-10 05:43:09 <canoon> hmm
608 2013-03-10 05:43:32 <gmaxwell> In any case I think max(size-inputs*scale,1)+outputs*scale eliminates that, and the perverse incentives. perhaps the 1 should be some slightly larger value to prevent block bloat.
609 2013-03-10 05:44:17 <remote> even hash_to_address(pubkey_to_hash(pubkey)) doens't work
610 2013-03-10 05:44:27 <gmaxwell> I guess there is some slightly preverse incentive there... if size-inputs*scale would be negative then you might avoid consuming some utxo you would otherwise consume.
611 2013-03-10 05:45:00 <canoon> is inputs the inputs' output?
612 2013-03-10 05:45:30 <gmaxwell> inputs is just the number of outputs this transaction is consuming.
613 2013-03-10 05:45:30 <lianj> remote: add address version and checksum
614 2013-03-10 05:45:37 <canoon> oh right
615 2013-03-10 05:46:38 <remote> lianj: http://paste.lisp.org/display/135929
616 2013-03-10 05:46:54 <gmaxwell> that residual perversity is why I just like setting the scale to some value such that size-(inputs-outputs)*scale is always postive.
617 2013-03-10 05:46:58 <lianj> remote: add address version and checksum
618 2013-03-10 05:47:24 <canoon> gmaxwell, lol 0?
619 2013-03-10 05:48:02 <gmaxwell> dur. long day. right.
620 2013-03-10 05:48:22 <canoon> well if its 0 its current algorithm
621 2013-03-10 05:48:55 <remote> I'm passing address version to hash_to_address() but I'm not seeing any checksum what is it?
622 2013-03-10 05:49:33 <canoon> hmm that still has the dos problem just blocksize is limited by a scale factor
623 2013-03-10 05:49:36 <gmaxwell> canoon: double dur. There is a scale that is non-zero and keeps it positive.
624 2013-03-10 05:50:10 <canoon> i don't think the perverse incentives is really a problem
625 2013-03-10 05:50:22 <gmaxwell> (because size must increase by some amount per input you consume even if the scriptsig is empty)
626 2013-03-10 05:51:00 <canoon> because its limited how many outputs they can do
627 2013-03-10 05:51:01 <gmaxwell> canoon: I think its a major criteria. Software will act in the users interest and will do things like add extra change outputs to avoid losing uxto juice.
628 2013-03-10 05:51:20 <gmaxwell> lol yes, but it's a large limit (rightfully so!)
629 2013-03-10 05:51:21 <canoon> yeah but its only going to happen when they are already reducing outputs
630 2013-03-10 05:51:47 <gmaxwell> canoon: yes sure but it means that they're not actually incentivized to reduce outputs.
631 2013-03-10 05:52:25 <canoon> well only when they are already reducing outputs
632 2013-03-10 05:52:35 <sipa> always incentivized to reduce outputs, but not always to *maximally* do so
633 2013-03-10 05:52:45 <canoon> yeah
634 2013-03-10 05:52:56 <gmaxwell> What is your complaint with size-(inputs-outputs)*scale such that it's always positive. (if we assume that each input adds 36 bytes, then setting scale to 35 achieves that, for example)
635 2013-03-10 05:53:35 <gmaxwell> (I don't know what the minimum marginal increase is, I know its >33 bytes.. but I'm too lazy right now to check exactly)
636 2013-03-10 05:53:53 <canoon> minimum marginal increase?
637 2013-03-10 05:54:21 <canoon> i think scale should be whatever the cost to redeem a to address transaction
638 2013-03-10 05:54:25 <gmaxwell> canoon: a txin makes a transaction larger even with a 0byte scriptsig... e.g. the txid:vout, sequence number, etc.
639 2013-03-10 05:54:53 RainbowDashh has quit (Quit: Sleep. <redacted> I joked I would replace all her sensitive files on her old computer with ponies so nothing could be recovered.)
640 2013-03-10 05:54:54 <gmaxwell> canoon: as noted before it _can't_ be whatever the cost is, because we don't actually know the cost.
641 2013-03-10 05:55:05 <gmaxwell> Sometimes it will not be enough unless you set the scale to 10,000.
642 2013-03-10 05:55:12 <canoon> no for that specific transaction type
643 2013-03-10 05:55:22 <gmaxwell> you can't tell what transaction type an output is.
644 2013-03-10 05:55:56 <gmaxwell> (and certantly if this were to be a hard protocol rule you wouldn't want to special case a bunch of types even for the ones you can identify)
645 2013-03-10 05:56:21 grau_ has quit (Remote host closed the connection)
646 2013-03-10 05:56:28 owowo has quit (Quit: sayonara)
647 2013-03-10 05:56:29 <canoon> no like a to address one OP_DUP OP_HASH160 XX OP_EQUALVERIFY OP_CHECKSIG
648 2013-03-10 05:56:46 <canoon> specifically how much it costs to redeem that one
649 2013-03-10 05:59:05 <gmaxwell> You can't generally know that even for those script types without a big dumb table. Ugh. That is _not_ going to go in as a protocol rule. And besides: how much does this cost to redeem OP_HASH160 OP_PUSH da39a3ee5e6b4b0d3255bfef95601890afd80709 OP_EQUAL ?
650 2013-03-10 06:00:21 <canoon> gmaxwell, not based on the actual script just the size of a signature + pubkey + txin overhead
651 2013-03-10 06:00:26 <remote> I was passing a 130 char public key, maybe that's the problem
652 2013-03-10 06:00:36 <canoon> but i guess that has problems with a negative size
653 2013-03-10 06:01:12 <gmaxwell> canoon: it has problems with some transactions take much much more than signature + pubkey + txin overhead to redeem... and you can't even tell this from the txout that created them.
654 2013-03-10 06:01:38 unknown45682 has quit ()
655 2013-03-10 06:01:46 <gmaxwell> (arguably P2SH should have had a OP_PUSH_I_PROMISE_TO_NOT_COST_MORE_THAN_THIS_TO_REDEEM, alas)
656 2013-03-10 06:02:40 <canoon> yeah i think we argued that
657 2013-03-10 06:03:07 <canoon> its to prevent someone from ignoring transactions that cost more to redeem
658 2013-03-10 06:03:16 <gmaxwell> ...
659 2013-03-10 06:03:17 <canoon> theres no real incentive to send those transactions in the first place
660 2013-03-10 06:03:31 <gmaxwell> And yet people do for all kinds of odd reasons.
661 2013-03-10 06:03:33 <gmaxwell> 21:54 < gmaxwell> canoon: as noted before it _can't_ be whatever the cost is, because we don't actually know the cost.
662 2013-03-10 06:03:38 <gmaxwell> not the 'as noted before'
663 2013-03-10 06:04:00 <canoon> yeah but mostly to addresses
664 2013-03-10 06:04:03 <gmaxwell> I'm pointing out that nothing you can propose here can prevent txn that cost more to redeem than they're worth, they can only make them more rare.
665 2013-03-10 06:04:45 <gmaxwell> canoon: I think it's very likely that in the future (2+ years from now) most transactions will be multisignature. It's the only way to make wallets on commodity hardware secure. Gavin has long term plans to support them as standard wallet features.
666 2013-03-10 06:05:27 <phantomcircuit> gmaxwell, in most cases multi sig doesn't actually buy you any real security
667 2013-03-10 06:05:29 <gmaxwell> So given that you can only make them more rare, not impossible... why not choose a smaller scale factor so you're always strongly incentivized to unbloat?
668 2013-03-10 06:05:46 <gmaxwell> phantomcircuit: uh. I'm waiting to hear this argument.
669 2013-03-10 06:06:15 <canoon> a larger scale factor increases the incentive no?
670 2013-03-10 06:06:23 <phantomcircuit> gmaxwell, almost all automated interaction with bitcoind follows the basic format of a payment instruction (eg a database record) being processed
671 2013-03-10 06:06:45 <gmaxwell> phantomcircuit: I'm not talking about merchants and automated systems.
672 2013-03-10 06:06:56 <phantomcircuit> gmaxwell, normal users?
673 2013-03-10 06:07:12 <phantomcircuit> bob the wallet man with his 10 btc?
674 2013-03-10 06:07:20 <sipa> canoon: increases the initial incentive, but makes it stop earlier
675 2013-03-10 06:07:46 B0g4r7 has quit (Ping timeout: 276 seconds)
676 2013-03-10 06:07:48 <canoon> how so?
677 2013-03-10 06:07:54 <gmaxwell> maybe I'm overly fixated on the small scale factor just becuase it removes a free parameter. :(
678 2013-03-10 06:07:57 <phantomcircuit> hmm i guess maybe that would make it more secure
679 2013-03-10 06:08:03 <warren> gmaxwell: you mean like a hardware token you plug in for the second sig?
680 2013-03-10 06:08:07 <sipa> canoon: because you'll hit 0 faster
681 2013-03-10 06:08:10 <gmaxwell> warren: yes. or your phone.
682 2013-03-10 06:08:14 <warren> ah
683 2013-03-10 06:08:19 <canoon> sipa, 0 what?
684 2013-03-10 06:08:24 <phantomcircuit> bob has one bitcoin-qt on his windows 7 desktop and one bitcoin-qt on his os x laptop
685 2013-03-10 06:08:26 <gmaxwell> canoon: zero size.
686 2013-03-10 06:08:36 <phantomcircuit> if he needs to have signatures from both he's probably more secure
687 2013-03-10 06:08:37 <sipa> canoon: size - scale*ntxoutdiff
688 2013-03-10 06:08:41 <warren> phantomcircuit: you're already in trouble if you want the same wallet on both
689 2013-03-10 06:08:46 <canoon> oh right
690 2013-03-10 06:08:57 <sipa> canoon: if scale is larger, you'll sooner hit 0, at which point you have no further incentive to reduce the outputs
691 2013-03-10 06:09:04 <phantomcircuit> warren, not really
692 2013-03-10 06:09:08 <warren> phantomcircuit: unless you have deterministic keys?
693 2013-03-10 06:09:12 <canoon> but the next person who receives that will have incentive
694 2013-03-10 06:09:18 <phantomcircuit> it's only a problem if you dont know what you're doing
695 2013-03-10 06:09:23 <phantomcircuit> which i guess is an issue for bob
696 2013-03-10 06:09:28 <warren> exactly
697 2013-03-10 06:09:33 <warren> unless it is bob the coder
698 2013-03-10 06:09:46 <phantomcircuit> gmaxwell, that reminds me
699 2013-03-10 06:09:48 <Vinnie_win> evoorhees claims SD loss-bet tx is only 16% of network
700 2013-03-10 06:09:49 <warren> bob the coder who reads instructions
701 2013-03-10 06:09:52 <gmaxwell> and if you use plain size - scale*ntxoutdiff instead of max(size-inputs*scale,1)+outputs*scale you'll be incentivized to add more outputputs to 'recover' your lost value. :(
702 2013-03-10 06:09:54 <phantomcircuit> the keypool behaviour should be changed
703 2013-03-10 06:10:01 <Vinnie_win> can someone point me to gavin's post that shows recent blocks and the percent of SD spam?
704 2013-03-10 06:10:23 <warren> Vinnie_win: one user is only 16% of the network. sounds great.
705 2013-03-10 06:10:24 <phantomcircuit> when the wallet is initial created a larger number of private keys should be generated (think 1,000)
706 2013-03-10 06:10:33 <phantomcircuit> then the keypool size set to the normal 100
707 2013-03-10 06:10:39 <Vinnie_win> warren: The real number is like 80%...I'd like to find gavin's post which makes that clear
708 2013-03-10 06:10:46 <warren> Vinnie_win: As long as people hold on to the fantasy that every KB has the same cost to the network, we won't fix this.
709 2013-03-10 06:10:48 <phantomcircuit> if the keypool refills the ui should warn the user to back again
710 2013-03-10 06:10:54 <warren> Vinnie_win: I mean even 16% is bad.
711 2013-03-10 06:11:02 <Vinnie_win> warren: Yeah but do you have any idea where gavin's post is? I'd like to refute evoorhees' claim
712 2013-03-10 06:11:23 <Vinnie_win> I've got this bastard on the defensive and I'd like to press the advantage
713 2013-03-10 06:11:24 <gmaxwell> warren: no thats just the bitdust losses.. SD involved transactions is more like 80% .. but if you say 80% then 50 plays and 50% responses and .. then less than half the responses are losses because more people pay the higher win percentage games.. doesn't sound incorrect, perhaps misleading.
714 2013-03-10 06:11:57 <canoon> theres this its a bit old but has it at 64% https://bitcointalk.org/index.php?topic=80312.0
715 2013-03-10 06:12:09 <gmaxwell> Vinnie_win: I posted a list by block, look at my post history
716 2013-03-10 06:12:21 <Vinnie_win> gmaxwell: I found it...well, I found yours. Didn't find gavin's. Thanks
717 2013-03-10 06:12:53 <warren> gmaxwell: I didn't suggest 16% was right, I said even if it were correct, it's still bad.
718 2013-03-10 06:13:04 <canoon> the size adjustment would fix the bitdust losses :p
719 2013-03-10 06:13:10 <gmaxwell> Vinnie_win: but I think what he's telling youâ that 16% are losses, may well be roughly right.
720 2013-03-10 06:13:47 <Vinnie_win> gmaxwell: how the hell could 16% be anywhere remotely near the correct number?
721 2013-03-10 06:14:17 <Vinnie_win> he says loss confirms are 1/4 of SD traffic, and SD traffic is 1/2 of the network
722 2013-03-10 06:14:20 <gmaxwell> Vinnie_win: if 80% are SD playing, then 40% are bets, and 40% are responses (because there is 1:1 bet and response). And then not all responses are _losses_.
723 2013-03-10 06:14:44 <Vinnie_win> Hmm...
724 2013-03-10 06:14:44 <warren> This ultimately isn't about DP. They should be credited for exposing the UXTO cost problem, we fix it, and move on.
725 2013-03-10 06:14:55 <Vinnie_win> okay I can still spin that
726 2013-03-10 06:15:06 <gmaxwell> Vinnie_win: if he's saying 1/2 / 1/4 what he's probably doing there is not counting the bets. (in which case he's saying sd is ~100% of the network. :P)
727 2013-03-10 06:15:24 <gmaxwell> warren: they didn't expose the utxo cost problem. Firstbits and lots of other things did.
728 2013-03-10 06:15:35 <Vinnie_win> gmaxwell: I think he's right not to count the bets. They are legit tx after all
729 2013-03-10 06:15:44 <gmaxwell> Including petertodd's timestamper than I said "NO STOP!" to and which he then joined in trying to figure out how to improve scalablity.
730 2013-03-10 06:16:02 <Vinnie_win> why'd gavin reject peter's pull req
731 2013-03-10 06:16:04 B0g4r7 has joined
732 2013-03-10 06:16:30 <warren> Vinnie_win: apparently git pull request isn't a discussion forum
733 2013-03-10 06:16:36 <gmaxwell> Vinnie_win: I don't agree. I mean, they wouldn't exist absent the really inefficient way the site works. You could perhaps try to not count like 1 tx per user of the site per hour, but doing the blockchain analysis to approximate that would be a PITA.
734 2013-03-10 06:17:05 <Vinnie_win> gmaxwell: There is no way to win an argument against high transaction volume which creates spendable outputs
735 2013-03-10 06:17:45 <warren> Even if they were to stop dusting, it would still be a lot of tx's with high fees that others have to compete with. None of my "pollution tax" suggestions would have any effect on that.
736 2013-03-10 06:18:12 <lianj> is this still 1dice talk?
737 2013-03-10 06:18:25 <canoon> warren, isn't that just the free market
738 2013-03-10 06:18:28 <gmaxwell> Vinnie_win: who said anything about winning arguments? His service is responsible for almost all the transactions. Its just how it is. If that doesn't help your argument, bummer.
739 2013-03-10 06:18:43 <gmaxwell> lianj: it wasn't for a long time then Vinnie_win crapped it all up.
740 2013-03-10 06:18:45 <gmaxwell> :P
741 2013-03-10 06:18:54 <Vinnie_win> heh
742 2013-03-10 06:18:57 <warren> canoon: I'd agree, if our current fee calculation formula followed actual costs.
743 2013-03-10 06:19:01 <Vinnie_win> well, SD did raise the output to 5k instead of 1.
744 2013-03-10 06:19:19 <gmaxwell> Vinnie_win: in any case, the percentage of the network that is his un-enconomical-to-spend outputs isn't the relevant metric.
745 2013-03-10 06:19:19 <Vinnie_win> gmaxwell: should I have not brought it up?
746 2013-03-10 06:19:30 <lianj> my bitcoin hating friends started to call bitcoin buttcoins. someone should register that domain
747 2013-03-10 06:19:33 <Vinnie_win> gmaxwell: I mean is Bitcoin better served by staying silent
748 2013-03-10 06:19:41 <gmaxwell> I guess the relevant metric for the argument you're making is what percentage of the UTXO growth his service is responsible for.
749 2013-03-10 06:19:43 <canoon> warren, should it also count the extra output size increase?
750 2013-03-10 06:19:46 <warren> lianj: better yet, start a new alt coin named it.
751 2013-03-10 06:19:55 <Vinnie_win> gmaxwell: Yes that's exactly the metric I'm interested in
752 2013-03-10 06:20:06 <lianj> "buttcoins - 1dice welcome"
753 2013-03-10 06:20:46 <warren> litecoin is almost 5x the USD exchange rate of last week. It makes no sense.
754 2013-03-10 06:20:46 ThomasV has joined
755 2013-03-10 06:21:02 RainbowDashh has joined
756 2013-03-10 06:21:08 <gmaxwell> Vinnie_win: sounds like a pain to compute. You'd need to get the UTXO size at time X and then again at time Y and then figure out all if all the outputs in Y that are not in X, how many are a result of SD.
757 2013-03-10 06:21:19 <Vinnie_win> "Litecoin is the noise to Bitcoin's signal" - Vinnie
758 2013-03-10 06:21:40 <lianj> "buttcoin" - dongs
759 2013-03-10 06:22:02 <Vinnie_win> gmaxwell: I would just include any tx that comes from 1dice* and has an output less than 100 satoshi
760 2013-03-10 06:23:12 <canoon> gmaxwell, you only need to scan between the two blocks i think
761 2013-03-10 06:23:34 <gmaxwell> canoon: noisy metric.
762 2013-03-10 06:23:51 <gmaxwell> e.g. you hit a block that blocks SD... you won't get much. :P
763 2013-03-10 06:24:16 <canoon> i didn't mean sequential blocks
764 2013-03-10 06:24:45 <gmaxwell> well thats what I mean by time x and time y.
765 2013-03-10 06:25:40 <gmaxwell> (in particular, using a longer window lets you ignore 'bloat' created by spendable transactions that get spent)
766 2013-03-10 06:26:01 <canoon> oh right but i meant you can just scan between the block at x and y, you don't have to calculate the utxo size at x
767 2013-03-10 06:26:10 <warren> gmaxwell: is p2pool's minimum payout big enough to be considered not dust?
768 2013-03-10 06:26:26 xjrn has quit (Remote host closed the connection)
769 2013-03-10 06:26:39 <lianj> warren: borderline
770 2013-03-10 06:26:43 <gmaxwell> warren: yes, at least at the current subsidy level.
771 2013-03-10 06:27:16 <gmaxwell> Part of the design is to keep the minimum from being insanely small.
772 2013-03-10 06:29:00 <warren> gmaxwell: if a non-mining node is paid a --fee would that be way below that?
773 2013-03-10 06:32:35 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
774 2013-03-10 06:33:31 sgornick has quit (Ping timeout: 245 seconds)
775 2013-03-10 06:39:48 <gmaxwell> warren: if you wanted to do that you could use a lottery instead of a payment.
776 2013-03-10 06:40:03 <gmaxwell> warren: "stochastic micropayment"
777 2013-03-10 06:40:26 <warren> gmaxwell: I was just thinking that
778 2013-03-10 06:40:37 <warren> gmaxwell: it's rather futile though
779 2013-03-10 06:40:52 <gmaxwell> canoon: I think I've solved all my concerns: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas see "Transaction cost prepayment" but I think that form is too different from bitcoin.
780 2013-03-10 06:41:05 <gmaxwell> Transaction cost prepayment: One problem is that it's possible to create UTXO that are unprofitable to redeem.
781 2013-03-10 06:41:08 <gmaxwell> Instead make every output specify a max_size, which is the maximum size of a TX_IN that will be permitted to redeem it. Then for the 'cost' of a transaction use cost = MAX(size-sum_inputs(max_size),minimum_viable_txn_size) + sum_outputs(max_size) In order to economical align cost the blocksize limit should be based on it rather than size.
782 2013-03-10 06:41:46 <gmaxwell> basically let the address specify the prepayment amount. And you can't lowball it because you will just make the txout unredeemable.
783 2013-03-10 06:41:50 DrAkaman has joined
784 2013-03-10 06:43:44 coblee has quit (Read error: Connection reset by peer)
785 2013-03-10 06:43:56 <canoon> yeah i think that completely misses the point
786 2013-03-10 06:44:02 coblee has joined
787 2013-03-10 06:44:20 <gmaxwell> canoon: ... uh. Please expand on that.
788 2013-03-10 06:44:53 <canoon> because people could just lie and say it takes 1 byte to redeem it and they weren't planning to redeem it anyway
789 2013-03-10 06:45:18 <gmaxwell> canoon: anyone can make unredeemable txn all they want. That can't be prevented.
790 2013-03-10 06:45:20 xjrn has joined
791 2013-03-10 06:45:25 <canoon> but just using it to message someone else
792 2013-03-10 06:45:40 <gmaxwell> http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE
793 2013-03-10 06:46:44 <gmaxwell> canoon: sure, sorry, well I expected max_size would be seralized as 40+???? (40 being whatever the minimum credible max_size is)
794 2013-03-10 06:46:49 <gmaxwell> if that wasn't obvious I'll add it.
795 2013-03-10 06:48:09 <canoon> hmm actually i guess that makes sense
796 2013-03-10 06:48:52 <canoon> oh so it has a minimum cost anyway?
797 2013-03-10 06:49:44 <gmaxwell> ** max_size is serialized as an unsigned variable length int minus whatever the smallest credible maxsize is, (e.g. something like 40 for bitcoin)
798 2013-03-10 06:50:51 <canoon> ah k
799 2013-03-10 06:51:46 <gmaxwell> basically it means any payment "reserves" the space its redemption will consume.
800 2013-03-10 06:52:38 <gmaxwell> does kinda disincentivize txn that have a large worst case, sadly. but then again those _should_ be disincentivized simply because they may turn out to be harder to spend than expected.
801 2013-03-10 06:53:18 <Vinnie_win> Have you guys thought about shaping the overlay network through peer connection preferencing?
802 2013-03-10 06:53:31 <gmaxwell> overlay network?
803 2013-03-10 06:53:38 <Vinnie_win> The peers
804 2013-03-10 06:53:49 <Vinnie_win> Host connections...whatever you call them
805 2013-03-10 06:54:29 <gmaxwell> What for? For oneâ preferencing makes security much harder to analyize. e.g. a simplistic preferencing scheme makes it easy for an attacker to partition the network.
806 2013-03-10 06:55:24 chrisb has quit (Ping timeout: 255 seconds)
807 2013-03-10 06:55:30 <Vinnie_win> For example, drop any peer which forwards a transaction that has economically unspendable outputs. This could be done probabilistically to prevent creating separate partitions. They effect would be to push the older hosts out, while forming a well connected core of hosts with the new behavior
808 2013-03-10 06:56:49 <warren> gmaxwell: wait a minute, subsidy level? you mean there are still donations to encourage people to use p2pool?
809 2013-03-10 06:58:52 <Vinnie_win> warren: I think we crashed him
810 2013-03-10 06:58:57 <gmaxwell> Vinnie_win: transitive dropping allows an attacker to create partitions easily.
811 2013-03-10 06:59:36 <gmaxwell> Vinnie_win: e.g. I flood all the unspendable forwarders, and then tada, they are paritioned eventually with high probablity.
812 2013-03-10 06:59:45 <Vinnie_win> gmaxwell: It would be probabilistic. Each node generates a permanent static guid and that gets used to decide what fraction of nodes would be dropped (could be zero)
813 2013-03-10 07:00:28 cheesepi has quit (Read error: Connection reset by peer)
814 2013-03-10 07:00:32 <Vinnie_win> gmaxwell: To prevent partitions, most nodes would drop all forwarders, while some nodes would drop all but one forwarder. This creates a core of new guys with the forwarders as leaves at the border
815 2013-03-10 07:00:59 <gmaxwell> Vinnie_win: There is no value there which is both safe and effective. :P Though hey, I'll offer you a less bad alternative: if you don't like the txn your peer is giving you, ask it to stop fowarding transactions to you (But still exchange blocks)
816 2013-03-10 07:01:11 <warren> Vinnie_win: isn't that assuming the "core" has the majority mining power?
817 2013-03-10 07:01:21 <Vinnie_win> warren: This has nothing to do with mining power, just regular nodes
818 2013-03-10 07:01:43 <warren> Vinnie_win: miners get tx's from regular nodes
819 2013-03-10 07:01:45 <gmaxwell> Vinnie_win: great so them I'm a evil guy and then I run a bunch of nodes that DON'T drop them but do other evil. Then its very likely that your bad nodes will connect to the good nodes via my nodes exclusively.
820 2013-03-10 07:02:32 <gmaxwell> but paritioning for txn forwarding is far less evil than partitioning for blocks.. so having some block only peers might be interesting.
821 2013-03-10 07:02:33 <warren> Vinnie_win: you could also be kicking out mining nodes (and you won't know it), which is quite bad for your desired tx's
822 2013-03-10 07:02:43 mcx has joined
823 2013-03-10 07:02:43 mcx is now known as cheesepi
824 2013-03-10 07:02:44 <Vinnie_win> There's no way to stop from connecting to bad actors but there's a way to shape the network based on who is running older versions, is what I'm saying
825 2013-03-10 07:03:36 <Vinnie_win> Okay here's a different idea
826 2013-03-10 07:04:28 <Vinnie_win> The flood fill of newly mined blocks can be used to create a directed acyclic graph of the network at a single point in time (the time the block was mined). It would be possible to use the return trip to aggregate statistics about nodes or otherwise communicate information back up the chain to the node that produced the block
827 2013-03-10 07:04:58 <Vinnie_win> i.e. when a block is mined, your "parent" in the graph is whoever you heard the block from first
828 2013-03-10 07:05:38 <canoon> gmaxwell, how about we limit the value of outputs - inputs in each block?
829 2013-03-10 07:06:26 <warren> canoon: even if that were a good idea, how do you set the value?
830 2013-03-10 07:06:50 <canoon> just hardcoded value
831 2013-03-10 07:06:53 <gmaxwell> warren: same way you set a maximum block size.
832 2013-03-10 07:07:06 <canoon> to calculate a good one
833 2013-03-10 07:07:09 <Vinnie_win> "How many forum members does it take to plug in a block size..."
834 2013-03-10 07:08:19 <canoon> just calculate the average number increase in the output from the last 1gb of transactions / 1000
835 2013-03-10 07:08:19 <warren> Vinnie_win: we don't have enough yet, apparently
836 2013-03-10 07:08:21 <gmaxwell> canoon: well doing purely that has the problem that it still allows that giant block dos attack. If you have two constraints, then you make optimal mining income a knapsack problem, and make fees hard to reasona about.
837 2013-03-10 07:09:16 <gmaxwell> canoon: anything based on a blockchain average incentivizes miners to mine dummy transactions to drive up the maximum. With greedy-rational miners all blocks would have exactly the maximum output increase. :P
838 2013-03-10 07:09:19 <canoon> you can already do that with block size thoug no?
839 2013-03-10 07:09:36 <canoon> oh i just meant to calculate an initial one
840 2013-03-10 07:09:38 <gmaxwell> canoon: no. 1MB is small enough that there is no giant block forking attack.
841 2013-03-10 07:09:51 <gmaxwell> canoon: well then you have some magic number that might not reflect future usage. :(
842 2013-03-10 07:10:08 <canoon> you'd tie it to block size
843 2013-03-10 07:10:31 muhoo has joined
844 2013-03-10 07:10:52 <gmaxwell> You're going to have to explain that to me.
845 2013-03-10 07:10:55 <muhoo> Luke-Jr: looks to me like dnsseed.bitcoin.dashjr.org is down, or perhaps dashjr dns has gone wonky
846 2013-03-10 07:11:11 <muhoo> and, this causes bitcoinj to lock up hard and not talk to any peers :-/
847 2013-03-10 07:11:36 <canoon> well i think the max should be a ratio of the max block size
848 2013-03-10 07:11:55 <canoon> this ofcourse relys on you guys having a good way for deciding block size
849 2013-03-10 07:12:01 <canoon> *max block size
850 2013-03-10 07:12:21 <muhoo> i do think it odd that the canonical nameservers for dashjr.org are on dashjr.org, that's usually a no-no (use static IP addresses or a name that resolves on a different domain)
851 2013-03-10 07:12:34 dust-otc has quit (Remote host closed the connection)
852 2013-03-10 07:12:59 <canoon> regardless if you limit it to say 100 that means you know the max entries that will be in your uxto later
853 2013-03-10 07:13:29 dust-otc has joined
854 2013-03-10 07:14:45 <canoon> gmaxwell, btw what is the plan for adjusting max block size?
855 2013-03-10 07:14:50 <canoon> or none?
856 2013-03-10 07:15:16 <gmaxwell> canoon: there isn't currently a plan. It's complicated.
857 2013-03-10 07:16:43 <petertodd> canoon: What has to happen is off-chain transaction systems get developed, so the block size doesn't have to grow much, or perferably not at all, for the forseeable future.
858 2013-03-10 07:16:59 <muhoo> like ripple?
859 2013-03-10 07:17:01 * muhoo ducks
860 2013-03-10 07:17:18 <canoon> petertodd, you kinda lose the universality of bitcoin then
861 2013-03-10 07:17:22 <gmaxwell> Gavin has proposed just removing the maximum. I believe that Jeff, Sipa, and I all believe this is an unacceptably bad idea. (though I think no one argues that it should never be increased at all). There has been a lot of discussion and argument on the forum, mostly by uninformed people (by sheer count), though a number of interesting thoughts have been expressed.
862 2013-03-10 07:17:23 <petertodd> muhoo: Lol, as gmaxwell would say, like Genuine Ripple (not that shitty thing that actually happened)
863 2013-03-10 07:18:06 <petertodd> canoon: Universality is a tradeoff between centralization and decentralization. The larger the blocksize is, the fewer people can afford to run a full, validating node.
864 2013-03-10 07:18:07 brendyn has quit (Ping timeout: 245 seconds)
865 2013-03-10 07:18:41 <petertodd> canoon: Bitcoin simply can-not scale to even handling a tiny, tiny fraction of the worlds finance and be decentralize at the same time if every transaction goes on the blockchain itself.
866 2013-03-10 07:19:05 <muhoo> sad, but true.
867 2013-03-10 07:19:18 <gmaxwell> As sipa says, "if the size is very small everyone will validate but no one will transact (and bitcoin is worthless), if the size is very large everyone will transact but no one will validate (and bitcoin is worthless)"
868 2013-03-10 07:19:49 <gmaxwell> A well calibrated system has a size which maximizes both of those things.
869 2013-03-10 07:19:55 <muhoo> Hard Problem.
870 2013-03-10 07:20:04 Diablo-D3 has quit (Quit: This computer has gone to sleep)
871 2013-03-10 07:20:14 <petertodd> Visa does thousands of transactions a second; you just can't run a validating node processing all those transactions and stay anonymous at the same time.
872 2013-03-10 07:20:23 <petertodd> Even right now it's tough to run Bitcoin on Tor, doable, but tough.
873 2013-03-10 07:20:30 <canoon> anyone for having the block size such that real transaction fees stay the same?
874 2013-03-10 07:20:32 <zveda> i dont think you can assume miners are both greedy and rational. miners also want the btc system to succeed.
875 2013-03-10 07:20:59 <petertodd> canoon: Also hopeless, because you still run into the scaling issue. The demand for 1 cent secure transactions is utterly enormous.
876 2013-03-10 07:21:01 <warren> petertodd: due to latency or slowness of exit nodes? can bitcoind run directly as a hidden service?
877 2013-03-10 07:21:01 <zveda> if they're rational enough to optimize their greedy behavior they're rational enough to realise that
878 2013-03-10 07:21:02 RainbowD_ has joined
879 2013-03-10 07:21:12 <gwillen> 23:06:40 < muhoo> i do think it odd that the canonical nameservers for dashjr.org are on dashjr.org, that's usually a no-no (use static IP addresses or a name that resolves on a different domain)
880 2013-03-10 07:21:16 <gwillen> muhoo: offtopic, but what you say is not true
881 2013-03-10 07:21:17 <warren> petertodd: hidden service speeds aren't that bad
882 2013-03-10 07:21:22 <gwillen> muhoo: NS records must have names, they cannot have IPs
883 2013-03-10 07:21:29 <petertodd> warren: Bandwidth, specifically you have a high orphan rate when you mine because it takes too long to download 1MB, at least in my tests.
884 2013-03-10 07:21:30 RainbowDashh has quit (Disconnected by services)
885 2013-03-10 07:21:30 RainbowD_ is now known as RainbowDashh
886 2013-03-10 07:21:32 <muhoo> gwillen: but not on the same domain as they are serving
887 2013-03-10 07:21:37 <gwillen> muhoo: and if you want the names to be in third party domains, consider what would happen if everyone did that
888 2013-03-10 07:21:43 <warren> petertodd: yeah, you're nuts if you mine on tor
889 2013-03-10 07:21:46 <gwillen> indeed they _ought_ to be in the domain they are serving
890 2013-03-10 07:22:17 <petertodd> warren: But at the same time, being able to run a pool on tor could be a very good thing in the future, so it's good for us to ensure it remains possible, even if it's hard too.
891 2013-03-10 07:22:19 <gwillen> if everyone pointed at some other domain.... you'd never be able to resolve any domain
892 2013-03-10 07:22:19 <muhoo> gwillen: ok, well then i've got it wrong. but dashjr.org does appear down.
893 2013-03-10 07:22:23 <canoon> petertodd, so how much? 5c? i don't see why that isn't possible
894 2013-03-10 07:22:23 * gwillen nods
895 2013-03-10 07:24:21 ciphermonk has joined
896 2013-03-10 07:24:47 <petertodd> canoon: Well, lets assume you paid for the block subsidy with fees from transactions right now, at current volumes fees would need to be $3 USD per transaction.
897 2013-03-10 07:25:55 <petertodd> canoon: Now, lets say you stick with 1MB blocks, and pay fees from the 7 transactions a second that happen, then with the current amount of network security, you'd be paying $0.25 per transaction.
898 2013-03-10 07:27:09 brendyn has joined
899 2013-03-10 07:27:17 <canoon> yeah guess it depends how much network security you want
900 2013-03-10 07:27:29 <petertodd> Yup, and god only knows how much is enough.
901 2013-03-10 07:27:59 <petertodd> Keep in mind that anyone who can short a large amount of Bitcoins can use it to fund a 51% attack: you short Bitcoin, attack it, then take advantage of the fact that the price has dropped like a stone.
902 2013-03-10 07:29:00 nus-- has joined
903 2013-03-10 07:29:31 <canoon> i wonder if there would be a better system based of trusted signatures
904 2013-03-10 07:29:44 <petertodd> That's called the banking system...
905 2013-03-10 07:30:08 <canoon> lol true
906 2013-03-10 07:31:07 <petertodd> The good thing is coming up with such a large short position is hard, the bad thing is the attacker may not even be economically rational.
907 2013-03-10 07:31:46 <petertodd> Anyway, 51% attacks don't worry me, centralization does.
908 2013-03-10 07:31:58 <canoon> whats the difference?
909 2013-03-10 07:32:26 <canoon> (what are you worried about centralisation?)
910 2013-03-10 07:32:42 <petertodd> Centralization is something that can be done slowly, without looking like you are attacking anything.
911 2013-03-10 07:33:04 <petertodd> Keep in mind, the entities that might do a 51% attack, really wouldn't want to be known to be doing a 51% attack.
912 2013-03-10 07:33:17 nus- has quit (Ping timeout: 276 seconds)
913 2013-03-10 07:33:27 <canoon> hmm
914 2013-03-10 07:33:49 <warren> 50.99% Corp.
915 2013-03-10 07:33:59 <canoon> 50.99?
916 2013-03-10 07:34:06 <warren> It isn't 51%.
917 2013-03-10 07:34:10 <warren> I get goofy when i'm tired.
918 2013-03-10 07:34:13 <petertodd> Tagline: "We are the 51%"
919 2013-03-10 07:34:16 <xjrn> it's hard to pinpoint from this discussion whether increasing tx throughput is a goal or liability
920 2013-03-10 07:34:32 * warren resisting the urge to reply to him.
921 2013-03-10 07:34:47 <petertodd> warren: New troll I don't know about?
922 2013-03-10 07:34:55 <warren> petertodd: no, same old troll
923 2013-03-10 07:35:23 <xjrn> i have warren and Luke-Jr on ignore, sorry if i don't play in the sand
924 2013-03-10 07:35:40 <warren> petertodd: it looks like folks gave up "DP" today huh?
925 2013-03-10 07:36:09 <petertodd> warren: They did? Aww
926 2013-03-10 07:36:19 <petertodd> warren: (I was busy getting real work done)
927 2013-03-10 07:36:37 <canoon> dp?
928 2013-03-10 07:37:11 <warren> canoon: http://pastebin.com/ng9nF4K3
929 2013-03-10 07:37:59 <gmaxwell> Ex0deus: yes, I didâ so that I could write up that explanation first.
930 2013-03-10 07:38:19 <gmaxwell> oops wrong window
931 2013-03-10 07:38:39 <canoon> so... wah?
932 2013-03-10 07:42:40 holorga has quit (Ping timeout: 276 seconds)
933 2013-03-10 07:45:17 [\\\] is now known as [III]
934 2013-03-10 07:45:55 [III] is now known as [\\\\\\\\\\\\\\]
935 2013-03-10 07:46:34 [\\\\\\\\\\\\\\] is now known as `0
936 2013-03-10 07:47:16 holorga has joined
937 2013-03-10 07:52:10 <muhoo> i knew it would happen, someone grabbed the vanity address 1FUCK
938 2013-03-10 07:52:37 <warren> you can't really own a vanity address, can you?
939 2013-03-10 07:52:53 <warren> I mean, prefix
940 2013-03-10 07:53:40 <muhoo> and, related, scrolling, "DP" makes me laugh, because (sorry) it will always mean "double penetration" to me.
941 2013-03-10 07:54:04 <muhoo> warren: true, there doesn't appear to be any registry for them.
942 2013-03-10 07:54:44 <warren> muhoo: there is no registry, you can't own a prefix
943 2013-03-10 07:54:45 <muhoo> ok, the dashjr.org dns issue appears to have been local, and transient.
944 2013-03-10 07:55:30 <muhoo> still disconcerted that bitcoinj just locked up because one seed domain out of 4 failed to resolve.
945 2013-03-10 07:55:55 moarrr has quit (Read error: Connection reset by peer)
946 2013-03-10 07:56:01 `0 is now known as [\\\]
947 2013-03-10 07:56:55 moarrr has joined
948 2013-03-10 07:57:19 ciphermonk has quit (Quit: Leaving)
949 2013-03-10 07:59:42 muhoo has quit (Quit: leaving)
950 2013-03-10 08:00:11 ThomasV has quit (Ping timeout: 248 seconds)
951 2013-03-10 08:01:07 gribble has quit (Remote host closed the connection)
952 2013-03-10 08:01:07 nanotube has quit (Remote host closed the connection)
953 2013-03-10 08:01:15 <gmaxwell> warren: some crazy people announced some 'service' to 'register' prefixes by making the first transaction paying it, called "firstbits" which caused an orgy of flooding transactions as people tried to claimjump prefixes which was probably only bounded by the vanitygen computational cost.
954 2013-03-10 08:01:47 <gmaxwell> warren: of course the whole idea is moronic: you can't do a secure efficient proof that a particular address was the first user of a prefix.
955 2013-03-10 08:01:51 <warren> gmaxwell: sounds like win.
956 2013-03-10 08:02:08 <gmaxwell> Which means that to use that resolution people will have to trust central servers.. and if you're going to do that you might as well skip the txn spam.
957 2013-03-10 08:02:11 ashams has joined
958 2013-03-10 08:02:11 ashams has quit (Changing host)
959 2013-03-10 08:02:11 ashams has joined
960 2013-03-10 08:02:21 <gwillen> gmaxwell: the efficiency problem being that you have to search the entire blockchain to look for counterexamples?
961 2013-03-10 08:02:36 <gmaxwell> fortunately the claim jumping means that it's unattractive "all the good prefixes are taken"
962 2013-03-10 08:02:51 <gmaxwell> gwillen: correct!
963 2013-03-10 08:02:59 * gwillen nods
964 2013-03-10 08:03:04 <gmaxwell> or at least the whole blockchain prior to the first example you know of.
965 2013-03-10 08:04:19 <gwillen> right
966 2013-03-10 08:05:33 <gmaxwell> of course as soon as we (folks here) saw it we were like "nooo donnnnt!" but the orgy had started, and the proof of it being a good idea was the flood of transactions producing 200+ 1e-8 outputs.
967 2013-03-10 08:05:51 <gmaxwell> (which is like .. totally stupid, since it's not like anyone wants to buy a private key from you)
968 2013-03-10 08:06:51 <gmaxwell> total idea of pruning and proofs, or computational complexity and indexes and such are lost on the php jockies (sorry those of you who are php + clue) promoting stuff like that.
969 2013-03-10 08:07:04 <gwillen> hahahahah
970 2013-03-10 08:07:11 <gwillen> I laugh because I was forced to write PHP recently
971 2013-03-10 08:07:19 <warren> AT GUNPOINT
972 2013-03-10 08:07:36 <warren> This is a clear sign to go to sleep. g'nite.
973 2013-03-10 08:07:41 <gwillen> haha
974 2013-03-10 08:07:43 Goonie has joined
975 2013-03-10 08:08:21 nanotube has joined
976 2013-03-10 08:08:25 <gmaxwell> gwillen: it was even more awesome that the first firstbits lookup site forever registered the name at the first confirm. So when reorgs changed the rightful 'firstbits' they gave wrong results.
977 2013-03-10 08:08:39 <gmaxwell> meaning you could tell people your firstbits address and then they'd send funds elsewhere.
978 2013-03-10 08:08:57 <gwillen> hah, oh dear
979 2013-03-10 08:09:34 <gmaxwell> they later made it 6, which only makes the problem less likely... and in doing soâ a problem created by the fundimental suckyness of the ideaâ they still didn't seem to realize that it was sucky. :P
980 2013-03-10 08:09:59 <gmaxwell> perhaps they actually believe a six deep reorg is impossible. :P
981 2013-03-10 08:11:07 <warren> doesn't mtgox assume that?
982 2013-03-10 08:11:17 <warren> oh right. sleep.
983 2013-03-10 08:12:32 toffoo has quit ()
984 2013-03-10 08:12:34 <gmaxwell> No,â they don't. Just unlikely enough to be worth the risks..... (also noting that if a reorg >6 happens they will likely freeze all trading and withdraws)
985 2013-03-10 08:12:51 <gwillen> yeah, I think if a 6-block reorg happens, we will have enough to worry about besides firstbits
986 2013-03-10 08:13:17 <gmaxwell> But with something like firstbits the risk is infinite and unbounded. A reorg of 6 happens and a bunch of firstbits change and forver money is sent to the wrong ones. :P
987 2013-03-10 08:13:45 <gmaxwell> well we've had 4 that I'm aware of. Maybe 5. (and this isn't including the really huge one for the overflow bug)
988 2013-03-10 08:14:09 <gmaxwell> 6 will happen at some point, but it probably won't reverse any txn.
989 2013-03-10 08:14:44 gribble has joined
990 2013-03-10 08:16:35 <gmaxwell> perhaps in the future bitcoin will forward the blockheaders of competing forks that a node considers valid but late... then you could augment your acceptance criteria based on that. (wouldn't stop a malicious reorg, but might make 2-3 confirm acceptance more safe aganst reorg by chance.)
991 2013-03-10 08:19:04 B0g4r7 has quit (Ping timeout: 276 seconds)
992 2013-03-10 08:19:18 moarrr has quit (Read error: No route to host)
993 2013-03-10 08:22:25 JZavala has joined
994 2013-03-10 08:23:46 B0g4r7 has joined
995 2013-03-10 08:23:56 brwyatt is now known as brwyatt|Away
996 2013-03-10 08:24:40 zveda is now known as [[]][[]][]
997 2013-03-10 08:27:59 mappum has quit (Ping timeout: 264 seconds)
998 2013-03-10 08:28:27 ciphermonk has joined
999 2013-03-10 08:28:30 DrAkaman has quit (Ping timeout: 245 seconds)
1000 2013-03-10 08:30:56 [\\\] is now known as A1398F4C58AC3D38
1001 2013-03-10 08:32:05 random_cat is now known as AI398F4C58AC3D38
1002 2013-03-10 08:33:12 A1398F4C58AC3D38 is now known as [\\\]
1003 2013-03-10 08:33:16 idstam has joined
1004 2013-03-10 08:33:56 AI398F4C58AC3D38 is now known as urandom_cat
1005 2013-03-10 08:34:59 urandom_cat is now known as random_cat
1006 2013-03-10 08:35:15 [[]][[]][] is now known as zveda
1007 2013-03-10 08:49:41 ThomasV has joined
1008 2013-03-10 08:52:46 ciphermonk has quit (Remote host closed the connection)
1009 2013-03-10 08:55:58 JZavala has quit (Ping timeout: 276 seconds)
1010 2013-03-10 08:57:55 <gmaxwell> would be nice if someone would make a pretty chart of bitcoin days destroyed / txn volume (in bytes, txn count, whatever).
1011 2013-03-10 09:02:07 ovidiusoft has joined
1012 2013-03-10 09:05:35 ciphermonk has joined
1013 2013-03-10 09:08:47 ThomasV has quit (Read error: Operation timed out)
1014 2013-03-10 09:13:45 ThomasV has joined
1015 2013-03-10 09:14:45 geb has quit (Ping timeout: 245 seconds)
1016 2013-03-10 09:16:40 comboy has quit (Remote host closed the connection)
1017 2013-03-10 09:16:46 comboy has joined
1018 2013-03-10 09:18:29 geb has joined
1019 2013-03-10 09:18:29 geb has quit (Excess Flood)
1020 2013-03-10 09:18:49 geb has joined
1021 2013-03-10 09:18:50 geb has quit (Excess Flood)
1022 2013-03-10 09:19:29 geb has joined
1023 2013-03-10 09:19:29 geb has quit (Excess Flood)
1024 2013-03-10 09:20:29 geb has joined
1025 2013-03-10 09:20:29 geb has quit (Excess Flood)
1026 2013-03-10 09:20:50 geb has joined
1027 2013-03-10 09:20:50 geb has quit (Excess Flood)
1028 2013-03-10 09:21:29 geb has joined
1029 2013-03-10 09:28:35 nus-- is now known as nus
1030 2013-03-10 09:32:03 grau has joined
1031 2013-03-10 09:37:35 gjs278 has quit (Read error: Connection reset by peer)
1032 2013-03-10 09:38:08 gjs278 has joined
1033 2013-03-10 09:42:18 gjs278 has quit (Read error: Connection reset by peer)
1034 2013-03-10 09:42:43 gjs278 has joined
1035 2013-03-10 09:43:43 grau has quit (Remote host closed the connection)
1036 2013-03-10 09:44:09 Quazgaa has quit (Ping timeout: 255 seconds)
1037 2013-03-10 09:56:36 Quazgaa has joined
1038 2013-03-10 09:59:20 Wayward has joined
1039 2013-03-10 09:59:36 <Wayward> In the bitcoin-qt console, isn't there a command to expand the keypool?
1040 2013-03-10 09:59:51 <Wayward> or would I have to close bitcoin-qt and restart it with a command line param?
1041 2013-03-10 10:03:54 Quazgaa has quit (Ping timeout: 260 seconds)
1042 2013-03-10 10:05:16 ashams has quit (Ping timeout: 240 seconds)
1043 2013-03-10 10:10:07 doublec has quit (Ping timeout: 248 seconds)
1044 2013-03-10 10:11:32 B0g4r7 has quit (Ping timeout: 276 seconds)
1045 2013-03-10 10:15:25 random_cat has quit (Ping timeout: 276 seconds)
1046 2013-03-10 10:17:55 fishfish is now known as AFK!~fishfish2@cpc10-mort5-2-0-cust225.19-2.cable.virginmedia.com|fishfish
1047 2013-03-10 10:21:44 B0g4r7 has joined
1048 2013-03-10 10:27:17 <weex> Wayward: bitcoind is the way
1049 2013-03-10 10:27:59 <Wayward> isn't that interface just a UI for bitcoind?
1050 2013-03-10 10:30:25 Ken` has joined
1051 2013-03-10 10:37:54 <weex> in a way but it doesn't implement everything in bitcoind
1052 2013-03-10 10:39:23 <gmaxwell> Wayward: it's just a config / commandline argument.
1053 2013-03-10 10:39:38 <gmaxwell> weex: the GUI implements everything in bitcoind.
1054 2013-03-10 10:39:52 <gmaxwell> -keypool=<n> Set key pool size to <n> (default: 100)
1055 2013-03-10 10:40:03 <gmaxwell> or keypool=n in bitcoin.conf
1056 2013-03-10 10:40:05 <Wayward> here's the thing
1057 2013-03-10 10:40:15 <Wayward> I want to pre-generate 10,000 keys
1058 2013-03-10 10:40:18 <Wayward> and not a penny more
1059 2013-03-10 10:40:33 <weex> oh i'm just thinking of what can be done from menus
1060 2013-03-10 10:40:49 <gmaxwell> if you set it to 10,000 and let it do that then set it to 100 then thats what it should do until you get to 10,000-100.
1061 2013-03-10 10:40:53 <Wayward> so my wallet backup doesn't become outdated because bitcoin-qt decided to continue generating new keys that entered circulation
1062 2013-03-10 10:41:17 <Wayward> so I have to quit, edit config, restart, quit, edit config, restart?
1063 2013-03-10 10:41:17 <gmaxwell> if you also lock the wallet then it won't be able to generate more until it is unlocked.
1064 2013-03-10 10:41:21 * Wayward blehs
1065 2013-03-10 10:41:34 <Wayward> you have to unlock the wallet to use it
1066 2013-03-10 10:41:38 <Wayward> not to create backups
1067 2013-03-10 10:42:00 <gmaxwell> you have to unlock it to send coins. I didn't know your application, some people want to precalculate to put it on a system as an address source.
1068 2013-03-10 10:42:13 <gmaxwell> You're really blehing about restarting it twice?
1069 2013-03-10 10:42:53 cheesepi has quit (Ping timeout: 264 seconds)
1070 2013-03-10 10:43:53 mcx has joined
1071 2013-03-10 10:43:53 mcx is now known as cheesepi
1072 2013-03-10 10:47:23 RazielZ has joined
1073 2013-03-10 10:48:59 one_zero has quit ()
1074 2013-03-10 10:52:29 zoinky has quit (Quit: Leaving.)
1075 2013-03-10 10:56:55 fishfish is now known as fishfish|AFK
1076 2013-03-10 11:00:48 xjrn has quit (Read error: Connection reset by peer)
1077 2013-03-10 11:01:51 xjrn has joined
1078 2013-03-10 11:05:43 nowan_ has quit (Read error: Operation timed out)
1079 2013-03-10 11:06:17 nowan has joined
1080 2013-03-10 11:11:53 ThomasV has quit (Read error: Operation timed out)
1081 2013-03-10 11:15:38 grau has joined
1082 2013-03-10 11:18:18 pooler has quit (Remote host closed the connection)
1083 2013-03-10 11:29:22 Wayward has left ()
1084 2013-03-10 11:34:32 Wayward has joined
1085 2013-03-10 11:34:45 <Wayward> btw, you have to start bitcoin-qt with -keypool=10,000
1086 2013-03-10 11:35:17 <Wayward> then you have to open the GUI console window, and type "keypoolrefill"
1087 2013-03-10 11:35:56 <Wayward> kind of silly that half the options exist as config/commandline params, and the other half exist as console commands.
1088 2013-03-10 11:36:04 <Wayward> and never the twain shall meet.
1089 2013-03-10 11:41:29 moarrr has joined
1090 2013-03-10 11:48:01 doublec has joined
1091 2013-03-10 11:48:15 doublec has quit (Changing host)
1092 2013-03-10 11:48:15 doublec has joined
1093 2013-03-10 11:58:12 axhlf has joined
1094 2013-03-10 12:04:27 <Luke-Jr> fwiw, restarted dnsseed for the lulz, but it looked fine
1095 2013-03-10 12:07:44 Hashdog has joined
1096 2013-03-10 12:09:13 D34TH has joined
1097 2013-03-10 12:09:14 D34TH has quit (Changing host)
1098 2013-03-10 12:09:14 D34TH has joined
1099 2013-03-10 12:10:19 fishfish is now known as AFK!~fishfish2@cpc10-mort5-2-0-cust225.19-2.cable.virginmedia.com|fishfish
1100 2013-03-10 12:16:44 Quazgaa has joined
1101 2013-03-10 12:19:24 t7 has quit (Read error: Connection timed out)
1102 2013-03-10 12:20:09 t7 has joined
1103 2013-03-10 12:20:31 sgornick has joined
1104 2013-03-10 12:24:47 bock has joined
1105 2013-03-10 12:27:53 CodeShark has quit (Remote host closed the connection)
1106 2013-03-10 12:36:46 daybyter has joined
1107 2013-03-10 12:37:17 <ciphermonk> Can I use locked outputs (locked with lockunspent) in raw transactions?
1108 2013-03-10 12:42:49 asdasada has quit (Ping timeout: 255 seconds)
1109 2013-03-10 12:43:18 fishfish is now known as fishfish|AFK
1110 2013-03-10 12:44:26 james321 has joined
1111 2013-03-10 12:46:54 HM has joined
1112 2013-03-10 12:47:01 fishfish is now known as AFK!~fishfish2@cpc10-mort5-2-0-cust225.19-2.cable.virginmedia.com|fishfish
1113 2013-03-10 13:00:25 t7 has quit (Read error: Connection timed out)
1114 2013-03-10 13:01:03 t7 has joined
1115 2013-03-10 13:16:11 t7_ has joined
1116 2013-03-10 13:20:01 fishfish is now known as fishfish|AFK
1117 2013-03-10 13:21:30 t7 has quit (Quit: Leaving)
1118 2013-03-10 13:22:54 da2ce7 has joined
1119 2013-03-10 13:23:47 t7_ is now known as t7
1120 2013-03-10 13:28:28 Lannoc has joined
1121 2013-03-10 13:29:21 da2ce7 has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
1122 2013-03-10 13:32:00 da2ce7 has joined
1123 2013-03-10 13:34:15 nus has quit (Read error: Connection reset by peer)
1124 2013-03-10 13:39:32 ciphermonk has quit (Ping timeout: 276 seconds)
1125 2013-03-10 13:47:50 nus has joined
1126 2013-03-10 13:56:46 copumpkin has quit (Ping timeout: 240 seconds)
1127 2013-03-10 13:57:22 copumpkin has joined
1128 2013-03-10 14:04:29 Z0rZ0rZ0r has joined
1129 2013-03-10 14:06:57 Namworld has joined
1130 2013-03-10 14:09:34 fishfish is now known as AFK!~fishfish2@cpc10-mort5-2-0-cust225.19-2.cable.virginmedia.com|fishfish
1131 2013-03-10 14:09:36 asdasada has joined
1132 2013-03-10 14:13:13 rdymac has joined
1133 2013-03-10 14:18:00 grau has quit (Remote host closed the connection)
1134 2013-03-10 14:31:04 fishfish is now known as fishfish|AFK
1135 2013-03-10 14:38:30 ThomasV has joined
1136 2013-03-10 14:40:09 rdymac has quit (Read error: Connection reset by peer)
1137 2013-03-10 14:41:05 zooko` has joined
1138 2013-03-10 14:43:10 pooler has joined
1139 2013-03-10 14:43:10 pooler has quit (Changing host)
1140 2013-03-10 14:43:10 pooler has joined
1141 2013-03-10 14:43:56 zooko has quit (Ping timeout: 248 seconds)
1142 2013-03-10 14:47:16 ThomasV_ has joined
1143 2013-03-10 14:49:40 rdymac has joined
1144 2013-03-10 14:50:20 ThomasV has quit (Ping timeout: 248 seconds)
1145 2013-03-10 14:50:45 fishfish is now known as AFK!~fishfish2@cpc10-mort5-2-0-cust225.19-2.cable.virginmedia.com|fishfish
1146 2013-03-10 14:57:06 nouitfvf has joined
1147 2013-03-10 15:00:35 rdymac has quit (Read error: Connection reset by peer)
1148 2013-03-10 15:07:32 Lannoc has quit ()
1149 2013-03-10 15:07:42 tsche has quit (Ping timeout: 260 seconds)
1150 2013-03-10 15:09:55 grau has joined
1151 2013-03-10 15:09:55 ciphermonk has joined
1152 2013-03-10 15:10:24 rdymac has joined
1153 2013-03-10 15:11:33 tsche has joined
1154 2013-03-10 15:22:01 vampireb has joined
1155 2013-03-10 15:22:38 GMP has joined
1156 2013-03-10 15:25:09 anddam has left ("WeeChat 0.3.9.2")
1157 2013-03-10 15:26:41 optimator_ has quit ()
1158 2013-03-10 15:28:24 agricocb has quit (Quit: Leaving.)
1159 2013-03-10 15:32:50 ThomasV_ has quit (Quit: Quitte)
1160 2013-03-10 15:37:07 rdymac has quit (Read error: Connection reset by peer)
1161 2013-03-10 15:40:37 Diablo-D3 has joined
1162 2013-03-10 15:47:46 canoon has quit (Ping timeout: 260 seconds)
1163 2013-03-10 15:52:04 vampireb has quit (Quit: Lost terminal)
1164 2013-03-10 15:53:42 vigilyn2 has quit (Read error: Connection reset by peer)
1165 2013-03-10 15:53:46 vigilyn3 has joined
1166 2013-03-10 16:04:08 RBecker is now known as rbecker
1167 2013-03-10 16:16:34 cobrahorse has joined
1168 2013-03-10 16:16:50 ciphermonk has quit (Ping timeout: 276 seconds)
1169 2013-03-10 16:19:27 vampireb has joined
1170 2013-03-10 16:21:20 cobrahorse has quit (Quit: - nbs-irc 2.39 - www.nbs-irc.net -)
1171 2013-03-10 16:32:34 zveda has quit (Quit: Ex-Chat)
1172 2013-03-10 16:36:28 Goonie has quit (Ping timeout: 248 seconds)
1173 2013-03-10 16:38:24 zooko` is now known as zooko
1174 2013-03-10 16:39:12 ciphermonk has joined
1175 2013-03-10 16:40:46 <licnep> is there any technical primer on the current bitcoin implementation? Something like the bitcoin paper but specific to the current implementation
1176 2013-03-10 16:41:47 <Luke-Jr> the source code of bitcoind!
1177 2013-03-10 16:43:19 bwen has joined
1178 2013-03-10 16:43:26 <licnep> Luke-Jr: genius! why didn't i think of that? hehe
1179 2013-03-10 16:43:34 <licnep> anyway i think i've found something
1180 2013-03-10 16:47:16 HM has quit (Ping timeout: 252 seconds)
1181 2013-03-10 16:47:38 MiningBuddy has quit (Remote host closed the connection)
1182 2013-03-10 16:48:23 JUSTcallmePRE has joined
1183 2013-03-10 16:48:38 <wumpus> you could try reading the BIPs; the most sigificant functional changes to the network have been documented in one
1184 2013-03-10 16:48:46 JUSTcallmePRE is now known as Guest56433
1185 2013-03-10 16:50:50 <licnep> wumpus: yea i'll check those out too
1186 2013-03-10 16:51:47 Guest56433 has quit (Client Quit)
1187 2013-03-10 16:52:11 b4tt3r135 has joined
1188 2013-03-10 16:56:31 Ken`_ has joined
1189 2013-03-10 16:59:46 Ken` has quit (Ping timeout: 255 seconds)
1190 2013-03-10 17:00:31 da2ce7_d has joined
1191 2013-03-10 17:01:33 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1192 2013-03-10 17:02:50 da2ce7 has quit (Ping timeout: 256 seconds)
1193 2013-03-10 17:05:50 muhoo has joined
1194 2013-03-10 17:07:09 <muhoo> are there any known instances of someone executing a preimage atyack against a pubkey, or is that mostly a theoretical possibility still?
1195 2013-03-10 17:10:08 <moarrr> lol i hope not
1196 2013-03-10 17:10:31 <moarrr> i assume if it was possible it woudl be attempted, probably on one of the wealthier addresses
1197 2013-03-10 17:11:37 xempew has joined
1198 2013-03-10 17:11:40 BenderCoin has quit (Ping timeout: 248 seconds)
1199 2013-03-10 17:13:16 Conflict has quit (Remote host closed the connection)
1200 2013-03-10 17:13:29 aethero has quit ()
1201 2013-03-10 17:13:49 <Luke-Jr> muhoo: theoretical impossibility, more like
1202 2013-03-10 17:14:23 valparaiso has quit (Remote host closed the connection)
1203 2013-03-10 17:14:29 <sipa> muhoo: by preimage attack again pubkey, you mean finding pubkeys given the address?
1204 2013-03-10 17:18:20 Conflict has joined
1205 2013-03-10 17:18:38 owowo has joined
1206 2013-03-10 17:21:26 bitafterbit has joined
1207 2013-03-10 17:22:12 impulse has joined
1208 2013-03-10 17:27:34 vampireb has quit (Quit: Lost terminal)
1209 2013-03-10 17:27:59 Goonie has joined
1210 2013-03-10 17:29:03 defunctzombie_zz is now known as defunctzombie
1211 2013-03-10 17:30:47 HM has joined
1212 2013-03-10 17:32:10 t7 has quit (Quit: Konversation terminated!)
1213 2013-03-10 17:32:39 <HM> hmm
1214 2013-03-10 17:33:49 <HM> 1 million RPC calls in 35 seconds. that's not too great
1215 2013-03-10 17:34:13 defunctzombie is now known as defunctzombie_zz
1216 2013-03-10 17:35:33 jgarzik_ has joined
1217 2013-03-10 17:37:19 krysits has joined
1218 2013-03-10 17:52:16 zoinky has joined
1219 2013-03-10 17:52:33 defunctzombie_zz is now known as defunctzombie
1220 2013-03-10 17:55:49 PiZZaMaN2K has joined
1221 2013-03-10 17:56:37 PiZZaMaN2K has quit (Changing host)
1222 2013-03-10 17:56:37 PiZZaMaN2K has joined
1223 2013-03-10 17:57:52 ByteUnit has joined
1224 2013-03-10 17:58:06 ByteUnit has left ()
1225 2013-03-10 17:58:51 zoinky has left ()
1226 2013-03-10 18:01:36 jgarzik_ has quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
1227 2013-03-10 18:01:53 valparaiso has joined
1228 2013-03-10 18:02:17 Lowflow has joined
1229 2013-03-10 18:02:18 bakh has joined
1230 2013-03-10 18:05:04 defunctzombie is now known as defunctzombie_zz
1231 2013-03-10 18:10:20 b4tt3r135 has quit (Ping timeout: 248 seconds)
1232 2013-03-10 18:11:16 Lowflow_ has joined
1233 2013-03-10 18:11:24 Lowflow has quit (Ping timeout: 248 seconds)
1234 2013-03-10 18:11:26 Lowflow_ is now known as Lowflow
1235 2013-03-10 18:11:53 random_cat has joined
1236 2013-03-10 18:12:28 daybyter has quit (Ping timeout: 248 seconds)
1237 2013-03-10 18:12:38 daybyter has joined
1238 2013-03-10 18:13:20 Guest40859 has quit (Quit: leaving)
1239 2013-03-10 18:18:24 MobiusL has quit (Remote host closed the connection)
1240 2013-03-10 18:19:26 MobiusL has joined
1241 2013-03-10 18:20:41 random_cat has quit (Remote host closed the connection)
1242 2013-03-10 18:21:58 random_cat has joined
1243 2013-03-10 18:26:07 frac has joined
1244 2013-03-10 18:26:49 <frac> hello, i'm trying to use -loadblock to load an existing blk....dat file and it doesnt seem to be loading
1245 2013-03-10 18:27:02 <frac> im using version 0.8
1246 2013-03-10 18:27:26 <Prattler> How much RAM does 1 unspent output take?
1247 2013-03-10 18:27:40 <Prattler> (assuming UTXO is stored in RAM)
1248 2013-03-10 18:27:54 grau has quit (Remote host closed the connection)
1249 2013-03-10 18:28:10 grau has joined
1250 2013-03-10 18:28:17 <sipa> Prattler: it's not really stored in RAM, just cached
1251 2013-03-10 18:28:24 <sipa> in several places even
1252 2013-03-10 18:28:40 <Prattler> so how much data is that? ~100 bytes?
1253 2013-03-10 18:28:59 <sipa> that order of magnitude yes, i'd say a bit more
1254 2013-03-10 18:29:16 <sipa> also, depends what you're comparing with
1255 2013-03-10 18:29:23 <frac> hey sipa, if im starting a new instance of bitcoin but have a bunch of blk000.dat files, whats the fastest way to get that read into bitcoin
1256 2013-03-10 18:29:39 <frac> if i use the -rescan or -reindex command, where must these blk....dat files be located
1257 2013-03-10 18:29:40 <Prattler> well I'd like to calculate how much 1 unspent output costs to the network
1258 2013-03-10 18:30:21 <sipa> Prattler: it depends whether it's a new transaction, or just a UTXO being added to an already transaction
1259 2013-03-10 18:30:38 <sipa> frac: in blocks/blk00000.dat, blk00001.dat, ...
1260 2013-03-10 18:30:42 <Luke-Jr> Prattler: also note most of the network is using pre-0.8 versions, which doesn't do UTXO db
1261 2013-03-10 18:30:43 <Prattler> sipa, oh? explain please
1262 2013-03-10 18:31:09 <sipa> Prattler: UTXO's are stored in a tree, first indexed by txid, then by output#
1263 2013-03-10 18:31:12 <frac> sipa if there is no index folder in blocks, will it still pick it up?
1264 2013-03-10 18:31:18 <Prattler> Luke-Jr, well the calculation would be to evaluate future system costs, assuming nodes are most efficient
1265 2013-03-10 18:31:21 <sipa> frac: -reindex should
1266 2013-03-10 18:31:35 <Prattler> sipa, thanks! Let me think on that
1267 2013-03-10 18:31:45 <sipa> Prattler: so if you add a tx with a UTXO, you need a new entry in the top tree
1268 2013-03-10 18:31:52 <sipa> while otherwise it's just an output being added
1269 2013-03-10 18:31:57 <Prattler> I understand
1270 2013-03-10 18:32:06 <sipa> Prattler: if you assume maximal efficiency, i think you should just count on-disk storage
1271 2013-03-10 18:32:08 <Prattler> how much space would each of those be?
1272 2013-03-10 18:32:19 <sipa> anything above will be caches, which can be small or large, but don't have a permanent cosr
1273 2013-03-10 18:32:28 <sipa> Prattler: let me count that for you
1274 2013-03-10 18:33:08 <Prattler> I'd think that assuming bitcoin is super popular and is pushing around 10+ MB blocks, most (50%?) of the UTXO should be cached in RAM.
1275 2013-03-10 18:33:23 Diablo-D3 has quit (Quit: This computer has gone to sleep)
1276 2013-03-10 18:34:37 <ciphermonk> One output is 34 byte ( standard pubkeyhash output )
1277 2013-03-10 18:34:52 <sipa> ciphermonk: the UTXO on disk uses a custom format which compressed such outputs
1278 2013-03-10 18:35:29 <ciphermonk> oh cool, so it basically just stores the value and the pubkeyhash ?
1279 2013-03-10 18:35:57 <frac> thanks again sipa you are always helpful
1280 2013-03-10 18:36:04 <frac> 10 internet points awarded to you
1281 2013-03-10 18:36:11 <ciphermonk> I'll go read the code ;-)
1282 2013-03-10 18:36:19 frac has quit (Quit: leaving)
1283 2013-03-10 18:36:51 Diablo-D3 has joined
1284 2013-03-10 18:37:28 <sipa> Prattler: should be 41.5 bytes for each transactions which is not entirely spent (excluding any of its outputs)
1285 2013-03-10 18:37:58 <sipa> plus 23 bytes for each unspent output
1286 2013-03-10 18:38:14 <Prattler> oh that's cool :) Thanks!
1287 2013-03-10 18:38:34 <sipa> in-memory it's a lot more, but that's just the lowest-level cache
1288 2013-03-10 18:38:48 <sipa> the on-disk format also gets cached, which has the same space characteristics
1289 2013-03-10 18:39:45 <sipa> Prattler: the gettxoutsetinfo RPC commands calculates some statistics
1290 2013-03-10 18:40:12 <Prattler> nice, will check it out, thanks
1291 2013-03-10 18:40:51 <xjrn> sipa: is it fair to consider the UTXO the same as a shared simulation? e.g. symetrical on all nodes, and eventually consistent based on new inputs
1292 2013-03-10 18:41:15 <Happzz> is samba capable of indexing stuff for windows clients to effectively search through?
1293 2013-03-10 18:41:23 <Happzz> i know a windows server can do that
1294 2013-03-10 18:41:29 <Happzz> if it can, how?
1295 2013-03-10 18:41:57 <sipa> Happzz: maybe ask in #samba? :)
1296 2013-03-10 18:42:29 <Happzz> #samba is dead :(
1297 2013-03-10 18:42:40 <Happzz> i asked that question there like a dozen times just today
1298 2013-03-10 18:42:46 <Happzz> oh oops
1299 2013-03-10 18:42:52 <Happzz> lol i thought it's #samba-dev!
1300 2013-03-10 18:42:57 bakh has quit (Remote host closed the connection)
1301 2013-03-10 18:43:13 <Happzz> samba-technical even
1302 2013-03-10 18:43:18 <Happzz> sorry.
1303 2013-03-10 18:44:43 defunctzombie_zz is now known as defunctzombie
1304 2013-03-10 18:45:46 daybyter has quit (Quit: Konversation terminated!)
1305 2013-03-10 18:46:32 xjrn has quit (Read error: No route to host)
1306 2013-03-10 18:46:53 <Prattler> Is it ok to assume UTXO data has to be on RAM or at least on an SSD drive. Assuming bitcoin gets big, there are lots of transactions, blocks are big, etc. Considering an attack like this https://bitcointalk.org/?topic=144122
1307 2013-03-10 18:46:55 HiWEB has joined
1308 2013-03-10 18:46:59 <Prattler> ?
1309 2013-03-10 18:47:47 <remote> how many blocks currently exist?
1310 2013-03-10 18:47:48 xjrn has joined
1311 2013-03-10 18:48:08 <sipa> ;;bc,blocks
1312 2013-03-10 18:48:13 <gribble> timed out
1313 2013-03-10 18:48:15 <remote> ;;bc,blocks
1314 2013-03-10 18:48:16 <gribble> 225226
1315 2013-03-10 18:48:20 <remote> not bad
1316 2013-03-10 18:48:26 <remote> hey sipa
1317 2013-03-10 18:48:46 <remote> i'm about to resume trying to convert pub key to address again ;-)
1318 2013-03-10 18:49:10 <remote> there must be something silly I'm doing wrong
1319 2013-03-10 18:50:47 PhantomSpark has joined
1320 2013-03-10 18:50:57 <HM> remote: what language?
1321 2013-03-10 18:53:14 zveda has joined
1322 2013-03-10 18:53:22 <remote> HM: python
1323 2013-03-10 18:53:36 <remote> I didn't write much, trying to use existing code
1324 2013-03-10 18:54:34 <remote> I've tried using https://github.com/jtobey/bitcoin-abe/blob/master/Abe/util.py
1325 2013-03-10 18:55:30 <remote> hash_to_address("00", pubkey_to_hash(pubkey))
1326 2013-03-10 18:57:04 <remote> http://paste.lisp.org/display/135995
1327 2013-03-10 18:57:29 <remote> does anything seem incorrect in the usage I'm making of these methods?
1328 2013-03-10 18:58:32 <lianj> unpack the hex pubkey first?
1329 2013-03-10 18:58:54 <sipa> you're passing a hex-encoded pubkey, not the pubkey itself
1330 2013-03-10 18:58:56 Pwngu has quit (Ping timeout: 245 seconds)
1331 2013-03-10 18:59:02 BenderCoin has joined
1332 2013-03-10 19:01:16 <remote> I get the same results if I .decode('hex')
1333 2013-03-10 19:01:24 <remote> if I pass pubkey.decode('hex')
1334 2013-03-10 19:03:41 <remote> hmm no not the same
1335 2013-03-10 19:04:23 <remote> http://paste.lisp.org/display/135996
1336 2013-03-10 19:04:46 <remote> it's still not the address
1337 2013-03-10 19:06:27 etotheipi_ has joined
1338 2013-03-10 19:06:54 <remote> sipa: is the pubkey.decode('hex') the public key?
1339 2013-03-10 19:06:58 <etotheipi_> sipa: gmaxwell: Luke-Jr: I'm sure you'll see it yourself, but I just did a simple download test and here's what I found: https://bitcointalk.org/index.php?topic=150782.msg1608234#msg1608234
1340 2013-03-10 19:07:48 ThomasV has joined
1341 2013-03-10 19:08:03 <lianj> remote: "0x00" is wrong
1342 2013-03-10 19:08:22 <lianj> do "\x00"
1343 2013-03-10 19:08:57 <remote> win!
1344 2013-03-10 19:09:04 <remote> thanks lianj!
1345 2013-03-10 19:11:15 axhlf has quit (Remote host closed the connection)
1346 2013-03-10 19:12:28 Belkaar has quit (Ping timeout: 246 seconds)
1347 2013-03-10 19:12:39 Pwngu has joined
1348 2013-03-10 19:12:55 <sipa> etotheipi_: fixed in 0.8.1
1349 2013-03-10 19:13:19 <etotheipi_> sipa: really? what is different?
1350 2013-03-10 19:13:24 <sipa> it uses projected transaction count instead of block count
1351 2013-03-10 19:13:37 <sipa> weighing transactions after the last checkpoint higher
1352 2013-03-10 19:14:08 <etotheipi_> sipa: oh, I thought you meant the O(N^8) relationship was "fixed" in 0.8.1... but you're saying your "percent complete" meter is fixed
1353 2013-03-10 19:14:13 <sipa> yeah
1354 2013-03-10 19:14:43 <etotheipi_> well, I just wanted to come up with a reasonable equation to use for myself, and was surprised that N^8 was the answer
1355 2013-03-10 19:15:05 <sipa> it's not really useful to try to measure without taking signature verification into account
1356 2013-03-10 19:15:17 <sipa> if anything, do prediction before and after the checkpoint separately
1357 2013-03-10 19:15:34 <sipa> on my system, it's easily a speed factor 10
1358 2013-03-10 19:15:38 <etotheipi_> what do you mean?
1359 2013-03-10 19:15:52 <etotheipi_> I setup a process to download from scratch and record progress every 5 sec
1360 2013-03-10 19:15:53 <sipa> well signature verification is disabled before the last checkpoint
1361 2013-03-10 19:15:56 <etotheipi_> oooh
1362 2013-03-10 19:16:09 FredEE has joined
1363 2013-03-10 19:16:14 <sipa> it's quite expected to be a lot slower in the last blocks
1364 2013-03-10 19:16:29 <etotheipi_> I guess that would've been good to realize...
1365 2013-03-10 19:17:45 RainbowDashh has quit (Quit: Sleep Mode. <redacted> I joked I would replace all her sensitive files on her old computer with ponies so nothing could be recovered.)
1366 2013-03-10 19:18:54 <etotheipi_> does anyone here use a Bitcoin-accepting webhost?
1367 2013-03-10 19:18:59 tg has quit (Ping timeout: 264 seconds)
1368 2013-03-10 19:19:15 Belkaar has joined
1369 2013-03-10 19:19:36 <zooko> etotheipi_: I use cinfu.com
1370 2013-03-10 19:19:53 <zooko> etotheipi_: recently heard about http://www.orangewebsite.com/bitcoin.php but haven't tried it.
1371 2013-03-10 19:20:20 <gmaxwell> Prattler: it doesn't need to be in ram or a ssd.
1372 2013-03-10 19:20:26 <etotheipi_> oh, does WordPress do webhosting?
1373 2013-03-10 19:20:28 <Prattler> oh? how so?
1374 2013-03-10 19:21:16 <zooko> etotheipi_: cinfo.com sells me a vps and I run my own web server software on it.
1375 2013-03-10 19:21:19 <gmaxwell> Prattler: it does txn*log(utxo) random accesses at most. This number can't be large. And the latency of doing this is substantially hidden for all txn that you've heard before they've shown up in a block.
1376 2013-03-10 19:21:52 <etotheipi_> meh... I just had someone ask me to recommend a webhost... I was just wondering if there was a reliable on, since she just got involved with Bitcoin
1377 2013-03-10 19:22:09 <Scrat> etotheipi_: #bitcoin-hosting
1378 2013-03-10 19:22:10 <gmaxwell> Prattler: it does need to be in _local_ storage.. because it needs to be trusted, and inserting potentially hundreds of ms in for each would likely break it.
1379 2013-03-10 19:22:19 <etotheipi_> Scrat: perfect, thanks
1380 2013-03-10 19:22:26 <Prattler> gmaxwell, but if bitcoin does 1000 transactions/second, wouldn't it be a problem to fetch the UTXO from a slow HDD?
1381 2013-03-10 19:22:45 BeagleSeven has joined
1382 2013-03-10 19:23:32 <gmaxwell> Prattler: bitcoin cannot do 1000 transactions per second. And if you were to modify it to try you'd run out of ECDSA _long_ before you'd run out of IO.
1383 2013-03-10 19:25:46 <Prattler> well I'm assuming bitcoin has gained global adoption and has scaled up. ECDSA validations are parallelizable, so it should not be a problem. I understand that storage can be distributed...
1384 2013-03-10 19:25:49 <gmaxwell> (and out of bandwidth, and out of people willing to do this validation stuff, and ...etc) And, well. "relay your transactions early if you don't want your blocks to be propagted slowly"
1385 2013-03-10 19:26:29 owowo has quit (Remote host closed the connection)
1386 2013-03-10 19:26:32 <gmaxwell> Prattler: storage lookups are perfectly parralizable too.parallelizable too.
1387 2013-03-10 19:26:54 <Prattler> yes, I get it.. Any way to calculate the cost of such a system?
1388 2013-03-10 19:27:21 <gmaxwell> Prattler: of ... a computer? use the dell order page? :P
1389 2013-03-10 19:27:39 BeagleSeven has left ()
1390 2013-03-10 19:27:59 <gmaxwell> Prattler: the utxo accesses can just be assume to be constant time per txin.
1391 2013-03-10 19:28:16 <gmaxwell> (because log(utxo size) is never especially big)
1392 2013-03-10 19:28:29 <Prattler> Ok. The problem is if HDD access time > (1/transaction_rate)
1393 2013-03-10 19:28:33 owowo has joined
1394 2013-03-10 19:29:06 <Prattler> you can make a system with 100 hard disks and they will read data 100 faster, am I correct?
1395 2013-03-10 19:29:14 <gmaxwell> Prattler: "The problem is if ECDSA validation time is > 1/transaction_rate"
1396 2013-03-10 19:29:23 <gmaxwell> Prattler: yes.
1397 2013-03-10 19:29:25 <Prattler> ok, thanks
1398 2013-03-10 19:29:27 owowo has quit (Remote host closed the connection)
1399 2013-03-10 19:29:33 <gmaxwell> But this is a silly topic, whos going to pay for those 100 harddisks?
1400 2013-03-10 19:29:46 <Prattler> that is the main problem
1401 2013-03-10 19:29:56 owowo has joined
1402 2013-03-10 19:29:58 <Prattler> that maybe full nodes could be too expensive :P
1403 2013-03-10 19:30:43 <Luke-Jr> maybe some day we will have to run "semi-full nodes" that verify everything, but discard most of the data ;p
1404 2013-03-10 19:31:19 <xjrn> ssd's scale horizontally with size
1405 2013-03-10 19:31:34 <gmaxwell> Luke-Jr: well Prattler is specifically asking about utxo side, which is the minimum you need to actually validate against inflation. Though it's possibleâ with some hardforking changesâ to do secure randomized partial validation.
1406 2013-03-10 19:31:35 <sipa> Luke-Jr: sure
1407 2013-03-10 19:31:41 Lowflow has quit (Remote host closed the connection)
1408 2013-03-10 19:32:07 <Luke-Jr> gmaxwell: right, but you could insist the spender include the relevant UTXO data with the txn
1409 2013-03-10 19:32:59 <Luke-Jr> as long as you save enough to verify the data they provide quickly
1410 2013-03-10 19:33:36 gritcoin has joined
1411 2013-03-10 19:33:45 <gmaxwell> Luke-Jr: unfortunately w/ sender provided utxo data you can't actually update the utxo set, only validate it.
1412 2013-03-10 19:34:09 tg has joined
1413 2013-03-10 19:36:15 <gmaxwell> Prattler: one idea, for example is you make it possible to relay messages that say "someone cheated <here>, and here is the data you need to prove this for yourself" then you have most nodes randomly check some small fraction... and trust that if there is any cheating someone will notice and make an announcement and you'll hear it. Though makes an attacker that can partition you much more powerful.
1414 2013-03-10 19:37:10 <Prattler> gmaxwell, it's probably what a single node would do to optimize the load. I think we need to assume the full node doesn't trust anyone.
1415 2013-03-10 19:37:41 <gmaxwell> Prattler: well if you're assuming a full node needs 100 high speed disks or whatever then it should also be safe to assume that there are almost no full nodes.
1416 2013-03-10 19:38:01 <Prattler> well that's my point.. that maybe this is how bitcoin will die
1417 2013-03-10 19:38:02 <gmaxwell> as there is no way to monetize validation.
1418 2013-03-10 19:38:09 paraipan has joined
1419 2013-03-10 19:38:10 <gmaxwell> Prattler: it can only die that way if we choose that death.
1420 2013-03-10 19:38:14 krysits has quit ()
1421 2013-03-10 19:38:26 <gmaxwell> Since the blocksize is capped and the current limits can't be argued to result in that kind of death.
1422 2013-03-10 19:39:00 gritcoin has quit (Quit: gritcoin)
1423 2013-03-10 19:39:26 <Prattler> yes, the current 1MB in a fortunate limiter to full node cost increase
1424 2013-03-10 19:39:33 <gmaxwell> if we do do not make a hardfork and bitcoin dies it would be because transactions are too costly. (or some other technical issue, or because something else gets promoted by facebook or...)
1425 2013-03-10 19:40:29 defunctzombie is now known as defunctzombie_zz
1426 2013-03-10 19:40:47 Pwngu has quit ()
1427 2013-03-10 19:41:13 PiZZaMaN2K is now known as PiZZaMaN2K|away
1428 2013-03-10 19:41:27 tg has quit (Ping timeout: 245 seconds)
1429 2013-03-10 19:41:41 Pwngu has joined
1430 2013-03-10 19:42:43 <gmaxwell> Prattler: my thinking is that we put in all the scaling we can to grow as much as is possible with as much security as possible (e.g. all those cheating proofs and such), and then increment the limit periodically only when its clear that doing so doesn't cause a loss of decenteralization. But there are a lot of risks, including the risk that short term thinking miners or the using-public who doesn't understand these subtle tradeoffs ...
1431 2013-03-10 19:42:49 <gmaxwell> ... demanding an uncapped blocksize which dooms the system to bloat death.
1432 2013-03-10 19:43:11 <xjrn> according to google (((minutes per day) / 10) * (1 megabyte)) * 365 = 51.328125 gigabytes
1433 2013-03-10 19:43:12 <Prattler> gmaxwell, that's exactly what I'm thinking, I just didn't have time to put in in writing
1434 2013-03-10 19:43:20 <gmaxwell> It's further complicated that this issue is a weak spot that someone trying to destroy bitcoin could exploit.
1435 2013-03-10 19:44:07 <xjrn> ram will be cheap enough to catch up with current block size limits soon enough
1436 2013-03-10 19:44:49 <gmaxwell> E.g. someone could maliciously spam the blockchain to make txn fees go up while promoting uncapping the limit to users and force a tough decision between usability and securityâ and since security is distant people tend to reliably make bad long term decisions. ... and this attack is indistinguishable from stuff that happens without malice. :(
1437 2013-03-10 19:45:23 <i2pRelay> <Schnaubelt@i2p> Is this relay two-way?
1438 2013-03-10 19:45:34 <sipa> Schnaubelt: no!
1439 2013-03-10 19:46:47 <gmaxwell> oh hey, schnaubelt people were saying the i2prelay didn't work in #bitcoin the other day.
1440 2013-03-10 19:47:15 <gmaxwell> schnaubelt: is it working there too now?
1441 2013-03-10 19:47:18 tg has joined
1442 2013-03-10 19:47:27 <i2pRelay> <Schnaubelt@i2p> I already knew that. Good to see it goes both ways here.
1443 2013-03-10 19:48:10 <gmaxwell> xjrn: with the limited blocksize there is no need to use ram though.
1444 2013-03-10 19:48:26 <i2pRelay> <Schnaubelt@i2p> On this side #bitcoin messages only come in, but not out.
1445 2013-03-10 19:48:37 Lowflow has joined
1446 2013-03-10 19:48:44 <xjrn> 100 disks, discounting that nowadays a single ssd can max a controller, seems an unlikely eventuality
1447 2013-03-10 19:49:15 <xjrn> that was my point in looking up bloat per year
1448 2013-03-10 19:49:21 <xjrn> i didnt know til now
1449 2013-03-10 19:50:27 <xjrn> google actually likes "(minutes per year /10 * 1 megabyte)", fwiw
1450 2013-03-10 19:52:16 jevin has quit (Ping timeout: 240 seconds)
1451 2013-03-10 19:53:20 <Eliel_> Is there a thread somewhere that will get me a quick overview on where the current discussion is about whether or not to increase the blocksize limit and if so, how to do it?
1452 2013-03-10 19:53:38 <xjrn> if a utxo item were hypotheticall referenced within 20 bytes, idealizing that a tx is 2 utxo plus 10 bytes of ieee floating point, you could describe 20.9 kilotx in a megabyte, or about 1000 per minute
1453 2013-03-10 19:53:48 tg has quit (Ping timeout: 264 seconds)
1454 2013-03-10 19:55:23 jevin has joined
1455 2013-03-10 19:55:51 <i2pRelay> <KillYourTV@i2p> gmaxwell: the relay bot was muted/banned in #bitcoin a week or so ago (because of an idiot flooder on this side :/) but I don't know if it's been lifted. I do know that messages don't get through to the freenode side in #bitcoin.
1456 2013-03-10 19:57:28 <i2pRelay> <Schnaubelt@i2p> KillYourTV, I know that. The last time I checked (which was like months ago) that was the case, and I just assumed it was always like that.
1457 2013-03-10 19:57:43 <i2pRelay> <Schnaubelt@i2p> Damn flooders. They're why we can't have nice things.
1458 2013-03-10 19:58:03 <i2pRelay> <KillYourTV@i2p> let's keep it on topic so we don't get blocked here too ;)
1459 2013-03-10 19:58:27 <i2pRelay> <Schnaubelt@i2p> (yeah. I'll shut up now.)
1460 2013-03-10 19:58:51 zooko has quit (Ping timeout: 276 seconds)
1461 2013-03-10 20:00:22 unknown45682 has joined
1462 2013-03-10 20:00:54 <xjrn> there's a "Hutter prize" which pays per fraction of wikipedia corpus compressed against $50k total for beating the previous.
1463 2013-03-10 20:02:18 <xjrn> mining seems like it's got its own builtin prize for compressing tx, if maximum abuse were factored in as a constant
1464 2013-03-10 20:02:23 ciphermonk has quit (Ping timeout: 276 seconds)
1465 2013-03-10 20:03:04 Lowflow has quit (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931])
1466 2013-03-10 20:07:45 zooko has joined
1467 2013-03-10 20:10:40 HiWEB has quit (Ping timeout: 248 seconds)
1468 2013-03-10 20:10:51 <Prattler> I tried to estimate the network storage cost for 1 unspent output if the network scales up tomorrow (hardware costs remain the same).
1469 2013-03-10 20:10:58 <Prattler> please tell me if something is very broken
1470 2013-03-10 20:10:58 <Prattler> https://bitcointalk.org/index.php?topic=151329.msg1608413#msg1608413
1471 2013-03-10 20:12:48 <warren> Prattler: indeed, everyone needs to better understand that the block size storage is NOT the only cost. Our fee calculations forgot to think about the UTXO cost.
1472 2013-03-10 20:13:51 <Prattler> A malicious party could pay $0.02 to put $0.08 load on a network.
1473 2013-03-10 20:14:00 <Prattler> the assumption was that no one would do this...
1474 2013-03-10 20:14:08 <Prattler> but.. it costs nothing for satoshi dice :( BOOM!!
1475 2013-03-10 20:14:17 Lowflow has joined
1476 2013-03-10 20:14:44 zooko has quit (Ping timeout: 276 seconds)
1477 2013-03-10 20:14:49 <Prattler> SD is of course just an example, each time a block size is increased, it would get filled by similar users
1478 2013-03-10 20:15:26 <Prattler> because block size is pretty much free (0.00008 BTC according to Gavin)
1479 2013-03-10 20:15:42 <gmaxwell> Prattler: it's worse than you say there. What is your cost in the model for _one_ copy?
1480 2013-03-10 20:16:02 <Prattler> so 0.00008 BTC miner cost and $0.08 network cost..
1481 2013-03-10 20:16:13 <gmaxwell> because the miner will accept one_copy_cost*profit_margin and be quite happy, the rest is all a negative externality.
1482 2013-03-10 20:16:26 <Prattler> yes true
1483 2013-03-10 20:16:41 <Prattler> the miner should accept everything above 0.00008 BTC
1484 2013-03-10 20:16:45 <Prattler> a rational one
1485 2013-03-10 20:17:21 <Prattler> <gmaxwell> Prattler: it's worse than you say there. What is your cost in the model for _one_ copy?
1486 2013-03-10 20:17:37 paraipan has quit (Write error: Broken pipe)
1487 2013-03-10 20:17:38 owowo has quit (Remote host closed the connection)
1488 2013-03-10 20:17:39 <Prattler> I'm not sure I fully understand this. Does this coincide with Gavin's calculations?
1489 2013-03-10 20:18:09 owowo has joined
1490 2013-03-10 20:18:12 <gmaxwell> gavin's calculations were purely on the marginal orphaning risk.
1491 2013-03-10 20:18:25 <gmaxwell> Which you're ignoring, but they're very small.
1492 2013-03-10 20:18:45 <gmaxwell> PRab in here was doing some more sophicated orhpaning cost estimations.
1493 2013-03-10 20:18:59 <Prattler> well he calculated one time miner costs, which is only risk
1494 2013-03-10 20:19:22 tg has joined
1495 2013-03-10 20:19:34 <gmaxwell> but orphaning costs go down if you have fewer better connected miners in any case.
1496 2013-03-10 20:19:39 paraipan has joined
1497 2013-03-10 20:19:53 <Prattler> either way, costs for the miner are cheap, however you calculate it
1498 2013-03-10 20:20:05 <gmaxwell> Yup.
1499 2013-03-10 20:20:10 <Prattler> hashing is expensive, but adding a single transaction is chea
1500 2013-03-10 20:20:12 <Prattler> hashing is expensive, but adding a single transaction is cheap
1501 2013-03-10 20:20:18 <Prattler> so it makes sense to add as much of those as possible
1502 2013-03-10 20:20:23 <Prattler> (for the miner)
1503 2013-03-10 20:20:26 <gmaxwell> Well hashing is adaptive. It can be very cheap.
1504 2013-03-10 20:20:28 vigilyn has joined
1505 2013-03-10 20:20:45 <gmaxwell> a single gpu can run the whole network at minimum difficulty.
1506 2013-03-10 20:21:05 <xjrn> it may well be that SD is seen as a way to insert hidden costs to inflate the cost to play, passed along to the price, and induce the impulse buy of new entrants who require more time to decypher the hidden costs than the prospecting hype
1507 2013-03-10 20:22:16 vigilyn3 has quit (Ping timeout: 240 seconds)
1508 2013-03-10 20:23:48 tg has quit (Ping timeout: 264 seconds)
1509 2013-03-10 20:24:30 <xjrn> it seems like the reactionary client patches to invalidate dust amounts in tx reduces the available currency faster, despite cheapening the near-term infrastructure overhead
1510 2013-03-10 20:24:47 BenderCoin has quit (Ping timeout: 245 seconds)
1511 2013-03-10 20:27:00 <Prattler> xjrn, pretending that bitcoin can support information transactions is cheating the users. This is just not true.
1512 2013-03-10 20:27:46 <Prattler> so if bitcoin will suffer because SD can't send dust outputs, I'd say let it be
1513 2013-03-10 20:28:01 <Prattler> better that than long term failure of the network
1514 2013-03-10 20:28:42 defunctzombie_zz is now known as defunctzombie
1515 2013-03-10 20:29:36 <xjrn> Prattler: as i see bitcoin might've initially missed the mark in the interest of security, a near miss, but a miss. it charges by the byte, but doesn't assert that entropy is taxable.
1516 2013-03-10 20:29:48 skeledrew1 has joined
1517 2013-03-10 20:30:09 <Prattler> wow, a cool observation
1518 2013-03-10 20:30:37 bitcoinbulletin has quit (Ping timeout: 245 seconds)
1519 2013-03-10 20:30:38 <Prattler> need to think on that.. for like.. a long time!
1520 2013-03-10 20:32:12 skeledrew has quit (Ping timeout: 272 seconds)
1521 2013-03-10 20:32:57 BenderCoin has joined
1522 2013-03-10 20:33:23 CaptainBlaze has joined
1523 2013-03-10 20:34:38 <xjrn> if i generate a new key for each dust payment, i think it's fair to pay a fee on the difference between declaring a new address, and declaring an old address with a new tx, by a huge magnitude. the difference between referencing existing utxo and relaying a new key
1524 2013-03-10 20:34:57 zooko has joined
1525 2013-03-10 20:38:42 ahbritto has joined
1526 2013-03-10 20:38:46 ahbritto_ has joined
1527 2013-03-10 20:39:17 rlifchitz has quit (Quit: "I never worry about action, but only about inaction" (W. Churchill))
1528 2013-03-10 20:40:29 bitcoinbulletin has joined
1529 2013-03-10 20:43:29 rlifchitz has joined
1530 2013-03-10 20:43:29 rlifchitz has quit (Changing host)
1531 2013-03-10 20:43:29 rlifchitz has joined
1532 2013-03-10 20:44:39 <xjrn> from what i read of early bitcoin concepts, when bitcoin was first published it started with claims that you could do per-group accounting and use the information as an irrefutable ledger to make some other type of accountability transparent and easy.
1533 2013-03-10 20:45:21 gritcoin has joined
1534 2013-03-10 20:45:26 <xjrn> fast forward to now, SD provides an absolutely impeccable accounting of winners and losing, but the network does not "value" that transparency
1535 2013-03-10 20:46:06 <xjrn> so i'd be fucked if i sold accounting innovations based on trusting miners not to screw with the knobs and dials to profit thier own simple accounting interests
1536 2013-03-10 20:46:09 <warren> xjrn: why do you sit here literally all day and talk about things that nobody cares about? Before you were talking past people, pushing your agenda that nobody cares about, and now you're just trolling into air.
1537 2013-03-10 20:46:14 <xjrn> using bitcoin as a new paradigm
1538 2013-03-10 20:48:04 <xjrn> if i wanted to pitch venture capitalists on micropayments, I would NOT mention bitcoin, sadly
1539 2013-03-10 20:48:22 <Luke-Jr> warren: he has us on ignore, lol
1540 2013-03-10 20:50:09 distortednet has joined
1541 2013-03-10 20:51:14 <egecko> is there even a #bitcoin-vulturecapitalists?
1542 2013-03-10 20:51:19 <xjrn> missing the mark on entropy based fees leaves the door open to pitch venture capitalists on a system that can be fixed cheaply and adopted easily
1543 2013-03-10 20:51:49 <distortednet> Hey guys, ive been mulling over an idea to make buying bitcoin easier. my only problem would be keeping the bitcoin wallet funded enough to provide a constant, quick service. With the mtgox api, would it be possible to insta fund my mtgox account, buy the required btc, then xfer it out into a wallet?
1544 2013-03-10 20:52:25 <distortednet> or, would it be a better idea to just keep a wallet saturated with bitcoin, and once it reaches a threshold just prevent orders from being made until im able to add more bitcoins to it
1545 2013-03-10 20:52:41 <warren> Luke-Jr: that's actually an improvement
1546 2013-03-10 20:53:18 <HM> distortednet: the latter sounds easier to implement and less dependant
1547 2013-03-10 20:53:19 <Luke-Jr> distortednet: #mtgox maybe
1548 2013-03-10 20:53:47 <distortednet> yeah i think i might go the latter, it might be a bit more inconvient for customers but at least that way i could guarentee transactions
1549 2013-03-10 20:53:51 <Luke-Jr> warren: I presume it's why nobody's bothered to point out how ridiculous his current idea is
1550 2013-03-10 20:54:34 <Luke-Jr> distortednet: eh, more likely to get a transaction via MtGox :p
1551 2013-03-10 20:55:54 <distortednet> haha, i will ask in #mtgox and see if they have any answers, if not i will consider doing the wallet threshold thing. thanks good sir, mam, or unknown species
1552 2013-03-10 20:56:16 Ken` has joined
1553 2013-03-10 20:57:33 * HM wonders why he's getting a 40% performance hit using libevent with 1 thread over vanilla sockets
1554 2013-03-10 20:57:53 axhlf has joined
1555 2013-03-10 20:58:11 <xjrn> hm: pastebin ?
1556 2013-03-10 20:58:54 rbecker is now known as RBecker
1557 2013-03-10 20:59:16 Ken`_ has quit (Ping timeout: 240 seconds)
1558 2013-03-10 21:01:34 <HM> no need
1559 2013-03-10 21:01:42 idstam has quit ()
1560 2013-03-10 21:02:28 <etotheipi_> sipa: what is the last checkpoint in 0.8?
1561 2013-03-10 21:02:34 <gmaxwell> xjrn: "from what i read of early bitcoin concepts," I have no clue what you're talking about. The initial bitcoin publications are available to everyone, http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source there is no need to wave arms. Provide links.
1562 2013-03-10 21:03:18 <sipa> etotheipi_: 216116 iirc
1563 2013-03-10 21:03:22 <gmaxwell> xjrn: you don't need to make every transaction _in_ bitcoin to provide a highly transparent ledger, and in fact puting that data in bitcoin degrades transparency because you're so constrained on how much data you can provide and how quickly you can provide it.
1564 2013-03-10 21:03:47 <gmaxwell> xjrn: moreover, what you are saying is in clear opposition with section 10 of bitcoin.pdf.
1565 2013-03-10 21:04:30 <etotheipi_> sipa: thanks
1566 2013-03-10 21:04:40 <HM> a 16 thread test probably wasn't a good idea on a dual core machine
1567 2013-03-10 21:04:42 <etotheipi_> that explains the dramatic slow-down for the very end
1568 2013-03-10 21:04:52 <gmaxwell> xjrn: and, finally, bitcoin _has_ entropy based feesâ because bytes == entropy when almost all your data is highly entropic digital signatures.
1569 2013-03-10 21:06:12 mappum has joined
1570 2013-03-10 21:06:21 coolsa has joined
1571 2013-03-10 21:07:26 welovecp has quit (Ping timeout: 260 seconds)
1572 2013-03-10 21:14:23 <HM> anyone know a bash one liner to spawn 50 processes of something in the background?
1573 2013-03-10 21:15:27 <sipa> for A in $(seq 1 50); do something & done
1574 2013-03-10 21:16:07 <HM> yeah i tried {1..50} and only got 3
1575 2013-03-10 21:17:09 <HM> also had ; before 'done'
1576 2013-03-10 21:17:11 <HM> thanks sipa
1577 2013-03-10 21:18:05 <warren> http://microcash.org I have no idea what it is, and judging from the site they don't know either, but it seems exciting at least.
1578 2013-03-10 21:18:39 <sipa> isn't that the latest generation of solidcoin?
1579 2013-03-10 21:19:58 <warren> I have no idea what solidcoin is. I was just referring to the rocket animation.
1580 2013-03-10 21:20:05 zooko has quit (Read error: Connection reset by peer)
1581 2013-03-10 21:20:07 <sipa> haha
1582 2013-03-10 21:20:30 <Wayward> gmaxwell: Interesting effect in increasing my wallet's keypool last night...
1583 2013-03-10 21:20:37 zooko has joined
1584 2013-03-10 21:21:08 <phantomcircuit> http://forums.microcash.org/index.php/topic/584-discussion-future-solidcoin-ideas/
1585 2013-03-10 21:21:13 <phantomcircuit> im goign with yes
1586 2013-03-10 21:21:57 <Wayward> gmaxwell: When the keypool was 100, my wallet was 100K. Changed to 10,000 keys, the wallet only became 5,000K but not 10,000K
1587 2013-03-10 21:21:58 <warren> phantomcircuit: *visionary*
1588 2013-03-10 21:22:50 <gmaxwell> Wayward: sure? This isn't surprising. There keys are quite small.
1589 2013-03-10 21:23:01 welovecp has joined
1590 2013-03-10 21:23:20 <Wayward> I would have expected a 1:1 ratio, though, unless there's 50K of overhead in the wallet file.
1591 2013-03-10 21:23:55 brwyatt is now known as brwyatt|Away
1592 2013-03-10 21:24:13 random_cat has quit (Remote host closed the connection)
1593 2013-03-10 21:24:28 <gmaxwell> Wayward: the wallet stores many things other than keys.. it stores your transactions (which are bigger than the keys) and it has indexes and other overheads (block alignment, free space, etc).
1594 2013-03-10 21:24:33 <Wayward> Or does the client max out at a hart limit of 5,000 keys?
1595 2013-03-10 21:24:50 <Wayward> It's a brand new wallet.
1596 2013-03-10 21:25:13 holorga has quit (Remote host closed the connection)
1597 2013-03-10 21:25:35 <gmaxwell> Wayward: how many keys does it tell you are int the keypool. Run getinfo.
1598 2013-03-10 21:25:50 <sipa> Wayward: it's a database files; its size is quite unpredictable unless you understand bdb's internals, i guess
1599 2013-03-10 21:25:51 GMP has quit (Remote host closed the connection)
1600 2013-03-10 21:26:10 <Wayward> hmm, "keypoolsize" : 10001,
1601 2013-03-10 21:26:14 <Wayward> I guess it's Ok then.
1602 2013-03-10 21:26:22 <sipa> if you ask for 10000 keys, it will have 10000 keys
1603 2013-03-10 21:26:32 <Wayward> sipa: unless there's a hard upper bounds, of course.
1604 2013-03-10 21:26:39 defunctzombie is now known as defunctzombie_zz
1605 2013-03-10 21:26:41 <sipa> i'm sure there are people running with 100000 as well
1606 2013-03-10 21:26:42 holorga has joined
1607 2013-03-10 21:26:52 <gmaxwell> with no overheads (e.g. assuming 32+32 bytes) the keys would be 640,000 bytes for 10000 keys
1608 2013-03-10 21:26:59 <gmaxwell> I have tested 100000
1609 2013-03-10 21:27:04 <Wayward> ok.
1610 2013-03-10 21:27:59 <gmaxwell> (not extensively but at least basically)
1611 2013-03-10 21:28:02 <Wayward> So now I can make an offsite copy of the wallet... and starting bitcoin with no keypool= option, it should revert to the default 100 so no new keys are ever created and added to the pool?
1612 2013-03-10 21:28:03 <sipa> gmaxwell: unencrypted keys are stored as address -> openssl_eckey, which is around 34 + 279 bytes
1613 2013-03-10 21:28:10 <Luke-Jr> "judging from the site they don't know either" <-- lol
1614 2013-03-10 21:28:16 <xjrn> gmaxwell: "almost all your data is highly entropic digital signatures." doesn't add up for me. i think the majority of signatures are re-used
1615 2013-03-10 21:29:00 <xjrn> ^wallets, sorry. i understand signatures are highly entropic, and most are unique
1616 2013-03-10 21:29:21 <sipa> gmaxwell: actually, it's from serialized pubkey -> serialized secret key, so 33 + 279 bytes + overhead
1617 2013-03-10 21:29:29 <Luke-Jr> warren: we should make bets on how long until he ignores people
1618 2013-03-10 21:29:53 tg has joined
1619 2013-03-10 21:30:22 <warren> Luke-Jr: exciting.
1620 2013-03-10 21:30:52 Goonie has quit (Ping timeout: 248 seconds)
1621 2013-03-10 21:31:03 moreati has joined
1622 2013-03-10 21:31:19 <warren> Luke-Jr: ooh... I hear microcash needs a theoretical entropic mathematician who doesn't code.
1623 2013-03-10 21:32:01 PlantMan has joined
1624 2013-03-10 21:32:11 <Luke-Jr> warren: did you read up on the completely unbreakable encryption algorithm?
1625 2013-03-10 21:32:17 fpgaminer has joined
1626 2013-03-10 21:32:17 <xjrn> gmaxwell: tx are relaying info about UTXO, but using an impedence layer that re-states and reifies the UTXO features naively
1627 2013-03-10 21:32:24 <Luke-Jr> warren: they avoided the risk of exploits by simply not using any math
1628 2013-03-10 21:32:42 <sipa> "all network rules decided by a fair dice roll"
1629 2013-03-10 21:32:53 <warren> Luke-Jr: If nobody uses it, you can't exploit it.
1630 2013-03-10 21:32:57 <Luke-Jr> warren: :D
1631 2013-03-10 21:33:32 <Prattler> ok.. My network storage cost calculation was bashed by a person who thinks 1000 network full nodes is enough. I guess there's nothing too wrong with the calculations then :)
1632 2013-03-10 21:33:57 <petertodd> Prattler: As I said, the cost calculations depend hugely on the number of nodes, and that spans orders of magnitude.
1633 2013-03-10 21:34:15 <Prattler> but surely >10000
1634 2013-03-10 21:34:17 <warren> Prattler: perhaps assume a rate of growth of nodes over time
1635 2013-03-10 21:34:19 <Prattler> probably >100000
1636 2013-03-10 21:34:20 PlantMan has quit (Remote host closed the connection)
1637 2013-03-10 21:34:45 <gmaxwell> Luke-Jr: lol. Math is elitist.
1638 2013-03-10 21:35:09 <warren> Prattler: Harder to measure costs are "average users who want to run the full client but give up because it uses too much resources."
1639 2013-03-10 21:35:19 <Prattler> 1000 nodes would not even survive a terrorist attack, FFS
1640 2013-03-10 21:35:20 Ken` has quit (Quit: leaving)
1641 2013-03-10 21:35:40 vampireb has joined
1642 2013-03-10 21:35:52 <moreati> As an exercise I'm hacking on https://github.com/moreati/pybrainwallet including filtering by candidate public address(es). Profiling shows 50% of CPU time is spent on base58 encoding generated addresses.
1643 2013-03-10 21:37:31 <Prattler> warren, agreed. Would be nice if the system could aim for <$20,000 full node cost. But that's impossible to estimate, because the costs increase with blockchain bloat and decrease with technology :(
1644 2013-03-10 21:38:00 <xjrn> gmaxwell: section 10 is a statement of reccomendation, a sales bullet point. it is pure arm-waving to say that scripts are not frequently repeated
1645 2013-03-10 21:38:50 <Prattler> the cost per 1 UTXO output is pretty clear though. It's >$0.08 for 100,000 nodes today.
1646 2013-03-10 21:39:14 ThomasV has quit (Ping timeout: 276 seconds)
1647 2013-03-10 21:39:17 <gmaxwell> xjrn: it is how the system acheives privacy. Which is a major criteria for a finance transaction system. You don't get to go claiming the system is built around no privacy when there is a nice section on how to achieve it, reference software which does as described, and you have a lack of citations supporting your position.
1648 2013-03-10 21:39:24 tg has quit (Ping timeout: 264 seconds)
1649 2013-03-10 21:39:25 <gmaxwell> xjrn: but have fun. cheers.
1650 2013-03-10 21:39:41 <warren> Prattler: even harder to measure is the cost of discouraging new users because fees are higher and the full client uses too much resources. That calculation isn't really about "hardware is cheap and always getting cheaper".
1651 2013-03-10 21:39:51 <xjrn> if section 10 is what "secure" requires, it has a high entropy cost like everything about security. if novel transaction systems are taken at face value the value of section 10 is a speed bump with wide margins to skirt
1652 2013-03-10 21:40:06 <petertodd> warren: Yes, but off-chain transactions can help solve both.
1653 2013-03-10 21:40:15 <Prattler> warren, oh yeah, that's massive opportunity cost for bitcoin. That goes on top of hardware costs.
1654 2013-03-10 21:40:31 <warren> petertodd: no disputing that.
1655 2013-03-10 21:40:36 licnep has quit (Ping timeout: 272 seconds)
1656 2013-03-10 21:40:36 <petertodd> Bitcoin infrastructure is probably mostly funded by visions of future growth right now.
1657 2013-03-10 21:40:39 <Prattler> warren, if full node were too expensive to run in year 2010, you wouldn't be here :)
1658 2013-03-10 21:40:52 <warren> Prattler: exactly
1659 2013-03-10 21:41:06 <petertodd> Yeah, it's good that I can run three full nodes just in my apartment without thinking about it.
1660 2013-03-10 21:41:06 <warren> "expensive to run" for an average user
1661 2013-03-10 21:41:57 <petertodd> In some respects, Bitcoin already is expensive to run for the average user.
1662 2013-03-10 21:41:59 <Prattler> yeah, bitcoin is not a ponzi in the financial sense, but the infrastructure is certainly funded by future hopes.
1663 2013-03-10 21:42:31 <xjrn> gmaxwell: I've never stated anything about privacy in here to date, but i can look at blockchain and clearly see section 10 is the road less traveled
1664 2013-03-10 21:42:36 <petertodd> Based on order numbers, BFL labs seems to have sold maybe $30 million worth of hardware for instance; I could be quite off though.
1665 2013-03-10 21:43:22 <Prattler> ok, I'm out. Gavin wanted a number, glad my numbers agreed with someone else in the forum thread. Thanks all for help!
1666 2013-03-10 21:44:05 <gmaxwell> xjrn: Citation needed.
1667 2013-03-10 21:44:21 <warren> petertodd: I was going to order Avalon batch #3 as it at least has a chance of mining before the majority of BFL goes online, but then I read from ckolivas that Avalon work return latency is at least 1.4 seconds. Then I gave up, as the global hashrate will be too high by the time I get a newly ordered BFL.
1668 2013-03-10 21:45:00 GMP has joined
1669 2013-03-10 21:45:27 <xjrn> gmaxwell: I cite any dart thrown at blockchain.info listings will land on a tx that has some repeat addresses
1670 2013-03-10 21:46:34 <xjrn> you wrote the vanity address post. i cite your own vanity address write-up as the mechanism by which the majority, not the exception conduct thier affairs.
1671 2013-03-10 21:46:41 <petertodd> warren: I actually just ordered some BFL equipment last week. I did the math and figured that I was convinced they'd really ship, and my return in the long run would still be positive.
1672 2013-03-10 21:47:03 <petertodd> I also ordered ASIC gear the moment they announced it, but just $150 worth. :P
1673 2013-03-10 21:47:49 <sipa> i wonder whether i'll have my BFL order within 12 months of ordering it :p
1674 2013-03-10 21:48:36 <petertodd> sipa: same...
1675 2013-03-10 21:48:54 <HM> have BFL shipped anything yet?
1676 2013-03-10 21:49:01 <petertodd> Yes
1677 2013-03-10 21:49:04 <petertodd> Just not ASICS
1678 2013-03-10 21:49:13 <HM> bumper stickers?
1679 2013-03-10 21:49:26 <sipa> i'm at 259 days since orde
1680 2013-03-10 21:49:29 <petertodd> fpgas
1681 2013-03-10 21:51:02 ThomasV has joined
1682 2013-03-10 21:51:17 <xjrn> gmaxwell: I'm indifferent to the frequency of section 10 adherence either way. i'm looking at the mechanics, apparently UTXO is a rolling cache inferred from what's unspent, and "cache of what's unspent" is far cheaper to implement as a shared simulation than as a fully denoarmalized restatement of scripts
1683 2013-03-10 21:51:48 bitafterbit_ has joined
1684 2013-03-10 21:52:19 bitafterbit has quit (Ping timeout: 260 seconds)
1685 2013-03-10 21:52:52 grau has quit (Remote host closed the connection)
1686 2013-03-10 21:53:18 <Luke-Jr> sipa: BFL wasn't taking orders for ASICs this time a year ago :/
1687 2013-03-10 21:53:27 <Luke-Jr> oh, wait, stupid year length..
1688 2013-03-10 21:53:35 <Luke-Jr> why isn't it 256 <.<
1689 2013-03-10 21:53:59 <petertodd> Luke-Jr: wow
1690 2013-03-10 21:54:01 PhantomSpark has joined
1691 2013-03-10 21:54:14 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Read error: Connection reset by peer)
1692 2013-03-10 21:54:17 <sipa> Luke-Jr: because the factor between a rotation of the earth around its axis over a rotation around the sun is no nice power of 2 ;)
1693 2013-03-10 21:54:21 gritcoin has quit (Quit: gritcoin)
1694 2013-03-10 21:54:34 <sipa> (or power of 10, for that matter)
1695 2013-03-10 21:54:37 <Luke-Jr> the one thing tonal can't fix
1696 2013-03-10 21:54:44 <Luke-Jr> sigh
1697 2013-03-10 21:54:50 <sipa> there is an easy solution
1698 2013-03-10 21:55:09 <sipa> use two independent time systems: one day-based, one year-based
1699 2013-03-10 21:55:18 <sipa> we already do so for weekdays anyway
1700 2013-03-10 21:55:19 tg has joined
1701 2013-03-10 21:56:48 <petertodd> Luke-Jr: why can't tonal fix that? tonal just needs to build some rocket engines...
1702 2013-03-10 21:57:23 <sipa> petertodd: like the ones on microcrash.org?
1703 2013-03-10 21:57:27 <sipa> eh, microcash.org
1704 2013-03-10 21:57:38 <Luke-Jr> petertodd: and totally screw up the universe's orbit?
1705 2013-03-10 21:57:51 <sipa> what's the worst that could happen?
1706 2013-03-10 21:58:13 <Luke-Jr> the sun collides with us?
1707 2013-03-10 21:58:14 <petertodd> sipa: yes
1708 2013-03-10 21:58:42 <Luke-Jr> sipa: we should get theymos to put the rocket on bitcointroll.org
1709 2013-03-10 21:58:57 <petertodd> Well, what if we first use the sun to brute force a SHA256 PoW, so it's out of hydrogen and won't cause any problems?
1710 2013-03-10 21:59:56 <petertodd> sipa: wait, microcash isn't a joke? WTF...
1711 2013-03-10 22:00:19 <moreati> petertodd: it would still have the mass of that hydrogen (as e.g. iron) and you'd still pulverise the earth due to strong gravity once you got close enough to the sun
1712 2013-03-10 22:00:39 MobiusL has quit (Remote host closed the connection)
1713 2013-03-10 22:00:45 <Luke-Jr> petertodd: it's like the first scamcoin
1714 2013-03-10 22:01:17 <warren> petertodd: i find it interesting that BFL jacked up their shipping costs by hundreds of dollars, then announces their BFL colo service
1715 2013-03-10 22:01:28 <petertodd> moreati: Nah, you'd be right so long as you're careful to keep the orbital parameters sane.
1716 2013-03-10 22:01:34 <petertodd> warren: link?
1717 2013-03-10 22:01:57 MobiusL has joined
1718 2013-03-10 22:02:57 i2pRelay has quit (Remote host closed the connection)
1719 2013-03-10 22:03:06 <warren> petertodd: https://forums.butterflylabs.com/pre-sales-questions/1147-shipping-costs-something-wrong.html first this, ok, $149 in US for Express. https://forums.butterflylabs.com/showwiki.php?title=FAQ:MiniRig+SC+and+Single+SC+Hosting then this appeared.
1720 2013-03-10 22:03:39 i2pRelay has joined
1721 2013-03-10 22:04:00 bitafterbit_ has quit (Ping timeout: 264 seconds)
1722 2013-03-10 22:04:03 <moreati> petertodd: Ah guess we talking about different scenarios. I was referring to fusing all the sun's hydrogen, before crashing the earth into it. You seem to be referring to altering the earth's rotation period, without altering the orbit
1723 2013-03-10 22:04:04 <petertodd> warren: Hmm... just garden variety padding I think.
1724 2013-03-10 22:04:08 <warren> petertodd: their Single hosting cost is roughly double what it would cost me here in electricity alone, which may seem good, but it mines completely under their control on their pool, presumably with additional pool fees.
1725 2013-03-10 22:04:35 <sipa> anyone complaining about told to take their OT stuff elsewhere: now is your chance!
1726 2013-03-10 22:04:36 tg has quit (Ping timeout: 264 seconds)
1727 2013-03-10 22:04:37 xjrn has quit (Read error: No route to host)
1728 2013-03-10 22:04:41 <petertodd> moreati: Yeah, because if we're going to orbit the earth fast enough for 256 day years, without changing the length of the day, we need to be a lot closer to the sun.
1729 2013-03-10 22:05:01 <Vinnie_win> did I wander into #astrophysics ?
1730 2013-03-10 22:05:26 <petertodd> warren: See, the nasty thing they could do is push for local operation really hard, and have it turn out to be an attack...
1731 2013-03-10 22:05:27 <moreati> oh I misunderstood. /relurk
1732 2013-03-10 22:05:39 <warren> petertodd: no kidding
1733 2013-03-10 22:06:28 <warren> petertodd: that's the real risk with special purpose hardware vs. general purpose hardware that people will own for other purposes.
1734 2013-03-10 22:06:31 <petertodd> warren: It's the sort of thing I could see a friendly government asking them to do... For all the talk about keeping the node count high, the dependency on specialized mining hardware is ugly. On the other hand, not having that dependency is ugly too for a orthogonal set of reasons.
1735 2013-03-10 22:07:24 bitafterbit has joined
1736 2013-03-10 22:07:47 <warren> You know what they say about mining profitability ... you're better off selling the shovels? In this case, they sell the shovels, but make it unattractive for you to take delivery of the shovel, then offer to run the shovel for you while collecting perpetual fees from you.
1737 2013-03-10 22:07:52 <warren> As a business, it's quite clever.
1738 2013-03-10 22:08:25 <petertodd> For sure
1739 2013-03-10 22:09:02 <petertodd> The one good thing, is that within ASICs the performance differences are only maybe two orders of magnitude at most between the most and least accessible fab plants.
1740 2013-03-10 22:09:07 <i2pRelay> <K1773R@i2p> KillYourTV, whats special on your irc net?
1741 2013-03-10 22:09:25 <K1773R> oh, relay working again, sry about that ;)
1742 2013-03-10 22:09:28 <petertodd> I suspect in the future people will be able to make slower, but still decent, ASIC hardware as a grey/black market thing.
1743 2013-03-10 22:10:06 <warren> petertodd: we currently see that with ARM devices, but is that because the core designs are everywhere?
1744 2013-03-10 22:10:15 <warren> petertodd: these asic designers might not have leaked nearly as far
1745 2013-03-10 22:10:33 xjrn has joined
1746 2013-03-10 22:10:40 sgornick has quit (Ping timeout: 248 seconds)
1747 2013-03-10 22:10:40 <petertodd> SHA256 hashing is such a simple task that damn near any semi-talented team can do it.
1748 2013-03-10 22:11:27 <petertodd> In fact, it's such a simple task that you'll even see stuff like SHA256 hashers getting hidden on other chips at companies with really poor design controls, and similarly engineers sticking them on test wafer runs, again at companies with poor design controls.
1749 2013-03-10 22:11:45 <petertodd> (assuming the legit hardware becomes restricted of course)
1750 2013-03-10 22:11:52 sgornick has joined
1751 2013-03-10 22:11:52 <warren> so after this initial gold rush we'll see tons of mass produced knock-off shovels that aren't as good, but much cheaper
1752 2013-03-10 22:12:11 <petertodd> warren: Only if the good stuff becomes illegal to get.
1753 2013-03-10 22:12:33 <petertodd> warren: The weird thing about chip manufacturing is there is no such thing as not as good but much cheaper the way you're thinking.
1754 2013-03-10 22:12:50 welovecp has quit (Ping timeout: 260 seconds)
1755 2013-03-10 22:13:17 <warren> ok
1756 2013-03-10 22:13:53 <warren> petertodd: did hte math again... even if hashrates are far far worse than I previously calculated, the run-up in BTC price made it worth it again....
1757 2013-03-10 22:14:00 <warren> crazy times
1758 2013-03-10 22:14:23 <petertodd> warren: My BFL single has been getting me roughly $100/month since I got it nearly a year ago...
1759 2013-03-10 22:14:35 <Luke-Jr> [22:11:14] <petertodd> In fact, it's such a simple task that you'll even see stuff like SHA256 hashers getting hidden on other chips at companies with really poor design controls, and similarly engineers sticking them on test wafer runs, again at companies with poor design controls. <-- you mean like http://bitcointroll.org/index.php?topic=146371.0 ?
1760 2013-03-10 22:15:17 <petertodd> Luke-Jr: Exactly! Now don't get me wrong, that one could be a scam too, but it's a clever scam because the idea is quite reasonable...
1761 2013-03-10 22:15:44 bitafterbit has quit (Read error: Connection reset by peer)
1762 2013-03-10 22:16:50 <petertodd> Luke-Jr: Specifically, they're "clever idea" about the ARM core seems like a waste to me - I can't see that much CPU power being useful enough to sacrifice on hashing power. On the other hand, if it's real, maybe that's how they got the hashing units past the design review.
1763 2013-03-10 22:17:09 forrestv has quit (Changing host)
1764 2013-03-10 22:17:09 forrestv has joined
1765 2013-03-10 22:18:40 <Luke-Jr> petertodd: VIA's CPUs have SHA256 instructions :P
1766 2013-03-10 22:19:09 Lowflow has quit (Remote host closed the connection)
1767 2013-03-10 22:20:26 <petertodd> Luke-Jr: The new rick-roll of the fab world is going to be sneaking in SHA256 PoW modules into designs...
1768 2013-03-10 22:20:54 <warren> https://bitcointalk.org/index.php?topic=149085.20 This is curious... avalon batch #1 still hasn't shipped to most people?!
1769 2013-03-10 22:21:14 CaptainBlaze has quit (Quit: CaptainBlaze)
1770 2013-03-10 22:22:58 nologo has joined
1771 2013-03-10 22:23:00 <petertodd> warren: Customs officials are bad people, incapable of love.
1772 2013-03-10 22:24:30 <sipa> warren: they probably just produced a few units, enough to show off and make hesitant people make an order :p
1773 2013-03-10 22:25:42 <petertodd> sipa: It's not totally far-fetched... Avalon's rely on a rather large number of relatively slow chips, so it's possible they really did only have enough dies available for a few units.
1774 2013-03-10 22:25:55 nologo has quit (Client Quit)
1775 2013-03-10 22:26:20 <sipa> just to be clear: i assume this is not the case
1776 2013-03-10 22:26:21 <petertodd> sipa: Especially if they had a yield problem; 95% reject rates are not unheard of in IC mfg.
1777 2013-03-10 22:26:25 <sipa> but it could be :)
1778 2013-03-10 22:26:25 nologo has joined
1779 2013-03-10 22:26:30 <petertodd> sipa: Yup
1780 2013-03-10 22:26:59 <etotheipi_> is there a reason the OSX package for Bitcoin-Qt doesn't come with bitcoind?
1781 2013-03-10 22:27:51 <sipa> etotheipi_: because gavin is lazy :)
1782 2013-03-10 22:28:28 <etotheipi_> can I request that it be done in the future?
1783 2013-03-10 22:28:39 <etotheipi_> it's really complicating my Armory upgrades, and I don't see why it's not done
1784 2013-03-10 22:28:53 <lianj> -server arg?
1785 2013-03-10 22:29:43 <Luke-Jr> etotheipi_: you could try building my gitian stuff.. not sure it works with 0.8 tho
1786 2013-03-10 22:29:55 <etotheipi_> Luke-Jr: I'm not distributing Bitcoin-Qt/bitcoind myself
1787 2013-03-10 22:30:06 <etotheipi_> I'm asking users to download and install "Bitcoin software"
1788 2013-03-10 22:30:14 <etotheipi_> which includes bitcoind on Windows and Linux
1789 2013-03-10 22:30:21 <Luke-Jr> but Armory *is* Bitcoin software!
1790 2013-03-10 22:30:38 <etotheipi_> "bitcoin software from www.bitcoin.org"
1791 2013-03-10 22:30:52 <lianj> doesnt -server work anymore?
1792 2013-03-10 22:30:55 <sipa> still true... armory is referenced
1793 2013-03-10 22:31:03 <Luke-Jr> etotheipi_: Armory is on bitcoin.org! :D
1794 2013-03-10 22:31:03 <etotheipi_> lol
1795 2013-03-10 22:31:17 <Luke-Jr> etotheipi_: "bitcoind" :P
1796 2013-03-10 22:31:23 <sipa> lianj: sure does
1797 2013-03-10 22:31:39 <Luke-Jr> etotheipi_: back when I worked on Spesmilo, we just bundled bitcoind with the Windows version :P
1798 2013-03-10 22:31:52 <etotheipi_> Luke-Jr: I don't want to bundle it
1799 2013-03-10 22:31:55 <lianj> sipa: so whats the problem.
1800 2013-03-10 22:32:14 <etotheipi_> Luke-Jr: I don't want to be responsible for emergency Armory upgrades just to accommodate a bitcoind upgrade
1801 2013-03-10 22:32:15 nologo is now known as ismist
1802 2013-03-10 22:32:24 <sipa> lianj: i don't think armorybusers like the bitcoin-qt gui to be present all the time
1803 2013-03-10 22:32:50 <lianj> oh, does -server still popup the gui?
1804 2013-03-10 22:32:59 <sipa> yes
1805 2013-03-10 22:33:02 D34TH has quit (Quit: Leaving)
1806 2013-03-10 22:33:09 <sipa> of course
1807 2013-03-10 22:33:19 <sipa> if you don't want the gui, use bitcoind
1808 2013-03-10 22:33:23 <lianj> ok, makes sense then. never ran bitcoin-qt so didnt know. thought -server == bitcoind
1809 2013-03-10 22:33:43 <etotheipi_> it can't be that much more work to put bitcoind in there.... is it?
1810 2013-03-10 22:34:15 <sipa> etotheipi_: i wouldn't think so, but i never did any OSX stuff so i wouldn't know
1811 2013-03-10 22:34:28 <sipa> and gavin already complains about how much work a release is
1812 2013-03-10 22:34:40 <etotheipi_> sipa: unfortunately, I don't know much about OSX, either...
1813 2013-03-10 22:37:27 one_zero has joined
1814 2013-03-10 22:41:01 tg has joined
1815 2013-03-10 22:44:30 ismist has left ()
1816 2013-03-10 22:45:04 grau has joined
1817 2013-03-10 22:45:25 Z0rZ0rZ0r has quit (Quit: Wheeeee)
1818 2013-03-10 22:47:06 ThomasV has quit (Ping timeout: 248 seconds)
1819 2013-03-10 22:48:27 clarkm is now known as clark_
1820 2013-03-10 22:48:45 skeledrew1 has quit (Ping timeout: 248 seconds)
1821 2013-03-10 22:48:48 clark_ is now known as clarkm_
1822 2013-03-10 22:49:58 tsche has quit (Ping timeout: 248 seconds)
1823 2013-03-10 22:50:28 cypher has joined
1824 2013-03-10 22:51:11 skeledrew has joined
1825 2013-03-10 22:51:12 technotarian has quit (Ping timeout: 248 seconds)
1826 2013-03-10 22:51:16 coolsa_ has joined
1827 2013-03-10 22:51:19 RainbowDashh has joined
1828 2013-03-10 22:52:19 JDuke128 has joined
1829 2013-03-10 22:52:29 Mrcheesenips has quit (Ping timeout: 248 seconds)
1830 2013-03-10 22:53:01 cheesepi has quit (Ping timeout: 248 seconds)
1831 2013-03-10 22:53:26 clarkm_ is now known as clarkm
1832 2013-03-10 22:53:39 <HM> libevent seems to fair queue connections
1833 2013-03-10 22:53:55 coolsa has quit (Ping timeout: 255 seconds)
1834 2013-03-10 22:54:57 tsche has joined
1835 2013-03-10 22:55:20 Mrcheesenips has joined
1836 2013-03-10 22:55:20 Mrcheesenips has quit (Changing host)
1837 2013-03-10 22:55:20 Mrcheesenips has joined
1838 2013-03-10 22:55:30 mcx has joined
1839 2013-03-10 22:55:30 mcx is now known as cheesepi
1840 2013-03-10 22:55:49 <phantomcircuit> sipa, you remember the script i sent you to keep track of available peers?
1841 2013-03-10 22:55:58 <phantomcircuit> i accidentally ran that from my home connection
1842 2013-03-10 22:56:09 <phantomcircuit> router rebooted
1843 2013-03-10 22:56:11 <phantomcircuit> hehe
1844 2013-03-10 22:57:52 skeledrew has quit (Ping timeout: 248 seconds)
1845 2013-03-10 22:59:45 <sipa> phantomcircuit: lol
1846 2013-03-10 23:00:22 <phantomcircuit> turns out an e3000 cannot handle 3000 connections in 2 minutes
1847 2013-03-10 23:00:26 <phantomcircuit> who would have thought
1848 2013-03-10 23:00:40 rlifchitz has quit (Quit: "I never worry about action, but only about inaction" (W. Churchill))
1849 2013-03-10 23:00:47 skeledrew has joined
1850 2013-03-10 23:01:19 rlifchitz has joined
1851 2013-03-10 23:01:49 Unknown43131 has joined
1852 2013-03-10 23:01:53 toffoo has joined
1853 2013-03-10 23:02:12 ovidiusoft has quit (Read error: Operation timed out)
1854 2013-03-10 23:04:34 <HM> phantomcircuit: sounds like a cool script
1855 2013-03-10 23:05:03 <dinox> When dealing with scripts, am I correct if I think a transaction is valid if input ++ output evaluates to true? (++ means script concentration)
1856 2013-03-10 23:05:04 Goonie has joined
1857 2013-03-10 23:05:17 <sipa> dinox: that used to be true until somewhere in 2010
1858 2013-03-10 23:05:35 <dinox> hmm
1859 2013-03-10 23:06:06 <dinox> what has changed then?
1860 2013-03-10 23:06:07 <sipa> dinox: now you evaluate input, and then evaluate output with initial stack the resulting stack of the input evaluation
1861 2013-03-10 23:06:09 random_cat has joined
1862 2013-03-10 23:06:17 <dinox> ah
1863 2013-03-10 23:06:35 <dinox> that makes sense
1864 2013-03-10 23:06:37 <sipa> dinox: someone figured out that putting OP_TRUE OP_RETURN in the input scripts was a pretty smart way of stealing everyone's cins
1865 2013-03-10 23:06:57 <phantomcircuit> sipa, hehe
1866 2013-03-10 23:07:00 <sipa> (OP_RETURN got changed to cause immediately failure)
1867 2013-03-10 23:07:00 <dinox> hehe
1868 2013-03-10 23:10:00 <muhoo> sipa: what i meant was, i was told that reusing addresses was Bad(tm) because it exposes the pubkeys, and that allows an attack against them
1869 2013-03-10 23:10:11 <gmaxwell> muhoo: thats a really fringe concern.
1870 2013-03-10 23:10:11 <muhoo> did i completely misread whatever it was that i read?
1871 2013-03-10 23:10:29 <sipa> muhoo: reusing addresses is bad, but not for that reason
1872 2013-03-10 23:10:38 <muhoo> ok, why then is reusing addresses bad?
1873 2013-03-10 23:10:47 <sipa> privacy
1874 2013-03-10 23:10:53 <phantomcircuit> well
1875 2013-03-10 23:10:57 <muhoo> oh, but if you don't care about privacy in a particular application?
1876 2013-03-10 23:11:01 <phantomcircuit> it does expose the public key
1877 2013-03-10 23:11:04 <sipa> muhoo: not yours; everyone's
1878 2013-03-10 23:11:06 <phantomcircuit> but that really shouldn't matter
1879 2013-03-10 23:11:30 <gmaxwell> Reusing is bad because the privacy of the system for all users, including things like blocking resistance, is predicated on avoiding it. On the crypto thing avoiding reuse is only a minor improvement against purely theoretical weakness. (attacks on ECDSA)
1880 2013-03-10 23:11:50 <muhoo> OIC, so it means someone can know that they got money from you or gave money to you, which, you might not care about, but they might.
1881 2013-03-10 23:11:54 <xjrn> that ship has sailed
1882 2013-03-10 23:11:57 <gmaxwell> Bingo.
1883 2013-03-10 23:12:40 RBecker is now known as rbecker
1884 2013-03-10 23:12:46 <gmaxwell> muhoo: so thats why all the client software does stuff like sends change to new addresses, and why transactions don't have from but most things distinguish senders via distinct tos.
1885 2013-03-10 23:12:56 moarrr has quit ()
1886 2013-03-10 23:12:57 BCBot has joined
1887 2013-03-10 23:13:08 BCBot` has quit (Ping timeout: 245 seconds)
1888 2013-03-10 23:13:20 <muhoo> yes, i already had an "i can see your underwear" moment, with someone who paid me some coins, reused the same address for a bunch of stuff, and i can see how much money he has.
1889 2013-03-10 23:13:39 <gmaxwell> another security point is that it's just good keymanagement to avoid long term keys.
1890 2013-03-10 23:13:56 <muhoo> true, it's like rekeying an ssh or ssl session, sort of.
1891 2013-03-10 23:13:58 <Luke-Jr> muhoo: AFAIK only Lamport (and similar) can be attacked by knowing the pubkey. Bitcoin doesn't use this today.
1892 2013-03-10 23:14:19 D34TH has joined
1893 2013-03-10 23:14:20 D34TH has quit (Changing host)
1894 2013-03-10 23:14:20 D34TH has joined
1895 2013-03-10 23:14:23 <muhoo> ok, thanks, i think i have a better handle on it now.
1896 2013-03-10 23:14:34 <HM> Luke-Jr: define 'attacked'
1897 2013-03-10 23:14:38 <gmaxwell> I suppose thats another point: iff we do ever need to switch to another cryptosystem it may be less tolerate of key reuse.
1898 2013-03-10 23:14:51 <Luke-Jr> HM: that's not my area of expertise
1899 2013-03-10 23:15:53 cheesepi has quit (Ping timeout: 264 seconds)
1900 2013-03-10 23:15:54 <muhoo> i think where i got that misconception from, was here, just FYI http://blog.oleganza.com/post/42523601710/how-to-steal-all-coins
1901 2013-03-10 23:16:36 <gmaxwell> HM: as soon as you sign something twice with lamport you leak 1/hash_bits of your private key for each bit of the message hashes that differ.
1902 2013-03-10 23:16:50 <gmaxwell> muhoo: the title of that page should have warned you. :P
1903 2013-03-10 23:16:57 <gmaxwell> HM: (for lamport)
1904 2013-03-10 23:17:33 <HM> afaik there are basically 2 ways to steal coins: 1) crack ECDSA, or 2) somehow preimage ripemd160
1905 2013-03-10 23:17:50 <phantomcircuit> huh i had actually never given that much thought
1906 2013-03-10 23:17:52 <gmaxwell> HM: preimage ripemd160 isn't enough.
1907 2013-03-10 23:18:03 <dinox> sipa: Thanks btw! =)
1908 2013-03-10 23:18:22 <HM> well ripemd160(sha256())
1909 2013-03-10 23:18:35 <HM> hmm
1910 2013-03-10 23:18:57 <sipa> HM: it's not 1 or 2; it's 1 AND 2
1911 2013-03-10 23:19:06 <HM> yeah you're right, even if you produce a pubkey that preimages both those hash functions you need the privkey
1912 2013-03-10 23:19:07 <sipa> except in the case where the pubkey is known, there 1 suffices
1913 2013-03-10 23:19:20 <gmaxwell> If you can get a very specific second preimage of ripemd160+sha256 you can replace a p2sh script, otherwise you'd need a second preimage of ripemd160+sha256 that you have the ecckey for 0_o or you need to get a specific second preimage on sha256() to rebind a ECDSA signature.
1914 2013-03-10 23:19:28 mcx has joined
1915 2013-03-10 23:19:28 mcx is now known as cheesepi
1916 2013-03-10 23:19:42 <Scrat> 3) infiltrate the devs and introduce a very subtle backdoor
1917 2013-03-10 23:19:43 <gmaxwell> sorry, sha256^2()
1918 2013-03-10 23:19:46 <phantomcircuit> gmaxwell, in other words, lol yeah right
1919 2013-03-10 23:20:08 <HM> i think the best attack vector right now is probably assuming some of those signatures are using dodgy RNGs
1920 2013-03-10 23:20:16 <phantomcircuit> Scrat, there's enough people that actually review commits that you'd have a very hard time doing that
1921 2013-03-10 23:20:24 <Scrat> then someone will record your exploit and make your coinz worthless
1922 2013-03-10 23:20:40 <HM> there was a news story last year about phones producting bad random numbers
1923 2013-03-10 23:20:52 <HM> which you wouldn't expect because they have access to so much entropy
1924 2013-03-10 23:21:11 <phantomcircuit> HM, actually they dont really
1925 2013-03-10 23:21:41 <HM> gyro, microphone, cell signals, wifi, ?
1926 2013-03-10 23:21:42 <phantomcircuit> the radio runs it's own micro os and would need to explicitly provide the primary os with entropy
1927 2013-03-10 23:21:58 <doublec> HM: like http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
1928 2013-03-10 23:21:59 <HM> more than a pc
1929 2013-03-10 23:22:01 <Scrat> just the gyro would be pretty good entropy
1930 2013-03-10 23:22:15 <phantomcircuit> gyro takes power to do measurements
1931 2013-03-10 23:22:24 <Luke-Jr> boo hoo
1932 2013-03-10 23:22:25 <phantomcircuit> you wouldn't want to have it on all the time
1933 2013-03-10 23:22:32 <Luke-Jr> entropy isn't needed all the tim
1934 2013-03-10 23:22:43 <Scrat> you guys saw that unique identification based on gyro imperfections? bleh where did I read that
1935 2013-03-10 23:22:51 <phantomcircuit> you could write your own little program to collect entropy
1936 2013-03-10 23:23:54 <phantomcircuit> anyways
1937 2013-03-10 23:24:04 <phantomcircuit> there are a lot of good reasons not to re use addresses
1938 2013-03-10 23:24:09 <phantomcircuit> broken rng's is one of them
1939 2013-03-10 23:24:27 <HM> Ed25519 doesn't require randomness for signatures
1940 2013-03-10 23:24:36 <HM> according to the homepage
1941 2013-03-10 23:24:47 <HM> which is weird, because it thought it was a variant of Schnorr's
1942 2013-03-10 23:25:08 <dinox> I'm trying to figure out a way to send transactions that is spendable according to a target. That would be interesting in applications where number of transactions is extremely high and there is a desire to keep fees down
1943 2013-03-10 23:25:14 <phantomcircuit> im highly skeptical of that claim even though ed25519 has been well reviewed...
1944 2013-03-10 23:25:29 <dinox> This output script would probably do it
1945 2013-03-10 23:25:31 <dinox> OP_2DUP OP_SWAP <target> OP_LESSTHAN OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
1946 2013-03-10 23:25:56 <phantomcircuit> i was doing some crypto in javascript and just gave up
1947 2013-03-10 23:26:18 <dinox> with usual inputs, but what to do when sig does not match target? That would waste the coins with that script...
1948 2013-03-10 23:26:18 <HM> where did i see that post
1949 2013-03-10 23:26:35 <phantomcircuit> bitcoinjs-lib has a different byte encoding than sjcl which is different from crypto-ks
1950 2013-03-10 23:26:37 <phantomcircuit> js
1951 2013-03-10 23:27:23 <HM> https://groups.google.com/forum/#!msg/sci.crypt/J_7OGDf9cJE/-ePpoKkmw_UJ
1952 2013-03-10 23:27:41 <HM> Dan Bernstein talking about a Schnorr variant on Curve25519
1953 2013-03-10 23:27:50 <HM> I presumed this was a precursor or something to Ed25519
1954 2013-03-10 23:29:46 <HM> I'm going to have to read that paper sometime
1955 2013-03-10 23:30:34 <HM> Presumably the signature construction is slightly different
1956 2013-03-10 23:32:42 axhlf has quit (Ping timeout: 264 seconds)
1957 2013-03-10 23:33:28 rbecker is now known as RBecker
1958 2013-03-10 23:34:26 <muhoo> that paper is fascinating. what PRNG was generating the same number twice?
1959 2013-03-10 23:34:43 <muhoo> s/paper/blog post/
1960 2013-03-10 23:34:44 <Luke-Jr> int random() { return 4; /* dice roll */ }
1961 2013-03-10 23:34:49 <gmaxwell> the constant '0' PRNG.
1962 2013-03-10 23:37:04 <Diablo-D3> I thought it was 3?
1963 2013-03-10 23:37:17 <muhoo> but which client did that?
1964 2013-03-10 23:37:39 <sipa> Diablo-D3: nope, 4
1965 2013-03-10 23:37:42 <muhoo> or was it the system that was broken
1966 2013-03-10 23:38:02 <Diablo-D3> fucking sony
1967 2013-03-10 23:38:18 licnep has joined
1968 2013-03-10 23:38:23 <muhoo> oic, it was a hardware wallet
1969 2013-03-10 23:40:49 <phantomcircuit> muhoo, i believe it was the bitcoin card
1970 2013-03-10 23:40:58 <phantomcircuit> in which case a shitty rng actually makes sense
1971 2013-03-10 23:43:17 G________ has joined
1972 2013-03-10 23:43:22 <grazs> are there any upcoming features that will allow me to use QR codes to transport transactions from paper_wallet->cellphone->online_computer? like, you construct the transaction on the offline phone and transfer it via camera to the online computer?
1973 2013-03-10 23:43:24 <Luke-Jr> phantomcircuit: pfft, no. any kind of hardware wallet should obviously include a true RNG
1974 2013-03-10 23:43:47 <Luke-Jr> or very good PRNG if it doesn't make its own keys
1975 2013-03-10 23:43:48 <grazs> the phone itself read the privkey
1976 2013-03-10 23:44:06 vampireb has quit (Quit: Lost terminal)
1977 2013-03-10 23:44:11 <Luke-Jr> grazs: you need to construct it online
1978 2013-03-10 23:44:16 <Luke-Jr> grazs: signing can be offline
1979 2013-03-10 23:44:49 <phantomcircuit> Luke-Jr, it's based around a javacard iirc
1980 2013-03-10 23:44:59 <phantomcircuit> in which case it definitely should have an rng
1981 2013-03-10 23:45:01 <phantomcircuit> but they never do
1982 2013-03-10 23:45:09 <grazs> Luke-Jr: thanks, is this available today for Android phones?
1983 2013-03-10 23:45:20 <Luke-Jr> grazs: no idea
1984 2013-03-10 23:45:23 hackjealousy has quit (Quit: leaving)
1985 2013-03-10 23:45:35 <sipa> Luke-Jr: why would the transaction construction need to be online?
1986 2013-03-10 23:45:36 <Luke-Jr> but it'd need a total of 3 qr code transfers
1987 2013-03-10 23:45:42 <phantomcircuit> i was actually going to write a small signing program for a javacard but the lack of an rng in the commercially available ones pushed me away
1988 2013-03-10 23:45:46 <Luke-Jr> sipa: so you have a UTXO set to work with
1989 2013-03-10 23:45:56 <sipa> Luke-Jr: so, you need the wallet, yes
1990 2013-03-10 23:46:06 <Luke-Jr> sipa: the UTXO set
1991 2013-03-10 23:46:14 <sipa> ?
1992 2013-03-10 23:46:18 <Luke-Jr> the wallet only contains the keys, if offline
1993 2013-03-10 23:46:23 <sipa> huh
1994 2013-03-10 23:46:34 <sipa> ok, you have a different definition of wallet than i have :)
1995 2013-03-10 23:46:35 <Luke-Jr> sipa: you need to know what outputs are available to spend
1996 2013-03-10 23:46:49 <sipa> yes, of course
1997 2013-03-10 23:46:54 <HM> Ed25519 does appear to be Schnorr, except instead of random values it uses a hash function
1998 2013-03-10 23:46:55 <sipa> but you have those in your wallet
1999 2013-03-10 23:46:58 <Luke-Jr> sipa: explain how an offline wallet could have any info on outputs ;)
2000 2013-03-10 23:47:14 <Luke-Jr> not to mention, he said paper :P
2001 2013-03-10 23:47:25 <sipa> hmm, ok, true
2002 2013-03-10 23:47:29 <Luke-Jr> so really, he probably has 4 qr codes to use
2003 2013-03-10 23:47:54 <sipa> well you'd need to know about some incoming transactions at least, but in case of some long-term cold storage, that could just be part of the paper backet itself
2004 2013-03-10 23:48:09 <sipa> i.e. have it store a key + a funding txout
2005 2013-03-10 23:48:44 <muhoo> so that's kind of neat. the private key never needs to leave the offline thing. only the tx needs to come in, and a signed tx needs to come out, right?
2006 2013-03-10 23:48:48 <Luke-Jr> 0) paper displays private key (read by phone), 1) phone displays scriptPubKey to scan for (scanned by PC); 2) PC displays UTXOs to use (read by phone); 3) phone displays signed transaction
2007 2013-03-10 23:48:57 g2x3k has quit (Ping timeout: 245 seconds)
2008 2013-03-10 23:51:07 <muhoo> i've been deciding how to split up the work for this ecommerce thing between the webserver and the offsite machine that'll have the keys. generating the tx's on the server and then sending them offsite for signing seems like an attractive approach.
2009 2013-03-10 23:51:24 <muhoo> i'm sure i'm missing something important though.
2010 2013-03-10 23:52:02 <HM> yes you are
2011 2013-03-10 23:52:18 <HM> someone hacks your webserver and sends your offsite server arbitrary transactions
2012 2013-03-10 23:53:09 <muhoo> my offsite server may be doing reality checks though.
2013 2013-03-10 23:53:18 <muhoo> it'll have to be, actually.
2014 2013-03-10 23:53:50 <HM> you should aim for a dumb web server process
2015 2013-03-10 23:54:01 axhlf has joined
2016 2013-03-10 23:54:04 <muhoo> good point. and run the business logic offsite.
2017 2013-03-10 23:54:19 <HM> i dunno, it's tough
2018 2013-03-10 23:54:21 <muhoo> master => offsite. slave => webserver.
2019 2013-03-10 23:54:29 <HM> designing these things right is no easy matter
2020 2013-03-10 23:54:37 <muhoo> it's an interesting problem. been having fun with it.
2021 2013-03-10 23:54:47 G________ has quit (Quit: Textual IRC Client: www.textualapp.com)
2022 2013-03-10 23:54:51 hsmiths has quit (Read error: Connection reset by peer)
2023 2013-03-10 23:54:51 <grazs> I'm researching this as well
2024 2013-03-10 23:54:52 <muhoo> not getting a lot accomplished, but having fun anyway.
2025 2013-03-10 23:55:18 <grazs> safe offline storage without too many computers
2026 2013-03-10 23:55:25 puhc_ has joined
2027 2013-03-10 23:55:31 <HM> yeah i've put a lot of thought in to trying to secure web bitcoin services such that the web service itself has minimal trust
2028 2013-03-10 23:55:37 <muhoo> grazs: it seems like you, weex, me, and gary rowe, are all working on ecommerce stuff. weex actually has something in production already.
2029 2013-03-10 23:55:53 puhc has quit (Read error: Connection reset by peer)
2030 2013-03-10 23:55:54 <HM> at the end of the day though, if someone gets write access to your database you're boned unless everything is digitally signed by your users
2031 2013-03-10 23:56:05 <grazs> muhoo: I'm actually just working on storage of my private stash and a trading bot
2032 2013-03-10 23:56:20 <muhoo> grazs: cool.
2033 2013-03-10 23:56:39 <grazs> or, my friend is doing most of the heavy lifting. I'm helping him with algorithms
2034 2013-03-10 23:56:46 bock has quit (Quit: Verlassend)
2035 2013-03-10 23:56:52 <muhoo> heh, to me, algorithms are the heavy lifting.
2036 2013-03-10 23:57:03 <grazs> well, not really in this case
2037 2013-03-10 23:57:21 hsmiths has joined
2038 2013-03-10 23:57:24 <muhoo> i'm a sysop, basically, not a developer, no CS degree, no maths background. system stuff is easy, algorithms are hard.
2039 2013-03-10 23:57:26 <grazs> we're using genetic algorithms and artificial neural networks
2040 2013-03-10 23:57:56 <sipa> grazs: and DHT's, i hope?
2041 2013-03-10 23:58:36 <grazs> sipa: no, I'm not sure about that. havent come across it in our code
2042 2013-03-10 23:58:44 <Scrat> muhoo: how about this: you pregenerate a ton of addresses on a secure system, then you load them to the "dumb" system which only has to monitor incoming transactions
2043 2013-03-10 23:58:55 <HM> as long as there are some goto's and comefrom's in there i'm happy
2044 2013-03-10 23:59:07 <sipa> comefrom's?
2045 2013-03-10 23:59:12 <muhoo> Scrat: at some point, those coins need to be transferred, which means spent, which means tx's generated and signed with a private key.
2046 2013-03-10 23:59:28 <HM> sipa: https://en.wikipedia.org/wiki/COMEFROM
2047 2013-03-10 23:59:30 <muhoo> deciding what to spend and where is based on the database, which HM succicntly put, if an attacker gets the db, i'm boned
2048 2013-03-10 23:59:46 toffoo has quit ()
2049 2013-03-10 23:59:57 g2x3k has joined
2050 2013-03-10 23:59:57 g2x3k has quit (Changing host)
2051 2013-03-10 23:59:57 g2x3k has joined
2052 2013-03-10 23:59:58 g2x3k has quit (Excess Flood)