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
136
137
138
139
140
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 15BD2A49
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 13:39:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
[209.85.213.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 936DA14E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 13:39:39 +0000 (UTC)
Received: by mail-vk0-f51.google.com with SMTP id r126so12925293vkg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 06:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=+QQ2ehTDEEBjOkivuQqT6QEpA3ePJa0Tw00sReZP44c=;
b=b0qsygdg2AN7nTZN4lQMYeiFccCZ/cUeJTz1fEvcVXfzns73hioRYuJNJ7zavGsQib
g3zm6y2pxOQjLoudF9E6wCm6CY+k0U7OCeAJmHl+Ccot5e4cE3fC8DyyvdQlpjsF8puT
ygk3xs0iEqEXns1IpfCKJnu01YFDWBL5z/c26z9fgrEeBvIGxMeCmxqh7G/i+V9LF91P
zEoXM4xYIBHeOv6H+avjbabVXUN4duwce32hFyz/PwFAlWKA0pUSLyrxciHs3vHZRHft
k0hrA7yUIel3+5G56wyjR6Kdc7EP4RiYWdvqtvutbfbVHw9jcS8XYZrJjj1U4NAz89VS
OLcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=+QQ2ehTDEEBjOkivuQqT6QEpA3ePJa0Tw00sReZP44c=;
b=QxoXPG6zWMZcZZfk+/uHgaicLdkNO0A0ZKHi/K46AzqKV67HfgzVPnMAjsYEUlIpls
s7t+M8NadSWq8TbwyBD2jEWclU7J7wJSUMS60ocPykyyxZ+PKRFOuzWrodS8WLsbRGMC
D4QT39dfoWnqZYcTPcWx43opb1HZbNa1JJQzPxQBTEceCWEQcWqtSnfsb1res8GovHC2
E7XSWdeHMQD3xn9YyLnqZyjkYUljQvvP8GE+0jZUTnJ/KPfWR12Q1RqjpkKkId8Be/5X
+BzozDRQaN4x/sgJZjdAyXCo3RCK8hvEjGezJEK/fbmCFhFQCiBmqywupzraCKW69LF5
pbjA==
X-Gm-Message-State: AIVw111ckXThIXF2DMca1/TGvc13KMAY8jpcSygr4YamYrVYCPM4chbr
IeiM3NwxqVkjVo5bfFzerQqexFjjGTDY
X-Received: by 10.31.157.1 with SMTP id g1mr1255144vke.139.1499866778386; Wed,
12 Jul 2017 06:39:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.74.89 with HTTP; Wed, 12 Jul 2017 06:39:17 -0700 (PDT)
In-Reply-To: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 12 Jul 2017 09:39:17 -0400
Message-ID: <CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114157f4895b5a05541ef21a"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 12 Jul 2017 13:49:11 +0000
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
Merge Mined drivechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 12 Jul 2017 13:39:40 -0000
--001a114157f4895b5a05541ef21a
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1. Remove the necessity of coinbase commitments. The miner commits to
> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
> anyway. That way the h* commitment occurs only once in the block, in the
> transaction that does the OP_BRIBEVERIFY. In addition, there is no need to
> impose particular ordering on the coinbase outputs, which would be
> problematic as pointed out by others, for example if the miner is
> interested only in merge mining for sidechain id #35 and nobody else.
>
> 2. When verifying a block, keep a set of sidechain ID's. When processing
> a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID
> is in that set. If not in that set, add it to that set and continue script
> processing. If already in the set, fail the script processing. This
> ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a
> mainchain block.
>
At this point can we eliminate the need to use the scripting system at all
and just use a special, currently non-standard, OP_RETURN output to hold
the sidechain_id and h* instead? We can soft fork in a rule that at most
one such output can appear in a block per sidechain_id.
--001a114157f4895b5a05541ef21a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <span dir=3D"=
ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D""></span><div>In any case, l=
et me propose actual improvements to the OP_BRIBEVERIFY proposal:<br></div>=
<div><br></div><div>1.=C2=A0 Remove the necessity of coinbase commitments.=
=C2=A0 The miner commits to the sidechain_id and h* in the transaction that=
pays the OP_BRIBEVERIFY anyway.=C2=A0 That way the h* commitment occurs on=
ly once in the block, in the transaction that does the OP_BRIBEVERIFY.=C2=
=A0 In addition, there is no need to impose particular ordering on the coin=
base outputs, which would be problematic as pointed out by others, for exam=
ple if the miner is interested only in merge mining for sidechain id #35 an=
d nobody else.<br></div><div><br></div><div>2.=C2=A0 When verifying a block=
, keep a set of sidechain ID's.=C2=A0 When processing a transaction in =
that block with OP_BRIBEVERIFY, check if the sidechain ID is in that set.=
=C2=A0 If not in that set, add it to that set and continue script processin=
g.=C2=A0 If already in the set, fail the script processing.=C2=A0 This ensu=
res that at most one OP_BRIBEVERIFY exists for each sidechain_id in a mainc=
hain block.<br></div></blockquote><div><br></div><div>At this point can we =
eliminate the need to use the scripting system at all and just use a specia=
l, currently non-standard, OP_RETURN output to hold the sidechain_id and h*=
instead?=C2=A0 We can soft fork in a rule that at most one such output can=
appear in a block per sidechain_id.<br></div></div></div></div>
--001a114157f4895b5a05541ef21a--
|
