From: Ruben Somsen <rsomsen@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PoW fraud proofs without a soft fork
Date: Wed, 11 Sep 2019 06:58:57 +0200 [thread overview]
Message-ID: <CAPv7TjaMm5q8Q-AXbVcjx5RoKt-5y7t4Fx+CMhJ=cabLysc9=w@mail.gmail.com> (raw)
In-Reply-To: <y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com>
Hi ZmnSCPxj,
>I suppose the critical difference is that invalid inflation can fool the SPV node, the fullnode will not be so fooled.
That is correct. If you sybil the SPV node, you can break any
consensus rule you like. I believe this is inherent to fraud proofs in
general, because you skip consensus checks unless you're able to
receive a fraud proof.
But note that my goal in the comparison was to assert that there is no
security difference between committing or not committing the utreexo
hash into a block. The attack your describe works in either situation,
so my conclusion remains that committing the hash adds no security.
Other weaknesses compared to full nodes are:
- the SPV nodes rely on the existence of a healthy network of utreexo
supporting full nodes
- at least one honest block needs to be mined
- consensus slows down, because you need to allow time for an honest
minority to produce a block
Cheers,
Ruben
On Mon, Sep 9, 2019 at 8:58 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Ruben,
>
> Yes, I suppose that is correct.
>
> I suppose the critical difference is that invalid inflation can fool the SPV node, the fullnode will not be so fooled.
>
> A somewhat larger-scale attack is to force a miner-supported miner-subsidy-increase / blocksize-increase hard fork.
> If enough such SPV nodes can be sybilled, they can be forced to use the hard fork, which might incentivize them to support the hard fork rather than back-compatible consensus chain.
>
> Regards,
> ZmnSCPxj
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your comments. You raise an important point that I should clarify.
> >
> > > 1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.
> >
> > You can still attack the full node by feeding it a minority PoW chain,
> > then it won't stall.
> >
> > > 2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.
> >
> > Correct, but this false blockchain does need to have valid PoW.
> >
> > So in both cases valid PoW is required to fool nodes. The one
> > difference is that for a full node, the blocks themselves also need to
> > be valid (except for the fact that they are in a minority chain), but
> > the end result is still that a victim can be successfully double spent
> > and lose money.
> >
> > I hope this clarifies why I consider the security for these two
> > situations to be roughly equivalent. In either situation, victims can
> > be fooled into accepting invalid payments.
> >
> > Cheers,
> > Ruben
> >
> > On Mon, Sep 9, 2019 at 6:14 AM ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> >
> > > Good morning Ruben,
> > >
> > > > One might intuitively feel that the lack of a commitment is unsafe,
> > > > but there seems to be no impact on security (only bandwidth). The only
> > > > way you can be fooled is if all peers lie to you (Sybil), causing you
> > > > to follow a malicious minority chain. But even full nodes (or the
> > > > committed version of PoW fraud proofs) can be fooled in this way if
> > > > they are denied access to the valid most PoW chain. If there are
> > > > additional security concerns I overlooked, I’d love to hear them.
> > > >
> > >
> > > I think it would be better to more precisely say that:
> > >
> > > 1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.
> > > 2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.
> > >
> > > This has some differences when considering automated systems.
> > > Onchain automated payment processing systems, which use a fullnode, will refuse to acknowledge any incoming payments.
> > > This will lead to noisy complaints from clients of the automated payment processor, but this is a good thing since it warns the automated payment processor of the possibility of this attack occurring on them.
> > > The use of a timeout wherein if the fullnode is unable to see a new block for, say, 6 hours, could be done, to warn higher-layer management systems to pay attention.
> > > While it is sometimes the case that the real network will be unable to find a new block for hours at a time, this warning can be used to confirm if such an event is occurring, rather than a sybil attack targeting that fullnode.
> > > On the other hand, such a payment processing system, which uses an SPV with PoW fraud proofs, will be able to at least see incoming payments, and continue to release product in exchange for payment.
> > > Yet this is precisely a point of attack, where the automated payment processing system is sybilled and then false payments are given to the payment processor on the attack chain, which are double-spent on the global consensus chain.
> > > And the automated system may very well not be able to notice this.
> > > Regards,
> > > ZmnSCPxj
>
>
next prev parent reply other threads:[~2019-09-11 4:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-08 3:39 [bitcoin-dev] PoW fraud proofs without a soft fork Ruben Somsen
2019-09-09 4:14 ` ZmnSCPxj
2019-09-09 4:47 ` Dragi Bucukovski
2019-09-09 6:53 ` Ruben Somsen
2019-09-09 6:58 ` ZmnSCPxj
2019-09-11 4:58 ` Ruben Somsen [this message]
2019-09-16 16:48 ` David A. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPv7TjaMm5q8Q-AXbVcjx5RoKt-5y7t4Fx+CMhJ=cabLysc9=w@mail.gmail.com' \
--to=rsomsen@gmail.com \
--cc=ZmnSCPxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox