diff options
Diffstat (limited to 'bip-bustapay.mediawiki')
| -rw-r--r-- | bip-bustapay.mediawiki | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/bip-bustapay.mediawiki b/bip-bustapay.mediawiki index 9417ec4..084aea1 100644 --- a/bip-bustapay.mediawiki +++ b/bip-bustapay.mediawiki @@ -1,5 +1,5 @@ <pre> - BIP: 69 + BIP: ??? Layer: Applications Title: Bustapay :: a practical sender/receiver coinjoin protocol Author: Ryan Havar <rhavar@protonmail.com> @@ -26,7 +26,7 @@ This document is licensed under the Creative Commons CC0 1.0 Universal license. 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. -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. +We however can bust these assumption with a sender-receiver coinjoin. 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. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem. 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. @@ -67,7 +67,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the 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. -Should the receiver reject a transaction, it should not attempt to propagate it on the network. +Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the send to be aware that the receiver *can* at any time until one of the inputs has been used and thus invalidates the transaction. === Contributed Input Choice === @@ -79,7 +79,7 @@ It is strongly preferable that the receiver makes an effort to pick a contribute === Output Adjustment === -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. +After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* add or remove inputs, and *must not* ever decrease any output amount. === Returning the partial transaction === |