Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PayJoin #1262

Open
hsjoberg opened this issue Jul 4, 2023 · 2 comments
Open

PayJoin #1262

hsjoberg opened this issue Jul 4, 2023 · 2 comments
Milestone

Comments

@hsjoberg
Copy link
Owner

hsjoberg commented Jul 4, 2023

No description provided.

@hsjoberg hsjoberg added this to the 0.7.0 milestone Jul 4, 2023
@DanGould
Copy link

DanGould commented Jul 5, 2023

Thanks for bringing up this issue. I see two sane approaches to integrating send support as you mention on Telegram

1. TypeScript bindings to WASM Swift/Kotlin Payjoin Dev Kit

Boltz's @michael1011 has expressed support for a WASM bindings library based on PDK's rust-payjoin. WASM bindings are special in that they'd run just like any other npm library and would not require a separate process or thread to run like Tor would. BDK's React Native Bindings build on Swift and Kotlin bindings generated with UniFFI with a neat TypeScript wrapper. PDK is a complete payjoin kit and has all the features tested so we can collaborate on reliability and security. Originally I thought WASM would do the trick, but that doesn't work the same way in react native as in the browser. The best part about this work imo is that @kaloudis could use it for Zeus, too. Disclaimer: I'm biased since I maintain PDK and have been following BDK bindings for a while.

The advantage of this is that it is actively maintained, has an LND reference implementation, and the base library supports receiving. Receiving is a huge boon for Lightning Payjoin fee & time savings. PDK supports coin selection and error handling so Blixt could depend on that. Since we have Serverless Payjoin on the roadmap Blixt would be able to take advantage of that technology as early as it gets merged in the library. Blixt already supports Tor so receiving via ephemeral .onion would be straightforward to implement from these bindings based on Onion '78 or JoinMarket should the desire to receive be so great that it is accelerated on the roadmap.

The main disadvantages are that it will take some time to develop and bindings have not been tested yet.

A signal of interest from Blixt will bump the priority of a WASM bindings implementation based on what was learned developing BDK's WASM bindings proof of concept.

2. The payjoin-client JavaScript Library

payjoin-client is what BlueWallet uses, and it works alright. Blixt could marry LND's PSBT protocol with the JavaScript library to send Payjoin. However, the library only supports sending and there is no active maintenance or roadmap to add receiving capability going forward

3. DIY roll your own.

JoinMarket has rolled their own Payjoin implementation, but its ability to negotiate fees and handle errors is limited. From what I gather having worked with the source code a number of times, it expects a happy path that creates Payjoins with exactly 2 outputs. It's so tightly coupled to the implementation that JAM's JoinMarket UI, which has been around for years, is still unable to support Payjoin.


Thanks again for bringing this up and planning to integrate Payjoin. I'm looking forward to hearing your opinion of these options and any I may not have thought of.

@BitcoinZavior
Copy link

This sounds amazing, I would love to have Flutter and React Native implementations of PDK. Currently we have BDK and LDK Node for Flutter and React Native, you can refer to them here: https://github.com/LtbLightning

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

No branches or pull requests

3 participants