Hey  ZmnSCPxj,

Re-orgs should be solved in a different way.

Best Regards,
Micahel

On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj <zmnsc...@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
>

Attachment: Floating-Point Nakamoto Consensus.pdf
Description: Adobe PDF document

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to