0

With AssumeUTXO it should be possible to sync to chaintip from a recent snapshot of the UTXO set, rather than from the genesis block (although there's background full validation after sync). This is similar to Weak Subjectivity Checkpoints, with the difference that checkpoints work as a new genesis block, with a snapshot, from where new nodes sync. In other words, archival nodes can discard data older than these checkpoints since it's no longer needed for syncing.

So what are the arguments against having Weak Subjectivity Checkpoints on Bitcoin, a la AssumeUTXO? It seems a different trust model since new nodes are forced to trust the latest Bitcoin Core checkpoint / snapshot for syncing, assuming old data was discarded.

However, we are already trusting the Bitcoin Core development process to not have introduced malicious code at any point in the past. This is indeed the trust assumption of Bitcoin. Hence adding the requirement of a periodic checkpoint + UTXO snapshot seems under the same assumption. Notice that any user running a node can audit the correctness of a new checkpoint / snapshot being added. If an invalid checkpoint / snapshot gets added without anyone noticing, then developers can do equally bad things right now.

How is this a different trust assumption than Bitcoin’s?

Improve this question
1
  • 1
    By definition there is no trust involved in bitcoin core you verify each block header with software that you yourself run.
    – Poseidon
    Mar 9 at 22:17

3 Answers 3

Reset to default
4

You are comparing apples and oranges here. By weak subjectivity you are referring to the consensus rules of a "Proof of Stake" network. Assumeutxo is an IBD speedup specific to the Bitcoin Core client, that also verifies the rules of the Bitcoin network.

A user may choose to use assumeutxo, but they don't have to. Anyone can verify the Bitcoin chain since the genesis block without the UTxO set hash that might eventually be included in the Bitcoin Core client. It is not the case in the "weak subjectivity" system you refer to. In this kind of system in the end you have to rely on the provided checkpoints, you can't opt out of using them.

In addition, and this is often a point of confusion, note that a assumeutxo / -assumevalid user is not entirely trusting the provided data. For assumeutxo the client is still performing the regular IBD in the background. If it finds out the provided hash was incorrect it will discard it. Hence the user trusts the hash only for the duration of the IBD. For assumevalid if the node is provided an alternate chain with more work (strong objectivity!) it will discard the configured -assumevalid one.

So what are the arguments against having Weak Subjectivity Checkpoints on Bitcoin, a la AssumeUTXO? [...] How is this a different trust assumption than Bitcoin’s?

As explained above, assumeutxo is not a checkpoint. Assumeutxo allows you to temporarily trust a provided UTxO set while your node is syncing. A checkpoint would make your node refuse a chain that does not contain such block.

Sure if the blocks are deeply buried, the trust model of having a checkpoint is very different. The Bitcoin Core client already has buried deployments anyways. But if all you want is to speedup IBD, just use assumeutxo instead of introducing a network rule?

Related:

Improve this answer
8
  • No, I don’t think I’m comparing apples to oranges. What I’m saying is that a checkpoint with a snapshot can be used as a new genesis block, and old data discarded. I also note why nodes cannot opt-out in this case and why it seems like a different trust model. But you didn’t answer my main question.
    – Son Kaos999
    Mar 9 at 21:36
  • 2
    I might have extrapolated what you said. I didn't intend to. Weak subjectivity is often discussed in relation to "Proof of Stake" (blog.ethereum.org/2014/11/25/…) so i assumed from a quick read you were referring to this, my bad. I'll update the answer, it boils down to the same issue anyways.
    – Antoine Poinsot
    Mar 9 at 22:00
  • It was coined in the PoS context in order to solve the nothing at stake problem, but it's related to Bitcoin as well (i.e. there are things in Bitcoin that depend on trusting people and having a social consensus). Weak Subjetivity Checkpoints are called like that because you trust someone to give you the snapshot. In our case I was talking about devs doing it, since we already trust them for more critical stuff
    – Son Kaos999
    Mar 9 at 23:21
  • 1
    Well you can always trust a snapshot if you are so inclined but making it mandatory is a fundamental change in the system.. The value proposition of Bitcoin is that you can verify the current state by replicating all the transitions since state 0, without having to trust any provided data. I think we are both talking about the same thing now, but the crux of our misunderstanding is about the leap from having an opt-in snapshot mechanism to making it mandatory.
    – Antoine Poinsot
    Mar 10 at 13:02
  • 2
    It is true that some amount of trust is required at various levels. But it is tunable at all those levels. While you may opt-in to the easy-and-more-trusted sync, it is still possible to use the super-paranoid mode of syncing. Let's not throw the baby with the bathwater and say "since some trust is usually involved let's just make it mandatory and more trusted". By this same token you could end up arguing that we don't even need miners to coordinate transactions, let's just have developers run a server that provides checkpoints since we already trust them!
    – Antoine Poinsot
    Mar 10 at 13:38
1

it should be possible to sync to chaintip from a recent snapshot of the UTXO set, rather than from the genesis block

It should be possible

However, it is easy to verify the Genesis block as that is only a couple of hundred bytes, is well known and published in numerous places. You could cross check by hand.

The current UTXO set has tens of millions of UTXOs totalling tens of gigabytes of data. That's a lot more difficult to independently check.

You could make and check a hash of the UTXO snapshot but there might be significantly fewer independent places where the hash of an arbitrary UTXO snapshot was published.

It might also create a precedent which criminals would exploit by persuading victims to use a UTXO snapshot hash from their fake websites etc.

Then you'd have to maybe rely on signatures from some set of trusted authorities. But this can also be problematic.

Improve this answer
1
  • Well in AssumeUTXO the snapshot is published by Bitcoin Core contributors, reviewers, etc and it can be independently audited by anyone using a full node (just like AssumeValid).
    – Son Kaos999
    Mar 10 at 0:09
-1

However, we still trust Bitcoin Core without checkpoints in a similar way: we trust that the hardcoded genesis block is the correct one. Of course the genesis block is widely known and it’s easy to catch Core devs trying to change it. If we are able to attain social consensus over the true genesis block, then it follows that this is also the case for the checkpoint / snapshot, given enough time. In both cases we rely on social consensus.

I think this issue is dealt with through proof of work, you would waste your time trying to build a chain with as much work as bitcoin and catch up to it. If you had enough hashpower to do it you would be much more profitable just mining bitcoin.

The graph at the bottom of this page https://bitcoin.sipa.be/ puts it into perspective. Trying to re-write the entire bitcoin chain is literally Don Quixote level of delusion, you can re-write a block but you can't convince everyone that your one different block is the real one. It is just not realistic with proof of work and a dense full node graph. If no one ran their own node and it was a PoS system these would be very valid concerns.

Improve this answer
7
  • If your client software has a different genesis block then your starting point is already a false chain, an attacker doesn’t need to give you an expensive PoW chain
    – Son Kaos999
    Mar 9 at 22:39
  • Of course they do, if you start with a different genesis block you wont be able to connect to ANY nodes that have the real one.
    – Poseidon
    Mar 9 at 22:41
  • When you have a different chain you have a fork, these forks can happen naturally sometimes through block reorganizations at the latest blocks this basically represents miners fighting over block rewards. But that always settles with the actual dense node graph running the majority of the chain, they come to consensus on what is a reorg and what is not in real time and that has been going on since before the transaction scheme was even as secure as it is today.
    – Poseidon
    Mar 9 at 22:44
  • If you start with a different genesis block you have literally no chance of getting your blockchain to look exactly like Bitcoins or one with as much work. It would take you 600+ days and by then the Bitcoin network would be 600 days further
    – Poseidon
    Mar 9 at 22:45
  • What I meant is that you need to trust Bitcoin Core to have the correct genesis block hardcoded, that’s all
    – Son Kaos999
    Mar 9 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.