BTCPrivate
/
jsonPaymentProtocol
mirror of https://github.com/BTCPrivate/jsonPaymentProtocol.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update with information about inputs

This commit is contained in:
Rob Riddle 2018-03-01 16:31:30 -05:00
parent 97289845d2
commit 73c6cc4576
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bip70.md
View File

@ -1,11 +1,11 @@
# BIP-70 Modifications # BIP-70 Modifications
In addition to JSON payment protocol, BitPay Bitcoin and Bitcoin Cash invoices use a mildly modified version of [BIP-70](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki). We include In addition to JSON payment protocol, BitPay Bitcoin and Bitcoin Cash invoices use a mildly modified version of [BIP-70](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki). We include
one additional field which specifies the fee rate the transaction must have in order to be accepted. Bitcoin invoices are temporarily exempt from this rule to allow wallets time to adjust. one additional field which specifies the fee rate the transaction must have in order to be accepted. This minimum fee is required to ensure a reasonable confirmation time for payments which are sent to BitPay.
To further ensure this we also require payments be made with confirmed inputs. Payments using unconfirmed inputs, such as unconfirmed change, will be rejected. Bitcoin invoices are temporarily exempt from this rule to allow wallets time to adjust.
* `required_fee_rate` - The minimum fee per byte required on your transaction. Bitcoin Cash payments will be rejected if fee rate included for the transaction is not at least this value. _May be fractional value_ ie 0.123 sat/byte * `required_fee_rate` - The minimum fee per byte required on your transaction. Bitcoin Cash payments will be rejected if fee rate included for the transaction is not at least this value. _May be fractional value_ ie 0.123 sat/byte
## Application Logic ## Application Logic
Please note that you should **NOT** broadcast a payment to the P2P network if we respond with an http status code other than `200`. Broadcasting a payment before getting a success notification back from the server will Please note that you should **NOT** broadcast a payment to the P2P network if we respond with an http status code other than `200`. Broadcasting a payment before getting a success notification back from the server will
lead to a failed payment for the sender. The sender will bear the cost of paying transaction fees yet again to get their money back. lead to a failed payment for the sender. The sender will bear the cost of paying transaction fees yet again to get their money back.