diff options
Diffstat (limited to 'bip-0079.mediawiki')
| -rw-r--r-- | bip-0079.mediawiki | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index 7d0cc57..15948ad 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -14,9 +14,9 @@ ==Abstract== -The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardizes important properties that is expected of a useful currency. +The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency. -Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants. +Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants. ==Copyright== @@ -47,15 +47,15 @@ This is done via an HTTP POST request, sent to a "bustapay url" ====Step 3. Receiver processes the transaction and returns a partially signed coinjoin==== -The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to resign his own inputs. +The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to re-sign his own inputs. -====Step 4. Receiver validates, re-signs, and propagates on the bitcoin network==== +====Step 4. Sender validates, re-signs, and propagates on the bitcoin network==== -The receiver MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), resign its original inputs and propagates the final transaction over the bitcoin network. +The sender MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), re-sign its original inputs and propagate the final transaction over the bitcoin network. ====Step 5. Receiver observes the finalized transaction on the bitcoin network==== -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. +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, they will propagate the original "template transaction", which ensures the payment happens and functions a strong anti-DoS mechanism. == Specification == @@ -75,11 +75,11 @@ The receiver must add at least one input to the transaction (the "contributed in To prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receivers utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs. -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. +It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible. === Output Adjustment === -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. +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* remove inputs, and *must not* ever decrease any output amount. === Returning the partial transaction === |