Peter Todd [ARCHIVE] on Nostr: š Original date posted:2014-04-24 š Original message:On Thu, Apr 24, 2014 at ...
š
Original date posted:2014-04-24
š Original message:On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:
> > ... 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.
Like I said before, that leads to the obvious next step of
deleting/stealing their coinbases if they don't identify themselves.
Another likely outcome would be for coinbase blacklisting to be used as
a way to force a minority of miners to adopt a transaction blacklist
that the majority of miners had adopted. Any block containing
transactions spending coins on the txout blacklist would itself be
punished by having the block reward either blacklisted or taken.
> 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.
It's not possible to produce a cryptographic proof that a given block
engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation
mechanism is simply a way of voting on what coinbases to either
blacklist or reallocation, nothing more.
--
'peter'[:-1]@petertodd.org
00000000000000003d5f2a2a68690093cd99f8af1bc8395061251017019cc30a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/082da52b/attachment.sig>;
š Original message:On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:
> > ... 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.
Like I said before, that leads to the obvious next step of
deleting/stealing their coinbases if they don't identify themselves.
Another likely outcome would be for coinbase blacklisting to be used as
a way to force a minority of miners to adopt a transaction blacklist
that the majority of miners had adopted. Any block containing
transactions spending coins on the txout blacklist would itself be
punished by having the block reward either blacklisted or taken.
> 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.
It's not possible to produce a cryptographic proof that a given block
engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation
mechanism is simply a way of voting on what coinbases to either
blacklist or reallocation, nothing more.
--
'peter'[:-1]@petertodd.org
00000000000000003d5f2a2a68690093cd99f8af1bc8395061251017019cc30a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/082da52b/attachment.sig>;