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:51:22PM +0200, Mike Hearn wrote:
> >
> > Ok, so again, if that's your security criteria, what's the issue
> > with soft-forks?
>
>
> Please read my article as it's all explained there.
I have read your article. In fact we reviewed it at a NY BitDevs meetup
that I attended.
> But to reiterate: the risk is that miners will build invalid blocks on top
> of the best work chain, instead of an ignored lower work side chain. This
> opens users to payment fraud. With a hard fork, all the blocks by miners
> that aren't checking all the rules anymore get neatly collected together on
> a side chain after the split, and wallets all know how to ignore that chain.
Can you explain exactly how you think wallets will "know" how to ignore
the invalid chain?
With an advertised soft-fork, e.g. the IsSuperMajority() mechanism,
ignoring the invalid chain is easy: use nVersion to detect invalid
blocks when you know what soft-forks are coming up, and if presented
with an unknown - but advertised - soft-fork at minimum loudly warn the
user. In the case of a hard-fork identical logic can be used. (BIP101
being an example of a hard-fork triggered in a way that can be detected
by SPV clients, both explicitly (BIP101 specific) and implicitly
(general unknown block nVersion warnings))
> Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
> create invalid blocks, as long as they're running Core past that version.
> But this makes the IsStandard function very much like a part of the
> consensus rules, as bypassing it can result in invalid blocks being
> created.
How so? Miners can always choose to create invalid blocks, thus
attacking SPV wallets; my statement with regard to pull-req #5000 comes
from a risk-based approach, knowing that every invalid block is
expensive and the new concern created by a soft-fork is whether or not
miners will create them accidentally; miners can always create invalid
blocks delibrately.
> Miners have always understood that they can modify this function,
> or even bypass it entirely, without affecting the validity of their blocks.
> And some miners do exactly that.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
blocks in the event of a soft-fork. Equally, we design soft-forks to
take advantage of this.
> So I'll repeat the question that I posed before - given that there are
> clear, explicit downsides, what is the purpose of doing things this way?
> Where is the gain for ordinary Bitcoin users?
We seem to be in strong disagreement about which option has "clear,
explicit downsides"
--
'peter'[:-1]@petertodd.org
0000000000000000006f2abe95e361b73289e4a79ba3124801896f6b7dc8d977
-------------- 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/36509171/attachment.sig>;
š Original message:On Mon, Sep 28, 2015 at 04:51:22PM +0200, Mike Hearn wrote:
> >
> > Ok, so again, if that's your security criteria, what's the issue
> > with soft-forks?
>
>
> Please read my article as it's all explained there.
I have read your article. In fact we reviewed it at a NY BitDevs meetup
that I attended.
> But to reiterate: the risk is that miners will build invalid blocks on top
> of the best work chain, instead of an ignored lower work side chain. This
> opens users to payment fraud. With a hard fork, all the blocks by miners
> that aren't checking all the rules anymore get neatly collected together on
> a side chain after the split, and wallets all know how to ignore that chain.
Can you explain exactly how you think wallets will "know" how to ignore
the invalid chain?
With an advertised soft-fork, e.g. the IsSuperMajority() mechanism,
ignoring the invalid chain is easy: use nVersion to detect invalid
blocks when you know what soft-forks are coming up, and if presented
with an unknown - but advertised - soft-fork at minimum loudly warn the
user. In the case of a hard-fork identical logic can be used. (BIP101
being an example of a hard-fork triggered in a way that can be detected
by SPV clients, both explicitly (BIP101 specific) and implicitly
(general unknown block nVersion warnings))
> Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
> create invalid blocks, as long as they're running Core past that version.
> But this makes the IsStandard function very much like a part of the
> consensus rules, as bypassing it can result in invalid blocks being
> created.
How so? Miners can always choose to create invalid blocks, thus
attacking SPV wallets; my statement with regard to pull-req #5000 comes
from a risk-based approach, knowing that every invalid block is
expensive and the new concern created by a soft-fork is whether or not
miners will create them accidentally; miners can always create invalid
blocks delibrately.
> Miners have always understood that they can modify this function,
> or even bypass it entirely, without affecting the validity of their blocks.
> And some miners do exactly that.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
blocks in the event of a soft-fork. Equally, we design soft-forks to
take advantage of this.
> So I'll repeat the question that I posed before - given that there are
> clear, explicit downsides, what is the purpose of doing things this way?
> Where is the gain for ordinary Bitcoin users?
We seem to be in strong disagreement about which option has "clear,
explicit downsides"
--
'peter'[:-1]@petertodd.org
0000000000000000006f2abe95e361b73289e4a79ba3124801896f6b7dc8d977
-------------- 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/36509171/attachment.sig>;