📅 Original date posted:2015-05-19
📝 Original message:On Tue, May 19, 2015 at 11:16 AM Tier Nolan <tier.nolan at gmail.com> wrote:
> On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
> decker.christian at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/ffe7ffe5/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 15:35:16
in reply to nevent1q…0y5n
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 15:35:16Event JSON
{
"id": "28db8d91344d1985447e92bbf72b9e03bebb367d1633190c8a5fe14cdf7fce87",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686152116,
"kind": 1,
"tags": [
[
"e",
"d4296383f49c1a9f727ee325cad107826210d0f0a44bfb48a025773c99b7560e",
"",
"root"
],
[
"e",
"5d2f59c2afe65ec3059e868bde45ad27f0e903ac5378bad0b83145f3d4634354",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-05-19\n📝 Original message:On Tue, May 19, 2015 at 11:16 AM Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\n\u003e On Tue, May 19, 2015 at 9:28 AM, Christian Decker \u003c\n\u003e decker.christian at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Thanks Stephen, I hadn't thought about BIP 34 and we need to address this\n\u003e\u003e in both proposals. If we can avoid it I'd like not to have one\n\u003e\u003e transaction hashed one way and other transactions in another way.\n\u003e\u003e\n\u003e\n\u003e The normalized TXID cannot depend on height for other transactions.\n\u003e Otherwise, it gets mutated when been added to the chain, depending on\n\u003e height.\n\u003e\nWell in the case of coinbase transactions we want them to be dependent on\nthe height they are included in, which is not a problem since they are only\nvalid in conjunction with the block that mined them.\n\n\u003e\n\u003e An option would be that the height is included in the scriptSig for all\n\u003e transactions, but for non-coinbase transctions, the height used is zero.\n\u003e\nNo need to add an extra field to the transaction just to include the\nheight. We can just add a rule that the height specified in the scriptSig\nin coinbase transactions (and only coinbase transactions) is copied into\nthe locktime of the transaction before computing the normalized transaction\nID and leave the locktime untouched for all normal transactions\n\n\u003e\n\u003e I think if height has to be an input into the normalized txid function,\n\u003e the specifics of inclusion don't matter.\n\u003e\n\u003e The previous txid for coinbases are required to be all zeros, so the\n\u003e normalized txid could be to add the height to the txids of all inputs.\n\u003e Again, non-coinbase transactions would have heights of zero.\n\u003e\n\u003e\n\u003e\u003e Is there a specific reason why that was not chosen at the time?\n\u003e\u003e\n\u003e\n\u003e I assumed that since the scriptSig in the coinbase is specifically\n\u003e intended to be \"random\" bytes/extra nonce, so putting a restriction on it\n\u003e was guaranteed to be backward compatible.\n\u003e\nSounds reasonable :-)\n\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/ffe7ffe5/attachment.html\u003e",
"sig": "b36c3706e926a0f7185a9768b2facbb5ca635ee913e10034daf1b0311d833cdca095a5062749f08c18d79df13b82d7bb03bb64bdf21a5555ca01e00b37b0df9d"
}