wally: update libwally to v1.5.6
What the developer wrote
Authored by daywalker90
wally: update libwally to v1.5.6
This got fixed in libwally v1.5.2: https://github.com/ElementsProject/libwally-core/commit/7e483c049b0a4405801f010e60c9f0335d2a617f
```
def test_sign_signed_psbt(node_factory, bitcoind, chainparams):
l1 = node_factory.get_node()
l1.fundwallet(10**6)
psbt = l1.rpc.txprepare([{l1.rpc.newaddr('bech32')['bech32']: 10000}])['psbt']
signed_psbt = l1.rpc.signpsbt(psbt)['signed_psbt']
if TEST_NETWORK != 'liquid-regtest':
# FIXME: ideally this would succeed, as a noop. But it shouldn't crash
> with pytest.raises(RpcError):
^^^^^^^^^^^^^^^^^^^^^^^
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
```
Changelog-Changed: Update libwally to v1.5.6
Changelog-Fixed: JSON-RPC: `signpsbt` on an already-signed PSBT with taproot paths now succeeds as a no-op instead of failing.
What changed, and why it matters
This commit updates the bundled libwally library to version 1.5.6. The practical effect is that calling the JSON-RPC `signpsbt` command on a PSBT that is already signed now succeeds as a harmless no-op, instead of returning an error on Bitcoin networks. The underlying bug was in libwally's handling of duplicate Taproot keypath entries and was fixed in libwally v1.5.2.
Verify the libwally-core submodule points to a v1.5.6 tag or trusted commit, run the updated regression test, and consider whether any downstream tooling relied on the previous error behavior for already-signed PSBTs.
Security signals we found
Dependency update to incorporate upstream bug fix
Behavior change from error to no-op on re-signing signed PSBTs
Taproot keypath handling change in upstream cryptographic library
Regression test updated to reflect new expected behavior
Evidence from the diff
The change bumps the external/libwally-core submodule to v1.5.6 and updates the test_sign_signed_psbt regression test. Previously, re-signing an already-signed PSBT raised an RpcError on non-Liquid networks because libwally treated duplicate Taproot keypath entries as an error. libwally v1.5.2 changed this behavior to ignore duplicate keypath entries, making re-signing a no-op. The test now asserts that signpsbt returns the same PSBT unchanged on both Bitcoin and Liquid.
Changed components
external/libwally-core (submodule)JSON-RPC signpsbttests/test_wallet.pyInspect captured patch +7 / −8
diff --git a/tests/test_wallet.py b/tests/test_wallet.py
index 1e7e2a0..54e6b55 100644
--- a/tests/test_wallet.py
+++ b/tests/test_wallet.py
@@ -983,13 +983,12 @@ def test_sign_signed_psbt(node_factory, bitcoind, chainparams):
psbt = l1.rpc.txprepare([{l1.rpc.newaddr('bech32')['bech32']: 10000}])['psbt']
signed_psbt = l1.rpc.signpsbt(psbt)['signed_psbt']
- if TEST_NETWORK != 'liquid-regtest':
- # FIXME: ideally this would succeed, as a noop. But it shouldn't crash
- with pytest.raises(RpcError):
- l1.rpc.signpsbt(signed_psbt)['signed_psbt']
- else:
- # Non-taproot works fine.
- assert l1.rpc.signpsbt(signed_psbt)['signed_psbt'] == signed_psbt
+ # libwally >= 1.5.2 ignores duplicate taproot keypath entries
+ # (issue: ElementsProject/libwally-core#509,
+ # commit with fix: ElementsProject/libwally-core#7e483c049b0a4405801f010e60c9f0335d2a617f),
+ # so re-signing an already signed PSBT input is now a noop
+ # rather than an error, on both bitcoin and liquid.
+ assert l1.rpc.signpsbt(signed_psbt)['signed_psbt'] == signed_psbt
def test_psbt_version(node_factory, bitcoind, chainparams):
Why this scored 33/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.