[Pre-BIP] Fee Accounts



Summary:

A proposal has been made to improve the Bitcoin API and make it less vulnerable to pinning issues. This involves the concept of sponsor transactions or fee accounts, which separates the pays-for from the participates-in concerns. The purpose is to simplify the computation of an effective feerate for a transaction. Compared to using sighash flags, this approach eliminates the potential third-party malleability of transactions while allowing for the addition of fees to any transaction regardless of whether someone is related to that transaction or not.The proposed solution also has the potential for mild byte savings and fixes dust leakage for eltoo-like protocols. However, there are still challenges in designing such a system, including tracking and propagating feerates and dependencies. Another proposed solution mentioned in the conversation is a new sighash flag named SIGHASH_EXTERNAL, which specifies that a transaction must be mined together with another transaction or a list of transactions.The proposed account system aims to clean up the fee-paying semantics in Bitcoin through an extension block account system. This system defines a special output type called a "fee account" that allows for deposits to be stored in a separate UTXO database. These fee accounts can sign two types of transactions: a fee amount and a TXID (or Outpoint), or a withdraw amount, a fee, and an address. The design could also be modified to improve privacy by implementing something like Tornado.cash. The proposal is scalable and could work well with Lightning channels. It could potentially be done as a federated network that bribes miners before a consensus upgrade is deployed. The purpose of this proposal is to make contract writing easier as the logic of the transaction and fees need to be expressed.


Updated on: 2023-06-03T07:12:55.902917+00:00