
{"id":241066,"date":"2026-10-19T06:24:36","date_gmt":"2026-10-19T06:24:36","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=241066"},"modified":"2026-10-19T06:24:36","modified_gmt":"2026-10-19T06:24:36","slug":"bdks-electrum-txid-check-took-171-days-to-ship-and-5-of-the-9-crates-using-it-cant-get-it","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=241066","title":{"rendered":"BDK\u2019s Electrum txid check took 171 days to ship, and 5 of the 9 crates using it can\u2019t get it"},"content":{"rendered":"<h4>The fix is one comparison. Only bdk_electrum 0.24.1 has it, there\u2019s no fixed 0.23, and LDK Node shipped on 0.23 eight hours\u00a0later<\/h4>\n<p>In BDK\u2019s Electrum client, the loop that gathers fee data for a wallet has a comment on line 588 of the 0.23.2 source that says exactly what it should\u00a0do:<\/p>\n<p>let prev_tx = self.fetch_tx(outpoint.txid)?;<br \/>\/\/ Ensure server returns the expected txout.<br \/>let txout = prev_tx<br \/>    .output<br \/>    .get(vout as usize)<\/p>\n<p>The only check under that comment is that output number vout exists. Nothing checks that prev_tx is the transaction the wallet asked for. fetch_tx sends a txid to the Electrum server, takes back whatever transaction the server returns and caches it under the txid it asked for. The output then goes into a map keyed by the outpoint the wallet asked about, and that map is where BDK gets input values when it works out the fee on a transaction whose inputs the wallet doesn\u2019t\u00a0own.<\/p>\n<p>So for a parent the wallet doesn\u2019t already hold, a server could answer with any transaction that has enough outputs, and its amount would become that input\u2019s value in the wallet\u2019s fee numbers. That\u2019s as far as I can follow it in the code. fetch_tx also serves the wallet\u2019s own history, and I haven\u2019t traced what a swapped transaction does on that path, or run any of this against a server that\u00a0lies.<\/p>\n<p>bdk_electrum 0.23.2 against 0.24.1: where the server\u2019s answer was trusted, and the check that 0.24.1\u00a0adds.<\/p>\n<h3>One comparison, merged in\u00a0April<\/h3>\n<p>The fix is six lines in fetch_tx: compute the txid of what came back and return an error if it isn\u2019t the one requested. It was merged to master on 24 April as PR\u00a02188.<\/p>\n<p>Master isn\u2019t what gets published, though. bdk_electrum 0.24.0 came out on 8 May without the check; I diffed the published sources, and its fetch_tx is the same as 0.23.2\u2019s. The backport, PR 2228, was merged on 16 June into a branch called release\/chain-0.23.x, and that name nearly caught me out. I read it as the 0.23 line getting the fix. It\u2019s the release branch for bdk_chain 0.23, and bdk_electrum\u2019s 0.24 releases come off it. The fix sat merged there for 118 days, until 0.24.1 was published on 12 October at 05:29 UTC, 171 days after it first\u00a0landed.<\/p>\n<p>From merge to release: 171 days, 118 of them merged on the branch that 0.24.1 was cut\u00a0from.<\/p>\n<h3>Who can\u2019t take\u00a0it<\/h3>\n<p>Cargo treats 0.23 and 0.24 as incompatible, the way it treats any minor bump before 1.0. A crate that asks for bdk_electrum 0.23 gets 0.23.2 at most, and no 0.23 release has the check. Moving to 0.24 also moves electrum-client from 0.24 to 0.25, so it takes an edit to the manifest, and cargo update won\u2019t do\u00a0it.<\/p>\n<p>crates.io lists 11 crates that depend on bdk_electrum. Two use it only in tests. Of the other nine, five ask for 0.23 and four for 0.24. LDK Node is one of the five. Its 0.7.1 release came out at 13:53 UTC on 12 October, eight hours and 24 minutes after 0.24.1, still on bdk_electrum 0.23, and it asks for previous outputs in both its sync and its full scan. It does fill the client\u2019s cache from its own wallet first, so parents it already holds never go to the server. fedimint-ldk-node 0.7.0 asks for 0.23 too. LDK Node\u2019s main branch has moved to 0.24.0, which resolves to 0.24.1 on a fresh lockfile, so its next release should carry the\u00a0check.<\/p>\n<p>The nine crates on crates.io that depend on bdk_electrum outside tests, by the version they ask\u00a0for.<\/p>\n<p>Downloads tell it from the other side. On 13 October, the first full day 0.24.1 existed, crates.io counted 2,050 downloads of bdk_electrum, and 530 were 0.24.1. 799 were 0.23.2, the last of the line that has no fix. Downloads are CI runs and mirrors as much as people, so I wouldn\u2019t read them as users, but they\u2019re the only count there\u00a0is.<\/p>\n<p>Daily crates.io downloads of bdk_electrum, split by whether the version has the txid check. 14 October is\u00a0partial.<\/p>\n<p>The case where any of this matters is a node pointed at an Electrum server somebody else runs. I don\u2019t know of a way to count LDK Node deployments set up like that. Until LDK Node ships a release on 0.24, the apps built on it can\u2019t get the check without patching LDK Node\u00a0itself.<\/p>\n<p><a href=\"https:\/\/medium.com\/coinmonks\/bdks-electrum-txid-check-took-171-days-to-ship-and-5-of-the-9-crates-using-it-can-t-get-it-1af950a999d9\">BDK\u2019s Electrum txid check took 171 days to ship, and 5 of the 9 crates using it can\u2019t get it<\/a> was originally published in <a href=\"https:\/\/medium.com\/coinmonks\">Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"<p>The fix is one comparison. Only bdk_electrum 0.24.1 has it, there\u2019s no fixed 0.23, and LDK Node shipped on 0.23 eight hours\u00a0later In BDK\u2019s Electrum client, the loop that gathers fee data for a wallet has a comment on line 588 of the 0.23.2 source that says exactly what it should\u00a0do: let prev_tx = self.fetch_tx(outpoint.txid)?;\/\/ [&hellip;]<\/p>\n","protected":false},"author":0,"featured_media":241067,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-241066","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/241066"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=241066"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/241066\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/241067"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=241066"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=241066"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=241066"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}