From: Daniel Lipshitz <daniel@gap600•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>,
John Carvalho <john@synonym•to>
Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
Date: Sun, 18 Dec 2022 10:06:15 +0200 [thread overview]
Message-ID: <CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com> (raw)
In-Reply-To: <Y5zfuVGpRGaknwaU@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 6345 bytes --]
GAP600 is not a trxs processor or liquidity provider we service merchants,
payment processors & non-custodial liquidity providers - our service is
purely the 0-conf enabling our clients to accept 0-conf. Clients access our
service via API - sending us the Trx hash & output address. Our service is
not based on AML/KYC it is purely an analysis of the Bitcoin network.
I am not at liberty to share names of other services which have developed
their own 0-conf service - they include a payment processor on a gambling
platform which services multiple gambling operators, a standalone gaming
payment processor, and a payment processor recently I have come across. We
also do not have a significant presence in Asia - so I don't have
visibility there.
I see from the Wallet of Satoshis website that they are a custodial wallet
provider.
I don't see it being necessarily an either/or approach here. The risk
looking to be mitigated with FullRBF seems to be able to be mitigated with
FullRBF but with a swop limitation of at least the Inputs of Trx1 being in
Trx2 - no flagging required. Added to this all these trxs always have the
OptinRBF so if these platforms need to be able to recreate completely their
trxs they have that option as well. The option to Swop out or bump up trxs
seems to be well covered under those two options.
The case of creating multiple wallets with the same seeds seems to be an
edge case - and to do that and then recreate accidental double spends as a
result sounds like an extreme edge case which I would not think should be a
protocol consideration.
________________________________
Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz
On Fri, Dec 16, 2022 at 11:14 PM Peter Todd <pete@petertodd•org> wrote:
> 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
>
[-- Attachment #2: Type: text/html, Size: 8385 bytes --]
next prev parent reply other threads:[~2022-12-18 8:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 20:24 Daniel Lipshitz
2022-12-13 4:20 ` Yuval Kogman
2022-12-13 8:08 ` Daniel Lipshitz
2022-12-13 9:59 ` John Carvalho
2022-12-13 11:33 ` Daniel Lipshitz
2022-12-13 14:00 ` Lucas Ontivero
2022-12-13 14:08 ` Daniel Lipshitz
2022-12-13 21:41 ` Peter Todd
2022-12-13 21:58 ` Daniel Lipshitz
2022-12-16 21:14 ` Peter Todd
2022-12-18 8:06 ` Daniel Lipshitz [this message]
2023-01-13 23:53 ` Peter Todd
2023-01-14 20:15 ` Daniel Lipshitz
2023-01-16 10:19 ` Daniel Lipshitz
2023-01-17 17:07 ` Erik Aronesty
2023-01-17 17:27 ` Daniel Lipshitz
2023-02-04 16:27 ` Peter Todd
2023-02-06 12:08 ` Daniel Lipshitz
2022-12-14 8:12 ` Daniel Lipshitz
2022-12-14 17:41 ` Erik Aronesty
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='CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com' \
--to=daniel@gap600$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@synonym$(echo .)to \
--cc=pete@petertodd$(echo .)org \
/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