<p>You are comparing apples and oranges here. By weak subjectivity you are referring to the consensus rules of a &quot;Proof of Stake&quot; network. Assumeutxo is an IBD speedup specific to the Bitcoin Core client, that also verifies the rules of the Bitcoin network.</p>
<p>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 &quot;weak subjectivity&quot; 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.</p>
<p>In addition, and this is often a point of confusion, note that a assumeutxo / <code>-assumevalid</code> 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!) <a href="https://bitcoin.stackexchange.com/a/88666/101498">it will discard the configured <code>-assumevalid</code> one</a>.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>As explained above, assumeutxo is <em>not</em> a checkpoint. Assumeutxo allows you to temporarily trust a provided UTxO set while your node is syncing. A checkpoint would make your node <em>refuse</em> a chain that does not contain such block.</p>
<p>Sure if the blocks are deeply buried, the trust model of having a checkpoint is very different. The Bitcoin Core client already has <a href="https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki" rel="nofollow noreferrer">buried deployments</a> anyways. But if all you want is to speedup IBD, just use assumeutxo instead of introducing a network rule?</p>
<p>Related:</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/a/7830/101498">https://bitcoin.stackexchange.com/a/7830/101498</a></li>
<li><a href="https://bitcoin.stackexchange.com/a/75735/101498">https://bitcoin.stackexchange.com/a/75735/101498</a></li>
</ul>

CC BY-SA 4.0
2023-03-09T21:36:56.693Z
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
CC BY-SA 4.0
2023-03-09T22:00:05.183Z
I might have extrapolated what you said. I didn't intend to. Weak subjectivity is often discussed in relation to "Proof of Stake" (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) 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
CC BY-SA 4.0
2023-03-09T23:21:55.823Z
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
CC BY-SA 4.0
2023-03-10T12:13:41.547Z
It's not just about speeding up IBD, the main point is that archival nodes can discard historic data that's no longer needed for syncing
Son Kaos999
CC BY-SA 4.0
2023-03-10T13:02:53.517Z
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
CC BY-SA 4.0
2023-03-10T13:20:54.913Z
You can not sync without trust however, you trust the developers as I have pointed. If there’s a softfork you also trust them to have implemented it correctly. You cannot opt-out this.
Son Kaos999
CC BY-SA 4.0
2023-03-10T13:38:25.987Z
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
CC BY-SA 4.0
2023-03-11T12:30:36.083Z
I agree, although it would be opt-in as long as there are archival nodes. I just wanted to know how substantially the trust assumption changes if it wasn't opt-in. I think ZK-STARKs are the best way to do this since with them trust is no longer needed.
Son Kaos999
CC BY-SA 4.0
2023-03-09T21:15:12.673Z
2023-03-10T14:22:10.693Z
2023-03-10T14:22:10.693Z
Antoine Poinsot
<blockquote>
<p><strong>it should be possible to sync to chaintip from a recent snapshot of the UTXO set, rather than from the genesis block</strong></p>
</blockquote>
<p>It should be possible</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>It might also create a precedent which criminals would exploit by persuading victims to use a UTXO snapshot hash from their fake websites etc.</p>
<p>Then you'd have to maybe rely on signatures from some set of trusted authorities. But this can also be problematic.</p>

CC BY-SA 4.0
2023-03-10T00:09:49.213Z
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
CC BY-SA 4.0
2023-03-09T23:58:26.540Z
2023-03-10T00:03:28.243Z
2023-03-10T00:03:28.243Z
RedGrittyBrick
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>The graph at the bottom of this page <a href="https://bitcoin.sipa.be/" rel="nofollow noreferrer">https://bitcoin.sipa.be/</a> 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.</p>

CC BY-SA 4.0
2023-03-09T22:39:35.687Z
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
CC BY-SA 4.0
2023-03-09T22:41:34.950Z
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
CC BY-SA 4.0
2023-03-09T22:44:14.207Z
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
CC BY-SA 4.0
2023-03-09T22:45:42.303Z
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
CC BY-SA 4.0
2023-03-09T22:51:29.330Z
What I meant is that you need to trust Bitcoin Core to have the correct genesis block hardcoded, that’s all
Son Kaos999
CC BY-SA 4.0
2023-03-09T23:18:14.877Z
but that's not really true, if they did not they would not allow you to transact with the real bitcoin network and thus core would not be functional.
Poseidon
CC BY-SA 4.0
2023-03-09T23:18:57.983Z
more so each user VERIFIES that Core has the correct genesis block
Poseidon
CC BY-SA 4.0
2023-03-09T22:24:27.507Z
2023-03-09T22:24:27.507Z
Poseidon
<p>With <a href="https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal" rel="nofollow noreferrer">AssumeUTXO</a> 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.</p>
<p>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.</p>
<p>However, <strong>we are already trusting the Bitcoin Core development process to not have introduced malicious code at any point in the past</strong>. 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.</p>
<p>How is this a different trust assumption than Bitcoin’s?</p>

CC BY-SA 4.0
2023-03-09T22:17:50.490Z
By definition there is no trust involved in bitcoin core you verify each block header with software that you yourself run.
Poseidon
<bitcoin-core><synchronization><checkpoints><assume-valid><assume-utxo>
Weak Subjectivity Checkpoints trust assumptions
Son Kaos999
# Weak Subjectivity Checkpoints trust assumptions

(Asked by: username_0 on 2023-03-09)

With [AssumeUTXO](https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal) 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?

**Tags:** bitcoin-core, synchronization, checkpoints, assume-valid, assume-utxo

> **Comments:**
> **username_1**: By definition there is no trust involved in bitcoin core you verify each block header with software that you yourself run.  

---

## 3 answers

### Answer by username_2 on 2023-03-09. Score: 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](https://bitcoin.stackexchange.com/a/88666/101498).

> 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](https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki) anyways. But if all you want is to speedup IBD, just use assumeutxo instead of introducing a network rule?

Related:

* <https://bitcoin.stackexchange.com/a/7830/101498>
* <https://bitcoin.stackexchange.com/a/75735/101498>

> **Comments:**
> **username_0**: 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.  
> **username_2**: I might have extrapolated what you said. I didn't intend to. Weak subjectivity is often discussed in relation to "Proof of Stake" (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) 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.  
> **username_0**: 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  
> **username_0**: It's not just about speeding up IBD, the main point is that archival nodes can discard historic data that's no longer needed for syncing  
> **username_2**: 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.  
> **username_0**: You can not sync without trust however, you trust the developers as I have pointed. If there’s a softfork you also trust them to have implemented it correctly. You cannot opt-out this.  
> **username_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!  
> **username_0**: I agree, although it would be opt-in as long as there are archival nodes. I just wanted to know how substantially the trust assumption changes if it wasn't opt-in. I think ZK-STARKs are the best way to do this since with them trust is no longer needed.  

---

### Answer by username_3 on 2023-03-09. Score: 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.

> **Comments:**
> **username_0**: 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).  

---

### Answer by username_1 on 2023-03-09. Score: -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.

> **Comments:**
> **username_0**: 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  
> **username_1**: 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.  
> **username_1**: 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.  
> **username_1**: 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  
> **username_0**: What I meant is that you need to trust Bitcoin Core to have the correct genesis block hardcoded, that’s all  
> **username_1**: but that's not really true, if they did not they would not allow you to transact with the real bitcoin network and thus core would not be functional.  
> **username_1**: more so each user VERIFIES that Core has the correct genesis block  

---

