On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner <sergioler...@certimix.com> wrote: > I would like to share with you a vulnerability in the Bitcoin protocol I've > been thinking of which might have impact on the future of Bitcoin. Please > criticize it! > The Freeze on Transaction Problem
I should point you to some of the tools that have been discussed in the past which are potentially helpful here: The first is the use of locktime on normal transactions. This behavior is already in Bitcoin core git: The idea is that users of the system should locktime their transaction at a point as high as they expect it to get included. If used well this means that there should always be a base of fees which can only be collected by future blocks, creating an incentive to move forward. This may be particularly effective if the limitations on blocksize mean that there is always a healthy standing load. The second is having block commitments in transactions (https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that the data under signature in a transaction could commit to some recent block which _must_ be in the chain or the transaction's fee cannot be collected (or, at least, not all of the fee). This would allow transacting users to 'vote with their fees' on the honest chain. Arguably this could also be used to pay for doublespending forks, but you can already do that by paying fees via a chain that stems from the doublespend. This greatly complicates strategy for forking miners, since future transactions which you haven't even seen yet may have fees conditional on the honest chain. I think both of the above are obviously useful, should be done, but don't completely address the concern, they may be adequate. The third is fee forwarding. An example form would be that the miner gets half the fees, the rest are added to a pool which pays out half in every successive block. This can prevent unusually high fees from making as much reorg pressure and more correctly models what people would like to pay for: getting their txn buried. The huge problem with this class is that miners can demand users pay fees "out of band", e.g. with additional txouts (just make a different version of the tx for each miner you wish to pay) and escape the process. I have had some notions about fees that come in the form of adjusting the difficulty of creating a block slightly (which is something that can't be paid out of band), but such schemes becomes very complicated very fast. I am unsure if any form of fee forwarding is workable. Something you might want to try to formalize in your analysis is the proportion of the network which is "rational" vs "honest"/"altruistic". Intuitively, if there is a significant amount of honest hashrate which is refusing to aid the greedy behavior even at a potential loss to themselves this strategy becomes a loser even for the purely greedy participants. It would be interesting to characterize the income tradeoffs for different amounts of altruism, or whatever convergence problems an attempt by altruistic participaints to punish the forkers might create. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
