From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Prayank <prayank@tutanota•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
Date: Mon, 21 Feb 2022 09:09:09 +0000 [thread overview]
Message-ID: <P-AzUGkyLnnGrB-5l8QdkQl9FSZdjL9wHZ-nyTcaMoh_i4dyWPWDWIl9ghAWqh00oreJ9ozX9oy-QCmTS_6b00OUAGPNID16tZj78JG20vA=@protonmail.com> (raw)
In-Reply-To: <MwPDtAD--3-2@tutanota.de>
Good morning,
> If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.
Perhaps a thing to note, is that if it allows us to move some activity off-chain, and reduce activity on the blockchain, then the increase in functionality does *not* translate to a requirement of block size increase.
So for example:
* Taproot, by allowing the below improvements, is good:
* Schnorr multisignatures that allow multiple users to publish a single signature, reducing block size usage for large participant sets.
* MAST, which allows eliding branches of complicated SCRIPTs that are not executed, reducing block size usage for complex contracts.
* `SIGHASH_ANYPREVOUT`, by enabling an offchain updateable multiparty (N > 2) cryptocurrency system (Decker-Russell-Osuntokun), is also good, as it allows us to make channel factories without having to suffer the bad tradeoffs of Decker-Wattenhofer.
* `OP_CTV`, by enabling commit-to-unpublished-promised-outputs, is also good, as it allows opportunities for transactional cut-through without having to publish promised outputs *right now*.
So I do not think the argument should really object to any of the above, either --- all these improvements increase the functionality of Bitcoin, but also allow opportunities to use the blockchain as judge+jury+executioner instead of noisy marketplace.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-02-21 9:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 1:57 Prayank
2022-02-18 23:41 ` Peter Todd
2022-02-20 18:35 ` Erik Aronesty
2022-02-21 3:03 ` Prayank
2022-02-21 9:02 ` ZmnSCPxj
2022-02-21 9:11 ` ZmnSCPxj
2022-02-21 9:48 ` Prayank
2022-02-22 12:57 ` Billy Tetrud
2022-02-21 9:09 ` ZmnSCPxj [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-01-04 11:53 Prayank
2022-01-04 14:15 ` Michael Folkson
2022-01-04 15:06 ` Prayank
2022-01-04 16:48 ` Michael Folkson
2022-01-04 17:07 ` Prayank
2022-01-04 14:42 ` Christian Decker
2022-01-04 15:45 ` Prayank
2022-01-03 2:05 Michael Folkson
2022-01-09 11:38 ` Peter Todd
2022-01-11 3:42 ` Jeremy
2022-01-11 4:38 ` Jeremy
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='P-AzUGkyLnnGrB-5l8QdkQl9FSZdjL9wHZ-nyTcaMoh_i4dyWPWDWIl9ghAWqh00oreJ9ozX9oy-QCmTS_6b00OUAGPNID16tZj78JG20vA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=prayank@tutanota$(echo .)de \
/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