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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 81D35486
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Jul 2017 21:32:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com
[209.85.220.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E16DCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Jul 2017 21:32:51 +0000 (UTC)
Received: by mail-qk0-f196.google.com with SMTP id 91so21926105qkq.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 02 Jul 2017 14:32:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=vU2gIoHXtaF6LHPm61nLr9LxBVP1X34vOderABjzHWM=;
b=eSTl6VKUBVBnUGX73Oo78HOYoakzHqsrMCP7Jny4PyUVbEwX9OBoLjZXAinaab21Fw
EBuj4gpWwxmRaxCZBrZke6oT19TG4FMopwHdcyzVqpZv3pQ2xKQtGvSwvZaKtnDvNzm4
Pup7zaG4NziJtzSzfHvJzcq9SFIcYXce8/zRdB220bzzn/vV8OYS1GDIjTyHKE1NZl/H
JYQxvT2aV2OWO3ThhVPP0MV5+Zne3piy/Cqe+VUXwlJ76Er/pAfPVwZ5sNekT3MkZf+A
vjT3qDI5NYFWtBrn/rykgtY70dmzM5nOyKrhHLJji0RZz4UaiYKBYOOdTTwSckDFZT0b
P6rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=vU2gIoHXtaF6LHPm61nLr9LxBVP1X34vOderABjzHWM=;
b=st5ZfNqnNJa0qodkbPscOkS+RehZfS4pIn+HUZsMo9cI1GCNNTxhow2QuYdzm2IT2Z
sIJKKbcvN0EeEJQHsfgsZ2NrVxn8AyeHDFixRJ1LiSab1nbqOwclgI4MagRhdEO0CwiP
dH6pxyb7octcfFQf/B7aP+h494qIHTJ3S2ao9wEIzwjHIjVws2LBqxw86/ORj52Sj06C
APBWKWbk5+u/GlUiMNeCMOjqrG9AVLd2p1e9fyzHYJdQqv1rm0O3//6zBTSCMjdfawSl
HTULBCkk+9+9YWGPXmPzMPLXCJARq9ILwCvBa6Odxx+BFjJ9ZlNohMPH+iyu/ZV32kFV
pqfA==
X-Gm-Message-State: AKS2vOydtu+0HoHN7g2NEBpG+/JvmQ1LDMMQFhRoFjw7MQw7EizN4TuU
KN0720gsp4z+6C/I
X-Received: by 10.55.11.134 with SMTP id 128mr36871397qkl.6.1499031170894;
Sun, 02 Jul 2017 14:32:50 -0700 (PDT)
Received: from [192.168.1.101] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
n11sm357561qtf.45.2017.07.02.14.32.48
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 02 Jul 2017 14:32:49 -0700 (PDT)
To: ZmnSCPxj <ZmnSCPxj@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>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
Date: Sun, 2 Jul 2017 17:32:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 02 Jul 2017 21:32:52 -0000
Hi,
Sorry for the delay, I overlooked this email until now. I see that Chris
and CryptAxe both answered but I will also answer, because the message
was addressed to me.
On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
> >Your way is actually very similar to mine. Mine _forces_ the bribe to =
be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn=
"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This create=
s
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot
> reorganize unless the mainchain reorganizes, since the consensus loop
> only cares about matching the current block; it ignores splits and
> does not consider them valid.
If I've understood you correctly, you have said that each OP Return
links the (ex)-latest block to a brand new block, and that whichever
message of this kind comes first (in the mainchain) wins and the rest
are discarded.
So what if I had a sidechain represented by a jumble of capital letters,
discarded entries as lowercase letters.
Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
Mainchain Block #200002: [Q --> H], [Q --> z],
Mainchain Block #200003: [H --> F]
Mainchain Block #200004: [F --> J], [F -->w]
Mainchain Block #200005: [H --> P], [J -->x]
Mainchain Block #200006: [P --> D]
Isn't the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
competing chain {{ Q --> H --> P --> D }} ?
> But I suppose you are considering something like the Ethereum
> mutability feature, which I do not think is something you would want
> in a sidechain.
What I do want to do, is retain the existing model to some extent.
Specifically, to the degree where sidechains could salvage some bad
situations (eg value overflow incident, or March 2013 incident).
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require o=
ne
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter=
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once
> in the coinbase and once in the briber's separate transaction?
That is a good point. Technically, we do include it twice, but the
second instance (briber-transaction) can be "shuffled" out if the
counterparties are part of the same Lightning Network (which I expect to
the be the case, in equilibrium).
>
> In my scheme at least there is no indicator byte -- the "previous
> block" hash is the indicator of which sidechain it is extending. From
> your other emails on this list, it seems the ratchet is for
> withdrawals from sidechain to mainchain? If so, should it not only
> appear in only some of the sidechains (the ones which are currently
> doing some withdrawal?)?
No, sorry. There are many tangled issues (Drivechain (total system);
side-to-main withdrawals (OP CountACKs); individual Drivechains
themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
about withdrawals, it is exclusively about Blind Merged Mining, and
making a better OP BribeVerify that offers better guarantees to both side=
s.
Paul
|
