public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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 [bitcoin-dev] Stumbling into a contentious soft fork activation attempt 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=prayank@tutanota.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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