From: Christian Decker <decker.christian@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Date: Tue, 19 May 2015 10:43:39 +0000 [thread overview]
Message-ID: <CALxbBHUvtoc25Eyh1KF=bmG8SbZd_UpO1QeUVLbicNqJQPHBLQ@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OXC-uCYQmhGJd2ZVfLrEbAZVhEz0ejkbwmcRgK3kbjSrg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]
On Tue, May 19, 2015 at 11:16 AM Tier Nolan <tier.nolan@gmail•com> wrote:
> On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
> decker.christian@gmail•com> wrote:
>
>> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
>> in both proposals. If we can avoid it I'd like not to have one
>> transaction hashed one way and other transactions in another way.
>>
>
> The normalized TXID cannot depend on height for other transactions.
> Otherwise, it gets mutated when been added to the chain, depending on
> height.
>
Well in the case of coinbase transactions we want them to be dependent on
the height they are included in, which is not a problem since they are only
valid in conjunction with the block that mined them.
>
> An option would be that the height is included in the scriptSig for all
> transactions, but for non-coinbase transctions, the height used is zero.
>
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in coinbase transactions (and only coinbase transactions) is copied into
the locktime of the transaction before computing the normalized transaction
ID and leave the locktime untouched for all normal transactions
>
> I think if height has to be an input into the normalized txid function,
> the specifics of inclusion don't matter.
>
> The previous txid for coinbases are required to be all zeros, so the
> normalized txid could be to add the height to the txids of all inputs.
> Again, non-coinbase transactions would have heights of zero.
>
>
>> Is there a specific reason why that was not chosen at the time?
>>
>
> I assumed that since the scriptSig in the coinbase is specifically
> intended to be "random" bytes/extra nonce, so putting a restriction on it
> was guaranteed to be backward compatible.
>
Sounds reasonable :-)
>
>
> ------------------------------------------------------------------------------
> 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: 4712 bytes --]
next prev parent reply other threads:[~2015-05-19 10:43 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
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 [this message]
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='CALxbBHUvtoc25Eyh1KF=bmG8SbZd_UpO1QeUVLbicNqJQPHBLQ@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--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