UTXO checkpoint transactions
3 messages, 28 Jan 2025. Started by Erik Aronesty.
Erik Aronesty (2), Eric Voskuil
Has it been considered to add a UTXO checkpoint transaction
Here's how it would work
Someone submits a transaction that contains a large fee and a hash of the UTXO set along with block height as opcode parameter
Miners refuse to include this transaction unless the hash of the UTXO set matches
Because performing that hash is expensive, it should have an extremely high cost factor, equivalent to say a 100KB transaction or something
These checkpoints are explicitly for the purpose of fast-synchronizing extremely lightweight nodes. It's reasonable to refuse to use a checkpoint that isn't at least several months old. It should be easy for anyone to find a sufficiently aged checkpoint and synchronize from that point onward.
Or is this just a solution without a problem?
Hi Erik,
Miners committing to a checkpoint does not make the checkpoint valid. The only way one would know it’s valid is by validating the chain up to that point.
Given that it implies one would be trusting hash power for validity there is no need for a utxo set. SPV is sufficient. A utxo set is only necessary for validation.
e
On Jan 28, 2025, at 01:32, Erik Aronesty <erik@q32•com> wrote:
Has it been considered to add a UTXO checkpoint transaction
Here's how it would work
Someone submits a transaction that contains a large fee and a hash of the UTXO set along with block height as opcode parameter
Miners refuse to include this transaction unless the hash of the UTXO set matches
Because performing that hash is expensive, it should have an extremely high cost factor, equivalent to say a 100KB transaction or something
These checkpoints are explicitly for the purpose of fast-synchronizing extremely lightweight nodes. It's reasonable to refuse to use a checkpoint that isn't at least several months old. It should be easy for anyone to find a sufficiently aged checkpoint and synchronize from that point onward.
Or is this just a solution without a problem?
correct, it's an "all full node vaidates" and not "trust miners only"
the intention was to *reduce* the assumption of validity hacks that i agree, are a problem
spv should definitely be enough for mobile clients interested solely in their own chain of wallet addresses
On Tue, Jan 28, 2025 at 9:11 AM Eric Voskuil <eric@voskuil•org> wrote:
Quoted text (78 lines)
> More age doesn’t make it more valid. If you can’t answer the same > questions that SPV can answer then use SPV. Did you mean the reverse? > > This constant creep toward non-validating bitcoin is troublesome, and > largely driven by poor software performance. We have SPV (without any > chance of fraud proofs becoming useful), “assume valid”, and now “assume > utxo”, and people are working toward what amounts to “assume utreexo”. This > cacaphony of trust-me-bro services that are drowning out individual > validation. > > That aside I cannot see utxo commitments as being beneficial unless they > are validated by full nodes (and how else would miners validate them?). > That still reduces to SPV security, since the wallet couldn’t validate it, > but at least it’s not adding a layer of trust that miners alone will > validate it. If you want to ensure it’s valid then it’s a soft fork. > > e > > On Jan 28, 2025, at 11:52, Erik Aronesty <erik@q32•com> wrote: > > > It seems that a sufficiently aged one would be useful in situations where > you are not able to answer the same questions that SPV can answer > > On Mon, Jan 27, 2025, 10:42 PM Eric Voskuil <eric@voskuil•org> wrote: > >> Hi Erik, >> >> Miners committing to a checkpoint does not make the checkpoint valid. The >> only way one would know it’s valid is by validating the chain up to that >> point. >> >> Given that it implies one would be trusting hash power for validity there >> is no need for a utxo set. SPV is sufficient. A utxo set is only necessary >> for validation. >> >> e >> >> On Jan 28, 2025, at 01:32, Erik Aronesty <erik@q32•com> wrote: >> >> >> Has it been considered to add a UTXO checkpoint transaction >> >> Here's how it would work >> >> Someone submits a transaction that contains a large fee and a hash of the >> UTXO set along with block height as opcode parameter >> >> Miners refuse to include this transaction unless the hash of the UTXO set >> matches >> >> Because performing that hash is expensive, it should have an extremely >> high cost factor, equivalent to say a 100KB transaction or something >> >> These checkpoints are explicitly for the purpose of fast-synchronizing >> extremely lightweight nodes. It's reasonable to refuse to use a checkpoint >> that isn't at least several months old. It should be easy for anyone to >> find a sufficiently aged checkpoint and synchronize from that point onward. >> >> >> Or is this just a solution without a problem? >> >> >> >> >> >> >> -- >> 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/CAJowKgLC9LdAu2mrQB-yW2Qoa3jU3BwZyL%2BQT4WW8f257Jkfhw%40mail.gmail.com >> <https://groups.google.com/d/msgid/bitcoindev/CAJowKgLC9LdAu2mrQB-yW2Qoa3jU3BwZyL%2BQT4WW8f257Jkfhw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >>