{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-10\n📝 Original message:On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore \u003cme at ricmoo.com\u003e wrote:\n\n\u003e I was also wondering, with CPFP, should the transaction fee be based on\n\u003e total transactions size, or the sum of each transaction’s required fee? For\n\u003e example, a third transaction C whose unconfirmed utxo from transaction B\n\u003e has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),\n\u003e with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001\n\u003e btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for\n\u003e the 3 transactions it is going to commit.\n\u003e\n\nIt should be whatever gives the highest fee.  In effect, child pays for\nparent creates compound transactions.\n\nA: 250 bytes, 0 fee\nB: 300 bytes: 0.0005 fee\nC: 400 bytes: 0.0001 fee\n\nThere are 3 combinations to consider\n\nA: 0 fee for 250 bytes = 0 per byte\nA\u0026B: 0.0005 fee for 550 bytes = 0.91 uBTC per byte\nA\u0026B\u0026C: 0.0006 fee for 950 bytes = 0.63uBTC per byte\n\nThis means that the A\u0026B combination has the best fee per byte value.  A\u0026B\nshould be added to the memory pool (if 0.91 uBTC per byte is above the\nthreshold).\n\nOnce A\u0026B are added, then C can be reconsidered on its own.\n\nC: 0.0001 for 400 bytes = 0.25 BTC per byte\n\nIf that is above the threshold, then C should be added.\n\nIn practice, it isn't possible to check every combination.  If there are N\ntransactions, then checking all triple combinations costs around N cubed.\n\nA 2 pass system could get a reasonably efficient result.\n\nB is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a\nhigh value transaction.\n\nThe algorithm would be\n\nPass 1:\nProcess all transactions in order of BTC per byte, until block is full\n    If the transaction's parents are either already in the pool or a\nprevious block, add the transaction.\n\nPass 1:\nProcess all non-included transactions in order of BTC per byte, until block\nis full\n    If the transaction's parents are either already in the pool or a\nprevious block, add the transaction.\n\n    Otherwise, consider the transaction plus all non-included ancestors as\na single transaction\n        If this combined transaction has a higher BTC per byte than the\nlowest transaction(s),\n            add the combined transaction\n            drop the other transaction(s)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/68d6acca/attachment.html\u003e"}