BIP 79: Bustapay :: a practical coinjoin protocol

RHavar commented at 4:18 am on October 7, 2018: contributor

Requesting a BIP number assignment

RHavar force-pushed on Oct 7, 2018

Add bip for bustapay 605c31a9e0

RHavar force-pushed on Oct 7, 2018

in bip-bustapay.mediawiki:2 in 605c31a9e0 outdated

0@@ -0,0 +1,120 @@
1+<pre>
2+  BIP: 69

luke-jr commented at 8:51 am on October 16, 2018:

Please don’t make up BIP numbers.

in bip-bustapay.mediawiki:70 in 605c31a9e0 outdated

65+
66+The template transaction should be sent to the receiver via an HTTP POST to the bustapay url, with a binary encoded body.
67+
68+The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.
69+
70+Should the receiver reject a transaction, it should not attempt to propagate it on the network.

luke-jr commented at 8:54 am on October 16, 2018:

It seems like this is a problem. What happens if the receiver sends a 422 and then broadcasts it anyway? The user might try to pay again, possibly with different inputs, thinking that the first send failed…

in bip-bustapay.mediawiki:64 in 605c31a9e0 outdated

59+
60+== Specification ==
61+
62+The standard way of letting a sender know where to send a bustapay transaction is done via a bip21 encoded address. The key value "bpu" (short for "BustaPayUrl") should be used. An example such address would be bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bpu=https://bp.bustabit.com/submit  It is highly encouraged that urls are kept short.
63+
64+When the sender is creating a "template transaction" it is done almost identically to creating a normal send, with the exception that *only* segwit inputs may be used. The sender is also encouraged to use a slightly more aggressive feerate than usual as well as BIP125 (Opt-in Full Replace-by-Fee Signaling), but neither is strictly required.

luke-jr commented at 8:55 am on October 16, 2018:

Is it signed or unsigned?

luke-jr commented at 9:09 am on October 16, 2018:

Why only segwit inputs?

RHavar commented at 8:56 pm on October 16, 2018:

It is fully signed. This is important so the receiver can push the transaction onto the network (make it cost spending a utxo to learn one of the receivers utxos)

RHavar commented at 9:34 pm on October 16, 2018:

Simplicity/txid malleability.

The receiver needs to watch the network for the final payment, and needs to differentiate a normal payment and a bustapayment to the same address. So if there’s no transaction id malleability this is simpler as the final transaction will have the same txid as the partial transaction txid.

It definitely would be possible to support “legacy” transactions, just not worth the effort.

luke-jr commented at 10:46 pm on October 16, 2018:

As soon as a signed transaction is sent (even privately), we must assume the transaction has successfully completed, and cannot give the user the impression it failed.

in bip-bustapay.mediawiki:68 in 605c31a9e0 outdated

63+
64+When the sender is creating a "template transaction" it is done almost identically to creating a normal send, with the exception that *only* segwit inputs may be used. The sender is also encouraged to use a slightly more aggressive feerate than usual as well as BIP125 (Opt-in Full Replace-by-Fee Signaling), but neither is strictly required.
65+
66+The template transaction should be sent to the receiver via an HTTP POST to the bustapay url, with a binary encoded body.
67+
68+The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.

luke-jr commented at 8:57 am on October 16, 2018:

422 seems to be WebDAV-specific. I’m not familiar with WebDAV. Is this protocol compatible with it?

If not WebDAV-compatible, the only appropriate response I know of for this is 400.

luke-jr commented at 9:07 am on October 16, 2018:

Since the receiver is the most interested party to the transaction confirming, it would seem ideal for a norm where the sender does not contribute any fees (or perhaps only fees covering its inputs) and the receiver contributes whatever fees they desire.

RHavar commented at 8:58 pm on October 16, 2018:

It is not WebDav-compatible. I find it’s a lot nicer to use more specific error codes than 400, as something like 400 is frequently used by reverse-proxies and http libraries in general.

If you want, I’ll change it over to 400, but I think 422 is better.

RHavar commented at 9:23 pm on October 16, 2018:

The anti-spy/anti-DoS aspect of this proposal is based around the receiver being able to propagate the template-transaction if the sender doesn’t go through with the whole process. It’s now possible for a receiver to reimburse some of the txfees though by increasing the change amount (Although that’s not particularly reliable, as the sender doesn’t even need to use change).

luke-jr commented at 10:47 pm on October 16, 2018:

I suppose the BIP can itself define the 422 outside of the WebDAV context.

