Hey ZmnSCPxj,
Re-orgs should be solved in a different way.
Best Regards,
Micahel
On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj 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
>
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
