Bitcoin Development Mailinglist
 help / color / mirror / Atom feed

• * [bitcoindev] OP_CHECKUTXOSETHASH idea
         [not found] <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
  @ 2025-09-30  0:09 ` Erik Aronesty
    2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
                       ` (2 more replies)
    0 siblings, 3 replies; 6+ messages in thread
  From: Erik Aronesty @ 2025-09-30  0:09 UTC (permalink / raw)
    To: bitcoindev
  
  [-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
  
  A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing
  miners to optionally commit a deterministic hash of the current UTXO set
  into a block. If present, all nodes must verify its correctness or reject
  the block; if absent, the block is still valid. Old nodes treat the opcode
  as unspendable, so backward compatibility is preserved.
  
  Because computing the full UTXO root is costly, this makes each checkpoint
  intentionally expensive to produce, ensuring that miners will only include
  them when compensated with sufficient fees. Additionally, it could be
  limited to one per block.
  
  The result is a voluntary, self-limiting, incentive-aligned, fee-driven
  system where checkpoints are cheaply consensus-enforced when included but
  never mandatory.
  
  Most nodes could operate on a rolling history validated by occasional,
  high-value commitments, while archival nodes remain free to preserve the
  full chain. This reduces the burden of initial sync and resource use
  without sacrificing Bitcoin’s security model, since any invalid checkpoint
  would invalidate its block.
  
  In practice, the chain becomes more efficient for everyday use while the
  historical record remains intact for those willing to bear the expense of
  maintaining it.
  
  -- 
  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/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com.
  
  [-- Attachment #2: Type: text/html, Size: 2187 bytes --]
  
  ^ permalink raw reply	[flat|nested] 6+ messages in thread

• • * Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
      2025-09-30  0:09 ` [bitcoindev] OP_CHECKUTXOSETHASH idea Erik Aronesty
    @ 2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
      2025-10-02 23:39     ` Erik Aronesty
      2025-10-03 16:12   ` Peter Todd
      2025-11-16 19:11   ` [bitcoindev] " Eric Voskuil
      2 siblings, 1 reply; 6+ messages in thread
    From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-10-02 22:40 UTC (permalink / raw)
      To: Erik Aronesty; +Cc: bitcoindev
    
    Hi Erik,
    
    Since it is costly for nodes to compute, this is a bit of a DOS vector. I would suggest to limit UTXO set commitments to every 2016 blocks (either the first or the last block of a difficult adjustment epoch).
    
    If it checks the UTXO set commitment of a previous block, it will not interfere with mining, for example always commit to the initial state of the difficult adjustment epoch at the end of the epoch. The hash can be calculated well in advance. It also would be the same in every check, so it's not possible to use it for denial of service.
    
    It's a bit interesting that the script can not be fully validated before it hits an actual block. It also allows for submitting a transaction into the mempool that might be invalid to mine, that needs additional steps for eviction. Wonder if this allows for weird new pinning attacks for free?
    
    Overall I have low confidence that this belongs in script instead of the coinbase transaction structure via a more specific soft fork.
    
    BR,
    moonsettler
    
    On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty <erik@q32.com> wrote:
    
    > A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing miners to optionally commit a deterministic hash of the current UTXO set into a block. If present, all nodes must verify its correctness or reject the block; if absent, the block is still valid. Old nodes treat the opcode as unspendable, so backward compatibility is preserved.
    > Because computing the full UTXO root is costly, this makes each checkpoint intentionally expensive to produce, ensuring that miners will only include them when compensated with sufficient fees. Additionally, it could be limited to one per block.
    > 
    > The result is a voluntary, self-limiting, incentive-aligned, fee-driven system where checkpoints are cheaply consensus-enforced when included but never mandatory.
    > 
    > Most nodes could operate on a rolling history validated by occasional, high-value commitments, while archival nodes remain free to preserve the full chain. This reduces the burden of initial sync and resource use without sacrificing Bitcoin’s security model, since any invalid checkpoint would invalidate its block.
    > 
    > In practice, the chain becomes more efficient for everyday use while the historical record remains intact for those willing to bear the expense of maintaining it.
    > 
    > 
    > 
    > --
    > 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/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com.
    
    -- 
    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/yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0%3D%40protonmail.com.
    
    
    ^ permalink raw reply	[flat|nested] 6+ messages in thread

  • • * Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
        2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
      @ 2025-10-02 23:39     ` Erik Aronesty
        0 siblings, 0 replies; 6+ messages in thread
      From: Erik Aronesty @ 2025-10-02 23:39 UTC (permalink / raw)
        To: moonsettler; +Cc: bitcoindev
      
      [-- Attachment #1: Type: text/plain, Size: 4617 bytes --]
      
      I agree, this doesn’t belong in general script where it could create
      mempool weirdness; also the DoS surface is real if checkpoints can be
      demanded arbitrarily.
      
      Verification isn’t nearly as heavy as you suggest though. Every validating
      node already maintains the UTXO set; computing the salted hash once per
      epoch is basically a linear scan with caching.  Incremental hashing
      techniques can make it even faster.
      
      To reduce attack surface: commitment in the coinbase only, at most once per
      difficulty epoch. No mempool footprint, no risk of pinning attacks, and no
      repeat scanning.  Nodes just compute and cache the root when they process
      the epoch’s first block, then check a 32-byte value at the epoch’s end.
      Producing that root is still expensive enough to require real incentives
      (sponsor still has to pay for it, and that's OK) - checking it is trivial.
      
      Voluntary and expensive to make, cheap to verify, consensus-enforced if
      present but never mandatory. Miners and sponsors decide if it’s worth
      burning the cycles, nodes get a safe fast-sync path.
      
      The key ingredient is sponsor-paid-work.  This thing disappears if nobody
      wants to pay for it or mine it.
      
      On Thu, Oct 2, 2025 at 3:40 PM moonsettler <moonsettler@protonmail.com>
      wrote:
      
      > Hi Erik,
      >
      > Since it is costly for nodes to compute, this is a bit of a DOS vector. I
      > would suggest to limit UTXO set commitments to every 2016 blocks (either
      > the first or the last block of a difficult adjustment epoch).
      >
      > If it checks the UTXO set commitment of a previous block, it will not
      > interfere with mining, for example always commit to the initial state of
      > the difficult adjustment epoch at the end of the epoch. The hash can be
      > calculated well in advance. It also would be the same in every check, so
      > it's not possible to use it for denial of service.
      >
      > It's a bit interesting that the script can not be fully validated before
      > it hits an actual block. It also allows for submitting a transaction into
      > the mempool that might be invalid to mine, that needs additional steps for
      > eviction. Wonder if this allows for weird new pinning attacks for free?
      >
      > Overall I have low confidence that this belongs in script instead of the
      > coinbase transaction structure via a more specific soft fork.
      >
      > BR,
      > moonsettler
      >
      > On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty <erik@q32.com>
      > wrote:
      >
      > > A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`,
      > allowing miners to optionally commit a deterministic hash of the current
      > UTXO set into a block. If present, all nodes must verify its correctness or
      > reject the block; if absent, the block is still valid. Old nodes treat the
      > opcode as unspendable, so backward compatibility is preserved.
      > > Because computing the full UTXO root is costly, this makes each
      > checkpoint intentionally expensive to produce, ensuring that miners will
      > only include them when compensated with sufficient fees. Additionally, it
      > could be limited to one per block.
      > >
      > > The result is a voluntary, self-limiting, incentive-aligned, fee-driven
      > system where checkpoints are cheaply consensus-enforced when included but
      > never mandatory.
      > >
      > > Most nodes could operate on a rolling history validated by occasional,
      > high-value commitments, while archival nodes remain free to preserve the
      > full chain. This reduces the burden of initial sync and resource use
      > without sacrificing Bitcoin’s security model, since any invalid checkpoint
      > would invalidate its block.
      > >
      > > In practice, the chain becomes more efficient for everyday use while the
      > historical record remains intact for those willing to bear the expense of
      > maintaining it.
      > >
      > >
      > >
      > > --
      > > 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/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com
      > .
      >
      
      -- 
      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/CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-MLXan7w%40mail.gmail.com.
      
      [-- Attachment #2: Type: text/html, Size: 5563 bytes --]
      
      ^ permalink raw reply	[flat|nested] 6+ messages in thread

  • * Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
      2025-09-30  0:09 ` [bitcoindev] OP_CHECKUTXOSETHASH idea Erik Aronesty
      2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
    @ 2025-10-03 16:12   ` Peter Todd
      2025-10-03 22:15     ` Erik Aronesty
      2025-11-16 19:11   ` [bitcoindev] " Eric Voskuil
      2 siblings, 1 reply; 6+ messages in thread
    From: Peter Todd @ 2025-10-03 16:12 UTC (permalink / raw)
      To: Erik Aronesty; +Cc: bitcoindev
    
    [-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
    
    On Mon, Sep 29, 2025 at 05:09:15PM -0700, Erik Aronesty wrote:
    > A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing
    > miners to optionally commit a deterministic hash of the current UTXO set
    > into a block. If present, all nodes must verify its correctness or reject
    > the block; if absent, the block is still valid. Old nodes treat the opcode
    > as unspendable, so backward compatibility is preserved.
    > 
    > Because computing the full UTXO root is costly, this makes each checkpoint
    > intentionally expensive to produce, ensuring that miners will only include
    > them when compensated with sufficient fees. Additionally, it could be
    > limited to one per block.
    
    No, it's costly for everyone to compute: everyone needs to recompute this to
    validate that the block is valid.
    
    Anyway, just as an aside, if you really need to do something like this, make
    the commitment be computable in advance by using a UTXO set root from the
    *prior* interval, to give nodes plenty of time to compute it. I outlined this
    approach before in the form of delayed txo commitments:
    
    https://petertodd.org/2016/delayed-txo-commitments
    
    -- 
    https://petertodd.org 'peter'[:-1]@petertodd.org
    
    -- 
    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/aN_16-lBQzY5K9XL%40petertodd.org.
    
    [-- Attachment #2: signature.asc --]
    [-- Type: application/pgp-signature, Size: 833 bytes --]
    
    ^ permalink raw reply	[flat|nested] 6+ messages in thread

  • • * Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
        2025-10-03 16:12   ` Peter Todd
      @ 2025-10-03 22:15     ` Erik Aronesty
        0 siblings, 0 replies; 6+ messages in thread
      From: Erik Aronesty @ 2025-10-03 22:15 UTC (permalink / raw)
        To: Peter Todd; +Cc: bitcoindev
      
      [-- Attachment #1: Type: text/plain, Size: 865 bytes --]
      
      agreed!  UTXO set root from the *prior* interval is the best way to go.
      the whole point is it's supposed to be old, safe beyond reorg and for
      lightweight sync with no centralized checkpoint producers.
      
      i do think that incremental-hashing can be used to speed things up a lot.
      
      Merkleized, Merklix trie, or an accumulator like Utreexo: you can maintain
      the root incrementally by only touching the leaves that correspond to
      changed UTXOs
      
      should be very fast, not heavy at all
      
      -- 
      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/CAJowKgLpix4KjzJGKNzR3JpiKLDJKSiuuOdcebCyGJnDuw0wJw%40mail.gmail.com.
      
      [-- Attachment #2: Type: text/html, Size: 1206 bytes --]
      
      ^ permalink raw reply	[flat|nested] 6+ messages in thread

  • * [bitcoindev] Re: OP_CHECKUTXOSETHASH idea
      2025-09-30  0:09 ` [bitcoindev] OP_CHECKUTXOSETHASH idea Erik Aronesty
      2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
      2025-10-03 16:12   ` Peter Todd
    @ 2025-11-16 19:11   ` Eric Voskuil
      2 siblings, 0 replies; 6+ messages in thread
    From: Eric Voskuil @ 2025-11-16 19:11 UTC (permalink / raw)
      To: Bitcoin Development Mailing List
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 2923 bytes --]
    
    Hi Erik,
    
    >  Most nodes could operate on a rolling history validated by occasional, 
    high-value commitments, while archival nodes remain free to preserve the 
    full chain.
    
    This is an old big-blocker idea, and still a terrible one. It effectively 
    reduces what we now call validation to majority hash power control. IOW 
    functionally equivalent to SPV. A few actual full nodes (maybe) validating 
    does not have the implied effect. For a node's validation to matter, the 
    node has to be accepting coin in trade. SPV entirely relies on the 
    presumption that a very large portion of economic activity is actually 
    validated. Very large means enough that majority hash power has a true 
    disincentive to intentionally mine invalid blocks, despite the reward for 
    doing so (e.g. unlimited inflation). What you are calling "archival nodes" 
    don't actually "preserve the full chain" for everyone else, because their 
    effect is limited to their own transactions. Otherwise we are talking about 
    fraud proofs, which is a conversation that doesn't end well.
    
    >  Because computing the full UTXO root is costly...
    
    It is not, it's getting cheaper every year.
    
    e
    
    On Monday, September 29, 2025 at 8:11:51 PM UTC-4 Erik Aronesty wrote:
    
    A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing 
    miners to optionally commit a deterministic hash of the current UTXO set 
    into a block. If present, all nodes must verify its correctness or reject 
    the block; if absent, the block is still valid. Old nodes treat the opcode 
    as unspendable, so backward compatibility is preserved. 
    
    Because computing the full UTXO root is costly, this makes each checkpoint 
    intentionally expensive to produce, ensuring that miners will only include 
    them when compensated with sufficient fees. Additionally, it could be 
    limited to one per block.
    
    The result is a voluntary, self-limiting, incentive-aligned, fee-driven 
    system where checkpoints are cheaply consensus-enforced when included but 
    never mandatory. 
    
    Most nodes could operate on a rolling history validated by occasional, 
    high-value commitments, while archival nodes remain free to preserve the 
    full chain. This reduces the burden of initial sync and resource use 
    without sacrificing Bitcoin’s security model, since any invalid checkpoint 
    would invalidate its block. 
    
    In practice, the chain becomes more efficient for everyday use while the 
    historical record remains intact for those willing to bear the expense of 
    maintaining it.
    
    
    -- 
    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/76c1b5a1-5b78-4576-981f-4df69aefc9a6n%40googlegroups.com.
    
    [-- Attachment #1.2: Type: text/html, Size: 3606 bytes --]
    
    ^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-11-16 19:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
2025-09-30  0:09 ` [bitcoindev] OP_CHECKUTXOSETHASH idea Erik Aronesty
2025-10-02 22:40   ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-02 23:39     ` Erik Aronesty
2025-10-03 16:12   ` Peter Todd
2025-10-03 22:15     ` Erik Aronesty
2025-11-16 19:11   ` [bitcoindev] " Eric Voskuil

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox