Skip to content

backport: v0.26 bitcoin#28139, bitcoin#28232 - #65

Closed
DCG-Claude wants to merge 2 commits into
developfrom
backport-0.26-b054-test-functional
Closed

DCG-Claude wants to merge 2 commits into
developfrom
backport-0.26-b054-test-functional

Conversation

@DCG-Claude

Copy link
Copy Markdown
Collaborator

Automated Bitcoin Core v0.26 backports, batch backport-0.26-b054-test-functional.

upstream commit gates notes
bitcoin#28139 81f6e8f124 pick:pass build:pass tests:pass mech:warn tree:pass verify:pass The Dash commit reproduces upstream bitcoin#28139 in full: the locked-wallet case now creates, funds, encrypts, uses and unload
bitcoin#28232 7a37ac85d2 pick:pass build:pass tests:pass mech:warn tree:pass verify:pass Both upstream hunks land: the settxfee(self.min_relay_tx_fee) pin in test_locked_wallet and the replacement of the har

Skipped in this batch:

Failed gates (not included):

Provenance

Each commit passed: cherry-pick (adapted by an Opus lane only where conflicts existed), build, touched tests, a mechanical diff-of-diffs check (every upstream hunk landed; no added line without an upstream counterpart), and an independent Opus verification lane where anything was adapted. Gate rows and lane artifacts are in the backportsys DB.

…let case

c648bdb test: create wallet specific for test_locked_wallet case (furszy)

Pull request description:

  Coming from bitcoin#28089 (comment).

  Several test cases are relying on the node1 default wallet, which thanks to 'test_locked_wallet' is encrypted.
  And can be only accessed within a specific timeframe (100ms), a duration internally set by the same test.

  This situation introduces a potential race condition, where other tests must complete their operations within
  the specified 100ms window to pass (otherwise the wallet gets re-locked and they fail).

  This can be seen running the test in valgrind (bitcoin#28089), where other test cases fail due the wallet re-locking
  itself after the 100ms.

ACKs for top commit:
  MarcoFalke:
    lgtm ACK c648bdb
  ishaanam:
    utACK c648bdb

Tree-SHA512: 01cde5a4a0cb3405adb9ea3c1f73841f3fa237d1162268ed06f0d49ca38541006b423a029e0b5e5955e1aa7e018c4600d894e555a68cf17ff60a4b8be58f4aa9

Dash adaptations:
- test/functional/wallet_fundrawtransaction.py: kept Dash's `pkh(...)` descriptors instead of upstream's `wpkh(...)` (Dash has no segwit)
- test/functional/wallet_fundrawtransaction.py: kept Dash's `walletpassphrase(..., 999000)` timeouts instead of upstream's 10/100/600 — Dash already carries the later bitcoin#28403 which bumped these, so restoring the small values would regress it
- test/functional/wallet_fundrawtransaction.py: kept Dash's amounts (sendtoaddress 12, output 11, balance delta 511.0000000) rather than upstream's 1.2/1.1/51.10000000 — Dash's block subsidy and this test's amounts are 10x
- test/functional/wallet_fundrawtransaction.py: did not add upstream's `wallet.getrawchangeaddress()` (keypool drain) or `wallet.keypoolrefill(8)` lines — those lines do not exist in Dash's copy of this test (they were never introduced in Dash history); only the self.nodes[1]->wallet rename part of those upstream hunks applies
- test/functional/wallet_fundrawtransaction.py: changeless-tx fee deduction is `0.00000500` instead of upstream's `0.00002200`. Upstream's constant is exactly the fee of a 110-vB segwit tx at Bitcoin's test fallbackfee of 0.0002/kB; Dash's test fallbackfee/min relay fee is 0.00001/kB (1 duff/byte) and the tx is a legacy 1-in/1-out ~192 bytes, so the required fee is ~192 duffs. With 2200 deducted the 2008-duff remainder exceeds min_viable_change (discard fee 10000/kB * 148 B + 1 = 1481 duffs), so the wallet would demand a change output and `fundrawtransaction` would fail with -4 on the locked wallet instead of returning changepos -1. 500 duffs covers the fee and leaves 308 < 1481, giving the changeless tx upstream intends. Dash's old 2200 (with its stale 'bnb doesn't work same way as in bitcoin' comment) was sized for the previous multi-input selection and no longer applies now that the wallet holds exactly one UTXO; replaced by upstream's comments plus a one-line note about the value.
5364dd8 test: locked_wallet, skip default fee estimation (furszy)

Pull request description:

  Coming from bitcoin#28139 (comment).

  No test case in this file is meant to exercise fee estimation. All default wallets have a
  custom tx fee set [here](https://github.com/bitcoin/bitcoin/blob/b7138252ace6d21476964774e094ed1143cd7a1c/test/functional/wallet_fundrawtransaction.py#L100). The only one missing is the one created for `locked_wallet`.

ACKs for top commit:
  theStack:
    ACK 5364dd8

Tree-SHA512: 514c02708081d18330d759d10e306cee16c6350de243c68f0973777d2582f5d81968a237393c1f59aba245297e03f3f98d3ae5249a042469d0d016255f568719

Dash adaptations:
- test/functional/wallet_fundrawtransaction.py: import conflict resolved by keeping Dash's existing `satoshi_round` (still used at the outputs-value assertion in test_change_position) alongside upstream's new `get_fee`, in alphabetical order
- test/functional/wallet_fundrawtransaction.py: tx_size changed from upstream's 110 (p2wpkh->p2wpkh) to 192 (p2pkh->p2pkh) since Dash has no segwit — 4 version + 1 vin count + 148 input (36 prevout + 1 + 107 scriptSig + 4 sequence) + 1 vout count + 34 output + 4 locktime; 107-byte scriptSig follows from DUMMY_MAXIMUM_SIGNATURE_CREATOR(33,32) -> 72-byte DER sig plus a 33-byte compressed pubkey
- test/functional/wallet_fundrawtransaction.py: dropped the Dash-only comment explaining the hardcoded 0.00000500 constant, since upstream replaces that constant with an exact get_fee() computation and the comment no longer describes the code
@github-actions

github-actions Bot commented Sep 20, 2026 •

Copy link
Copy Markdown

Potential PR merge conflicts

This is advisory only. It does not block CI, but it marks PRs that will likely need a rebase depending on merge order.

If these PRs merge first

This PR will likely need a rebase:

@DCG-Claude

Copy link
Copy Markdown
Collaborator Author

folded into backport-0.26-b061-misc: its commits ship there

@DCG-Claude DCG-Claude closed this Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant