{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-01-01\n📝 Original message:Happy new years devs,\n\nI figured I would share some thoughts for conceptual review that have been\nbouncing around my head as an opportunity to clean up the fee paying\nsemantics in bitcoin \"for good\". The design space is very wide on the\napproach I'll share, so below is just a sketch of how it could work which\nI'm sure could be improved greatly.\n\nTransaction fees are an integral part of bitcoin.\n\nHowever, due to quirks of Bitcoin's transaction design, fees are a part of\nthe transactions that they occur in.\n\nWhile this works in a \"Bitcoin 1.0\" world, where all transactions are\nsimple on-chain transfers, real world use of Bitcoin requires support for\nthings like Fee Bumping stuck transactions, DoS resistant Payment Channels,\nand other long lived Smart Contracts that can't predict future fee rates.\nHaving the fees paid in band makes writing these contracts much more\ndifficult as you can't merely express the logic you want for the\ntransaction, but also the fees.\n\nPreviously, I proposed a special type of transaction called a \"Sponsor\"\nwhich has some special consensus + mempool rules to allow arbitrarily\nappending fees to a transaction to bump it up in the mempool.\n\nAs an alternative, we could establish an account system in Bitcoin as an\n\"extension block\".\n\n*Here's how it might work:*\n\n1. Define a special anyone can spend output type that is a \"fee account\"\n(e.g. segwit V2). Such outputs have a redeeming key and an amount\nassociated with them, but are overall anyone can spend.\n2. All deposits to these outputs get stored in a separate UTXO database for\nfee accounts\n3. Fee accounts can sign only two kinds of transaction: A: a fee amount and\na TXID (or Outpoint?); B: a withdraw amount, a fee, and an address\n4. These transactions are committed in an extension block merkle tree.\nWhile the actual signature must cover the TXID/Outpoint, the committed data\nneed only cover the index in the block of the transaction. The public key\nfor account lookup can be recovered from the message + signature.\n5. In any block, any of the fee account deposits can be: released into fees\nif there is a corresponding tx; consolidated together to reduce the number\nof utxos (this can be just an OP_TRUE no metadata needed); or released into\nfees *and paid back* into the requested withdrawal key (encumbering a 100\nblock timeout). Signatures must be unique in a block.\n6. Mempool logic is updated to allow attaching of account fee spends to\ntransactions, the mempool can restrict that an account is not allowed more\nspend more than it's balance.\n\n*But aren't accounts \"bad\"?*\n\nYes, accounts are bad. But these accounts are not bad, because any funds\nwithdrawn from the fee extension are fundamentally locked for 100 blocks as\na coinbase output, so there should be no issues with any series of reorgs.\nFurther, since there is no \"rich state\" for these accounts, the state\nupdates can always be applied in a conflict-free way in any order.\n\n\n*Improving the privacy of this design:*\n\nThis design could likely be modified to implement something like\nTornado.cash or something else so that the fee account paying can be\nunlinked from the transaction being paid for, improving privacy at the\nexpense of being a bit more expensive.\n\nOther operations could be added to allow a trustless mixing to be done by\nminers automatically where groups of accounts with similar values are\ntrustlessly  split into a common denominator and change, and keys are\nderived via a verifiable stealth address like protocol (so fee balances can\nbe discovered by tracing the updates posted). These updates could also be\nproduced by individuals rather than miners, and miners could simply honor\nthem with better privacy. While a miner generating an update would be able\nto deanonymize their mixes, if you have your account mixed several times by\nindependent miners that could potentially add sufficient privacy.\n\nThe LN can also be used with PTLCs to, in theory, have another individual\npaid to sponsor a transaction on your behalf only if they reveal a valid\nsig from their fee paying account, although under this model it's hard to\nensure that the owner doesn't pay a fee and then 'cancel' by withdrawing\nthe rest. However, this could be partly solved by using reputable fee\naccounts (reputation could be measured somewhat decentralized-ly by\nlongevity of the account and transactions paid for historically).\n\n*Scalability*\n\nThis design is fundamentally 'decent' for scalability because adding fees\nto a transaction does not require adding inputs or outputs and does not\nrequire tracking substantial amounts of new state.\n\nPaying someone else to pay for you via the LN also helps make this more\nefficient if the withdrawal issues can be fixed.\n\n*Lightning:*\n\nThis type of design works really well for channels because the addition of\nfees to e.g. a channel state does not require any sort of pre-planning\n(e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of\ndesign is naturally immune to pinning issues since you could offer to pay a\nfee for any TXID and the number of fee adding offers does not need to be\nrestricted in the same way the descendant transactions would need to be.\n\n*Without a fork?*\n\nThis type of design could be done as a federated network that bribes miners\n-- potentially even retroactively after a block is formed. That might be\nsufficient to prove the concept works before a consensus upgrade is\ndeployed, but such an approach does mean there is a centralizing layer\ninterfering with normal mining.\n\n\nHappy new year!!\n\nJeremy\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220101/4cd5c38b/attachment.html\u003e"}