* Re: [bitcoindev] UTXO checkpoint transactions
[not found] ` <128AF3BD-F034-46AB-B5BD-E00B405CB854@voskuil.org>
@ 2025-01-28 17:34 ` Erik Aronesty
0 siblings, 0 replies; 3+ messages in thread
From: Erik Aronesty @ 2025-01-28 17:34 UTC (permalink / raw)
To: Eric Voskuil, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] UTXO checkpoint transactions
2025-01-28 5:50 Erik Aronesty
@ 2025-01-28 6:42 ` Eric Voskuil
0 siblings, 0 replies; 3+ messages in thread
From: Eric Voskuil @ 2025-01-28 6:42 UTC (permalink / raw)
To: Erik Aronesty; +Cc: bitcoindev
[-- Attachment #1: Type: text/html, Size: 3417 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] UTXO checkpoint transactions
@ 2025-01-28 5:50 Erik Aronesty
2025-01-28 6:42 ` Eric Voskuil
0 siblings, 1 reply; 3+ messages in thread
From: Erik Aronesty @ 2025-01-28 5:50 UTC (permalink / raw)
To: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-01-28 17:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAJowKgJO6MbxPnyzEYYD5YxzEhPq_AkbOsmRc8a+oVMVeKC9Ew@mail.gmail.com>
[not found] ` <128AF3BD-F034-46AB-B5BD-E00B405CB854@voskuil.org>
2025-01-28 17:34 ` [bitcoindev] UTXO checkpoint transactions Erik Aronesty
2025-01-28 5:50 Erik Aronesty
2025-01-28 6:42 ` Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox