Closed vinarmani closed 5 years ago
These rates are generated dynamically based on network conditions, not statically defined, just like how you see in bitcoin ABC and most other wallets. No client implementing according to the spec should be using a static fee. The specification specifically mentions that the required rate returned can be a fractional rate and that rate is what clients should be using to calculate their fee.
We should be accounting for that for transactions smaller than 1kb. As long as your final fee is within 1 satoshi of the expected value it shouldn't be rejected.
At the moment, the fee must be greater than the min fee rate. ±1 would be awesome, but that's not the current behavior.
Just double checked, server side code which does this check allows for 1 satoshi under.
Right, but is it 1 Satoshi under the actual float of size*min_fee or under the ceiling integer? I believe it is set for the latter.
I had transactions rejected where the minimum miner fee in the payment request was 1.001, the size of the transaction was 292 and the fee was 292 Satoshis. if it was ±1, a fee greater than 291.292 (which 292 is) should have been accepted.
That last comment was incorrect so I deleted it as to not confuse anyone else following the thread later. Code is:
requiredFee = transactionSize * requiredFeePerByte;
if ((totalTransactionFee + 1) < requiredFee) {
//fail
}
An example: Generate TX of 350 bytes. Use fee rate of 1 sat/byte: fee is 350 sat Server receives tx, uses: 1.001 sat / byte * 350 byte = 350.35 sat Server compares fee: 350 + 1 sat < 350.35 sat = no failure
It doesn't make sense for the required minimum BCH fee to be 1001 Sats/kB when nodes accept 1000 Sats/kB by default. For most transactions, this change actually is not even a whole Satoshi, but implementations that use 1 Sat/byte will have their BitPay payments fail.
Is there some good reason to have implemented this change in JSON Payment Protocol?