--- Log opened Mon Mar 18 00:00:30 2013
06:00 < warren> sipa: missing 'obj' directory from your secp256k1 git
06:00 < sipa> mkdir obj
06:01 < warren> I know
06:01 < sipa> ok, thanks, i'll fix it
11:00 <@gmaxwell> sipa: using openssl for the bignums is 21% slower than GMP on your code. Crazy.
11:01 < sipa> gmaxwell: yes; gmp does a modular inversion in <3us; openssl takes 26us
11:01 < sipa> given that the entire verification takes 150us, that is significant...
21:15 < warren> you folks going to the bitcoin conference?
21:28 < jgarzik> da
21:30 < sipa> i'm sure gmaxwell and jgarzik are going
21:35 <@gmaxwell> sipa: I think it would be productive for you to come. Considering some of the stresses lately spending some time in person would probably be helpful.
21:37 < sipa> yeah i'd certainly like to meet gavin and you in person once
21:38 < jgarzik> beer.  There should be beer.
21:39 < sipa> well, jgarzik too of course, but i met him already :)
22:41 < sipa> gmaxwell: i wonder, with the PoW-that-proves-fast-UTXO-access
22:41 < sipa> seems that means you also needs the UTXO set to validate PoW
22:41 < sipa> which would mostly kill SPV usage?
22:44 <@gmaxwell> sipa: if you look how I stated the construction I 'solved' that.
22:45 <@gmaxwell> basically you stick an extra H() on top of whatever comes out of the UTXO lookup.
22:45 <@gmaxwell> so that when you send a block you also send the result of H()... so you can do a context free check.
22:45 < sipa> right
22:45 <@gmaxwell> Also, if the lookup is really a UTXO fragment from a committed UTXO structure, you send the fragment.
22:46 <@gmaxwell> e.g. H(header) tells you a path you walk through the utxo tree... and you just send that walk. the hash of the walk is hashed with the header.
22:47 < sipa> i'll have a look at this, at a non-4am point in tim
22:54 <@gmaxwell> like any of this NP pow stuff, the searcher is O(N) and the client is O(1).  Now perhaps you could cheat the pow by just picking a few random paths through the utxo that you happen to know then searching through nonces that happen to pick those paths.
22:55 <@gmaxwell> This can be avoided by requiring sufficiently long paths, but that makes the workload high on the validatees.
23:32 < warren> coblee seems confused about the 0.8.1 hardfork reason.  I'm trying to explain it to him.  Let me clarify one detail... If 0.8 didn't exist, 0.7.x is still vulnerable to a certain depth of reorg failure due to the BDB limit?
23:33 < warren> If miners increased the block size limit (which is "legal" under the 0.7.x protocol), and sufficiently large blocks are adjacent to each other, it could cause a reorg failure and fork between clients of the same 0.7.x with BDB limit?
23:35 <@gmaxwell> warren: correct. <0.8 is not self-consistent.
23:35 < warren> gmaxwell: thank you.
23:35 <@gmaxwell> though it's not clear that any amount of lock tuning can completely resolve the issue, at least according to luke's reports today. Though it can probably make it hard enough to trigger to not be a pratical issue for bitcoin.
23:36 < warren> what's the new limit?
23:38 < warren> I mean, the May 15th limit
23:38  * warren looks for it...
23:41 <@gmaxwell> warren: there is no limit after may 15th.
23:41 <@gmaxwell> just the regular limits we always though were there.
23:42 < warren> so technically, all bitcoin clones should hardfork for the same reason, as they are now attackable.
23:43 < warren> Probably not with the existing miners (not enough tx's for them to increase the block size limit), but their hash rate is so low, it wouldn't take much to attack the network with rogue miners.
23:44 <@gmaxwell> the blocksize target in older code was 500k. And technically crafted txn can trigger problems with 500k blocks. These txn would be non-standard in bitcoin, but not all alts have the same rules.
23:44 < warren> 0.6 had a soft limit of 500KB, but that was reduced in 0.7?
23:45 <@gmaxwell> correct, but it was also much harder to hit in 0.6... due to the fee ramping.. though LC's fees are all miscalibrated and have always been.
23:46 < warren> It would be expensive (in fees) to attack using the standard miners, but rogue miners could avoid enforcing the fees.  You just need a surge of enough miners and a temporary partition to destroy the chain consensus.
23:47 < warren> That's pretty hard to pull off.
23:47 <@gmaxwell> a rogue miner would just mine their own txn... and the soft limit wouldn't matter at all.
23:47 < warren> yeah
23:48 < warren> Just thinking how hard it would be to break litecoin now.
23:48 <@gmaxwell> well getting some nodes to accept it and some to choke is the hard part.
23:48 <@gmaxwell> you have to be right at the limit.
23:49 < warren> Is the standard way to partition by DoS attack?
23:49 <@gmaxwell> huh?
23:49 < warren> How you would isolate nodes
23:49 <@gmaxwell> you don't isolate nodes.
23:50 <@gmaxwell> oh I suppose you could use isolation to make the reorg version of the attack happen. but for that, you just do a race. You mine two blocks at the same height and announce at once.
23:51 <@gmaxwell> but I was thinking you'd break it with a _single block_ break.
23:51 < warren> "getting some nodes to accept it and some to choke"  oh... it's a random timing issue.  If some haven't received the main fork deep enough yet to fail the reorg, then they will disagree with the nodes that did fail the reorg.
23:51 < warren> Oh, single block? hmm
23:51 <@gmaxwell> warren: there are two main attack vectors here.
23:51 <@gmaxwell> One is that you mine a single block which is near the limit,— the 0.7 limit is fuzzy it depends on the internal state of bdb.
23:51 <@gmaxwell> so you can make a block which some nodes will accept some will reject.
23:52 <@gmaxwell> but getting that right is hard. Too big and almost all reject, too small and almost all accept.
23:52 <@gmaxwell> your goal is 50% of the hashpower on each fork.
23:52 <@gmaxwell> an 'easier' attack— targeting wise, is to mine two blocks and simultaniously announce, ... but thats harder mining wise.
23:53 <@gmaxwell> you can also attack newly bootstrapping nodes in a very effective way.
23:53 <@gmaxwell> and that doesn't even need high power mining.
23:53 < warren> just lucky timing
23:54 < warren> gmaxwell: aren't the newly bootstrapping nodes going to just be on their own fork without miners, thus impotent?
23:54 <@gmaxwell> yea, just catch nodes when they're new, feed them the real chain up to some height, then a set of choke blocks... and they will later hear the whole real chain but can't reorg off it.
23:54 <@gmaxwell> warren: _you_ can be their miner. :P
23:54 <@gmaxwell> mining away at minimum difficult.y
23:54 <@gmaxwell> giving them confirmations that are totally bogus.
23:55 < warren> they'll see the pre-fork difficulty though.  It's hard to mine as fast as the entire main network.
23:55 <@gmaxwell> warren: does anything actually display the difficulty in a place a user would notice it?
23:56 < warren> no, but they might notice the confirmations coming slowly
23:56 <@gmaxwell> warren: .. uh. you only have to mine at minimum difficulty.
23:56 <@gmaxwell> because you fork off the network at a point where its still at or near minimum difficulty.
23:57 < warren> ok, that doesn't describe some of the alt chains now.
23:57 <@gmaxwell> I suppose what will actually save them is the "you're on a shorter fork" warning.
23:57 <@gmaxwell> warren: what do you mean "that doesn't describe some of the alt chains now"?
23:57 < warren> "because you fork off the network at a point where its still at or near minimum difficulty."
23:57 <@gmaxwell> ...
23:57 <@gmaxwell> warren: the attacker choses the point in the networks history that he creates a fork from.
23:58 < warren> OH
23:58 < warren> ok
23:58 <@gmaxwell> he can choose to start his fork at block 1.
23:59 < warren> OK, so by observing main, you the only miner can make them think they are good until you defraud them.
--- Log closed Tue Mar 19 00:00:04 2013