From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ArmchairCryptologist <ArmchairCryptologist@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Thu, 10 Nov 2022 09:35:18 +0000 [thread overview]
Message-ID: <F1L5VSwhj9SNtMuI7bhBzxyyuAIxwla8NI1T4_pZVDiN0nWYCvdTqq5vPl_SOXp2Ca6_-VJ340eTwPSWelM4k04mRLxoZNkpEF-MIW6xa9g=@protonmail.com> (raw)
In-Reply-To: <fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@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
next prev parent reply other threads:[~2022-11-10 9:35 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 16:20 Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding
2022-10-07 17:28 ` Greg Sanders
2022-10-07 21:37 ` Dario Sneidermanis
2022-10-11 16:18 ` Pieter Wuille
2022-10-12 5:42 ` Anthony Towns
2022-10-12 16:11 ` Pieter Wuille
2022-10-12 21:44 ` Dario Sneidermanis
2022-10-13 4:35 ` Anthony Towns
2022-10-16 8:08 ` Anthony Towns
2022-10-17 14:25 ` Greg Sanders
2022-10-17 21:41 ` Antoine Riard
2022-10-18 7:00 ` Anthony Towns
2022-10-19 3:01 ` Antoine Riard
2022-10-19 3:17 ` alicexbt
2022-10-20 22:08 ` Peter Todd
2022-11-02 15:04 ` AdamISZ
2022-10-20 23:18 ` Peter Todd
2022-11-09 13:19 ` ArmchairCryptologist
2022-11-10 9:35 ` ZmnSCPxj [this message]
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14 2:44 ` alicexbt
2022-10-14 15:02 ` Peter Todd
2022-10-17 20:31 ` Antoine Riard
2022-10-17 22:14 ` Antoine Riard
[not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04 ` Peter Todd
2022-10-14 16:28 ` Erik Aronesty
2022-10-15 4:08 ` John Carvalho
2022-10-15 4:20 ` John Carvalho
[not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45 ` Erik Aronesty
2022-10-19 15:43 ` Jeremy Rubin
2022-10-19 15:51 ` Greg Sanders
2022-10-19 16:04 ` Sergej Kotliar
2022-10-19 16:08 ` Greg Sanders
2022-10-20 1:37 ` Antoine Riard
2022-10-20 14:11 ` Sergej Kotliar
2022-10-21 1:04 ` Antoine Riard
2022-10-20 4:05 ` Peter Todd
2022-10-21 19:35 ` Peter Todd
2022-10-20 7:22 ` Anthony Towns
2022-10-20 12:37 ` Sergej Kotliar
2022-10-20 14:14 ` Ruben Somsen
2022-10-20 14:17 ` Sergej Kotliar
2022-10-20 19:58 ` Anthony Towns
2022-10-20 21:05 ` David A. Harding
2022-10-20 21:07 ` Greg Sanders
2022-10-20 22:02 ` Eloy
2022-10-21 12:02 ` Sergej Kotliar
2022-10-21 14:01 ` Greg Sanders
2022-10-21 14:19 ` Sergej Kotliar
2022-10-21 14:47 ` Greg Sanders
2022-10-21 19:43 ` Peter Todd
2022-10-24 7:55 ` Sergej Kotliar
2022-10-20 22:13 ` Peter Todd
2022-10-21 9:34 ` Sergej Kotliar
2022-10-21 19:33 ` Peter Todd
2022-10-24 7:45 ` Sergej Kotliar
2022-10-21 11:56 ` Sergej Kotliar
2022-10-23 19:20 ` David A. Harding
2022-10-23 20:51 ` alicexbt
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02 6:34 ` Daniel Lipshitz
2022-12-02 1:52 ` Antoine Riard
2022-12-02 6:59 ` Daniel Lipshitz
2022-12-02 4:30 ` Peter Todd
2022-12-02 7:06 ` Daniel Lipshitz
2022-12-03 8:50 ` Peter Todd
2022-12-03 11:01 ` Daniel Lipshitz
2022-12-03 11:51 ` Daniel Lipshitz
2022-12-03 12:12 ` Peter Todd
2022-12-03 13:17 ` Daniel Lipshitz
2022-12-03 14:03 ` Daniel Lipshitz
2022-12-05 12:21 ` angus
[not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='F1L5VSwhj9SNtMuI7bhBzxyyuAIxwla8NI1T4_pZVDiN0nWYCvdTqq5vPl_SOXp2Ca6_-VJ340eTwPSWelM4k04mRLxoZNkpEF-MIW6xa9g=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=ArmchairCryptologist@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox