Depends on D13902
Fee of 2.01 sat/byte was arbitrary used very early in ecash history as part of the effort to protect against empty blocks.
Reduce to minimum fee.
Details
Details
- Reviewers
- None
- Group Reviewers
Restricted Project
npm test
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- cashtab-improve-alias-settings
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 23721 Build 47053: Build Diff cashtab-tests Build 47052: arc lint + arc unit
Event Timeline
Comment Actions
Seeing this fail on some edge case txs e.g. sending a max-length OP_RETURN msg.
- Add these cases to unit tests
- Patch the bug causing the failure at this rate
Comment Actions
I've tested across the permutations and the min fees varies depending on the transaction. Unencrypted msg at max length is 457 sats, airdrop txs is 528 sats, airdrop txs with a msg is 707 sats. Therefore landed at 1.11 sats per byte as the correct figure to ensure Cashtab covers the 707 min sat fee
Fees based on 1.11 satsperbyte
- send XEC - 2.51 XEC
- send XEC with unencrypted message at max length - 4.90 XEC
- send XEC with encrypted message at max length - 4.83 XEC
- send one to many XEC - 3.27 XEC
- send one to many XEC with max unencrypted message - 7.30 XEC
- send airdrop XEC - 5.29 XEC
- send airdrop XEC with max unencrypted message - 7.25 XEC
Note: Create/send token has an edge fee bug because the calcFee() call in generateTokenTxInput isn't passing the opReturn byte count. I'll address that first as a separate diff.
Comment Actions
Therefore landed at 1.11 sats per byte as the correct figure to ensure Cashtab covers the 707 min sat fee
1 sat per byte is enough. Arguably we should keep it slightly above 1 sat per byte in Cashtab in case of high tx events. But, 1 sat per byte will not be rejected by the node.
So, deeper issue is that the calculation for tx size is off and needs to be improved.
Reducing to 1.11 sats per byte in the interim is worth it though. Big fee reduction win.
Comment Actions
Just note that before this can land I need to get through D13917 and equivalent fixes for send/burn tokens to ensure reducing to 1.11 sats/byte won't cause issues for token transactions.