No std

[DanGould]

Conform to wasm restrictions for MutinyWallet/mutiny-node#194

bitcoin/rand is a reexport of secp256k1/rand which is no-std

@TonyGiorgio I think these are the changes you're looking for

[TonyGiorgio]

I tested this branch out but it looks like that version of bip21 is pulling in std for bitcoin:

├── payjoin feature "send"
│   └── payjoin v0.8.0 (https://github.com/DanGould/rust-payjoin.git?branch=no-std#d79c5493)
│       ├── bitcoin v0.29.2 (*)
│       ├── base64 feature "default" (*)
│       ├── log feature "default" (*)
│       ├── url feature "default" (*)
│       └── bip21 feature "default"
│           └── bip21 v0.2.0
│               ├── bitcoin feature "default"
│               │   ├── bitcoin v0.29.2 (*)
│               │   ├── bitcoin feature "secp-recovery" (*)
│               │   └── bitcoin feature "std"

Maybe try bip21 v0.3.0 ? @benthecarman added no-std support recently: Kixunil/bip21@8113919

[DanGould]

Rats, we're waiting on @Kixunil to release a new version of bip21 removing bitcoin default-features

[TonyGiorgio]

Ah, for some reason I thought we were already using that library.

[Kixunil]

This doesn't work since you don't have #[no_std] in lib.rs, after which I expect more things to break, you'll see.

I originally didn't bother with no_std because I expected that payjoin is effectively impossible/impractical without OS but WASM is a good counterargument, so concept ACK.

I will look into releasing BIP21 soon.

[Kixunil]

FYI I came across this: https://users.rust-lang.org/t/is-disabling-features-of-a-dependency-considered-a-breaking-change/94302

Will give it some time for people to reply and decide afterwards.

[DanGould]

@cryptoquick, How come bitmask-core has no problem with std payjoin and bitcoin crates? Don't you build it with wasm_pack?

[cryptoquick]

Sure, we use std with WASM, works great!

For those curious:
https://github.com/diba-io/bitmask-core

[benthecarman]

Yeah we have to use no-std for mutiny because ldk expects you to have system time unless you are no std

[Kixunil]

@benthecarman IIUC you could just deactivate std in LDK and keep it in payjoin. It should work despite looking weird. And for not looking weird part, based on the discussion I will release a non-breaking release.

[Kixunil]

I've released bip21 0.3.1.

[DanGould]

I just published payjoin-0.8.1 with bitcoin-0.30.0 and bip21 0.3.1.

IIUC you could just deactivate std in LDK and keep it in payjoin. It should work despite looking weird. And for not looking weird part, based on the discussion I will release a non-breaking release.

Does this work in your wasm setting @TonyGiorgio? You can see from the updated draft, as Kixunil said, no-std here is more involved than I thought. I'd definitely run a mutinynet payjoin receiver at payjoin.org and a new version of relayed payjoin is getting ready to drop, too.

[TonyGiorgio]

Cool thanks! It looks like 0.8.1 works when I include it in my cargo and run a build.

TBH some of the rust dependency hell confuses me sometimes. Can't tell if its sometimes just problems with wasm-pack, LDK, or general rust.

mutinynet payjoin receiver at payjoin.org

Would love that! Also been meaning to ask, we've worked out a way to do p2p connections from mobile going through a websocket proxy. If we had two peers talking to each other, would it be possible with this library to get them to do a payjoin when one is paying the other? I haven't looked too deeply at the API's yet but at least for paying a server it should be no problem.

[DanGould]

If we had two peers talking to each other, would it be possible with this library to get them to do a payjoin when one is paying the other? I haven't looked too deeply at the API's yet but at least for paying a server it should be no problem.

Yes. There are 2 caveats to look out for

1. the body is unencrypted/unauthenticated, so without something like "serverless payjoin" upgrades you're placing a lot of trust in the coordinator (not to snoop or MITM attack by changing in-flight psbt) and
2. I'd look out for bip21 compatibility. Ideally whatever you proxy doesn't break that. what I have in mind is the receiver allocating space on a proxy with websockets on a server that listens to http concurrently. That way old bip78 senders can still send to the receivers listening to the relay.

Because of caveat 1, it might be best to release this to production until the encryption & authentication is dealt with, but I'd love to see a mutinynet rollout of a relay like you describe to prove the concept and later have as a fallback

p.s. a final consideration I forgot to mention for a new protocol is asynchrony. It solves so many ux problems.

[Kixunil]

Hmm, for a while I was thinking about PayJoin v 2.0 and I'm now convinced we should do it. I will discuss with folks at dev/hack/day. @DanGould we could do some sort of video call I guess.

[DanGould]

Hell yes. I'd like for us to have a v2 document drafted to talk about. I made an unencrypted public payjoin matrix room to organize https://matrix.to/#/%23payjoin%3Amatrix.org

[DanGould]

Looks like Mutiny and other wasm projects can use this library without no-std, so I'm closing this to avoid maintaining complexity until it becomes necessary.