luke-jr commented at 10:51 pm on October 16, 2018:

I wonder if it might be appropriate to use SIGHASH_SINGLE or such so that the receiver can add its input/output and propagate the new transaction without going back through the sender…

RHavar commented at 10:54 pm on October 16, 2018:

That would be more robust against spies/DoS, but would make it obvious what is a bustapayment transactions and thus negate the primary privacy benefits bustapay offers

in bip-bustapay.mediawiki:82 in 605c31a9e0 outdated

77+
78+It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as much the other transaction inputs if possible.
79+
80+=== Output Adjustment ===
81+
82+After adding inputs to the transaction, the receiver will generally want to adjust the output that pays himself. This is the *only* output that the receiver should adjust. All other outputs *must* be left intact. The receiver *must never* decrease the amount they get paid nor increase, and generally not increase it by more than the contributed input amount.

luke-jr commented at 8:59 am on October 16, 2018:

I don’t understand “…nor increase, and generally not increase…”

RHavar commented at 9:06 pm on October 16, 2018:

I meant to write “generally should not”, i’ll rework this whole paragraph

in bip-bustapay.mediawiki:86 in 605c31a9e0 outdated

81+
82+After adding inputs to the transaction, the receiver will generally want to adjust the output that pays himself. This is the *only* output that the receiver should adjust. All other outputs *must* be left intact. The receiver *must never* decrease the amount they get paid nor increase, and generally not increase it by more than the contributed input amount.
83+
84+=== Returning the partial transaction ===
85+
86+The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200.

luke-jr commented at 8:59 am on October 16, 2018:

Content MIME types might be good to specify

in bip-bustapay.mediawiki:95 in 605c31a9e0 outdated

90+
91+The sender *must* do important validation on the partial transaction. They *must* verify:
92+
93+* All template transaction inputs are in the partial transaction (but perhaps different order) and have the same sequence numbers.
94+* The partial transaction contains at least one new (and signed) segwit input (owned by the receiver)
95+* All outputs from the template transaction exist in the partial transaction, except they are allowed to be reordered and have their amounts increased (but *never* decreased)

luke-jr commented at 9:00 am on October 16, 2018:

Should the sender verify that its change has not increased? That might be a confusing situation for the user.

RHavar commented at 9:15 pm on October 16, 2018:

Probably not a big problem, I’ve updated the “output adjustment” section to actually allow this situation – as I just don’t see it as a problem. And it might be kind of useful if a receiver wants to incentivize or reimburse users using bustapay (like refunding a “consolidation fee” that some services like bitpay put on the invoice)

luke-jr commented at 10:48 pm on October 16, 2018:

Someone using BitPay won’t be able to implement this BIP - only BitPay themselves could. And in that case, they can just not add the fee…

RHavar commented at 10:51 pm on October 16, 2018:

When bitpay creates an invoice they won’t know if you will pay via a normal transaction or bustpay. They have to always assume that a normal transaction will be used to make the payment, so the invoice amount will reflect that. But if the invoice is finally paid via bustpay, they could potentially offer a discount (if they wanted)

in bip-bustapay.mediawiki:99 in 605c31a9e0 outdated

94+* The partial transaction contains at least one new (and signed) segwit input (owned by the receiver)
95+* All outputs from the template transaction exist in the partial transaction, except they are allowed to be reordered and have their amounts increased (but *never* decreased)
96+
97+=== Creating Final Transaction ===
98+
99+After validating the partial transaction, the sender signs all its inputs to create what is now the final transaction. It is important that the sender is careful to not be tricked by the receiver into signing other inputs it owns. The sender must only sign inputs that existed in the template transaction. If the sender is not careful the receiver may "contribute" inputs that are actually owned with by the sender, with the hope the sender blindly signs everything.

luke-jr commented at 9:02 am on October 16, 2018:

What happens if both the sender and receiver have the same private key in their wallets?

RHavar commented at 9:17 pm on October 16, 2018:

Not really a problem. In the “reference implementation” it does support using the same wallet for both sending and receiving. As long as you verify the inputs were in the template transaction, as opposed to checking if you “own” them (like it says here).

luke-jr commented at 10:49 pm on October 16, 2018:

The receiver-contributed input won’t have been in the template transaction.

in bip-bustapay.mediawiki:31 in 605c31a9e0 outdated

