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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EBE5411C2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Feb 2016 16:14:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DCAC170
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Feb 2016 16:14:20 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id g203so78699306iof.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Feb 2016 08:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=biXnCbBKB864dXoHpwOkUKwgL40K3695yfacNGCfjDg=;
b=xIEeudlzLgEFgmw4omeFYXzfPDHtKl0SzsLSrQTiMSCoyMLJ+z7njjXU27kD9ZWrv5
c1IrcKhpyc4KXA8P4CAUOfUVZsTJEDvPZ9ATWJv6rNZqd0LI9S99qRq/9TwRYJ1pUJDB
An4P+dtYLGNtBCEKMgAMIg5m/J3VPDI5UnPo/jZvfQW4gcYv1ulECMjqIcNuEvt1rWUb
hLxJh1MXHMVIwtJ1ZMrYwDY1lIB+43/9J/q6QGcIRqJZa60eqOBsrxP1MDLolgfTBQHd
FywzttREiYJRbBuAWHznFDA6bin/j1EZLUlKSung0/phgJqYb3AZj5kkfTq2Hu2/qmOi
gpow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=biXnCbBKB864dXoHpwOkUKwgL40K3695yfacNGCfjDg=;
b=JiVsZFk+VMqNazDV56t4qKeaOW+oA+FTpTFetTCY7J26fYOXErbELc95w7rAtofJJZ
wl5eisDjWuQaMz71ppPL8jbcV6J4F9qN5X6pvxMES3IXLRLZAO8sEW6iQkH2B/rB9v4l
h7Xm0de6AdgJCxfQ427qaoZ3PxxtOFfDQ0NYhMsQX5fK4RCsnx0c3brj8NhjKBD54Ijh
x/TV1c8lxnK6IyrLryMSb7OQTBxsuH7fsHGjIooTkxYA11qw4ffTW6N8mqBuNN9uJALg
aZ8ElW8GfYj0QWTwd0i/zutdMpLVK/FbhXjrV8mDd4TM8ScUXW325t3sIeOmDBOUIZ3I
opqg==
X-Gm-Message-State: AG10YOS0WJfreKrAld32zwjZxKgG8zN7SnJIZQlpGp38u2ks1hIHwqbidnBPh2Vrr1t9qEuKIP+mHb/nQlJ04A==
MIME-Version: 1.0
X-Received: by 10.107.155.206 with SMTP id d197mr9261787ioe.135.1455812059536;
Thu, 18 Feb 2016 08:14:19 -0800 (PST)
Received: by 10.79.77.65 with HTTP; Thu, 18 Feb 2016 08:14:19 -0800 (PST)
Date: Thu, 18 Feb 2016 16:14:19 +0000
Message-ID: <CAE-z3OUT0vAzj03DjnjJuS_w-ntYLqV5Y-YuY9JuaQfz+ne-mQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11402a9eab2a2e052c0da8b3
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
Subject: [bitcoin-dev] Sig-Witness and legacy outputs
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: Thu, 18 Feb 2016 16:14:22 -0000
--001a11402a9eab2a2e052c0da8b3
Content-Type: text/plain; charset=UTF-8
I wrote a bip last year about extended transaction information. The idea
was to include the scriptPubKey that was being spent along with
transactions.
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki
This makes it easier possible to verify the transactions locally. An
extended transaction would contain the current transaction and also the
CTxOuts that are being spent.
For each entry in the UTXO set, a node could store
UTXO_hash = hash(txid_parent | n | CTxOut)
Witness transactions will do something similar. I wonder if it would be
possible to include the CTxOut for each input that isn't a segregated
witness output, as part of the witness data. Even for witness data, it
would be good to commit to the value of the output as part of the witness.
There was a suggestion at one of the conferences to have the witness data
include info about the block height/index of the output that each input is
spending.
The effect of this change is that nodes would only have to store the
UTXO_hashes for each UTXO value in the database. This would make it much
more efficient.
It would also make it easier to create a simple consensus library. You
give the library the transaction and the witness and it returns the
UTXO_hashes that are spent, the UTXO_hashes that are created, the fee,
sigops and anything that needs to be summed.
Validating a block would mostly (famous last words) mean validating the
transactions in the block and then adding up the totals.
The advantage of including the info with the transactions is that it saves
each node having to include a lookup table to find the data.
--001a11402a9eab2a2e052c0da8b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>I wrote a bip last year abou=
t extended transaction information.=C2=A0 The idea was to include the scrip=
tPubKey that was being spent along with transactions.<br><br><a href=3D"htt=
ps://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki=
">https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.medi=
awiki</a><br><br></div>This makes it easier possible to verify the transact=
ions locally.=C2=A0 An extended transaction would contain the current trans=
action and also the CTxOuts that are being spent.<br><br></div>For each ent=
ry in the UTXO set, a node could store<br><br></div>UTXO_hash =3D hash(txid=
_parent | n | CTxOut)<br><br></div>Witness transactions will do something s=
imilar.=C2=A0 I wonder if it would be possible to include the CTxOut for ea=
ch input that isn't a segregated witness output, as part of the witness=
data.=C2=A0 Even for witness data, it would be good to commit to the value=
of the output as part of the witness.=C2=A0 <br><br>There was a suggestion=
at one of the conferences to have the witness data include info about the =
block height/index of the output that each input is spending.<br><br></div>=
<div>The effect of this change is that nodes would only have to store the U=
TXO_hashes for each UTXO value in the database.=C2=A0 This would make it mu=
ch more efficient.<br><br></div><div>It would also make it easier to create=
a simple consensus library.=C2=A0 You give the library the transaction and=
the witness and it returns the UTXO_hashes that are spent, the UTXO_hashes=
that are created, the fee, sigops and anything that needs to be summed.<br=
><br></div><div>Validating a block would mostly (famous last words) mean va=
lidating the transactions in the block and then adding up the totals.<br><b=
r></div><div>The advantage of including the info with the transactions is t=
hat it saves each node having to include a lookup table to find the data.<b=
r></div></div></div>
--001a11402a9eab2a2e052c0da8b3--
|
