From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UcbJk-0003VM-TO for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 13:00:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.42 as permitted sender) client-ip=74.125.83.42; envelope-from=adam.back@gmail.com; helo=mail-ee0-f42.google.com; Received: from mail-ee0-f42.google.com ([74.125.83.42]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UcbJi-0002nG-QW for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 13:00:28 +0000 Received: by mail-ee0-f42.google.com with SMTP id c50so1076091eek.29 for ; Wed, 15 May 2013 06:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-hashcash:x-hashcash:x-hashcash; bh=IeyTqKIFOa5nfikDM08gHsUu9UJhtA1dr9uw3mRr0lI=; b=gbVDipYP7p01I6XuXPThsEmitAgTm+A2TjP4II3vqlSJlk2tUe4Yn/eLyhjPf5WpZ/ Pdl/+c+duIAb+kuKcK/93HU9oy1YbDpahwQNLi7Eu5ytKNb8HCziK+PYhTvRUrpfvQXM POhvbt6ZDawMom+xx6Xhfw1XmMC/H5tKONMpHeHMg6OtzpffCvYTBRd5++NbCPJKZlDK ZuU+A3dU5OnRKMlgZFTnhx2lghPAF3OJd4Orw4+65RrhesmxGgkNMKfBDdXyizL8Sp/i gXx6XVvcxZuKYWm5z4tV0JvKmyt6bNkyplHUQ+DqELnoGuU0muqoEOqFjh6ZsBuUOSPf c9qw== X-Received: by 10.14.108.1 with SMTP id p1mr103655989eeg.31.1368622820432; Wed, 15 May 2013 06:00:20 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id x41sm3761264eey.17.2013.05.15.06.00.18 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 06:00:19 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id F40742E04CB; Wed, 15 May 2013 15:00:16 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Wed, 15 May 2013 15:00:14 +0200 Date: Wed, 15 May 2013 15:00:14 +0200 From: Adam Back To: Peter Todd Message-ID: <20130515130014.GA6156@netbook.cypherspace.org> References: <20130515113827.GB26020@savin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20130515113827.GB26020@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130515:pete@petertodd.org::x630ksJtZ75DLA+f:0000000000000000000 00000000000000000000000057+U X-Hashcash: 1:20:130515:bitcoin-development@lists.sourceforge.net::CujD/9/6CC5L2 l1L:000000000000000000004CzW X-Hashcash: 1:20:130515:adam@cypherspace.org::kr6NZxZ39Js4rgm5:00000000000000000 0000000000000000000000007C1R X-Spam-Score: -1.5 (-) 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 (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UcbJi-0002nG-QW Cc: Bitcoin-Dev Subject: [Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy) 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: Wed, 15 May 2013 13:00:29 -0000 On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: >no-one seems to think much about how in practice very few vendors have a >setup to detect if conflicting transactions were broadcast on the network >simultaneously - after all if that is the case which transaction gets mined >is up to chance, so much of the time you'll get away with a double spend. >We don't yet have a mechanism to propagate double-spend warnings, and funny >enough, in the case of a single txin transaction the double-spend warning >is also enough information to allow miners to implement replace-by-fee. About double-spends it might be better if the double-spend results in no-one keeping the money ie it gets deleted by definition (except for the fees, or the whole payment gets converted into a 0BTC output so 100% fees). Ideally you'd want a way for known double spends to be circulated at priority in the p2p network, even routed directly to earlier recipients if known. However have to watch out for even the fees being double spent in other transactions. Maybe the fees could be demanded to be self-created (no trusted green-coin issuer) 6-confirmation spend-to-miner green-coins. (Note double spends are not-binary. An attacker can spend a 25BTC coin via 50x 1BTC transactions. Which 25 are valid? Currently it is the first 25 from the network perspective of the miner that succeeds on the current block. (And that view overrides, even if other miners had differing views, unless the block later becomes an orphan). Its surely easy for a double spender to accumulate fast connections to known powerful miners to get the spends that benefit him to them first.) In that way (with double-spend deletes) the would be double-spender can not gain within the bitcoin protocol by double spending. He can gain outside of the protocol eg by persuading merchants to give him non-revocable resellable non-physical goods (or physical but anonymous goods). But that is harder work, and people selling goods with no recourse will be defensive about confirmations. ps I still dont think replace-by-fee is a good idea, at least the way it was implemented with changeable outputs, but I think that discussion seemed closed, so I wont rehash it. Adam