Mike Brooks [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-01 📝 Original message:Hey ZmnSCPxj, Re-orgs ...

📅 Original date posted:2020-08-01
📝 Original message:Hey ZmnSCPxj,

Re-orgs should be solved in a different way.

Best Regards,
Micahel

On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Mike,
>
> Hard NAK.
>
> The responses to the original posting already pointed out important
> problems with this:
>
> * Encourages address reuse, hurting fungibility and privacy.
> * Prevents pruning, since access to previous blocks must always be
> available in order to validate.
> * Optimized implementation requires creating yet another index to previous
> block data, increasing requirements on fullnodes.
> * Requires SCRIPT to be re-evaluated on transactions arriving in
> newblocks, to protect against reorgs of the chaintip, and in particular
> `OP_PUBREF` references to near the chaintip.
>
> None of these issues have been addressed in your current proposal.
> The proposal looks at clients only, without considering what validators
> have to implement in order to validate new blocks with this opcode.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200801/39c1cb94/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Floating-Point Nakamoto Consensus.pdf
Type: application/pdf
Size: 70769 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200801/39c1cb94/attachment-0001.pdf>;