MIME-Version: 1.0
Date: Fri, 28 Oct 2022 21:45:09 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Y1nIKjQC3DkiSGyw@erisian.com.au>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <194063b733e539e8e24cfd83fa879ed0@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list

On 2022-10-26 13:52, Anthony Towns via bitcoin-dev wrote:
> The cutoff for that is probably something like "do 30% of listening
> nodes have a compatible policy"? If they do, then you'll have about a
> 95% chance of having at least one of your outbound peers accept your 
> tx,
> just by random chance.

I think this might be understating the problem.  A 95% chance of having
an outbound peer accept your tx conversely implies 1 in 20 payments will 
fail to
propagate on their initial broadcast.  That seems to me like an
unacceptably high failure rate both for the UX of regular payments and
for the safety of time-sensitive transactions like onchain HTLC
resolutions.

Additionally, the less reliable propagation is, the more reliably spy
nodes can assume the first IP address they received a transaction from
is the creator of that transaction.

I think those two problems combine in an especially unfortunate way for
lightweight clients.  Lightweight clients wanting to find a peer who
supports a more permissive policy than most of the network and whose
client authors want to provide a good UX (or safety in the case of time
sensitive contract protocols like LN) will need to open large numbers of
connections, increasing their chance of connecting to a spy node which
will associate their IP address with their transaction, especially since
lightweight clients can't pretend to be relaying transactions for other
users.  Some napkin math: there are about 250,000 transactions a day; if
we round that up to 100 million a year and assume we only want one
transaction per year to fail to initially propagate on a network where
30% of nodes have adopted a more permissive policy, lightweight clients
will need to connect to over 50 randomly selected nodes.[1]  For a more
permissive policy only adopted by 10% of nodes, the lightweight client
needs to connect to almost 150 nodes.

This also implies that nodes adopting a more restrictive policy degrades
UX, safety, and privacy for users of transactions violating that policy.
For example, if 30% of nodes used Knots's -spkreuse configuration option
and about 50% of transactions reuse scriptPubKeys, then about 9
transactions a day wouldn't initially propagate (assuming 8 randomly
selected peers[2]) and lightweight clients who wanted 1-in-100-million
safety would need to connect to about 15 random nodes.

Towns's post to which I'm replying describes several alternative
approaches which mitigate the above problems, but he also documents that
they're not without tradeoffs.

-Dave

[1] (1-0.3)**50 * 100_000_000 =~ 1.8

[2] That assumes every transaction is sent to a different
randomly-selected set of peers, which isn't really the case.  However,
one day $GIANT_EXCHANGE could suddenly be unable to broadcast hundreds 
or
thousands of withdrawal transactions because all of its peers implement
a restrictive policy.