Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tomh@thinlink.com>) id 1XjAji-0000cu-9l
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Oct 2014 17:39:14 +0000
X-ACL-Warn: 
Received: from mail-pa0-f50.google.com ([209.85.220.50])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XjAjh-0002Tc-4D
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Oct 2014 17:39:14 +0000
Received: by mail-pa0-f50.google.com with SMTP id eu11so1207499pac.37
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 28 Oct 2014 10:39:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=qZaYRUo8G+2yvbZPVDoh7+hEqpW+kjWVms9RwN0WQPM=;
	b=c90zFwsxqIuVbeSFivw5om9Ey8qw1gTp25efmLiAoHaFCX5Zd7oo/4B2MNJT2GFLMP
	9LxZUQjTzu1jLX0Wd910zJ63KMWJ7zjVN02VAcdS0QxOjg+/d6A8H/h9YoJKcGAtZCJa
	qMDSvXtKKJX8BxdPDcHBrxFS89mKUp/qFnG1+Ak4/YPN0nIHfo+hy94uKZFCG2Zb6Mry
	CZo0e7ooykWZYFAG+AIh5Xvi/4iwoNH9a6VD66YChjNQ6hjnTdiFVeCXX77s0SoBGNZ9
	WMqozb4HcYx3tIQgovTqcPT8P1DtzojxQpoaNo7rejgXMnmbJ99qlQ8mH1cQZBsymrrg
	jSdA==
X-Gm-Message-State: ALoCoQkDFydX8UtkcMGwffl/QCtACifaQ3ZAC+Z29WZBzKNP6jwyYClIz1wXTZr+SsCq89G7AN3D
X-Received: by 10.66.121.65 with SMTP id li1mr3245510pab.148.1414517947146;
	Tue, 28 Oct 2014 10:39:07 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
	by mx.google.com with ESMTPSA id ra4sm2217884pab.33.2014.10.28.10.39.05
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 28 Oct 2014 10:39:05 -0700 (PDT)
Message-ID: <544FD47F.6060900@thinlink.com>
Date: Tue, 28 Oct 2014 10:38:07 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <544EA3D7.2050901@thinlink.com>	<544EA85E.8010400@bluematt.me>	<544EFEE8.4000000@thinlink.com>
	<CAAS2fgTW9uWewWbdRj6SCCAKU0D30jFiukDL9YPeG4n8LVwoYg@mail.gmail.com>
In-Reply-To: <CAAS2fgTW9uWewWbdRj6SCCAKU0D30jFiukDL9YPeG4n8LVwoYg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
	[204.58.254.99 listed in dnsbl.sorbs.net]
X-Headers-End: 1XjAjh-0002Tc-4D
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] DS Deprecation Window
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 17:39:14 -0000

On 10/27/2014 7:36 PM, Gregory Maxwell wrote:
> Consider a malicious miner can concurrently flood all other miners
> with orthogonal double spends (which he doesn't mine himself). These
> other miners will all be spending some amount of their time mining on
> these transactions before realizing others consider them
> double-spends.

If I understand correctly, the simplest example of this attack is three 
transactions spending the same coin, distributed to two miners like this:

             Miner A    Miner B
Mempool       tx1a       tx1b
Relayed       tx2        tx2

Since relay has to be limited, Miner B doesn't know about tx1a until it 
is included in Miner A's block, so he delays that block (unless it 
appears very quickly).

To create this situation, attacker has to transmit all three 
transactions very quickly, or mempools will be too synchronized. 
Attacker tries to make it so that everyone else has a tx1a conflict that 
Miner A does not have.  Ditto for each individual victim, with different 
transactions (this seems very difficult).

Proposal shows that there is always a tiny risk to including tx1 when a 
double-spend is known, and I agree that this attack can add something to 
that risk.  Miner A can neutralize his risk by excluding any tx1 known 
to be double-spent, but as Thomas Zander wrote, that is an undesirable 
outcome.

However, Miner A has additional information - he knows how soon he 
received tx2 after receiving tx1a.

The attack has little chance of working if any of the malicious 
transactions are sent even, say, 10 seconds apart from each other. 
Dropping the labels for transmit-order numbering, if the 1->2 transmit 
gap is large, mempools will agree on 1.  If 1->2 gap is small, but the 
gap to 3 is large, mempools will agree on the 1-2 pair, but possibly 
have the order reversed.  Either way, mempools won't disagree on the 
existence of 1 unless the 1->3 gap is small.

So, I think it will be possible to quantify and target the risk of 
including tx1a to an arbitrarily low level, based on the local 
measurement of the time gap to tx2, and an effective threshold won't be 
very high.  It does highlight yet again, the shorter the time frame, the 
greater the risk.