On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > With multi-party transactions such as coinjoins and multi-party lightning
> > channels, we want full-rbf behavior because it avoids accidental
> > double-spends
> > holding up progress in these protocols.
> 
> what is meant by accidental double spends ? And do you have any data as to
> how often these occur and would cause harm?

A double-spend of an input to a multiparty transaction that isn't maximally
trying to exploit transaction pinning. For example, Wasabi has found many cases
of users imported the same seed into different wallets. This is quite hard to
avoid in decentralized wallets.

> Second, for intentional DoS attacks, it
> > makes those attacks much more expensive by forcing the attacker to use
> > tx-pinning.
> 
> how are these Dos attacks mitigated today if Full RBF is not in place ?

They aren't. During congested mempool conditions an attacker could cause
significant delays to multi-party transactions without full-rbf. Fortunately,
the mempool regularly empties right now. But that has not been true in the
past, we can not guarantee that, and for Bitcoin to remain secure without
inflation or demmurage in the future, we have to operate under full-mempools
with significant backlogs of transactions.

> > Thus we have a political tradeoff between a handful of centralized services
> > such as yours that benefit from the first-seen status quo, and the much
> > larger
> > group of users that use Lightning and coinjoins.
> 
> How many users are currently using Lightning and coinjoins today ?

Wallet of Satoshi, one of many Lightning wallets, claims to be performing
12,500 transactions/day: https://twitter.com/kerooke/status/1603812141966016520

Bitcoin as a whole currently does about 300,000 transactions per day(1). So that
one single Lightning wallet represents roughly 4% of the total payment volume
of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ downloads on
the Google Play store. So a reasonable guess is they're equally popular. Which
means they collectively represent 12% of the total number of transactions on
Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per
month(2), or about 10% of total transactions.


I don't have statistics for number of coinjoin transactions per day, or the
blockspace used. But Wasabi have published (reproducable) data showing that
currently about 750BTC/day are entering Wasabi 2.0 coinjoins:
https://mobile.twitter.com/wasabiwallet/status/1603366008437325828

You claimed GAP600 was responsible for USD $220 million of transaction
volume(2), significantly less than the ~$400 million / month that Wasabi
coinjoins alone represent. And of course, Wasabi is just one of three main
coinjoin implementations.

> > We've already been through
> > such a political tradeoff before with the blocksize debate - again, the
> > centralized payment providers lost the debate.
> 
> I don’t think this has anything to do with block size debate or
> decentralisation just looking to protect a significant use case that has
> been in place - GAP600 is by no means the only service provider is this
> place there are many merchants who do 0-conf on there own.

You claimed that GAP600 handled about 10% of all transactions. Obviously, if
that is true, that indicates a very high degree of centralization. It is
extremely undesirable for Bitcoin for one single entity with, as I understand
it, AML/KYC to handle 10% of all transactions. Probably an even higher
percentage when you take into account that only a minority of transactions are
merchant payment-type transactions where unconfirmed transactions would have
any relevance at all.

You claim that there are "many merchants" who do 0-conf on their own. Can you
list more examples of those merchants? Surely if there are "many" of them, you
could easily give us four or five more examples so this list can evaluate what
kinds of security guarantees they're actually relying on.

1) https://ycharts.com/indicators/bitcoin_transactions_per_day
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org