Support Bustapay (bip79)

[RHavar]

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

Here's the spec: https://github.com/bitcoin/bips/blob/master/bip-0079.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.

[SomberNight]

How is the partially signed txn serialised? Is it a PSBT? If so, that's not implemented yet (#4615).

[RHavar]

@SomberNight No, it doesn't use PSBT. I originally built a version with PSBT, but it was just overly complex and really provided no benefits.

What the client sends the bustapay server is a normal (fully signed) segwit transaction (i.e. the exact same thing you'd normally push on the network). So that part is easy. Then the server response with a raw partial transaction, an example would be:

0000000000010387014e780e16429d5dcfef196e80a1de19d6e5021f387908510fed5e3aadb21b01000000171600140240cce0051aa5cf8ab9d7796c5b03e338582f58feffffffd431a9704c8d6656fde860bc408f100b6a808da6590c58248ab23810cc5f7d9a0000000017160014f4a803a3d76b54b8cf94877c7f99a2076b110db1feffffffd431a9704c8d6656fde860bc408f100b6a808da6590c58248ab23810cc5f7d9a0100000017160014ba6a97198a04900e6d4aea160a870f03ba4a1e1dfeffffff02809698000000000017a914cf45e5da2391114a61590872931e3ac0e0edbfc387c2a62e6a0000000017a914f57ec68c94cf2f08d0d80589533e22a02f672f8c870247304402200bda0947a265784282cab8bd51cd7fcbccaa5c427acae02abaca2246be88972f0220164f168644561fc496e0bc93bdec7ba2a0a21cf492b4a8eaa8cb348db5652e09012102c9a38f2e40e25a09930275588171366f7bb3cc35a55ff03ad42feb612dde0422000000000000

The unsigned inputs are the same from the original transaction, just this time need to be resigned. So the client resigns it, and then pushes it on the network. The client already has enough information to resign, on account of it having done it in the first place. There's really not much to it, except the "validation" where you make sure the partially-signed transaction the server sends you is non-malicious (you can see what the validation looks like, checking the partial transaction against the original). But even that is a fair bit easier than you'd imagine, as you don't need to validate the servers inputs (if they're invalid, the transaction will just not propagate). You really just need to make sure: a) the outputs are the same (except the amounts may increase) and b) all your original inputs are there, and you are only (re)signing those original inputs.

[SomberNight]

Ok. In that case I don't see any major hurdles.
If someone contributes an implementation, it can get merged.
(to be clear, I mean the client-side; i.e. sending)

[ecdsa]

Note: we can do the receiver side too, since a http server is integrated to the client.
(note that this requires tx validation for step 1)

[SomberNight]

closing in favour of #6585