Wasabi support for bustapay (client/server coinjoin)

[RHavar]

It would be great if Wasabi could support sending bustapay payments.

Here's the spec: https://github.com/RHavar/bips/blob/master/bip-bustapay.mediawiki

It's actually a pretty straight forward protocol, that's a bit easier to develop than it looks -- and offers pretty powerful privacy improvements.

I have somewhat of a reference implementation here, which is pretty easy to follow along:
https://github.com/RHavar/bustapay/blob/master/send/send.go#L16

And to save anyone the trouble of setting up a bustapay receive server, I have one already running on testnet: http://test.bustapay.com

e.g. with the reference client you can go:

bustapay send $(curl http://test.bustapay.com/get-newish-address) http://test.bustapay.com  0.01

which would make a 0.01 BTC bustapayment to a (new) address on that server. I'd also love any feedback before that spec is fully finalized.

(And most importantly, I have some buy-in from some bitcoin services, so it actually stands a chance of achieving some adoption)

[nopara73]

You can find my take on P2EP here. where you can find many of the things I write down here. With that out of the way.

I don't think Bustapay in its current form is a good idea, because

1. server learns too much,
2. receiver learns too much
3. sender spy may not be sufficiently addressed
4. it disrupts current UX workflow

Issue 2

receiver learns too much

The concern of mine is generally with sender-receiver P2EP is that the receiver learns too much, too, if there is a no trust (from a privacy point of view) relationship between the sender and the receiver. However I tend to not care too much about this, since the benefits outweigh the cons. Anyway, I just wanted to mention it, back to Bustapay.

Issue 1

server learns too much

IMO the server should concentrate on matching, rather than coordinating. If the server wants to coordinate, maybe a Chaumian CoinJoin-like scheme could somehow prevent information link (maybe not.) Of course both matching and coordinating makes the scheme more complex, so there's that.

Issue 3

sender spy may not be sufficiently addressed

Unfortunately when we came up with P2EP sender receiver scheme, most of our work concentrated on how to prevent the sender to spy on known receivers.

To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo.

We've considered this, and I tend to agree that, if the implementation is correct (and no RBF used, that's missing from the BIP) then it is probably good enough.
Interestingly there's a perfect way to fix this issue with Bulletproofs, which I won't pretend to understand fully. (Tim Ruffing came up with the idea and Adam Gibson was one of those who understood it, so you may ask them if interested.) Generally I think a simple cut and choose is just sufficient and much simpler.
But I give it to Bustapay, since this is an edge case, it may not worth to overcomplicate this issue, until it really becomes one. For example in JoinMarket, the mere notion that the dos attacker had to expose its UTXOs stopped the DoS attack entirely. Yeah, I think what you say is sufficient.
Another way to handle this is that the receiver doesn't just automatically receive coins, but rather every time it'd receive it must click "ok I'm receiving it" manually, but that disrupts the workflow the user is used to. Speaking of UX.

Issue 4

it disrupts current UX workflow

What would be ideal is that the receiver simply gives a bitcoin address, as always. The sender from that address tries to compute an endpoint and if it succeeds to establish a P2P connection it progresses with P2EP sender-receiver scheme without a server, otherwise it sends a normal Bitcoin transaction. Users wouldn't even know they use P2EP. Such "ideal" workflow is however a lot of work. It probably even needs a special purpose anonymity network to be built for it.

Failing the above things, my current thinking on how Wasabi could solve all those issues above is the following:

P2EP in Wasabi

Step one Wasabi could do is to build a simple Friend CoinJoin Network. Here every user would expose an onion endpoint and could add each other as friends in the wallet. However they should only add friends if they are trusting them with their privacy.
This way, friends could send to each other in two ways (maybe randomly:)

• sender-receiver scheme
• avoiding coin merging.
  And when someone sends outside of its friend network, then it could ask friends to add some coins to their transactions.

Here, everything could happen on the background and Wasabi users would be motivated to invite people, since the more friends you have the better your privacy will be.

It may also be important to note that the assumption that friends trust each other with their privacy is not as strong as it sounds. They simply share coins in the same transaction once in a while (more friends there are, the less likely you reuse a friend.)
However this assumption simplifies schemes greatly. And, while it wasn't a design choice, an added plus that there's no need for server at all, it's just P2P communication without leaving the onion network.
I'm 90% sure this can be done. Failing it, I think the "ideal is that the receiver" scheme that doesn't disrupt the workflow could be pursued, failing that Bustapay can be considered if Issue 1 is solved. That being said, Issue 4 may still be a preventing factor, since it's hard enough to explain users coin control, introducing additional ways to receive may be really confusing.

[RHavar]

A lot of what you say is definitely valid, but I think you might be missing the larger point. Bustapay is just supposed to be a simple and practical protocol, not something ideal. As testament to this simplicity, I volunteered to implement receiving bustapayments in an existing commercial service (admittedly whos code-base I have some familiarity with) and it took me about ~1 day, and ~1 day of testing (although they have been reluctant to deploy it prior to wallet support. So a bit of a chicken-and-egg situation)

1. server learns too much,
2. receiver learns too much

Just to be clear, they're expected to be the same party. The sender should be communicating directly with the receiver. The receiver never learns more than they would learn from a normal bitcoin payment.

Just to reiterate, a bustapay is not designed as some "super secure anonymous payment protocol", just a better and practical alternative to a normal bitcoin send.

3. sender spy may not be sufficiently addressed

