diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2022-04-25 05:12:10 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-25 05:12:17 +0000 |
| commit | 7f5705b63ea3788d40cb2c222db5886d2379de2f (patch) | |
| tree | ecc557dc49c81187b193112edf79e1d9c8ff7114 /91 | |
| parent | abdac82e86d0c7c9d4b59c9548938fd1813d7c5d (diff) | |
| download | pi-bitcoindev-7f5705b63ea3788d40cb2c222db5886d2379de2f.tar.gz pi-bitcoindev-7f5705b63ea3788d40cb2c222db5886d2379de2f.zip | |
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Diffstat (limited to '91')
| -rw-r--r-- | 91/ea20d4c4f7d0c355df27efbbeb11af4580ab2f | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/91/ea20d4c4f7d0c355df27efbbeb11af4580ab2f b/91/ea20d4c4f7d0c355df27efbbeb11af4580ab2f new file mode 100644 index 000000000..12d26ff43 --- /dev/null +++ b/91/ea20d4c4f7d0c355df27efbbeb11af4580ab2f @@ -0,0 +1,126 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 12D0DC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Apr 2022 05:12:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id EE1A040181 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Apr 2022 05:12:16 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.201 +X-Spam-Level: +X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 + tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=protonmail.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 3QzdMh_QRxFp + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Apr 2022 05:12:15 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 1773B40022 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Apr 2022 05:12:14 +0000 (UTC) +Date: Mon, 25 Apr 2022 05:12:10 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail; t=1650863532; + bh=oWG8cUipybjLURG+4iyuibMLUdW5JNXoffkgBGfHFn4=; + h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID; + b=S8oGTdKeTo+aUGEBmhYQIY1PRJ0e3EGdRaFEnYSMS5/futQhBI1Yyjm5DVhwhozg0 + F2lC4498czKXGosHtDfS12XqQ3UiPEKYxLfb9TLiW6Y4lPskbG7zs/ikQWCtX1FTQL + /tQkHsedKj7RqC5aq7u0SbOUnI9hn/Ns3XXJ4nlK5KCHWPIeeUGEbEjmdhqFfWK/rG + umQ/uFKaVJmbccD9cJRSmizSSllqt/cOK1P0vzyTsvxuJG8/d+ElDc/zt4X4xYngZx + t07P7O6HcgsAyqZZ0hPGIRTXzsOm96TyeOajEGjYn/A8a5wUwCn1SU0/7rt3JqOXSQ + QifSgAXMriwHw== +To: "David A. Harding" <dave@dtrt.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <UWxdkhOFe4dSFiV8z5uYiAySZSj-YDfH6vG3nasOSrqiZg9W1gDfmNc1MbSNTtJV6fr2j_Ch9AkpbpJWflY8cUfsBT08B3XXYVht8zptF_4=@protonmail.com> +In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> +References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> +Feedback-ID: 2872618:user:proton +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, + e.g. for CTV +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 25 Apr 2022 05:12:17 -0000 + +Good morning Dave, et al., + +I have not read through *all* the mail on this thread, but have read a fair= + amount of it. + +I think the main argument *for* this particular idea is that "it allows the= + use of real-world non-toy funds to prove that this feature is something ac= +tual users demand". + +An idea that has been percolating in my various computation systems is to u= +se Smart Contracts Unchained to implement a variant of the Microcode idea I= + put forth some months ago. + +Briefly, define a set of "more detailed" opcodes that would allow any gener= +al computation to be performed. +This is the micro-opcode instruction set. + +Then, when a new opcode or behavior is proposed for Bitcoin SCRIPT, create = +a new mapping from Bitcoin SCRIPT opcodes (including the new opcodes / beha= +vior) to the micro-opcodes. +This is a microcode. + +Then use Smart Contracts Unchained. +This means that we commit to the microcode, plus the SCRIPT that uses the m= +icrocode, and instead of sending funds to a new version of the Bitcoin SCRI= +PT that uses the new opcode(s), send to a "(n-of-n of users) or (1-of-users= + and (k-of-n of federation))". + +This is no worse security-wise than using a federated sidechain, without re= +quiring a complete sidechain implementation, and allows the same code (the = +micro-opcode interpreter) to be reused across all ideas. +It may even be worthwhile to include the micro-opcode interpreter into Bitc= +oin Core, so that the mechanics of merging in a new opcode, that was protot= +yped via this mechanism, is easier. + +The federation only needs to interpret the micro-opcode instruction set; it= + simply translates the (modified) Bitcoin SCRIPT opcodes to the correspondi= +ng micro-opcodes and runs that, possibly with reasonable limits on executio= +n time. +Users are not required to trust a particular fixed set of k-of-n federation= +, but may choose any k-of-n they believe is trustworthy. + +This idea does not require consensus at any point in time. +It allows "real" funds to be used, thus demonstrating real demand for the s= +upposed innovation. +The problem is the effective erosion of security to depending on k-of-n of = +a federation. + +Presumably, proponents of a new opcode or feature would run a micro-opcode = +interpreter faithfully, so that users have a positive experience with their= + new opcode, and would carefully monitor and vet the micro-opcode interpret= +ers run by other supposed proponents, on the assumption that a sub-goal of = +such proponents would be to encourage use of the new opcode / feature. + +Regards, +ZmnSCPxj + |