Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-24 📝 Original message:> > Yes, you can reorg out ...
📅 Original date posted:2014-04-24
📝 Original message:>
> Yes, you can reorg out the blocks and actually remove them, but I
>
understood that you were _not_ proposing that quite specifically. But
> instead proposed without reorging taking txouts that were previously
> assigned to one party and simply assigning them to others.
>
Well, my original thought was just to delete the coinbases. But then some
people don't like the idea of destroying money (equivalently, reducing the
system's resolution) so I proposed reallocating it instead. I'm not sure
which is better though. Deletion is closer to what the existing system
allows, for sure.
Would you feel differently if the consequence was UTXO deletion rather than
reallocation? I think the difference makes no impact to the goal of
discouraging double spending.
> ... proposing the mechanism be used to claw back mining income from a
> hardware vendor accused of violating its agreements on the amount of
> self mining / mining on customers hardware.
>
I think this would not be doable in practice, unless there was a way to
identify that a block was mined with pre-sold equipment. Peter points out
that the pool in question is marking their blocks by reusing addresses -
ditto for the double spending against dice sites - but that's a trivial
thing for them to fix. Then it'd be difficult (impossible?) for miners to
identify KnC blocks even if there was a strong majority consensus to delete
their coinbases.
The reason I think this particular change is doable is that it should be
possible to quite reliably identify blocks that are Finney attacking for
profit. That doesn't generalise to any policy though. Blocks are intended
to be structurally identical to each other if best practices are followed
and even with the dire pool situation a big chunk of mining hash power
today is effectively anonymous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/33b9083b/attachment.html>;
📝 Original message:>
> Yes, you can reorg out the blocks and actually remove them, but I
>
understood that you were _not_ proposing that quite specifically. But
> instead proposed without reorging taking txouts that were previously
> assigned to one party and simply assigning them to others.
>
Well, my original thought was just to delete the coinbases. But then some
people don't like the idea of destroying money (equivalently, reducing the
system's resolution) so I proposed reallocating it instead. I'm not sure
which is better though. Deletion is closer to what the existing system
allows, for sure.
Would you feel differently if the consequence was UTXO deletion rather than
reallocation? I think the difference makes no impact to the goal of
discouraging double spending.
> ... proposing the mechanism be used to claw back mining income from a
> hardware vendor accused of violating its agreements on the amount of
> self mining / mining on customers hardware.
>
I think this would not be doable in practice, unless there was a way to
identify that a block was mined with pre-sold equipment. Peter points out
that the pool in question is marking their blocks by reusing addresses -
ditto for the double spending against dice sites - but that's a trivial
thing for them to fix. Then it'd be difficult (impossible?) for miners to
identify KnC blocks even if there was a strong majority consensus to delete
their coinbases.
The reason I think this particular change is doable is that it should be
possible to quite reliably identify blocks that are Finney attacking for
profit. That doesn't generalise to any policy though. Blocks are intended
to be structurally identical to each other if best practices are followed
and even with the dire pool situation a big chunk of mining hash power
today is effectively anonymous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/33b9083b/attachment.html>;