Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-20 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-20 Thread Ruben Somsen via bitcoin-dev
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.

>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.

Again, this is not a new observation. I am just recalling the fraud
proof debate from when it was being considered for segwit (though of
course it's possible I got some details wrong).

-- Ruben Somsen

On Sat, Apr 20, 2019 at 3:59 AM ZmnSCPxj  wrote:
>
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-20 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev