From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Date: Fri, 15 May 2015 11:45:05 +0100 [thread overview]
Message-ID: <CAE-z3OXwRArVnB13t+-S6EdxJkDx3EKbTN4dh2b-uJ05+6rqXw@mail.gmail.com> (raw)
In-Reply-To: <5555C26F.7080706@sky-ip.org>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
On Fri, May 15, 2015 at 10:54 AM, s7r <s7r@sky-ip•org> wrote:
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so mutations of the signature don't
cause the normalized txid to change.
If the refund transaction refers to the parent using the normalised txid,
then it doesn't matter if the parent has a mutated signature. The
normalized transaction ignores the mutation.
If the parent is mutated, then the refund doesn't even have to be modified,
it still refers to it.
If you want a multi-level refund transaction, then all refund transactions
must use the normalized txids to refer to their parents. The "root"
transaction is submitted to the blockchain and locked down.
> b) replays
>
If there are 2 transactions which are mutations of each other, then only
one can be added to the block chain, since the other is a double spend.
The normalized txid refers to all of them, rather than a specific
transaction.
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>
Mutation is only a problem if it occurs after signing. The signature signs
everything except the signature itself.
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays.
Correct, but normalized txids are safe against replays, so are better.
I think the new signature opcode fixes things too. The question is hard
fork but clean solution vs a soft fork but a little more hassle.
[-- Attachment #2: Type: text/html, Size: 2652 bytes --]
next prev parent reply other threads:[~2015-05-15 10:45 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
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 [this message]
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-z3OXwRArVnB13t+-S6EdxJkDx3EKbTN4dh2b-uJ05+6rqXw@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