mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

Retitle and move to bip79

Browse Source
This commit is contained in:
Ryan Havar 2018-10-19 01:27:42 -04:00
parent cad43f2f5b
commit 4a05f299ce
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
bip-bustapay.mediawiki → bip-0079.mediawiki
View File

@ -1,10 +1,10 @@
<pre>
BIP: ???
BIP: 79
Layer: Applications
Title: Bustapay :: a practical sender/receiver coinjoin protocol
Title: Bustapay :: a practical coinjoin protocol
Author: Ryan Havar <rhavar@protonmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-bustapay
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0079
Status: Proposed
Type: Informational
Created: 2018-10-5
@ -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. 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.
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.
=== Contributed Input Choice ===