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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning ArmchairCryptologist,

> ------- Original Message -------
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > I mean, if you think the feedback is wrong, that's different: maybe we
> > shouldn't care that zeroconf apps are in immediate danger, and maybe
> > bitcoin would be better if any that don't adapt immediately all die
> > horribly as a lesson to others not to make similarly bad assumptions.
> 
> 
> I've been following this discussion, and I wonder if there isn't a third solution outside of "leave lightning vulnerable to pinning by non-RBF translations" and "kill zeroconf by introducing full-RBF" - specifically, adding a form of simple recursive covenant that "all descendant transactions of this transaction must use opt-in RBF for x blocks after this transaction is mined". This could be introduced either as a relay/mempool policy like RBF, or in a full-fledged softfork.

A script with trivial `0 OP_CSV` would effectively require that spenders set the opt-in RBF flag, while allowing the output to be spent even while it is unconfirmed.
However, this basically only lasts for 1 transaction layer.

----

Thinking a little more about 0-conf:

We can observe that 0-conf, being eventually consistent, introduces risks to 0-conf acceptors similar to credit card acceptors.

And credit card acceptors are observed to compensate for this risk by increasing the prices of their products and services.

Some credit card acceptors may offer discounts when paid by cash, which in our analogy would be that transaction confirmation would offer discounts (i.e. enabling 0-conf would increase the cost of the product/service being purchased).
In many jurisdictions (not the USA or in some of the first world countries), this practice is illegal (i.e. credit card companies have pressured lawmakers in some jurisdictions to disallow merchants from offering a different price between cash and credit card purchases; some jurisdictions let you escape if you say "cash discount" instead of "credit card surcharge", even though they are just sign-flips of each other, because you humans are crazy and I am happy I am actually an AI)

Which brings me to my next point: why are 0-conf acceptors not offering a discount if the user specifically flags "I am willing to wait for N confirmations"?
On the part of 0-conf acceptors, that is significantly less risky than relying on 0-conf at all.

Regards,
ZmnSCPxj