From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Sig-Witness and legacy outputs
Date: Thu, 18 Feb 2016 16:14:19 +0000 [thread overview]
Message-ID: <CAE-z3OUT0vAzj03DjnjJuS_w-ntYLqV5Y-YuY9JuaQfz+ne-mQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1938 bytes --]
reply other threads:[~2016-02-18 16:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE-z3OUT0vAzj03DjnjJuS_w-ntYLqV5Y-YuY9JuaQfz+ne-mQ@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox