Add optional esplora wallet setup for payjoin-cli backend#1469
Add optional esplora wallet setup for payjoin-cli backend#1469benalleng wants to merge 3 commits intopayjoin:masterfrom
Conversation
eaadeb3 to
ad2171a
Compare
|
The payjoin-cli help with esplora and bitcoind |
ad2171a to
c93e600
Compare
Coverage Report for CI Build 24149462551Coverage increased (+0.2%) to 84.533%Details
Uncovered Changes
Coverage Regressions4 previously-covered lines in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
ca9bb4b to
50b8c94
Compare
|
@benalleng should we only use the public esplora backend during testing? i.e error out of network == mainnet? Until ohttp wrapper is available bitcoindevkit/rust-esplora-client#145 . |
a3a1c2d to
11f18d8
Compare
This adds a new esplora feature to use a bdk wallet as the supporting backend for payjoin-cli to reduce the need for a bitcoind rpc connection when testing against integrations. This does retain the bitcoind functionality so we can continue to run local e2e tests during the payjoin-cli CI tests.
11f18d8 to
3c9ec25
Compare
|
what is the motivation for this? this is a bit of a privacy footgun, such servers learn a lot of clustering related information (esplora esp. over http2 or with http1.1 pipelining is equivalent to electrum's leaks in this regard, but even with separate connections per request due to transport layer metadata) that would make breaking payjoin privacy basically trivial by an adversarial server if one of the parties to the payjoin transaction queries their addresses with that server esplora over ohttp would improve matters but the temporal leak is still enough to be a concern allowing queries for different addresses over different OHTTP requests to still be linked temporally and used as the basis for clustering this seems like more code that then needs caveats and qualifications to be understood in a constructive way, and because the main purpose of a reference client is to demonstrate that seems counterproductive (especially since bdk-cli integration would kinda make this obsolete?) |
The motivation is mostly testing infrastructure. This is not intended to be anymore than a dev feature for internal use really. Bull bitcoin only has a way to use testnet3 and to then create a regular way to test against it and payjoin-cli as in SatoshiPortal/bullbitcoin-mobile#1978 we would need to spin up at least a pruned tesnet3 node which is not insignificant given its age. In yesterday's call we discussed looking into ways to find faster ways to spin up this node setup as there are plenty of wallets that do not support regtest so we don't always have an easy way to quickly do regression tests on them. One of the ways brought up was by simply removing the need for a node altogether. An alternative approach to solving this was finding or hosting ourselves a mirror of the chainstate for testnet3 and 4 so that we can quickly download and start a rpc node without having to do validation
While true I think if we want to have bdk-cli be a reliable benchmark to test against for other upstream wallets we need to really take ownership of the payjoin integration there long term if we want to trust bdk-cli <> upstream wallet as a valid test. (Not a totally unreasonable thing to do as we stabilize around 1.0 but we would need to keep a close eye on it) |
arminsabouri
left a comment
There was a problem hiding this comment.
This seems like potential techdebt. From what I understand the problem is BB mobile doesnt support regtest (only testnet3). How much harder is to setup a testnet3 node and run integration tests on that box? Perhaps this can be part of CI somehow
| Ok(signed_psbt) | ||
| } | ||
|
|
||
| fn can_broadcast(&self, _tx: &Transaction) -> Result<bool> { Ok(true) } |
There was a problem hiding this comment.
Does esplora support mempoolaccept ? I know blockstream versions does.
There was a problem hiding this comment.
no the bdk esplora doesn't, or at least not that I could find
spinning up an rpc node with testnet3 took me about 8 hours on my local machine |
|
i'm glad we did this experiment to see how much effort it is but it's definitely simpler to just run RPC and a pruned snapshot should do the job. the config ergonomics just add a ton we would need to maintain. |
|
why doesn't bb mobile support regtest? if it already supports testnet3 that implies it's not mainnet only so probably not a major change to add regtest and/or signet support? |
This adds a new esplora feature to use a bdk wallet as the supporting backend for payjoin-cli to reduce the need for a bitcoind rpc connection when testing against integrations. This does retain the bitcoind functionality so we can continue to run local e2e tests during the payjoin-cli CI tests.
proof that it works https://mempool.space/testnet4/tx/a964e01d71d9dd6349a5e3ec4411e3d45f2769197f507100c692ea0f96dd4292
Claude wrote most of this code.
For review the greatest change is in wallet.rs as much of the other changes are feature gates and naming imports differrently
Pull Request Checklist
Please confirm the following before requesting review:
AI
in the body of this PR.