What is Nostr?
Clark Moody [ARCHIVE] /
npub1nr0…hypj
2023-06-07 22:51:44
in reply to nevent1q…84lu

Clark Moody [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-16 📝 Original message:Maybe I missed something, ...

📅 Original date posted:2021-04-16
📝 Original message: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/7954d8e1/attachment.html>;
Author Public Key
npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypj