Daniel Lipshitz [ARCHIVE] on Nostr: š Original date posted:2022-12-13 š Original message:On Tue, 13 Dec 2022 at ...
š
Original date posted:2022-12-13
š Original message:On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete at petertodd.org> wrote:
> On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> > I dont think there was anything technical with the implementation and as
> > far as I can tell this is well developed and ready.
>
> There are lots of problems with my first-seen-safe proposal. The only
> reason I
> proposed it in 2015 was as a political compromise.
>
> > The reasons I can find for not being adopted are listed here -
> > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not
> First-seen-safe
> > Replace-by-fee
> >
> > Those reasons do not seem pertinent here - given OptinRBF already exists
> > as an option and the added benefit of continuing to be able to support
> > 0-conf.
>
> First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
> merged into Bitcoin Core: multi-party transactions.
>
> 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?
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 ?
>
>
> Nothing less than full-rbf without restritions on outputs works for this
> use-case. The only compromise possible is Antoine Riard's spent-nVersion
> signalling proposalĀ¹, which has a significant, negative, privacy impactĀ².
> It
> also increases costs and time in many cases, as you often have to create
> new
> outputs to flag full-rbf.
>
> 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 ?
> 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.
>
>
>
> Anyway, my advice to you is to either change your business model to make
> use of
> scalable instant payment tech such as Lightning. Or give up on Bitcoin and
> expand your business with other chians, such as BSVĀ³. The fact is some
> hashing
> power is already beginning to run with full-rbfā“, and I fully expect that
> % to
> increase over time.
>
> 1)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
> 2)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
> 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
> 4)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/5169f876/attachment.html>;
š Original message:On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete at petertodd.org> wrote:
> On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> > I dont think there was anything technical with the implementation and as
> > far as I can tell this is well developed and ready.
>
> There are lots of problems with my first-seen-safe proposal. The only
> reason I
> proposed it in 2015 was as a political compromise.
>
> > The reasons I can find for not being adopted are listed here -
> > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not
> First-seen-safe
> > Replace-by-fee
> >
> > Those reasons do not seem pertinent here - given OptinRBF already exists
> > as an option and the added benefit of continuing to be able to support
> > 0-conf.
>
> First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
> merged into Bitcoin Core: multi-party transactions.
>
> 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?
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 ?
>
>
> Nothing less than full-rbf without restritions on outputs works for this
> use-case. The only compromise possible is Antoine Riard's spent-nVersion
> signalling proposalĀ¹, which has a significant, negative, privacy impactĀ².
> It
> also increases costs and time in many cases, as you often have to create
> new
> outputs to flag full-rbf.
>
> 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 ?
> 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.
>
>
>
> Anyway, my advice to you is to either change your business model to make
> use of
> scalable instant payment tech such as Lightning. Or give up on Bitcoin and
> expand your business with other chians, such as BSVĀ³. The fact is some
> hashing
> power is already beginning to run with full-rbfā“, and I fully expect that
> % to
> increase over time.
>
> 1)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
> 2)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
> 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
> 4)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/5169f876/attachment.html>;