From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 12D0DC002D for ; 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 ; 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 ; 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 ; 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" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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