From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Murch <murch@murch.one>, Sjors Provoost <sjors@sprovoost.nl>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Addressing remaining points on BIP 54
Date: Wed, 14 Jan 2026 15:33:16 +0000 [thread overview]
Message-ID: <_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo=@protonmail.com> (raw)
In-Reply-To: <1B807731-DC2A-4E59-B462-5C210EF1FB73@sprovoost.nl>
Thanks everyone for the comments.
Sjors, transactions are serialized in modern blocks as described by Murch.
Murch, for the purpose of computing the Merkle root transactions are serialized without witness data.
Best,
Antoine
On Wednesday, January 14th, 2026 at 5:23 AM, Sjors Provoost <sjors@sprovoost.nl> wrote:
>
>
> Hi Murch,
>
> You're referring to the "serialization with witness data" defined in BIP 141.
>
> But that's not how the transaction is serialised in a block, since the witness is
> segregated.
>
> > The witness is committed in a tree that is nested into the block's existing
>
> merkle root via the coinbase transaction for the purpose of making this BIP
> soft fork compatible. A future hard fork can place this tree in its own branch.
>
> As long as the miner doesn't touch the SegWit OP_RETURN , which also commits
> to the coinbase witness, it can safely use the legacy transaction serialisation.
>
> - Sjors
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id
>
> > Op 14 jan 2026, om 01:23 heeft Murch murch@murch.one het volgende geschreven:
> >
> > Hi Sjors,
> >
> > On 2026-01-08 00:30, Sjors Provoost wrote:
> >
> > > The approach suggested by Towns [4] of appending a 0-sat OP_RETURN output with
> > > padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is probably
> > > better, but not because like nLockTime it has a small hashing midstate
> > > benefit. It's easier to implement.
> > > I can’t access Delving right now to read AJ’s comment, but a small nit on the idea of using an additional output: BIP 141 requires coinbase transaction inputs to have a 32-byte witness. Since the witness section follows the outputs in the serialization, the bytes before the `nLocktime` in a coinbase transaction are the witness of the coinbase input, not the last output script.
> >
> > -Murch
>
>
> --
> 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/1B807731-DC2A-4E59-B462-5C210EF1FB73%40sprovoost.nl.
--
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/_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo%3D%40protonmail.com.
next prev parent reply other threads:[~2026-01-14 15:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 15:59 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-01-08 4:29 ` [bitcoindev] " Antoine Riard
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
2026-01-13 2:16 ` Antoine Riard
2026-01-13 16:59 ` Mubarek Juhar
2026-01-08 16:40 ` Matt Corallo
2026-01-13 1:49 ` Antoine Riard
2026-01-14 0:23 ` Murch
2026-01-14 10:15 ` Sjors Provoost
2026-01-14 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]
2026-01-14 18:58 ` Murch
2026-01-30 4:08 ` Antoine Riard
2026-02-05 22:48 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-12 3:57 ` Antoine Riard
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='_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=murch@murch.one \
--cc=sjors@sprovoost.nl \
/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