1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 72485C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Jul 2022 23:40:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 369FA41881
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Jul 2022 23:40:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 369FA41881
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=rAkeV+zm
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, 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,
URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id G8DBHHtwjkvO
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Jul 2022 23:40:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A16E41768
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by smtp4.osuosl.org (Postfix) with ESMTPS id 9A16E41768
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Jul 2022 23:40:43 +0000 (UTC)
Date: Sun, 24 Jul 2022 23:40:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1658706041; x=1658965241;
bh=euEUvNgx6lxCxKBVEgZTIqv1lQcfD5zYt/5PaPZnKSo=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=rAkeV+zmLh6WKDpAAuAXU9av9YfMSW0BL3C+dAMvrsfv+EoktD5ofrfBXgxMVoVGr
vLiGpbDn3PMH9/PvhYI4fesUTK+FLtGv/bYrFKjtlemLXVhU9isgnrVEiKwjzPJt1+
8P46vPt3mk9u3lCptAMK/YiufN7TfH/58sD3VfwzrSeQBTDBY++yeNzeePV7V4NW4j
qtBM7/xfZAmKPaazYZwYIl/32woDk7HP0cZfHw85xPpDLwVCI4SKUps9XoUcOA7gpN
lpPnFfXn/tEWYB8QRulYQUIZMB0SQVjhnraWa26ETUM0op3c+VuXkbO51o/v5mX6VO
WIJ+D+CthWbEQ==
To: "aliashraf.btc At protonmail" <aliashraf.btc@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com>
In-Reply-To: <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
<XSc7hh8TBcrQc8YsYbCj4dmf3YkdQwJAv50lIcAK7rMYH9gChkn_S3SkJFmATwCrD-klYeJ55FajcGQ1HVuY0msxyiah8rLbVlQG7sXkAmo=@protonmail.com>
<CALZpt+HerfG6hfkPksN=0ih5pRP6m0qAnxH3au7h3gadnHPKdQ@mail.gmail.com>
<oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
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] On a new community process to specify covenants
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: Sun, 24 Jul 2022 23:40:45 -0000
Good morning alia, Antoine, and list,
> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in b=
itcoin development, is just too much. Bitcoin development methodology is an=
open problem, given the contemporary escalation/emergence of challenges, h=
istory is not=C2=A0 entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, but i=
t is not guaranteed that the outcome to be always the same as your take.
>
> I'd suggest instead of inventing a multi-decades-lifecycle based methodol=
ogy (which is weird by itself, let alone installing it as a standard for bi=
tcoin projects), being open-mind=C2=A0 enough for examining more agile appr=
oaches and their inevitable effect on the course of discussions,
A thing I have been mulling is how to prototype such mechanisms more easily=
.
A "reasonably standard" approach was pioneered in Elements Alpha, where an =
entire federated sidechain is created and then used as a testbed for new me=
chanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`.
However, obviously the cost is fairly large, as you need an entire federate=
d sidechain.
It does have the nice advantage that you can use "real" coins, with real va=
lue (subject to the federation being trustworthy, admittedly) in order to c=
onvincingly show a case for real-world use.
As I pointed out in [Smart Contracts Unchained](https://zmnscpxj.github.io/=
bitcoin/unchained.html), an alternative to using a blockchain would be to u=
se federated individual coin outpoints.
A thing I have been pondering is to create a generic contracting platform w=
ith a richer language, which itself is just used to implement a set of `OP_=
` SCRIPT opcodes.
This is similar to my [Microcode proposal](https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2022-March/020158.html) earlier this year.
Thus, it would be possible to prototype new `OP_` codes, or change the beha=
vior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change in b=
ehavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a tran=
slation from `OP_` codes to the richer language.
Then you could prototype a new SCRIPT `OP_` code by providing your own tran=
slation of the new `OP_` code and a SCRIPT that uses that `OP_` code, and u=
sing Smart Contract Unchained to use a real funds outpoint.
Again, we can compare the Bitcoin consensus layer to a form of hardware: ye=
s, we *could* patch it and change it, but that requires a ***LOT*** of work=
and the new software has to be redeployed by everyone, so it is, practical=
ly speaking, hardware.
Microcode helps this by adding a softer layer without compromising the exis=
ting hard layer.
So... what I have been thinking of is creating some kind of smart contracts=
unchained platform that allows prototyping new `OP_` codes using a microco=
de mechanism.
Regards,
ZmnSCPxj
|
