From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Sat, 26 Feb 2022 06:43:52 +0000 [thread overview]
Message-ID: <fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
Good morning AJ,
> ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you arguing that it would be unwise to opt into a drivechain? Those are very different arguments. If drivechains compromised things for normal bitcoin nodes that ignore drivechains, then I agree that would be serious reason to reject drivechains outright and reject things that allow it to happen. However, if all you're saying is that people can shoot themselves in the foot with drivechains, then avoiding drivechains should not be a significant design consideration for bitcoin but rather for those who might consider spending their time working on drivechains.
Neither.
My argument is simply:
* If Drivechains are bad for whatever reason, we should not add recursive covenants.
* Otherwise, go ahead and add recursive covenants.
Drivechains are not a scaling solution [FOOTNOTE 1] and I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care (but I would *prefer* if people focus on scaling-useable functionality, like `SIGHASH_NOINPUT`, `OP_EVICT`, `OP_CTV`, `OP_TLUV` probably without the self-replace capability).
I bring this up simply because I remembered those arguments against Drivechains, and as far as I could remember, those were the reasons for not adding Drivechains.
But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants.
I do not intend to utilize them any time soon anyway.
My second position is that in general I am wary of adding Turing-completeness, due precisely to Principle of Least Power.
A concern is that, since it turns out recursive covenants are sufficient to implement Drivechains, recursive covenants may also enable *other* techniques, currently unknown, which may have negative effects on Bitcoin, or which would be considered undesirable by a significant section of the userbase.
Of course, I know of no such technique, but given that a technique (Drivechains) which before would have required its own consensus change, turns out to be implementable inside recursive covenants, then I wonder if there are other things that would have required their own consensus change that are now *also* implementable purely in recursive covenants.
Of course, that is largely just stop energy, so if there is *now* consensus that Drivechains are not bad, go ahead, add recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` first?).
Regards,
ZmnSCPxj
[FOOTNOTE 1] Sidechains are not a scaling solution, or at least, are beaten in raw scaling by Lightning. Blockchains are inefficient (THAT IS PRECISELY THE PROBLEM WHY YOU NEED A SCALING SOLUTION FOR BITCOIN THAT WAS LIKE THE FIRST RESPONSE TO SATOSHI ON THE CYPHERPUNK MAILING LIST) and you have to show your transaction to everyone. While sidechains imply that particular subsets are the only ones interested in particular transactions, compare how large a sidechain-participant-set would be expected to be, to how many people learn of a payment over the Lightning Network. If you want a sidechain to be as popular as LN, then you expect its participant set to be about as large as LN as well, and on a sidechain, a transaction is published to all sidechain participants, but on the LN, only a tiny tiny tiny fraction of the network is involved in any payment. Thus LN is a superior scaling solution. Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them (i.e. microchains). I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each, and then you would pay by transferring across multiple participants in a chain of HTLCs and look, oh wow, surprise surprise, you just got the Lightning Network. LN wins.
next prev parent reply other threads:[~2022-02-26 6:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27 4:20 ` James Lu
2022-01-27 19:16 ` Russell O'Connor
2022-01-28 0:18 ` James O'Beirne
2022-01-28 13:14 ` Michael Folkson
2022-01-28 14:17 ` Anthony Towns
2022-01-28 16:38 ` Jeremy
2022-01-28 14:13 ` Russell O'Connor
2022-01-28 15:14 ` James O'Beirne
2022-01-29 15:43 ` Russell O'Connor
2022-01-29 17:02 ` Jeremy Rubin
[not found] ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14 ` Russell O'Connor
2022-01-31 2:18 ` Anthony Towns
2022-01-28 1:34 ` Anthony Towns
2022-01-28 13:56 ` Russell O'Connor
2022-02-01 1:16 ` Anthony Towns
2022-02-08 2:16 ` Russell O'Connor
2022-02-17 14:27 ` Anthony Towns
2022-02-17 14:50 ` Russell O'Connor
2022-02-08 3:40 ` Rusty Russell
2022-02-08 4:34 ` Jeremy Rubin
2022-02-11 0:55 ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11 3:42 ` Jeremy Rubin
2022-02-11 17:42 ` James O'Beirne
2022-02-11 18:12 ` digital vagabond
2022-02-12 10:54 ` darosior
2022-02-12 15:59 ` Billy Tetrud
2022-02-17 15:15 ` Anthony Towns
2022-02-18 7:34 ` ZmnSCPxj
2022-02-23 11:28 ` ZmnSCPxj
2022-02-23 18:14 ` Paul Sztorc
2022-02-24 2:20 ` ZmnSCPxj
2022-02-24 6:53 ` Anthony Towns
2022-02-24 12:03 ` ZmnSCPxj
2022-02-26 5:38 ` Billy Tetrud
2022-02-26 6:43 ` ZmnSCPxj [this message]
2022-02-27 0:58 ` Paul Sztorc
2022-02-27 2:00 ` ZmnSCPxj
2022-02-27 7:25 ` ZmnSCPxj
2022-02-27 16:59 ` Billy Tetrud
2022-02-27 23:50 ` Paul Sztorc
2022-02-28 0:20 ` Paul Sztorc
2022-02-28 6:49 ` ZmnSCPxj
2022-02-28 7:55 ` vjudeu
2022-03-04 8:42 ` ZmnSCPxj
2022-03-04 13:43 ` vjudeu
2022-02-28 22:54 ` Paul Sztorc
2022-03-01 5:39 ` Billy Tetrud
2022-03-02 0:00 ` Paul Sztorc
2022-03-04 12:35 ` Billy Tetrud
2022-03-04 20:06 ` Paul Sztorc
2022-02-26 6:00 ` Anthony Towns
2022-02-15 8:45 ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57 ` Jeremy Rubin
2022-02-15 19:12 ` Russell O'Connor
2022-02-16 2:26 ` Rusty Russell
2022-02-16 4:10 ` Russell O'Connor
2022-02-14 2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26 7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
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='fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=billy.tetrud@gmail$(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