Bitcoin Development Mailinglist
 help / color / mirror / Atom feed
From: Sjors Provoost <sjors@sprovoost.nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Matt Corallo <lf-lists@mattcorallo.com>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoindev] [BIP Draft] 24 bits for nVersion nonce space instead of 16
Date: Wed, 8 Apr 2026 18:16:01 +0200	[thread overview]
Message-ID: <D52CEDCC-C7EF-429E-802F-F28DC9241FF0@sprovoost.nl> (raw)
In-Reply-To: <acfCTzCqIalFuOdi@erisian.com.au>

This could lead to friction around who gets to allocate these scarce 5 bits, as well as
potential confusion when people and client software interpret contentious bits differently.

What if we reserve bit 0 to indicate that the actual signal can be found in the coinbase
transaction? The signal itself can be as simple as OP_RETURN BIP-XXXX.

The chosen string doesn't matter. We can keep referring to "deployment bits", where
bits > 28 represent the new method. That gives us practically unlimited bits and no
need to ever repurpose them.

A quick vibe coding session suggests this is straightforward to implement. [0]

The two implementation caveats:
- BIP22 will need an extension to feed the new coinbase OP_RETURN fields to
  mining pool software (IPC clients like Stratum v2 work out of the box)  
- headers are no longer sufficient to track signalling [1]

- Sjors

[0] https://github.com/Sjors/bitcoin/commits/2026/05/version/
[1] v31.0 will make the coinbase is easily accessible via RPC: https://github.com/bitcoin/bitcoin/pull/34512


> Op 28 mrt 2026, om 12:58 heeft Anthony Towns <aj@erisian.com.au> het volgende geschreven:
> 
> On Thu, Feb 26, 2026 at 05:12:03PM -0500, Matt Corallo wrote:
>> ==Specification==
>> 24 bits from the block header nVersion field, starting from 5 and ending at
>> 28 inclusive (0x1fffffe0), are reserved for nonce use and removed from BIP8
>> and BIP9 specifications. A mask of 0xe000001f should be applied to nVersion
>> bits so bits 5-28 inclusive will be ignored for soft-fork signalling and
>> unknown soft-fork warnings.
> 
> This conflicts with the proposed use of bit 5 for signalling CTV activation
> over the next twelve months mentioned at:
> 
> * https://groups.google.com/g/bitcoindev/c/HC2bn4QOR-M/m/TF8qJidzAAAJ
> * https://delvingbitcoin.org/t/bip-119-ctv-activation-client/2242
> * https://github.com/ctv-activation/activation-client/blob/06ddbdf01bc8ce181b01c7497010bff74c2b79c6/src/kernel/chainparams.cpp#L121-L127
> 
> I don't think there's any meaningful support for that activation proposal,
> but thought it was worth pointing out for completeness.
> 
> BIP110 is currently signalling via bit 4 until block 963648; LNHANCE
> is possibly signalling on bit 3 between May last year and Jan 2028.
> 
> Previously, CSV signalled on bit 0, segwit on bit 1, segwit reduced
> threshold (bip 91) on bit 4, and taproot on bit 2.
> 
> Cheers,
> aj
> 

-- 
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/D52CEDCC-C7EF-429E-802F-F28DC9241FF0%40sprovoost.nl.


  reply	other threads:[~2026-04-08 16:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 22:12 Matt Corallo
2026-02-27 15:34 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-03-09 19:45   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-03-28 11:58 ` Anthony Towns
2026-04-08 16:16   ` Sjors Provoost [this message]
2026-04-08 20:11     ` 'Antoine Poinsot' via Bitcoin Development Mailing List

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D52CEDCC-C7EF-429E-802F-F28DC9241FF0@sprovoost.nl \
    --to=sjors@sprovoost.nl \
    --cc=aj@erisian.com.au \
    --cc=bitcoindev@googlegroups.com \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox