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