>
>
>
> 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?


>