{"type":"rich","version":"1.0","title":"Peter Todd [ARCHIVE] wrote","author_name":"Peter Todd [ARCHIVE] (npub1m2…a2np2)","author_url":"https://yabu.me/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-10\n📝 Original message:\nOn Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:\n\u003e Happy new years devs,\n\u003e \n\u003e I figured I would share some thoughts for conceptual review that have been\n\u003e bouncing around my head as an opportunity to clean up the fee paying\n\u003e semantics in bitcoin \"for good\". The design space is very wide on the\n\u003e approach I'll share, so below is just a sketch of how it could work which\n\u003e I'm sure could be improved greatly.\n\u003e \n\u003e Transaction fees are an integral part of bitcoin.\n\u003e \n\u003e However, due to quirks of Bitcoin's transaction design, fees are a part of\n\u003e the transactions that they occur in.\n\u003e \n\u003e While this works in a \"Bitcoin 1.0\" world, where all transactions are\n\u003e simple on-chain transfers, real world use of Bitcoin requires support for\n\u003e things like Fee Bumping stuck transactions, DoS resistant Payment Channels,\n\u003e and other long lived Smart Contracts that can't predict future fee rates.\n\u003e Having the fees paid in band makes writing these contracts much more\n\u003e difficult as you can't merely express the logic you want for the\n\u003e transaction, but also the fees.\n\u003e \n\u003e Previously, I proposed a special type of transaction called a \"Sponsor\"\n\u003e which has some special consensus + mempool rules to allow arbitrarily\n\u003e appending fees to a transaction to bump it up in the mempool.\n\u003e \n\u003e As an alternative, we could establish an account system in Bitcoin as an\n\u003e \"extension block\".\n\n\u003csnip\u003e\n\n\u003e This type of design works really well for channels because the addition of\n\u003e fees to e.g. a channel state does not require any sort of pre-planning\n\u003e (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of\n\u003e design is naturally immune to pinning issues since you could offer to pay a\n\u003e fee for any TXID and the number of fee adding offers does not need to be\n\u003e restricted in the same way the descendant transactions would need to be.\n\nSo it's important to recognize that fee accounts introduce their own kind of\ntransaction pinning attacks: third parties would be able to attach arbitrary\nfees to any transaction without permission. This isn't necessarily a good\nthing: I don't want third parties to be able to grief my transaction engines by\ngetting obsolete transactions confirmed in liu of the replacments I actually\nwant confirmed. Eg a third party could mess up OpenTimestamps calendars at\nrelatively low cost by delaying the mining of timestamp txs.\n\nOf course, there's an obvious way to fix this: allow transactions to designate\na pubkey allowed to add further transaction fees if required. Which Bitcoin\nalready has in two forms: Replace-by-Fee and Child Pays for Parent.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/ddb4235b/attachment.sig\u003e"}