public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"tdryja@media•mit.edu" <tdryja@media•mit.edu>
Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Date: Sat, 20 Apr 2019 01:59:25 +0000	[thread overview]
Message-ID: <EWP8Pzp8wS_Nh145H_g4w3yJaelXmm6UB12sa8MC2EsMbYFhm53C_kaOvjztksQpCNBBT0D0zuTbKHnEfEatlLKIa3whMlLZrihawZux1UY=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjYeuCA1WDHgEpkN1K8=NM88fw43HJeP5TeRE7q0Q+Chzg@mail.gmail.com>

Good morning,


> > As I understand it, this requires that UTXO commitments be mandatory.
>
> Perhaps UTXO sets can be made useful without committing them. I have
> some very loose thoughts on the subject, I consider it an open
> question.

There is no safe way to use UTXO sets without identifying who is telling you those sets are valid, or making it expensive to lie.
The first option requires trust and is weaker than SPV, the second requires committing to a proof-of-work (and probably best to fold it into the Bitcoin blockchain if so).

You would get the UTXO commitment from the previous block (if the UTXO commitment is in the coinbase, then all you need is the Merkle proof of the coinbase).


>
> > More difficult is: how can an SPV node acquire the UTXO set at a particular block?
>
> I think you are asking fair questions about how the UTXO set
> commitments would work in practice, and how viable that makes it. I'm
> not sure. The most comprehensive work I have seen on this topic has
> been the utreexo proposal by Tadge Dryja:
> https://www.youtube.com/watch?v=edRun-6ubCc
>
> Actually, now that I think about it... As an alternative to UTXO set
> commitments, the old fraud proofs idea for segwit can be applied here.
>
> We get miners to commit to the location of the UTXOs that are being
> spent (e.g. transaction 5 in block 12). This allows full nodes to
> succinctly prove invalidity to SPV clients in the following ways:
>
> -   a committed location does not contain the stated UTXO
> -   the UTXO has already been spent in a prior block
>
>     If no fraud proofs are given, then the inputs can be assumed to be valid.
>
>     As you may recall, these kinds of fraud proofs were abandoned mainly
>     because the data unavailability claim could only be verified by
>     downloading the data, resulting in a DoS vector where all blocks had
>     to be downloaded. This problem does not seem to apply here, because we
>     are only interested in blocks which have forks, so it's more doable to
>     download them.

This makes no sense.
In order to validate block N, you need to know that every UTXO spent by a transaction in block N is valid.
The UTXO you want to validate is located in some other block, not on the single block you are verifying.

Thus the non-existent fraud proof can only be validated by loading the block of the UTXO purported to be spent, and every block between that and the current block you are verifying, i.e. fullnode.
Either that or you trust that every peer you have is not omitting the proof.

Regards,
ZmnSCPxj


  reply	other threads:[~2019-04-20  1:59 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
2019-04-19 13:23               ` Ruben Somsen
2019-04-20  1:59                 ` ZmnSCPxj [this message]
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='EWP8Pzp8wS_Nh145H_g4w3yJaelXmm6UB12sa8MC2EsMbYFhm53C_kaOvjztksQpCNBBT0D0zuTbKHnEfEatlLKIa3whMlLZrihawZux1UY=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=rsomsen@gmail$(echo .)com \
    --cc=tdryja@media$(echo .)mit.edu \
    /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