Comments between lines... On 06/10/2014 03:42 a.m., Alex Mizrahi wrote: > ..... > > This doesn't require protocol changes(*) and can be simply > incorporated into a piece of code which decides what to do when a > transaction with unusually large fee appears. (I.e. it will > automatically share the fee, and others will recognize that). And if > the biggest miner has 25% of all hashrate, sharing 25% of your loot > doesn't sound that bad. The problem with this approach is that once the bitcoind has been modified to allow this sharing of the high-tx fee by delegation, then the same system can be used for an attack. Let's call a system that makes the Optimum Rational Best-chain Selection for maximizing profit "ORBS", just to give it a name. The system assures that the best chain chosen is always the optimum in terms of profit, taking into account fee delegation and all the game-theoretic incentives derived. It's only a theoretical abstraction, but could be approximated in practice.
The attack is called Chained Kickback DOuble-spend attack (or “CHAKIDO”) and is an extension of Bonneau's kickback attack. Basically the attack is to create the ORBS patch, and start convincing miners to use it, sending some probe high-fees tx. Once you have ORBS working in a majority of the mining nodes, you can perform a double-spend against a target like an exchange by: - Buy some btc X - Send those btc to an exchange (suppose the exchange requires 6 confirmations) in a transaction TX - Immediately convert those btc to an alt-coin, and collect the alt-coins - Create a high fee tx that is a double-spend of TX having a high fee Y such that Y < X but Y triggers a ORBS reorganization. - Profit (This rollback attack was performed against whitecoin, I think) This attack gets terrible powerful if there is no subsidy. You may need 500 blocks of confirmation to protect from a 10 BTC spend with current fees and no subsidy. This is because once 100% of the nodes use ORBS, the fee delegation is linear (it doesn't grow exponentially with the number of blocks). So ORBS should never be implemented without additional protective measures in merchant applications. If we had a closed formula for ORBS, then all merchants could compute the minimum confirmation blocks such that always Y > X, but such formula involves many unknowns which would need to be dynamically estimated, and also it should take into account the number of simultaneous payment attempts. My conclusions are: - We should never allow ORBS to be implemented unless merchants are also aware of it. If are aware of ORBS then Bitcoin with no subsidy will be become a terrible slow payment system so ... - We could implement the protections that work even if some nodes implement ORBS, such as fee and burn btc sharing, as I described before - Or we need some high percentage of miners to be irrational, to force ORBS fee delegation have an exponential decay. Best regards, Sergio. ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
