DO NOT MERGE: Send & Receive payjoin v2 working reference#344
Closed
DanGould wants to merge 28 commits intoSatoshiPortal:mainfrom
Closed
DO NOT MERGE: Send & Receive payjoin v2 working reference#344DanGould wants to merge 28 commits intoSatoshiPortal:mainfrom
DanGould wants to merge 28 commits intoSatoshiPortal:mainfrom
Conversation
DanGould
force-pushed
the
send-payjoin
branch
from
a276d2d to
1d619ce
Compare
Contributor
Author
|
Rebased on main but still incomplete. All commits up to 3bc6064 build and run |
Contributor
Author
|
I figured out how to send the specific data back and forth across the isolate boundary. It's not super ugly but there's a lot of boilerplate serialization code. I got most of the checks to pass this way, and I'm sure signing would work this way, based on how the two regions of memory and threads are interacting, but I need getCandidateInputs List data to somehow be serialized across this boundary. I think this is the last hurdle to get receiving actually working |
DanGould
changed the title
DanGould
force-pushed
the
send-payjoin
branch
2 times, most recently
from
3bba3cc to
d8f42c7
Compare
If the Default Payjoin setting is enabled, fetch a Payjoin endpoint and set it in the BIP21 URI (the Payjoin endpoint is hardcoded for now).
Parse the payjoin endpoint as a URI and add it to SendState.
but I don't know if it works yet because we haven't the smoke testing framework set up yet.
This is still broken because as far as I can tell the signer will not sign with a missing RedeemScript / WitnessScript. And those are missing.
really @b9d5af6
InputPairs seem not to be able to send across the boundary. But this separates sending secrets from crossing into a payjoin isolate. Sending happens on main.
With main / isolate separation so that signing can happen in the main thread
DanGould
force-pushed
the
send-payjoin
branch
3 times, most recently
from
20371d0 to
f54bde7
Compare
✅ passes send-receive smoke test
Contributor
Author
|
Closed because this functionality has been merged elsewhere |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This draft is the basis for e2e Payjoin V2 support.
The Sender contains all logic to create PSBTs to fulfil a given bitcoin URI and respond to updates.
The Receiver creates bitcoin URIs and listens for messages to receive sessions it spawns.
A Payjoin Manager depends on NetworkCubit and spawns isolates to run payjoin sessions concurrently. This should spawn persisted sessions on startup, pause them when the app goes to the background, and resume them when it comes to the foreground. (Eventually background processes can be run but that's for later).
This is DRAFT. I plan to rebase into a nice reviewable history.
There are 1 or 2 bugs remaining in the way of an end to end demo
1
The receiver won't finalize and sign the proposal PSBT. I believe that's because the PSBT produced by the payjoin receiver state machine doesn't have the non-witness UTXO details (redeem script or witness script) and I'm not sure yet how to get them out of bdk. One hacky way to do so is to build a faux transaction with the TxBuilder if this method were exposed. Another way would be to derive it from the appropriate descriptor.
EDIT Mon Dec 16 21:15:43 2024 UTC
The reason it's not signing is because I'm not supplying witness_script NOR bip32_derivation information with the PSBTin to the finalizer, and bdk.Wallet.sign() requires one or the other to be present if trustWitnessUtxo: true.
With trustWitnessUtxo: false, the non_witness_utxo data is required.
I beleive the way around this is to expose
get_psbt_input(LocalUtxo: utxo) -> Inputfrom bdk-flutter such that we have access to at least the witness_script for a given LocalUtxo. @BitcoinZavior I'm going to work on a fork of bdk-flutter to get this in ASAP. I think this functionget_psbt_inputis exposed but thepsbt::Inputtype doesn't expose sufficient information about its contents. Input details aren't exposed in bdk-ffi either, so this is going to require a bit of digging but is definitely possible to pull out2
I believe we may run into another issue on the sender side at signing where our app will need to reintroduce UTXO data the receiver removes. Bitcoin Core does this on its own, but BDK, at least this old version, does not
Finally, the current implementation fully triggers payjoin sends on the first send screen rather than building the psbt and only launching the payjoin on the Confirm Transaction screen, and then does not differentiate on the Success screen even though the transaction is only communicated to the receiver and not broadcast. We must differentiate for clarity.
My plan is to solve the signing bugs tomorrow. Any help getting the UI and flow into place would be great. Once we get these, we should be able to move on to ensuring that history is displayed properly, showing net flows for Payjoins.