> From: Fabian
> > Validating the headers is inconsequential if you are not verifying tx
> > inclusion. That's what SPV is, and people should not be misled into
> > believing that this is SPV.
>
> I did not claim header validation alone validates the UTXO set,
> and I have not suggested AssumeUTXO is SPV.
I did not say that you did.
You said in response to me (my comment first):
>>> Receiving payments without having validated is an exceedingly unwise scenario,
>>> and not worthy of protocol support.
>>
>> I also need to add that an AssumeUTXO node is not
>> "not validated". The header chain is fully validated before the snapshot is
>> loaded, and the historical blocks are validated in the background. The work
>> is the same, only the node becomes usable earlier.
We are clearly talking about the period between obtaining the assumption and having validated it. This is the entire purpose of the feature. Defending the security of the feature by referring to the time *after* the feature becomes irrelevant is non-responsive.
You are referring to header validation as if it provides some aspect of security in this period. The only way it could being doing so is SPV. So I said:
"Validating the headers is inconsequential if you are not verifying tx inclusion."
> What I wrote was that an AssumeUTXO node "is not 'not validated'".
And this is incorrect in the relevant period, and moot once that period ends.
> Headers are validated upfront and the historical chain is validated in the background.
The sole purpose of the feature is to use the node without validation. Validating headers is only useful for (1) SPV or (2) DoS protection while validating.
> Together, that is the same work as a normal IBD, performed in a different order.
It just happens that the order matters. You can't have it both ways.
> An incoming payment can only be confirmed in a
> mined block on the headers-validated chain. For an attacker to trick the user
> into accepting a transaction that spends UTXOs which exist only in a malicious
> snapshot, the majority of mining hashpower would have to be running nodes that
> accepted and continued to run based only on the same malicious snapshot.
It seems that it's not apparent to you that you are exactly describing SPV. The recipient cannot validate the tx, or the block, or even the amount of the prevout for non-segwit txs. But he can verify inclusion - by doing exactly what SPV does. The wallet follows the strong chain, verifies inclusion, and assumes validity of what's included. This is exactly the SPV security model. SPV with extra steps.
However it has notable downsides in relation to SPV.
(1) startup cost is much higher (big download)
(2) wallet complexity is pushed into nodes (e.g. dual chainstate, see thread)
(3) inclusion proofs are not available for any tx supposedly confirmed within the assumption window (usage gap)
(4) trust must be established in the assumption in order to prevent very costly DoS (wasted full chain validation - same problem as swift sync)
(5) degrades the formerly trustless p2p network.
> The snapshot hash itself would still have to have been
> compromised through the source code review process.
This has been covered and is not relevant.
> Even then, background validation would detect the inconsistency when it
> reaches the snapshot height.
The person is already using the node, and this could carry on for weeks or forever. As you previously pointed out, this is a long-term solution to performance. At some point it might take years to perform a sequential validation.
> > Above you make the explicit claim that Bitcoin Core is the oracle for
> > this "sole trust input". If that is the case you should add it to the
> > proposal so that people are fully aware. If so the proposal
> > establishes a central authority for validity.
>
> The BIP intentionally leaves the source of the Merkle root to the
> implementation.
So the BIP punts this aspect of security, and yet you keep claiming it's secure because of Bitcoin Core and code review. You are trying to have it both ways here as well.
This proposes a very poorly implementation of what is fundamentally the SPV security model, for the period until a node can be fully validated. I don't see any justification for putting this into a node or the P2P network. People already widely use SPV wallets and direct them to their own full nodes for better security.
Best,
Eric
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/20050ee8-6bd6-4372-a81e-ef51ffcc376an%40googlegroups.com.