Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-28 📝 Original message:On Mon, Sep 28, 2015 at ...
📅 Original date posted:2015-09-28
📝 Original message:On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote:
> >
> > SPV wallets can't detect hard-forks
>
>
> They don't have to - they pick the highest work chain. Any miner who hasn't
> upgraded makes blocks on the shorter chain that are then ignored (or
> rather, stored for future reorgs). After the fork point, there won't be any
> blocks in the main chain that violate the rules and end up being doomed to
> being orphaned, which is the underlying problem.
>
> And I think you know this already. There is no "flaw" in bitcoinj in this
> respect. It works exactly as it was designed to work.
Ok, so again, if that's your security criteria, what's the issue with
soft-forks? With soft-forks, the result of a SPV wallet following the
highest work chain is the same: eventually invalid blocks are reorged
out.
However, because soft-forks make it less likely that a long invalid
chain will be generated, an attacker sybil attacking your SPV wallet has
a much harder time tricking it into accepting a transaction. (they might
get one or two confirmations, rather than dozens)
What's the scenario where soft-forks are worse than hard-forks from a
SPV wallet's perspective?
--
'peter'[:-1]@petertodd.org
00000000000000000368227ec1de9c27c14d23cb7be9e9f38c0082db79a87c49
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2e7816df/attachment.sig>;
📝 Original message:On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote:
> >
> > SPV wallets can't detect hard-forks
>
>
> They don't have to - they pick the highest work chain. Any miner who hasn't
> upgraded makes blocks on the shorter chain that are then ignored (or
> rather, stored for future reorgs). After the fork point, there won't be any
> blocks in the main chain that violate the rules and end up being doomed to
> being orphaned, which is the underlying problem.
>
> And I think you know this already. There is no "flaw" in bitcoinj in this
> respect. It works exactly as it was designed to work.
Ok, so again, if that's your security criteria, what's the issue with
soft-forks? With soft-forks, the result of a SPV wallet following the
highest work chain is the same: eventually invalid blocks are reorged
out.
However, because soft-forks make it less likely that a long invalid
chain will be generated, an attacker sybil attacking your SPV wallet has
a much harder time tricking it into accepting a transaction. (they might
get one or two confirmations, rather than dozens)
What's the scenario where soft-forks are worse than hard-forks from a
SPV wallet's perspective?
--
'peter'[:-1]@petertodd.org
00000000000000000368227ec1de9c27c14d23cb7be9e9f38c0082db79a87c49
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2e7816df/attachment.sig>;