From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Date: Wed, 13 May 2015 21:27:14 +0100 [thread overview]
Message-ID: <CAE-z3OU-fdTrKRkni4xmmY5uBVWS0KJ_2NVh6k1tcMSGTPp+4Q@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OV1WEDEV+X7gNVx+qBMt4jpSHFKXm3dxUrUyBEJrCNDSQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning. All txids in the entire blockchain should be replaced with the
"correct" values.
This requires a full re-index of the blockchain. You can't work out what
the TXID-N of a transaction is without knowning the TXID-N of its parents,
in order to do the replacement.
The non-recursive version can only handle refunds one level deep.
A:
from: IN
sigA: based on hash(...)
B:
from A
sig: based on hash(from: TXID-N(A) | "") // sig removed
C:
from B
sig: based on hash(from: TXID-N(B) | "") // sig removed
If A is mutated before being added into the chain, then B can be modified
to a valid transaction (B-new).
A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation
B has to be modified to B-new to make it valid.
B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")
Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.
Howver, C-new cannot be created.
C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")
TXID-N(B-new) is not the same as TXID-N(B). Since the from field is not
removed by the TXID-N operation, differences in that field mean that the
TXIDs are difference.
This means that the signature for C is not valid for C-new.
The recursive version repairs this problem.
Rather than simply delete the scriptSig from the transaction. All txids
must also be replaced with their TXID-N versions.
Again, A is mutated before being added into the chain and B-new is produced.
A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation
TXID-N: TXID-N(A)
B has to be modified to B-new to make it valid.
B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")
TXID-N: TXID-N(B)
Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.
Likewise the TXID-N(B-new) is equal to TXID-N(B).
The from field is replaced by the TXID-N from A-mutated which is equal to
TXID-N(A) and the sig is the same.
C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")
The signature is still valid, since TXID-N(B-new) is the same as TXID-N(B).
This means that multi-level refunds are possible.
[-- Attachment #2: Type: text/html, Size: 2717 bytes --]
next prev parent reply other threads:[~2015-05-13 20:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 12:48 Christian Decker
2015-05-13 13:12 ` Tier Nolan
2015-05-13 13:41 ` Gavin Andresen
2015-05-13 15:24 ` Christian Decker
2015-05-13 16:18 ` Tier Nolan
2015-05-13 16:34 ` Luke Dashjr
2015-05-13 17:14 ` Pieter Wuille
2015-05-13 18:04 ` Christian Decker
2015-05-13 18:40 ` Pieter Wuille
2015-05-13 19:14 ` Christian Decker
2015-05-13 19:40 ` Pieter Wuille
2015-05-13 18:11 ` Tier Nolan
2015-05-13 20:27 ` Tier Nolan [this message]
2015-05-13 20:31 ` Pieter Wuille
2015-05-13 20:32 ` Tier Nolan
2015-05-14 0:37 ` Pieter Wuille
2015-05-14 11:01 ` Christian Decker
2015-05-14 11:26 ` Christian Decker
2015-05-15 9:54 ` s7r
2015-05-15 10:45 ` Tier Nolan
2015-05-15 16:31 ` Luke Dashjr
2015-05-16 3:58 ` Stephen
2015-05-16 10:52 ` Tier Nolan
2015-05-19 8:28 ` Christian Decker
2015-05-19 9:13 ` Tier Nolan
2015-05-19 10:43 ` Christian Decker
2015-05-19 12:48 ` Stephen Morse
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-z3OU-fdTrKRkni4xmmY5uBVWS0KJ_2NVh6k1tcMSGTPp+4Q@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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