Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Sergej Kotliar <sergej@bitrefill.com>]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

This is factually incorrect and not required for us to do what we do.

On Fri, 21 Oct 2022 at 00:13, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > > If someone's going to systematically exploit your store via this
> > > > mechanism, it seems like they'd just find a single wallet with a good
> > > > UX for opt-in RBF and lowballing fees, and go to town -- not
> something
> > > > where opt-in rbf vs fullrbf policies make any difference at all?
> > > Sort of. But yes once this starts being abused systemically we will
> have to
> > > do something else w RBF payments, such as crediting the amount in BTC
> to a
> > > custodial account. But this option isn't available to your normal
> payment
> > > processor type business.
> >
> > So, what I'm hearing is:
> >
> >  * lightning works great, but is still pretty small
> >  * zeroconf works great for txs that opt-out of RBF
>
> It's important to note that the businesses that say "zeroconf works great"
> for
> them, appear to be achieving that by sybil attacking the network to measure
> propagation. That's not sustainable nor decentralized, as only a small
> number
> of companies can do that without causing a lot of harm to Bitcoin by using
> up
> inbound slots. We've gone through this before with "zeroconf guarantee"
> services, and the end result is not good.
>
> It's in our interests to make sure those companies stop doing that, and no
> new
> companies start.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

[-- Attachment #2: Type: text/html, Size: 6377 bytes --]