Valid point. If hypothetically bustapay was very widely adopted, a sender-spy could simultaneously make a payment to N services, and only pay the cost of spending a single-utxo. If this happens, it should be pretty easily to detect and I have some ideas of how to make this harder. But introducing complexity for it right now I think is putting the cart before the horse.

4. it disrupts current UX workflow

I agree with your assessment, but as you said yourself:

Such "ideal" workflow is however a lot of work. It probably even needs a special purpose anonymity network to be built for it.

But again, it's important to recognize that bustapay is trying to be a better alternative to a normal bitcoin transaction. If there's something better, it should of course just use that.

[nopara73]

Just to be clear, they're expected to be the same party.

I see, I thought the sender and the receiver communicates through bustapay server. In this case, the sender has nothing to lose, just gain privacy, while this cannot be said to the receiver in case of sophisticated spy attacks, it doesn't matter for Wasabi users, since they are always senders. So I'm thinking of a working plan like this:
First BIP21 must be implemented (WalletWasabi/WalletWasabi#732) and then extend it with Bustapay.

I'm not exactly sure how to implement BIP21, but I guess if there's a bitcoin: url then it automatically fills out the relevant boxes in the GUI. Bustapay would not change anything, just in the background we'd recognize, hey, it can be a sender-receiver transaction, then why not use that.

Am I correct? If so, when we get to BIP21, we'll likely merge the work with bustapay. I added this to the meta.
(Mental note for me: look at BIP70, Payment Codes and Stealth when the work is about to come. I generally don't support many of these things, but if they can be implemented without Wasabi users privacy leak or ruining UX workflow, then my ideology is secondary compared to usability.)

[RHavar]

Yup! That all is right!

In this case, the sender has nothing to lose, just gain privacy,

The only minor note I'll add is that the sender might lose some privacy by directly connecting to the sender in terms of revealing their ip address. For 99% of the time the that's not going to be an issue, as the person is already using the site and the site knows their ip address anyway.

But I can think of a few edge-cases like "donation addresses" (e.g. normally you would not be able to associate an ip address with a donation to you), or someone who is using a browser-based proxy (but not system wide) and the bustapay reveals their ip, etc.

The obvious solution would be to connect to the receiver via tor to protect your ip address -- but I think in practice many targeted sites have just had to block tor because of the volume of malicious traffic. An alternative would be giving the user a warning about revealing their ip address, and the option to opt-out to do a normal bitcoin transaction broadcast

[nopara73]

The only minor note I'll add is that the sender might lose some privacy by directly connecting to the sender in terms of revealing their ip address.

Not an issue. Wasabi ships with Tor.

[nopara73]

@RHavar Any chance to bring back test.bustapay.com online? @Kukks @MaxHillebrand

[MaxHillebrand]

@Kukks has an initial POC branch!
Kukks/WalletWasabi@56bba9d

[Kukks]

Some notes on that branch:

• cheated by just taking the .Result from async methods to not refucktorize your code
• the payjoin endpoint textbox should be hidden unless a BIP21 is pasted with the endpoint( and removed if pasted without one)
• not tested :)

[nopara73]

As soon as you're ready to make the PR, I'm ready to fix it up and approve.

The "not tested" part is the only thing that's problematic. It's not tested because there's nothing to test against, huh? You should leave the others to me.

[Kukks]

I can test it locally on regtest against my btcpay payjoin PR. Ill deploy a testnet server today Most of the code(the response handling) is almost a copy pasta from the wallet side in BTCPay though, which I have test coverage on.

[MaxHillebrand]

@Kukks this is great, I'll try it out with your server asap.
can wasabi client become a receiving server too?

[Kukks]

Not easily. Wasabi would first need to be able to generate bip21 payment requests (along with storing them and viewing their status...aka BTCPay Invoices :P ) Then you would need to port all the payjoin state management, protection and detection. You already have tor in there but you will need to have a persistent hidden service endpoint so that when you generate a p2ep enabled bip21, the endpoint is reachable between wasabi restarts.

…

On Wed, 4 Mar 2020, 10:42 Max Hillebrand, ***@***.***> wrote: @Kukks <https://github.com/Kukks> this is great, I'll try it out with your server asap. can wasabi client become a receiving server too? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN357VSC2UKISDK5YMFNV3RFYPBBANCNFSM4F4L26PA> .

[nopara73]

I don't want Wasabi to support the receiver side as I think there's a better opportunity to do that after Taproot is activated that is compatible with current Bitcoin workflow: https://gist.github.com/NicholasTailor/b075ac92c22923c33eddfa38488719d6

[RHavar]

@nopara73 I kind of gave up on it (not because it's bad, just because getting a critical mass of adoption in both the send and receive case is too hard). That said the software is still at:

https://github.com/RHavar/bustapay

and is pretty trivial to run/debug.

I know that bustabit/bustadice used to support bustapay in production, but I'm pretty sure it's no longer running as so few people used it.

[Kukks]

@RHavar BIP79 support on BTCPay at btcpayserver/btcpayserver#1321
This should be a better bootstart to the payjoin ecosystem with a widely deployed Bitcoin merchant solution that also sports non-custodial sending support with harwdare wallet support( all of which works with BIP79).

I did "amend" the specs to also support PSBT and also not call it "bustapay" which just made it sound silly (no offense).

I'll deploy a testnet server at payjoin-testnet.kukks.org soon (dealing with some possible exploit scenarios first)