Re: [bitcoindev] UTXO checkpoint transactions

Re: [bitcoindev] UTXO checkpoint transactions

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

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:

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

-- 
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/CAJowKgJypG%2BW8GO%3Dn4g2Rdk2Qm4v6_hEGXA%2BN7meYRJaCEGpwg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6112 bytes --]

[bitcoindev] UTXO checkpoint transactions

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1957 bytes --]

Re: [bitcoindev] UTXO checkpoint transactions

[Eric Voskuil]

[-- Attachment #1: Type: text/html, Size: 3417 bytes --]