[27.x] Even more backports

[fanquake]

Backports:

• test: fix constructor of msg_tx #30552
• Fixes for GCC 15 compatibility #30633

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	stickies-v
Concept ACK	petertodd

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

[ariard]

I would recommend to re-add in the backport release notes that excerpt from 24.x:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-24.0.1.md

Contributors to this project strongly recommend that merchants and services
not accept unconfirmed transactions as final, and if they insist on doing so,
to take the appropriate steps to ensure they have some recourse or plan for
when their assumptions do not hold.

[petertodd]

@ariard Honestly I'm inclined to think that warning isn't necessary anymore. 24.x was two years ago, and anyone crazy enough to rely on first-seen has had plenty of warning; I'm not actually aware of any merchants or services still accepting unconfirmed transactions.

The last one I was aware of was the Chivo Bitcoin ATMs in El Salvador... but they would accept unconfirmed transactions even with BIP-125 opt-in enabled, so that example isn't actually relevant to this change.

If anything, I think that wording would actually confuse the issue as you could read it as though there was still a controversy about how safe unconfirmed transactions were. If you were to put in a warning, it should say something like "Bitcoin Core reminds people that unconfirmed transactions can always be cancelled by the sender. Only after at least one confirmation can a transaction be relied upon."

[ariard]

@petertodd, Yeah it might be too much zeal, yet I’ve been surprised when the option was introduced with 24.x how much services were still claiming to rely zero-conf acceptance. Same, I’m not aware of any bitcoin industry traffic with real-traffic actually accepting unconfirmed transactions (apart of few LSPs with zero-conf, it’s a paradigm of its own and people running that are more savvy about unconf txn risks due to channel funding flow).

The proposed alternative wording “Bitcoin Core reminds people that unconfirmed transactions can always be cancelled by the sender. Only after at least one confirmation can a transaction be relied upon” sounds indeed better.

[stickies-v]

code review ACK 885c4b7 but 8932090 is missing backport metadata in the commit message.

I verified that all backport commits are clean, except:

8932090 backported from 590456e: merge conflicts from 539404f and 8950053 which have been handled in a minimal and straightforward way.

I think backporting full-rbf makes sense conceptually, yet at the same time I'm a bit worried that shipping a new default value might be considered controversial for maintenance releases where I think people expect to be able to upgrade "automatically" without (non-bug) behaviour change? Although, of course, this exception already exists for consensus changes. Just putting it out there, no strong view.

[petertodd]

The cases where enabling full-rbf causes problems are very rare: you need to be running a service that is _not_ vulnerable to unconfirmed double-spends in general. Yet _does_ have some kind of bug related to double spends. And those rare services can still easily turn full-rbf off with a single config setting. Meanwhile, the harm to compact block propagation caused by not enabling full-rbf can be seen as a bug that should be fixed.

[petertodd]

Yeah it might be too much zeal, yet I’ve been surprised when the option was introduced with 24.x how much services were still claiming to rely zero-conf acceptance.

Only one service, GAP600, claimed to still rely on zero-conf and they refused to actually provide any examples of clients actually using them. I think it's highly likely that GAP600 was actually a scam that took peoples' money and provided nothing of value. Us continuing to claim that zeroconf services still exist is actually helping perpetrate scams like GAP600.

Same, I’m not aware of any bitcoin industry traffic with real-traffic actually accepting unconfirmed transactions (apart of few LSPs with zero-conf, it’s a paradigm of its own and people running that are more savvy about unconf txn risks due to channel funding flow).

Zeroconf LSPs are a very different thing. The trust model is explicitly trusting the LSP not to double spend you while the channel is unconfirmed. Phoenix, as an example, uses the BIP125 opt-in bit on their zeroconf channel transactions, so full-RBF settings are irrelevant.

[fanquake]

I'm just going to backport the other two fixes here, and will follow up with any other changes before the next 27.x.

[petertodd]

@fanquake That's perfectly reasonable. Concept ACK.

[stickies-v]

ACK b06c4c6