Author: Billy Tetrud 2022-01-20 05:23:12
Published on: 2022-01-20T05:23:12+00:00
A proposal has been made to improve the design of fee accounts in Bitcoin. The proposal suggests establishing an account system in Bitcoin as an "extension block." This would involve defining a special anyone can spend output type called a "fee account" that has a redeeming key and an associated amount but is overall anyone can spend. All deposits to these outputs would be stored in a separate UTXO database for fee accounts.Fee accounts would only be able to sign two kinds of transactions: A) a fee amount and a TXID (or Outpoint?) and B) a withdraw amount, a fee, and an address. These transactions would be committed in an extension block merkle tree. In any block, any of the fee account deposits can be released into fees if there is a corresponding tx, consolidated together to reduce the number of utxos, or released into fees *and paid back* into the requested withdrawal key.The proposed account-based approach would simplify the API and fix dust leakage for eltoo like protocols. Although the potential mild bytes savings is not significant, the API should be much less vulnerable to pinning issues, and just generally allow protocol designs to be fully abstracted from paying fees.The proposal aims to clean up the fee paying semantics in Bitcoin "for good." While transaction fees are an integral part of bitcoin, due to quirks of Bitcoin's transaction design, fees are a part of the transactions that they occur in. This works in a "Bitcoin 1.0" world, where all transactions are simple on-chain transfers, but 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, a special type of transaction called a "Sponsor" was proposed, which has some special consensus + mempool rules to allow arbitrarily appending fees to a transaction to bump it up in the mempool. However, the proposal provides a more general way to add a fee to any transaction, regardless of whether you're related to that transaction or not. The author suggests that funds withdrawn from the fee extension should be locked for 100 blocks as a coinbase output to prevent issues with reorgs. Additionally, since there is no "rich state" for these accounts, the state updates can always be applied in a conflict-free way in any order. The author also proposes modifying the design to improve privacy by implementing something like Tornado.cash or allowing trustless mixing to be done by miners automatically. This could potentially add sufficient privacy if accounts are mixed several times by independent miners.The Lightning Network can also be used with PTLCs to pay for transactions on someone else's behalf. The design is considered decent for scalability because adding fees to a transaction does not require adding inputs or outputs and does not require tracking substantial amounts of new state. However, the author notes that this type of design could be done as a federated network that bribes miners, potentially interfering with normal mining.
Updated on: 2023-06-15T03:53:00.884713+00:00