Skip to content

Commit 4a05f29

Browse files
committed
Retitle and move to bip79
1 parent cad43f2 commit 4a05f29

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

bip-bustapay.mediawiki renamed to bip-0079.mediawiki

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
<pre>
2-
BIP: ???
2+
BIP: 79
33
Layer: Applications
4-
Title: Bustapay :: a practical sender/receiver coinjoin protocol
4+
Title: Bustapay :: a practical coinjoin protocol
55
Author: Ryan Havar <[email protected]>
66
Comments-Summary: No comments yet.
7-
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-bustapay
7+
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0079
88
Status: Proposed
99
Type: Informational
1010
Created: 2018-10-5
@@ -67,7 +67,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the
6767

6868
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.
6969

70-
Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.
70+
Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.
7171

7272
=== Contributed Input Choice ===
7373

0 commit comments

Comments
 (0)