Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XavQ4-0008Hu-KD for bitcoin-development@lists.sourceforge.net; Sun, 05 Oct 2014 23:40:52 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.173 as permitted sender) client-ip=209.85.213.173; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f173.google.com; Received: from mail-ig0-f173.google.com ([209.85.213.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XavQ1-0002rQ-A0 for bitcoin-development@lists.sourceforge.net; Sun, 05 Oct 2014 23:40:52 +0000 Received: by mail-ig0-f173.google.com with SMTP id h18so1773062igc.0 for ; Sun, 05 Oct 2014 16:40:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.84.198 with SMTP id n6mr114334icl.73.1412552443934; Sun, 05 Oct 2014 16:40:43 -0700 (PDT) Received: by 10.107.168.5 with HTTP; Sun, 5 Oct 2014 16:40:43 -0700 (PDT) In-Reply-To: <5431CD8D.7050508@certimix.com> References: <5431CD8D.7050508@certimix.com> Date: Sun, 5 Oct 2014 16:40:43 -0700 Message-ID: From: Gregory Maxwell To: Sergio Lerner Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XavQ1-0002rQ-A0 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 23:40:52 -0000 On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner 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.