From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WgmZW-0005Gn-Eo for bitcoin-development@lists.sourceforge.net; Sun, 04 May 2014 02:54:34 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.181 as permitted sender) client-ip=209.85.223.181; envelope-from=christophe.biocca@gmail.com; helo=mail-ie0-f181.google.com; Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WgmZU-0000hW-N6 for bitcoin-development@lists.sourceforge.net; Sun, 04 May 2014 02:54:34 +0000 Received: by mail-ie0-f181.google.com with SMTP id y20so6787130ier.12 for ; Sat, 03 May 2014 19:54:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr14698301igh.43.1399172066820; Sat, 03 May 2014 19:54:26 -0700 (PDT) Received: by 10.64.102.136 with HTTP; Sat, 3 May 2014 19:54:26 -0700 (PDT) In-Reply-To: <536589CC.8080005@thinlink.com> References: <536589CC.8080005@thinlink.com> Date: Sat, 3 May 2014 22:54:26 -0400 Message-ID: From: Christophe Biocca To: "bitcoin-development@lists.sourceforge.net" 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 (christophe.biocca[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: 1WgmZU-0000hW-N6 Subject: Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk 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, 04 May 2014 02:54:34 -0000 Unfortunately this could fork the network permanently, which is much worse than a double spend. There's no magic way to have a consensus, so it becomes trivial with a few tries to split the network into two halves: (tx1 before tx2, tx2 before tx1). Some nodes in the middle will accept either block, but you've still forked off some non-zero number of nodes. At a minimum, you'd need a way to reconcile the split (Accept the offending block once it's 2+ deep). The problem is that since the rule isn't enforceable, no miner will wait before mining on the longest chain (which is the rational move), and you're back to where we are now. On Sat, May 3, 2014 at 8:29 PM, Tom Harding wrote: > This idea was suggested by "Joe" on 2011-02-14 > https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It > deserves another look. > > Nodes today make a judgment regarding which of several conflicting > spends to accept, and which is a double-spend. But there is no > incorporation of these collective judgments into the blockchain. So > today, it's the wild west, right up until the next block. To address this: > > - Using its own clock, node associates a timestamp with every > transaction upon first seeing its tx hash (at inv, in a block, or when > created) > - Node relays respend attempts (subject to anti-DOS rules, see github > PR #3883) > - Eventually, node adds a consensus rule: > Do not accept blocks containing a transaction tx2 where > - tx2 respends an output spent by another locally accepted > transaction tx1, and > - timestamp(tx2) - timestamp(tx1) > T > > What is T? > > According to http://bitcoinstats.com/network/propagation/ recent tx > propagation has a median of 1.3 seconds. If double-spender introduces > both transactions from the same node, assuming propagation times > distributed exponentially with median 1.3 seconds, the above consensus > rule with reject threshold T = 7.4 seconds would result in > mis-identification of the second-spend by less than 1% of nodes.* > > If tx1 and tx2 are introduced in mutually time-distant parts of the > network, a population of nodes in between would be able to accept either > transaction, as they can today. But the attacker still has to introduce > them at close to the same time, or the majority of the network will > confirm the one introduced earlier. > > Merchant is watching also, and these dynamics mean he will not have to > watch for very long to gain confidence if he was going to get > double-spent, he would have learned it by now. The consensus rule also > makes mining a never-broadcast double-spend quite difficult, because the > network assigns it very late timestamps. Miner has to get lucky and > find the block very quickly. In other words, it converges to a Finney > attack. > > This would be the first consensus rule that anticipated less than 100% > agreement. But the parameters could be chosen so that it was still > extremely conservative. Joe also suggested a fail-safe condition: drop > this rule if block has 6 confirmations, to prevent a fork in unusual > network circumstances. > > We can't move toward this, or any, solution without more data. Today, > the network is not transparent to double-spend attempts, so we mostly > have to guess what the quantitative effects would be. The first step is > to share the data broadly by relaying first double-spend attempts as in > github PR #3883. > > > *Calcs: > For Exp(lambda), median ln(2)/lambda = 1.3 ==> lambda = .533 > Laplace(0,1/lambda) < .01 ==> T = 7.34 seconds > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development