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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
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 241D3A91
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Jun 2017 16:35:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com
[209.85.216.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8AE5A18D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Jun 2017 16:35:37 +0000 (UTC)
Received: by mail-qt0-f170.google.com with SMTP id f92so53893964qtb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 28 Jun 2017 09:35:37 -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-language:content-transfer-encoding;
bh=cJeKIXlCegu6FA9I4QxaCf5sGkr0Z6gaB7UkAiFkLDw=;
b=QyokWe6RZDn53CkyLbOjfUXrtlVJJ1OX6AwOgLUkteyYTFt8FgaR/Bkf7AfIhb/TEc
FfErLy1baRJSk8PLe583+Da1/ZYsXrePfQJcOtGRbvTr9VQlvRB+vxWbDEXoWumva8hj
uHkKC16LBxJOTKnYhM7Essh5e3MbWwDDL8QiybcSLxGo1EUY7KKtdRSseXh0HCUaY7UD
V8uzS7hAuvif/5OpMMrPfGBW/Uf4QTxubeqVs6vZkOy+jMK0C3mn1Wu3dRmjcqIqDcMl
6ITJjBP8ufpP8QiYKZhPFXAVYCJP3zU/hgn60WR1SD8ZtxYpKfGYO7ydO2WMVTIoK6At
xjhw==
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-language
:content-transfer-encoding;
bh=cJeKIXlCegu6FA9I4QxaCf5sGkr0Z6gaB7UkAiFkLDw=;
b=jZdzDuZqMM35YEUi1ZKxJ4bdxNjYTB6OQ0OnG1XNDQxvUm2mIanzfdl6bPm0QngFeM
GKwSKnjDKe53lD1AP9BisUqBHMNR8g6a2FJ5Ookl0ub5EBNSd8pSK2N9YDDr+Ny3jWqY
VMUMpn1v/gpB8K2MUFygj5x0QAKs7yOOugZoUGKYr6zwvqctf0URT4du8uy6USNg7bTo
xCtg2EtkRSCM/09rKhBewmc1pfKBruPdyQkcHwTPXDTSmo0ZuuQ/XOwsHb5eUNJp1tEK
CE4tizNCLEjjg2by8KQuIxYI00flhWzM6Cgeedx1PIsluF2/GeffSNUND6x7Wc7C/dtT
xPRQ==
X-Gm-Message-State: AKS2vOxD78Y7GfB9CVEPkmC+9e4JWAdDbF4b8e0vsctBO11JgPn9DKjy
42veTvQTkwSy+0TJgd4=
X-Received: by 10.200.3.132 with SMTP id t4mr10942124qtg.232.1498667736217;
Wed, 28 Jun 2017 09:35:36 -0700 (PDT)
Received: from [192.168.1.100] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
w9sm2170684qta.29.2017.06.28.09.35.33
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 28 Jun 2017 09:35:34 -0700 (PDT)
To: Gregory Maxwell <greg@xiph.org>, Chris Stewart <chris@suredbits.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
<CAAS2fgS7Fn=k0mFt04-+0kPqZYFZXjaOQ7J3JzNXSnCgQiSSOw@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <53ce81c2-4eac-986c-a204-2f9b7d476260@gmail.com>
Date: Wed, 28 Jun 2017 12:35:32 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAAS2fgS7Fn=k0mFt04-+0kPqZYFZXjaOQ7J3JzNXSnCgQiSSOw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Wed, 28 Jun 2017 16:35:38 -0000
Chris/Greg,
For pending withdrawals (side-to-main transfers), all of the data is
stored in a teeny tiny extension block which contains all the drivechain
data (which we called "MinerDB"). And miners were supposed to commit to
this and put it in the coinbase in some locate-able place (for example,
index 1).
I had assumed that this would go the same for BMM, since it is all
drivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM
included), would claim one output index.
Moreover, while DC claims an output "slot", the claim doesn't need to be
permanent...if the BTC-value of the relevant output is not equal to
zero, the BMM code could just ignore it. The sidechains would each
assume that no sidechain block was merged-mined in this period. And DC
would assume that no forward progress was made on any side-to-main
transfers (ie, that everyone "abstained").
Perhaps that addresses Greg's third, first, and second concerns.
I am having some trouble understanding concern #4. I think you mean to
say that the output coins of a transaction which is encumbered by OP
BribeVerify are different from other coins. Indeed they are, and coins
locked by OP BribeVerify cannot be moved until their associated
sidechain header ("h*") is ~100 blocks deep in the sidechain (hence the
earlier conversation about the "ratchet", which attempts to measure this).
The timeline that CryptAxe and I discussed, as I last remember it, is that:
0. (setup) The sidechain node is run by a briber, and this briber
constructs a sidechain block paying himself all the fees. These fees
total q=4 BTC.
1. Negotiations happen out of bound, between Briber and all miners.
(still setting up) Each new transaction the Briber makes, he chooses a
completely new h* (which is trivial for him to do by incrementing a
nonce/anything), and he may as well also fund each of these txns with
the same unspent output (owned by him). This prevents a miner from
annoying the Briber by including many ultimately-invalid transactions.
2. Miner1 includes h* in the coinbase of today's block thus BMMing a
sidechain block today, he also includes the transaction he just
negotiated with the Briber (call it, "tx1"). This tx1 is one where
Briber pays z=(q-0.001) to an op_bribe script that will eventually pay z
BTC to Bitcoin address M owned by "miner1".
3. After ~123 blocks, the ratchet (on mainchain) indicates that the
sidechain headers have advanced sequentially by x=100 places. This
allows miner1 to spend from tx1 to address M.
3. OR, after ~250 blocks, the second timing threshold is reached*, and
the Briber can spend from his script back to an address he controls
(also predefined in steps 1 and 2).
*This is the dual-threshold time-locking technique that the LN uses to
prove a negative.
The second timelock setup is required because it is possible that miner
will earnestly BMM a sidechain block, but then reorg such that this
block is orphaned out of the longest (side)chain. In this case, the
Briber doesn't get paid his tx-fees, so he is entitled to a refund.
So, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm
glad Chris is taking the initiative and doing this work. And I'm sorry
if the documentation has shifted too much. At the bottom of the spec
blog post there are some notes, but they probably aren't very helpful.
On 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> A new block rule is added which requires that the miner's coinbase reward be
>> at index 0 in the coinbase transaction's output vector.
>
> This is an absurd restriction-- I hope it was not your intent to
> directly ban P2Pool and probably any other form of decentralized or
> less centralized mining pooling... but thats what doing that does.
>
>> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
>
> This removes important flexibility that was intentionally preserved.
> What happens when an additional commitment is needed for bitcoin?
> must some sidechain be irreparably destroyed? looks like it in your
> proposal.
>
>> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
>
> And what happens if index 1 isn't present? if index 35 is used must
> there be 34 dummy outputs?
>
>> This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
>
> This is not monotone/reorg safe. It means that the output coins (if
> any) are not equivalently fungible with other bitcoins (for, e.g. 100
> blocks) because if there is a reorg this transaction cannot be
> restored to the chain. It's also impure and not compatible with
> caching, which would be unfortunate and slow block propagation.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
