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
|
Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AF40C1298
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:13:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com
[209.85.160.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF7BD14F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 23:13:56 +0000 (UTC)
Received: by mail-yk0-f175.google.com with SMTP id a85so90547445ykb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 15:13:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=aKB4hbwOjAq4XYiFB/pfWi1HZSvFgWSss5vYJddYB7w=;
b=dAy8PtHUCNYBxX8cwfXBsc7qTVdy9r8j23LZW+L2dT3JfpKQ3Nvom9O3bIQZMG1xjg
qLGLNQuIhCVKMhmZvYLX4iaogJ8bVUQsAM86LfH/UAhgp/uDdWjjVDq76h62hmT9Pi0e
79QJ4eQZOYYj5wJ9F7b5ko/9KzMHhWaVlWKK4oFcx/pSz29a7yjKKHTyIxHp6JBa3jUu
6QFKJ3vJqxjue7Ctev/G2v8oYcRSuwRWNaklEmCgN8zCqbnX43qejvZJurrpG6dWAjnX
M2to8c0puwNobxoi/CP7RPFtx0uMcK1gzZ5aUBzYBifMi624m5+j1AYOhLpiA81Lmfo6
cdhQ==
MIME-Version: 1.0
X-Received: by 10.13.245.135 with SMTP id e129mr57362518ywf.106.1451517236085;
Wed, 30 Dec 2015 15:13:56 -0800 (PST)
Received: by 10.129.32.86 with HTTP; Wed, 30 Dec 2015 15:13:56 -0800 (PST)
In-Reply-To: <E89CCB0E-8EA8-46E0-90C2-C2F80B51C894@petertodd.org>
References: <CAPkFh0tj4cXYuk8=8QJOP5z4qea6bv_sELhkfHO6nU16mMnnZA@mail.gmail.com>
<6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org>
<CAPkFh0usGPFQ4Tpn4v9FNmAL=Z8vZYm-VU50aFDnTEWMrAr5eA@mail.gmail.com>
<E89CCB0E-8EA8-46E0-90C2-C2F80B51C894@petertodd.org>
Date: Wed, 30 Dec 2015 16:13:56 -0700
Message-ID: <CANN4kmfYwvWm=iE9f5iqp=tNwXLZbuhNHzoGuoqyHL-uU7ZKAA@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham 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, 30 Dec 2015 23:17:36 +0000
Subject: Re: [bitcoin-dev] How to preserve the value of coins after a fork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 30 Dec 2015 23:13:57 -0000
Emin,
I have two technical criticisms of your proposal, and one economic criticis=
m.
>Unified miners would make sure that they mine transactions on Dum first, t=
hen on Dee. Recall that Dee miners can always just take Dum transactions an=
d stick them in their blocks.
This seems to contradict a later section that says that users can use
Dee natively, without paying fees necessary to get a transaction into
Dum. You can't have this both ways - either you can get a transaction
into Dee without getting it into Dum first, or you can't.
>Such an attack would be quite visible, and it would leave Dum vulnerable. =
Unified clients could counter this launching a 51% counterattack on Dum.
What if some other group that wants to hurt both Dum and Dee were to
make a false-flag attack against Dee? Mutually assured destruction
doesn't work if you can't accurately attribute attacks.
>This would create some gentle pressure to explicitly unify the two chains =
(by merging Dee and Dum at some compromise and doing away with Unified)
I don't think a compromise would be reachable at that point - suppose
one had a market cap of 1.2 billion, and the other had a market cap of
0.8 billion. How would the coins on the unified chain be distributed?
You could give each chain an equal number of coins, but that's not
fair to the people holding the more valuable coins. You could give
each chain a number of coins proportional to the market cap, but that
invites price manipulation. In any case, if you had a way of reaching
compromise, why not use it instead of creating two chains?
Overall, I think this proposal is a bad idea.
>You seem to not be familiar with how multisig transactions on Bitcoin work=
- 99.9% of the time theyre hidden behind p2sh and there is no way to know =
what keys are involved. Equally, multisig is just one of many complex scrip=
ts possible.
That doesn't end up mattering, though, as I understand his proposal.
The unified client would just see that both validly spend an output
with a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL.
On Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 30 December 2015 12:22:43 GMT-08:00, "Emin G=C3=BCn Sirer" <el33th4x0r=
@gmail.com> wrote:
>>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete@petertodd.org> wrote:
>>
>>> Note how transaction malleability can quickly sabotage naive notions
>>of
>>> this idea.
>>>
>>
>>Bitcoin-United relies on a notion of transaction equivalence that
>>doesn't
>>involve the transaction hash at all, so it should be immune to
>>malleability
>>issues and compatible with segwit.
>>
> >From the post, two transactions are equal if they "consume the same
>>inputs
>>and result in the same outputs, not counting the miner fee. Simple
>>pay-to-pubkey-hash and pay-to-script-hash transactions are
>>straightforward.
>>Multikey transactions are evaluated for equivalency by their inputs and
>>outputs, so it is allowable for a 2-out-of-3 payment to be signed by
>>one
>>set of two keys on Dum and another set of two keys on Dee, as long as
>>the
>>transaction consumes the same coins and produces the same outputs. Not
>>that
>>we'll ever encounter such a case, but making this point helps
>>pedagogically
>>with getting across the notion of transaction equivalence. What counts
>>are
>>the consumed inputs and the destination and amounts of the outputs."
>
> You seem to not be familiar with how multisig transactions on Bitcoin wor=
k - 99.9% of the time theyre hidden behind p2sh and there is no way to know=
what keys are involved. Equally, multisig is just one of many complex scri=
pts possible.
>
> Look into what a segwit transaction hashes - that's a better notion of no=
n-malleable transaction. But even then lots of transactions are malleable, =
and its easy to trigger those cases intentionally by third parties.
>
> Most likely any Bitcoin United scheme would quickly diverge and fail; muc=
h simpler and more predictable to achieve convincing consensus, e.g. via pr=
oof of stake voting, or Adam Bank's extension blocks suggestions. (or of co=
urse, not trying to force controversial forks in the first place)
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N
> AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g
> w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH
> Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl
> nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df
> dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN
> Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY=3D
> =3DFfK1
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
