From: Tom Harding <tomh@thinlink•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] DS Deprecation Window
Date: Tue, 28 Oct 2014 10:38:07 -0700 [thread overview]
Message-ID: <544FD47F.6060900@thinlink.com> (raw)
In-Reply-To: <CAAS2fgTW9uWewWbdRj6SCCAKU0D30jFiukDL9YPeG4n8LVwoYg@mail.gmail.com>
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.
next prev parent reply other threads:[~2014-10-28 17:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 19:58 Tom Harding
2014-10-27 20:17 ` Matt Corallo
2014-10-28 2:26 ` Tom Harding
2014-10-28 2:36 ` Gregory Maxwell
2014-10-28 17:38 ` Tom Harding [this message]
2014-11-06 23:50 ` Tom Harding
2014-10-28 6:24 ` Thomas Zander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544FD47F.6060900@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox