From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Date: Sat, 20 Apr 2019 04:45:19 +0000 [thread overview]
Message-ID: <IbAS3IZpoD0wJKQvVekHDjHJL0R97CSGKwyy3ScU5yl2NIDSqBsmUJqvU_M7b0MRRu2u9aQXaof0zTs1OC562vkYu8LzV7vSDM6Pj5j55yI=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjbbYkXf62ApadMgOLef-Z9xTU1HQy_f+L3vNVUfRhChrw@mail.gmail.com>
Good morning Ruben,
> Hi ZmnSCPxj,
>
> > 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
>
> Olaoluwa Osuntokun's BIP157 manages to function without a commitment:
> "If the client receives conflicting filter headers from different
> peers for any block and filter type, it SHOULD interrogate them to
> determine which is faulty."
>
> I am wondering if the same logic can be applied to UTXO sets or the
> fraud proofs I just described.
UTXO sets can only be validated by actually running the entire blockchain, i.e. fullnoding.
What BIP157 does is summarize data that is within a block, thus validating them can be done simply by downloading the block in question.
UTXO sets summarize data in the entire blockchain, hence proper validation requires downloading the entire blockchain.
Thus it cannot be a comparison point.
> > This makes no sense
> > or you trust that every peer you have is not omitting the proof.
>
> It's the latter, you trust every peer you have is not omitting the
> proof. It requires one honest peer. The reason this is acceptable is
> because you're already making that assumption. If none of your peers
> are honest, you have no guarantee of hearing about the chain with the
> most PoW.
But peers can be set up to allow you to hear of all chains while denying you proof of the invalidity of some UTXO.
This is precisely the "data unavailability claim" that shot down the previous fraud proofs (i.e. absence of proof is not proof of absence, and proof of UTXO validity was defined by proof of absence of any intervening spend of the UTXO).
Perhaps in combination with BIP157/158 it may be possible, if the filters contain UTXO spends and a BIP158 filter was committed to on-chain.
Then a proof of absence could be done by revealing all the BIP158 filters from the UTXO creation to the block being validated, as well as the blocks whose BIP158 filters matched the UTXO and revealing that no, they actually do not spend the UTXO.
--
Tangentially, we cannot just magically commit to anything on the blockchain.
Header blocks commit to block data and commit to some other header block.
All those header blocks and the block data need to be stored and transmitted over the network somehow, even though they are "only" being committed to.
Thus, if you are adding new information to be committed, that may increase the resource usage of fullnodes.
So if UTXO set commitments, or utreexo commitments, or BIP158 filter digests, etc. are committed to in the coinbase, they have to be stored somehow in fullnodes the entire UUTXO set, or the actual utreexo structure, or the actual BIP158 filter, etc. at each block.
Otherwise it would be pointless to store those commitments since it would not be possible to somehow acquire the data being committed to after-the-fact.
This is probably still better than BIP37 but we should still be aware the additional load on fullnodes.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-04-20 4:45 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
2019-04-20 3:26 ` Ruben Somsen
2019-04-20 4:45 ` ZmnSCPxj [this message]
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='IbAS3IZpoD0wJKQvVekHDjHJL0R97CSGKwyy3ScU5yl2NIDSqBsmUJqvU_M7b0MRRu2u9aQXaof0zTs1OC562vkYu8LzV7vSDM6Pj5j55yI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@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