MIME-Version: 1.0
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
Subject: [bitcoin-dev] Sig-Witness and legacy outputs
Precedence: list

--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&#39;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--