📅 Original date posted:2021-04-16
📝 Original message:>>Maybe I missed something, but why does this change require a hard fork?
I guess you are right that it doesn't technically require a hard fork, but
I see this proposal as more likely being merged with other hard fork or
soft fork features. It depends on which upgrades are happening at the time.
If there's a specific soft fork being proposed to merge this proposal with,
I can update it.
>> I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.
This will be discussed further in a future BIP, but the basic idea is that
each miner can run an additional piece of software that builds the tree
structure. It's much like submitting a transaction to the network today, if
one of the miners does not accept it, another likely will.
>> Some of those OP_RETURN outputs have non-zero value. As such, those
outputs are provably unspendable, and they are essentially paying the rest
of the coin holders via supply deflation.
Good point, there are other ways to do proof of burn.
>> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.
Yes, but that doesn't affect IBD.
On Fri, Apr 16, 2021 at 1:59 PM Clark Moody <clark at clarkmoody.com> wrote:
> Maybe I missed something, but why does this change require a hard fork?
>
> You don't seem to provide any data as part of your rationale, so I'll
> provide some context. As it stands, the chain size sits around 386 GB, with
> OP_RETURN data accounting for 2.5 GB of that.
>
> I'm also concerned about the coordination required to get into The One
> OP_RETURN Per Block, as this certainly requires some measure of
> centralization of that Merkle Tree construction.
>
> Some of those OP_RETURN outputs have non-zero value. As such, those
> outputs are provably unspendable, and they are essentially paying the rest
> of the coin holders via supply deflation.
>
> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
> since they are unspendable. Thus, nodes can clear a few GB of disk space
> whenever they need it, but that data is less than 1% of the total chain
> size at the time of writing.
>
>
> -Clark
>
>
> On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/0bb514ec/attachment-0001.html>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 22:51:45
in reply to nevent1q…zwjc
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntSeen on
wss://relay.nostr.bandPublished at
2023-06-07 22:51:45Event JSON
{
"id": "cca4d699e2306bd9ed5c10f2ceb79fd7b2f5242440dbce40338ab6c180afe772",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686178305,
"kind": 1,
"tags": [
[
"e",
"603f39678bcc9e8e30f94bfe6386763f2e249a0ec7bc1f247dad6d882215065d",
"",
"root"
],
[
"e",
"a032cf122b164703b60c578a2cadbd0a1dfb9d30533f056e8f8d6efd3edeac4f",
"",
"reply"
],
[
"p",
"98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc"
]
],
"content": "📅 Original date posted:2021-04-16\n📝 Original message:\u003e\u003eMaybe I missed something, but why does this change require a hard fork?\n\nI guess you are right that it doesn't technically require a hard fork, but\nI see this proposal as more likely being merged with other hard fork or\nsoft fork features. It depends on which upgrades are happening at the time.\nIf there's a specific soft fork being proposed to merge this proposal with,\nI can update it.\n\n\u003e\u003e I'm also concerned about the coordination required to get into The One\nOP_RETURN Per Block, as this certainly requires some measure of\ncentralization of that Merkle Tree construction.\n\nThis will be discussed further in a future BIP, but the basic idea is that\neach miner can run an additional piece of software that builds the tree\nstructure. It's much like submitting a transaction to the network today, if\none of the miners does not accept it, another likely will.\n\n\u003e\u003e Some of those OP_RETURN outputs have non-zero value. As such, those\noutputs are provably unspendable, and they are essentially paying the rest\nof the coin holders via supply deflation.\n\nGood point, there are other ways to do proof of burn.\n\n\u003e\u003e Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,\nsince they are unspendable. Thus, nodes can clear a few GB of disk space\nwhenever they need it, but that data is less than 1% of the total chain\nsize at the time of writing.\n\nYes, but that doesn't affect IBD.\n\nOn Fri, Apr 16, 2021 at 1:59 PM Clark Moody \u003cclark at clarkmoody.com\u003e wrote:\n\n\u003e Maybe I missed something, but why does this change require a hard fork?\n\u003e\n\u003e You don't seem to provide any data as part of your rationale, so I'll\n\u003e provide some context. As it stands, the chain size sits around 386 GB, with\n\u003e OP_RETURN data accounting for 2.5 GB of that.\n\u003e\n\u003e I'm also concerned about the coordination required to get into The One\n\u003e OP_RETURN Per Block, as this certainly requires some measure of\n\u003e centralization of that Merkle Tree construction.\n\u003e\n\u003e Some of those OP_RETURN outputs have non-zero value. As such, those\n\u003e outputs are provably unspendable, and they are essentially paying the rest\n\u003e of the coin holders via supply deflation.\n\u003e\n\u003e Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,\n\u003e since they are unspendable. Thus, nodes can clear a few GB of disk space\n\u003e whenever they need it, but that data is less than 1% of the total chain\n\u003e size at the time of writing.\n\u003e\n\u003e\n\u003e -Clark\n\u003e\n\u003e\n\u003e On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I have created a BIP which can be found here:\n\u003e\u003e https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki\n\u003e\u003e\n\u003e\u003e I'm sending this email to start the discussion regarding this proposal.\n\u003e\u003e If there are any comments/suggestions, please let me know.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e Chris\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/0bb514ec/attachment-0001.html\u003e",
"sig": "96d0118cf9a386d71b8a27311032f5dc5b70eb5eaf3dad28cfb82b83b29a9da30f012045a1a9c1c49c0cef0ba4d6a13db88c03749c184242115b26c365da52ad"
}