26+
27+One of the most powerful blockchain analysis heuristics has been to assume all inputs of a transaction are controlled by a single party unless otherwise known (such as by the distinctive structure of a traditional coinjoin, or multisig spends that are validated onchain). Combined with other techniques (notably change-output guessing) this has lead to unexpectedly accurate tracking that has exposed bitcoin participants to unacceptable personal, business and financial risks -- undermining bitcoin's utility and fungibility -- and ultimately jeopardizing its ability to function as useful money.
28+
29+We however can bust these assumption, in a relatively simple way with a sender-receiver coinjoin. With our protocol we bypass many of the DoS and complexity problems that have plagued previous coinjoin protocols and hampered hopes of adoption. Besides being efficient and simple, bustapay most promisingly does have an identifiable structure for attackers, which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem.
30+
31+Bustapay transactions also they do not grow the receiver's count of unspent transaction outputs, and in fact gives the receiver an opportunity to better manage their utxo set, something normally only done when sending payments. Large utxo sets are often problematic and expensive, and frequently requiring privacy-destroying consolidation.  Besides busting clustering assumptions, bustapay also provides a layer of obfuscation of send amounts.

luke-jr commented at 9:05 am on October 16, 2018:

First sentence is nonsensical?

in bip-bustapay.mediawiki:62 in 605c31a9e0 outdated

57+
58+Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout will propagate the original "template transaction" to ensure the payment happens and function a strong anti-DoS mechanism.
59+
60+== Specification ==
61+
62+The standard way of letting a sender know where to send a bustapay transaction is done via a bip21 encoded address. The key value "bpu" (short for "BustaPayUrl") should be used. An example such address would be bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bpu=https://bp.bustabit.com/submit  It is highly encouraged that urls are kept short.

luke-jr commented at 9:09 am on October 16, 2018:

Why not drop the address, and have the server add the output? This enables the recipient to use any output it wants (not limited to merely address-representable outputs the sender already can understand; eg, it could use a native segwit output even with senders that don’t support Bech32), as well as choose a key per-request (so the URI can be placed on a static webpage, yet still avoid address reuse).

RHavar commented at 9:29 pm on October 16, 2018:

The big reason is that if the receiver an arbitrarily change his output, the sender has no way to validate it. Any MITM (imagine cloudflare) could change the output to their own, and then the sender would send them money. While with the current design, a MITM can only function as a DoS (in which case the sender will just fall back to a normal send).

There was a suggestion that in the “payment request” it encodes what the “new output” would be changed to. However, I didn’t think I could justify the complexity at this point in time.

luke-jr changes_requested

luke-jr commented at 9:10 am on October 16, 2018: member

This feels like it wants to be a BIP70 extension.

Needs a section addressing backwards compatibility.

luke-jr added the label New BIP on Oct 16, 2018

Address review comments 6322865e9d

RHavar commented at 10:03 pm on October 16, 2018: contributor

@luke-jr I think I addressed most of your comments, except adding a backwards compatibility section – as I’m not quite sure what I should put there. I don’t think there’s really any backwards compatibility issues

luke-jr commented at 10:53 pm on October 16, 2018: member

The backwards compatibility section is in fact the only part required to be assigned a BIP number.

It should probably discuss compatibility with existing wallets, BIP 21, and BIP 70. Simply saying why there are no issues should be fine.

Add backwards compatibility section cad43f2f5b

RHavar commented at 11:36 pm on October 16, 2018: contributor

Great! Thanks for all the feedback so far. Updated.

luke-jr renamed this:
~~Add bip for bustapay :: a practical sender/receiver coinjoin protocol~~
BIP 79: Bustapay :: a practical sender/receiver coinjoin protocol
on Oct 17, 2018

luke-jr commented at 9:00 am on October 17, 2018: member

Assigned BIP 79, but note that the current title is too long (max length 44 chars)

Gutoey approved

Retitle and move to bip79 4a05f299ce

RHavar force-pushed on Oct 19, 2018

luke-jr renamed this:
~~BIP 79: Bustapay :: a practical sender/receiver coinjoin protocol~~
BIP 79: Bustapay :: a practical coinjoin protocol
on Oct 19, 2018

luke-jr commented at 12:00 pm on October 19, 2018: member

0Invalid date format in bip-0079.mediawiki at scripts/buildtable.pl line 164, <$F> line 10.

Fix date format 1e0d737620

luke-jr merged this on Oct 19, 2018

luke-jr closed this on Oct 19, 2018

BIP 79: Bustapay :: a practical coinjoin protocol #729