Christopher Gilliard [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-16 📝 Original message:>>Maybe I missed ...
📅 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>;
📝 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>;