Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-05 📝 Original message:> > > > Many zero-conf ...
📅 Original date posted:2022-12-05
📝 Original message:>
>
>
> Many zero-conf proponents work on the bleeding edge of supporting
> Lightning, including myself. Lightning is not risk-free and the base layer
> should not be assuming it as a primary dependency for commercial payments.
>
for low-value payments, lightning is the only workable version because the
current low-fee environment is not scalable and never will be
for high valued payments, zero conf was never valuable or useful and never
can be - it was always the beneficence of users you are relying on low
fee/high fee double spends of a zero conf with no rbf flag has
been demonstrated, repeatedly ad nauseum.
... so there is no long term scenario where zero conf is valuable.
right *now* with low fees it might "seem nice", but really it just
incentivises network-wide surveillance, increased peer burden on nodes, and
unsustainable practices that are akin to a "mev" bounty hanging over
merchant's heads.
also, i've been using bitcoin for years without zero conf. selling and
buying online. operating merchants with millions in transactions. the
20 minute wait before i ship is meaningless, and the only risk i take on is
that a user replaces a transaction with a different destination. which
i've never observed. even with the flag on (which i dont care about, and
never have).
and if i do observe it ... i just won't ship. it was easy to code up.
the user will have to initiate a new tx. i have no objection to a user
being able to cancel their order. why would i?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/9b947dc5/attachment-0001.html>;
📝 Original message:>
>
>
> Many zero-conf proponents work on the bleeding edge of supporting
> Lightning, including myself. Lightning is not risk-free and the base layer
> should not be assuming it as a primary dependency for commercial payments.
>
for low-value payments, lightning is the only workable version because the
current low-fee environment is not scalable and never will be
for high valued payments, zero conf was never valuable or useful and never
can be - it was always the beneficence of users you are relying on low
fee/high fee double spends of a zero conf with no rbf flag has
been demonstrated, repeatedly ad nauseum.
... so there is no long term scenario where zero conf is valuable.
right *now* with low fees it might "seem nice", but really it just
incentivises network-wide surveillance, increased peer burden on nodes, and
unsustainable practices that are akin to a "mev" bounty hanging over
merchant's heads.
also, i've been using bitcoin for years without zero conf. selling and
buying online. operating merchants with millions in transactions. the
20 minute wait before i ship is meaningless, and the only risk i take on is
that a user replaces a transaction with a different destination. which
i've never observed. even with the flag on (which i dont care about, and
never have).
and if i do observe it ... i just won't ship. it was easy to code up.
the user will have to initiate a new tx. i have no objection to a user
being able to cancel their order. why would i?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/9b947dc5/attachment-0001.html>;