public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ethan Heilman <eth3rs@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Date: Fri, 19 Apr 2019 04:48:23 +0000	[thread overview]
Message-ID: <SHsLdVIPZcn9yyZN9Hx3moQmWXY-2yC99tEsFllksV-66ZrJNMQfDr0qHK_rCZuBcEa8gIcnThkvgRDkU6BYQ_mxX7JxfI_uM6ndOF26ofk=@protonmail.com> (raw)
In-Reply-To: <CAEM=y+V0tMYBBLJhePfGUzyFNXVe9hr0F3QrX9JYFrDg5N1qXg@mail.gmail.com>

Good morning Ethan,

> My above email contains an error. The SPV client needs to only
> download S+1, not S+1 and S+2.
>
> I agree with you that a weakness of this approach is a miner can make
> SPV clients do substantially more work. However:
>
> 1.  Mining a block which will never be accepted is an expensive way to
>     make SPV clients download, validate and discard ~2-4 megabytes of
>     data. There are far less expensive ways of wasting the resources of
>     SPV clients. Its unclear why someone would want to do this instead of
>     just packeting full nodes or SPV servers like we saw with the recent
>     DDoS attacks against electrum servers.
>
> 2.  SPV clients may not even learn about these splits because it
>     requires that someone relay the split to them. Honest full nodes
>     should not relay such splits. To their bitcoin's worth the attacker
>     must also connect to lots of SPV clients.
>
> 3.  Having SPV clients slow down or become full nodes when a malicious
>     miner with significant mining power is attempting to disrupt the
>     network is probably a best case outcome. I would prefer this failure
>     mode to the current SPV behavior which is to just go with the
>     "longest" chain.


I understand.
It seems a reasonable point to do so.

As I understand it, this requires that UTXO commitments be mandatory.
In particular, if UTXO commitments were not mandatory, it would be trivial to force chainsplits at heights where a UTXO commitment was not made, and force an SPV node to download more blocks backwards until a block with a UTXO commitment is found.

More difficult is: how can an SPV node acquire the UTXO set at a particular block?
Fullnodes automatically update their UTXO set at each block they accept as tip.
Reversing the blocks to update the UTXO set at a particular past time would require a good amount of CPU and memory.
Thus any service that can provide the actual UTXO set at each block would potentially be attackable by simply requesting enough past blocks.


Regards,
ZmnSCPxj


  reply	other threads:[~2019-04-19  4:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15  6:37 Ruben Somsen
2019-04-18 16:55 ` ZmnSCPxj
2019-04-18 20:12   ` Ethan Heilman
2019-04-19  0:25     ` ZmnSCPxj
2019-04-19  1:13       ` Ethan Heilman
2019-04-19  2:53         ` ZmnSCPxj
2019-04-19  3:21           ` Ethan Heilman
2019-04-19  4:48             ` ZmnSCPxj [this message]
2019-04-19 13:23               ` Ruben Somsen
2019-04-20  1:59                 ` ZmnSCPxj
2019-04-20  3:26                   ` Ruben Somsen
2019-04-20  4:45                     ` ZmnSCPxj
2019-04-21  9:13                       ` Ruben Somsen

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='SHsLdVIPZcn9yyZN9Hx3moQmWXY-2yC99tEsFllksV-66ZrJNMQfDr0qHK_rCZuBcEa8gIcnThkvgRDkU6BYQ_mxX7JxfI_uM6ndOF26ofk=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=eth3rs@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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