📅 Original date posted:2017-04-03
📝 Original message:> On 3 Apr 2017, at 04:39, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> • the witness of the first input of the coinbase transaction MUST have exactly one stack item (the "extended header"), with the following data:
> • bytes 0 to 3: nHeight MUST be equal to the height of this block (signed little endian)
>
> Someone told me a while back that it would be more natural if we move the nHeight from the coinbase script to the coinbase locktime. Have you considered doing this?
Yes, it’d look much better. But I’m thinking of a different approach: instead of using a hash of 0000….0000, we use the hash of previous block for the coinbase input. With some new SIGHASH design, this allows people to pay to a child of a particular block. This is actually implemented in my spoonnet2 branch. I’ll describe it with a BIP soon
However, what I’m trying to do in the extended block header is independent to the design of coinbase tx. Here I’m trying to let people knowing the height just by a header and extended header (<300 bytes), without requiring all headers in the history.
Also I forgot to post the link of the BIP: https://github.com/jl2012/bips/blob/spoonnet/bip-extheader.mediawiki <https://github.com/jl2012/bips/blob/spoonnet/bip-extheader.mediawiki>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170403/7b6c9678/attachment.html>;
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 17:58:58
in reply to nevent1q…vf2f
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:58:58Event JSON
{
"id": "c93c61dc05b0228fe7be608a71112fea2c3eae48a205cddc43d25325b877fb60",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686160738,
"kind": 1,
"tags": [
[
"e",
"ed5438e960e3e46c3ecdd5abd50fbc20d36320b38962234d04c80268a7df621d",
"",
"root"
],
[
"e",
"179d581a27feddeb0c716761dcdaa13c65d0dd5076d3cce16cc17647e0763940",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2017-04-03\n📝 Original message:\u003e On 3 Apr 2017, at 04:39, Russell O'Connor \u003croconnor at blockstream.io\u003e wrote:\n\u003e \n\u003e On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e • the witness of the first input of the coinbase transaction MUST have exactly one stack item (the \"extended header\"), with the following data:\n\u003e • bytes 0 to 3: nHeight MUST be equal to the height of this block (signed little endian)\n\u003e \n\u003e Someone told me a while back that it would be more natural if we move the nHeight from the coinbase script to the coinbase locktime. Have you considered doing this?\n\n\nYes, it’d look much better. But I’m thinking of a different approach: instead of using a hash of 0000….0000, we use the hash of previous block for the coinbase input. With some new SIGHASH design, this allows people to pay to a child of a particular block. This is actually implemented in my spoonnet2 branch. I’ll describe it with a BIP soon\n\nHowever, what I’m trying to do in the extended block header is independent to the design of coinbase tx. Here I’m trying to let people knowing the height just by a header and extended header (\u003c300 bytes), without requiring all headers in the history.\n\nAlso I forgot to post the link of the BIP: https://github.com/jl2012/bips/blob/spoonnet/bip-extheader.mediawiki \u003chttps://github.com/jl2012/bips/blob/spoonnet/bip-extheader.mediawiki\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170403/7b6c9678/attachment.html\u003e",
"sig": "9c85f68cf1d3c0c3a968c37d381832a535814ea0d2c3be48d041fdc8b8509485e32013d0507562c9749378c7057540ac186f90a2074d978df0df91e1f4cd5aa5"
}