From: Christian Decker <decker.christian@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Date: Thu, 14 May 2015 11:01:56 +0000 [thread overview]
Message-ID: <CALxbBHV_2NHAvS5GXCsqBR0gO9zZe55kz52geMhG+8=EkKN2KA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes the prevout and calculates its normalized transaction ID. It
then inserts the normalized transaction IDs in the OutPoint before
calculating its own hash which is then signed. Is that correct so far?
Let me try to summarize the discussion so far:
I think we have consensus that transaction malleability needs to be
addressed, and normalized transaction IDs seem to be the way to go forward.
The discussion now is how to use normalized transaction IDs and we have two
approaches to implement them:
- OP_CHECKAWESOMESIG which continues to use the current hashes to
reference a specific signed instance of a class of semantically identical
transactions. Internally only the semantic class is enforced. Transactions
can be fixed to reference the correct signed instance if the transaction
has been changed along the way.is a softfork using the "if I don't know
this opcode the TX is automatically valid" trick
On Thu, May 14, 2015 at 2:40 AM Pieter Wuille <pieter.wuille@gmail•com>
wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4676 bytes --]
next prev parent reply other threads:[~2015-05-14 11:02 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 [this message]
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='CALxbBHV_2NHAvS5GXCsqBR0gO9zZe55kz52geMhG+8=EkKN2KA@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=tier.nolan@gmail$(echo .)com \
/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