public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: 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 17:37:30 -0700	[thread overview]
Message-ID: <CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OU7nCJSGk-Mx_2gmpUjQ1gXeSNDiWfhPe-5rj5bG5ArWQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

>
> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>>
>> This was what I was suggesting all along, sorry if I wasn't clear.
>>
>> That's great.  So, basically the multi-level refund problem is solved by
> this?
>

Yes. So to be clear, I think there are 2 desirable end-goal proposals
(ignoring difficulty of changing things for a minute):

* Transactions and blocks keep referring to other transactions by full
txid, but signature hashes are computed off normalized txids (which are
recursively defined to use normalized txids all the way back to coinbases).
Is this what you are suggesting now as well?

* Blocks commit to full transaction data, but transactions and signature
hashes use normalized txids.

The benefit of the latter solution is that it doesn't need "fixing up"
transactions whose inputs have been malleated, but comes at the cost of
doing a very invasive hard fork.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1902 bytes --]

  reply	other threads:[~2015-05-14  0:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 12:48 [Bitcoin-development] [BIP] Normalized Transaction IDs 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 [this message]
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=CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=tier.nolan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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