From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Date: Mon, 25 Apr 2022 05:12:10 +0000 [thread overview]
Message-ID: <UWxdkhOFe4dSFiV8z5uYiAySZSj-YDfH6vG3nasOSrqiZg9W1gDfmNc1MbSNTtJV6fr2j_Ch9AkpbpJWflY8cUfsBT08B3XXYVht8zptF_4=@protonmail.com> (raw)
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
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 actual users demand".
An idea that has been percolating in my various computation systems is to use 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 general 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 / behavior) 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 microcode, and instead of sending funds to a new version of the Bitcoin SCRIPT 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 requiring 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 Bitcoin Core, so that the mechanics of merging in a new opcode, that was prototyped 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 corresponding micro-opcodes and runs that, possibly with reasonable limits on execution 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 supposed 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 interpreters 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
next prev parent reply other threads:[~2022-04-25 5:12 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 1:04 David A. Harding
2022-04-21 2:05 ` Luke Dashjr
2022-04-21 3:10 ` alicexbt
2022-04-21 5:56 ` Luke Dashjr
2022-04-21 6:20 ` Jeremy Rubin
2022-04-21 6:37 ` Luke Dashjr
2022-04-21 13:10 ` Jeremy Rubin
2022-04-24 15:22 ` Peter Todd
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06 ` David A. Harding
2022-04-21 18:39 ` Matt Corallo
2022-04-21 22:28 ` David A. Harding
2022-04-21 23:02 ` Matt Corallo
2022-04-22 1:20 ` David A. Harding
2022-04-22 18:40 ` Matt Corallo
2022-04-22 18:49 ` Corey Haddad
2022-04-22 16:48 ` James O'Beirne
2022-04-22 17:06 ` James O'Beirne
2022-04-22 16:28 ` James O'Beirne
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
2022-04-23 14:02 ` Russell O'Connor
2022-04-23 18:24 ` Matt Corallo
2022-04-23 19:30 ` Russell O'Connor
2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
2022-04-27 1:52 ` Billy Tetrud
2022-04-28 23:14 ` Nadav Ivgi
2022-04-28 23:51 ` Billy Tetrud
2022-04-22 18:35 ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22 0:28 ` Anthony Towns
2022-04-22 1:44 ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25 5:12 ` ZmnSCPxj [this message]
2022-04-22 19:05 alicexbt
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='UWxdkhOFe4dSFiV8z5uYiAySZSj-YDfH6vG3nasOSrqiZg9W1gDfmNc1MbSNTtJV6fr2j_Ch9AkpbpJWflY8cUfsBT08B3XXYVht8zptF_4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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