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
|
Return-Path: <el33th4x0r@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9FD4311D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 20:23:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com
[209.85.192.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0090111D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 20:23:03 +0000 (UTC)
Received: by mail-qg0-f47.google.com with SMTP id e32so99514125qgf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 12:23:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=Mo0PS4vRVVb5ps3At7tQwQhQoHgw5bamVvU8aKy45Uk=;
b=dDPn37dARfy913bOZ9SodGX0wT8UlD0jt5OFTFDEurw/U4v6ql1YxhzhTUf4f+gnnS
a+WTRQP9eMkAYZwvhG6OJFis86ZxWXKk2t6P+DGwMRy+gdLl7S23FZr4wmx5x4W676Ao
cq+1vuKIoEJhA4FZu5gyNHU1rUHEgWmKaeAiHI1lnYlCXRkdemVoO5Nn9VD31OBqzcvQ
xTtwyhlhIAPJCYKuxYnumDcUZc/TAF5B5Ngo3bqQilRL7p62NcUpY6ZQQWg/SnNyvE4z
kH0jqqHkvDKlsxpS+yTELioVA1JbADJ1ruv2fHmgAn5sZXUycOYASgL1ZwCN+G9jFUDI
TqUw==
X-Received: by 10.140.91.66 with SMTP id y60mr11024056qgd.20.1451506983248;
Wed, 30 Dec 2015 12:23:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.29.73 with HTTP; Wed, 30 Dec 2015 12:22:43 -0800 (PST)
In-Reply-To: <6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org>
References: <CAPkFh0tj4cXYuk8=8QJOP5z4qea6bv_sELhkfHO6nU16mMnnZA@mail.gmail.com>
<6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Wed, 30 Dec 2015 15:22:43 -0500
Message-ID: <CAPkFh0usGPFQ4Tpn4v9FNmAL=Z8vZYm-VU50aFDnTEWMrAr5eA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113a4f80202a530528234e60
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: =?UTF-8?Q?Emin_G=C3=BCn_Sirer_via_bitcoin=2Ddev?=
<bitcoin-dev@lists.linuxfoundation.org>
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 20:23:04 -0000
--001a113a4f80202a530528234e60
Content-Type: text/plain; charset=UTF-8
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."
But you're right, if a naive implementation were to just use the
transaction hash, the result would be a mess.
- egs
--001a113a4f80202a530528234e60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
</div><div class=3D"gmail_quote">On Wed, Dec 30, 2015 at 3:16 PM, Peter Tod=
d <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_bl=
ank">pete@petertodd.org</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Note how =
transaction malleability can quickly sabotage naive notions of this idea.<b=
r></blockquote><div><br></div><div>Bitcoin-United relies on a notion of tra=
nsaction equivalence that doesn't involve the transaction hash at all, =
so it should be immune to malleability issues and compatible with segwit.=
=C2=A0</div><div><br></div><div>From the post, two transactions are equal i=
f they "consume the same inputs and result in the same outputs, not co=
unting the miner fee. Simple pay-to-pubkey-hash and pay-to-script-hash tran=
sactions are straightforward. Multikey transactions are evaluated for equiv=
alency by their inputs and outputs, so it is allowable for a 2-out-of-3 pay=
ment 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 th=
e same outputs. Not that we'll ever encounter such a case, but making t=
his point helps pedagogically with getting across the notion of transaction=
equivalence. What counts are the consumed inputs and the destination and a=
mounts of the outputs."</div><div><br></div><div>But you're right,=
if a naive implementation were to just use the transaction hash, the resul=
t would be a mess.</div><div><br></div><div>- egs</div><div><br></div><div>=
<br></div></div></div></div>
--001a113a4f80202a530528234e60--
|
