{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-01-19\n📝 Original message:I see, its not primarily to make it cheaper to append fees, but also allows\nappending fees in cases that aren't possible now. Is that right? I can\ncertainly see the benefit of a more general way to add a fee to any\ntransaction, regardless of whether you're related to that transaction or\nnot.\n\nHow would you compare the pros and cons of your account-based approach to\nsomething like a new sighash flag? Eg a sighash flag that says \"I'm signing\nthis transaction, but the signature is only valid if mined in the same\nblock as transaction X (or maybe transactions LIST)\". This could be named\nSIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin\ntransactions, and no special account would need to be created. Any\ntransaction could specify this. At least that's the first thought I would\nhave in designing a way to arbitrarily bump fees. Have you compared your\nsolution to something more familiar like that?\n\nOn Tue, Jan 18, 2022 at 11:43 AM Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\n\u003e Can you clarify what you mean by \"improve the situation\"?\n\u003e\n\u003e There's a potential mild bytes savings, but the bigger deal is that the\n\u003e API should be much less vulnerable to pinning issues, fix dust leakage for\n\u003e eltoo like protocols, and just generally allow protocol designs to be fully\n\u003e abstracted from paying fees. You can't easily mathematically quantify API\n\u003e improvements like that.\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\n\u003e\n\u003e On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Do you have any back-of-the-napkin math on quantifying how much this\n\u003e\u003e would improve the situation vs existing methods (eg cpfp)?\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Happy new years devs,\n\u003e\u003e\u003e\n\u003e\u003e\u003e I figured I would share some thoughts for conceptual review that have\n\u003e\u003e\u003e been bouncing around my head as an opportunity to clean up the fee paying\n\u003e\u003e\u003e semantics in bitcoin \"for good\". The design space is very wide on the\n\u003e\u003e\u003e approach I'll share, so below is just a sketch of how it could work which\n\u003e\u003e\u003e I'm sure could be improved greatly.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Transaction fees are an integral part of bitcoin.\n\u003e\u003e\u003e\n\u003e\u003e\u003e However, due to quirks of Bitcoin's transaction design, fees are a part\n\u003e\u003e\u003e of the transactions that they occur in.\n\u003e\u003e\u003e\n\u003e\u003e\u003e While this works in a \"Bitcoin 1.0\" world, where all transactions are\n\u003e\u003e\u003e simple on-chain transfers, real world use of Bitcoin requires support for\n\u003e\u003e\u003e things like Fee Bumping stuck transactions, DoS resistant Payment Channels,\n\u003e\u003e\u003e and other long lived Smart Contracts that can't predict future fee rates.\n\u003e\u003e\u003e Having the fees paid in band makes writing these contracts much more\n\u003e\u003e\u003e difficult as you can't merely express the logic you want for the\n\u003e\u003e\u003e transaction, but also the fees.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Previously, I proposed a special type of transaction called a \"Sponsor\"\n\u003e\u003e\u003e which has some special consensus + mempool rules to allow arbitrarily\n\u003e\u003e\u003e appending fees to a transaction to bump it up in the mempool.\n\u003e\u003e\u003e\n\u003e\u003e\u003e As an alternative, we could establish an account system in Bitcoin as an\n\u003e\u003e\u003e \"extension block\".\n\u003e\u003e\u003e\n\u003e\u003e\u003e *Here's how it might work:*\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. Define a special anyone can spend output type that is a \"fee account\"\n\u003e\u003e\u003e (e.g. segwit V2). Such outputs have a redeeming key and an amount\n\u003e\u003e\u003e associated with them, but are overall anyone can spend.\n\u003e\u003e\u003e 2. All deposits to these outputs get stored in a separate UTXO database\n\u003e\u003e\u003e for fee accounts\n\u003e\u003e\u003e 3. Fee accounts can sign only two kinds of transaction: A: a fee amount\n\u003e\u003e\u003e and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address\n\u003e\u003e\u003e 4. These transactions are committed in an extension block merkle tree.\n\u003e\u003e\u003e While the actual signature must cover the TXID/Outpoint, the committed data\n\u003e\u003e\u003e need only cover the index in the block of the transaction. The public key\n\u003e\u003e\u003e for account lookup can be recovered from the message + signature.\n\u003e\u003e\u003e 5. In any block, any of the fee account deposits can be: released into\n\u003e\u003e\u003e fees if there is a corresponding tx; consolidated together to reduce the\n\u003e\u003e\u003e number of utxos (this can be just an OP_TRUE no metadata needed); or\n\u003e\u003e\u003e released into fees *and paid back* into the requested withdrawal key\n\u003e\u003e\u003e (encumbering a 100 block timeout). Signatures must be unique in a block.\n\u003e\u003e\u003e 6. Mempool logic is updated to allow attaching of account fee spends to\n\u003e\u003e\u003e transactions, the mempool can restrict that an account is not allowed more\n\u003e\u003e\u003e spend more than it's balance.\n\u003e\u003e\u003e\n\u003e\u003e\u003e *But aren't accounts \"bad\"?*\n\u003e\u003e\u003e\n\u003e\u003e\u003e Yes, accounts are bad. But these accounts are not bad, because any funds\n\u003e\u003e\u003e withdrawn from the fee extension are fundamentally locked for 100 blocks as\n\u003e\u003e\u003e a coinbase output, so there should be no issues with any series of reorgs.\n\u003e\u003e\u003e Further, since there is no \"rich state\" for these accounts, the state\n\u003e\u003e\u003e updates can always be applied in a conflict-free way in any order.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e *Improving the privacy of this design:*\n\u003e\u003e\u003e\n\u003e\u003e\u003e This design could likely be modified to implement something like\n\u003e\u003e\u003e Tornado.cash or something else so that the fee account paying can be\n\u003e\u003e\u003e unlinked from the transaction being paid for, improving privacy at the\n\u003e\u003e\u003e expense of being a bit more expensive.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Other operations could be added to allow a trustless mixing to be done\n\u003e\u003e\u003e by miners automatically where groups of accounts with similar values are\n\u003e\u003e\u003e trustlessly  split into a common denominator and change, and keys are\n\u003e\u003e\u003e derived via a verifiable stealth address like protocol (so fee balances can\n\u003e\u003e\u003e be discovered by tracing the updates posted). These updates could also be\n\u003e\u003e\u003e produced by individuals rather than miners, and miners could simply honor\n\u003e\u003e\u003e them with better privacy. While a miner generating an update would be able\n\u003e\u003e\u003e to deanonymize their mixes, if you have your account mixed several times by\n\u003e\u003e\u003e independent miners that could potentially add sufficient privacy.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The LN can also be used with PTLCs to, in theory, have another\n\u003e\u003e\u003e individual paid to sponsor a transaction on your behalf only if they reveal\n\u003e\u003e\u003e a valid sig from their fee paying account, although under this model it's\n\u003e\u003e\u003e hard to ensure that the owner doesn't pay a fee and then 'cancel' by\n\u003e\u003e\u003e withdrawing the rest. However, this could be partly solved by using\n\u003e\u003e\u003e reputable fee accounts (reputation could be measured somewhat\n\u003e\u003e\u003e decentralized-ly by longevity of the account and transactions paid for\n\u003e\u003e\u003e historically).\n\u003e\u003e\u003e\n\u003e\u003e\u003e *Scalability*\n\u003e\u003e\u003e\n\u003e\u003e\u003e This design is fundamentally 'decent' for scalability because adding\n\u003e\u003e\u003e fees to a transaction does not require adding inputs or outputs and does\n\u003e\u003e\u003e not require tracking substantial amounts of new state.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Paying someone else to pay for you via the LN also helps make this more\n\u003e\u003e\u003e efficient if the withdrawal issues can be fixed.\n\u003e\u003e\u003e\n\u003e\u003e\u003e *Lightning:*\n\u003e\u003e\u003e\n\u003e\u003e\u003e This type of design works really well for channels because the addition\n\u003e\u003e\u003e of fees to e.g. a channel state does not require any sort of pre-planning\n\u003e\u003e\u003e (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of\n\u003e\u003e\u003e design is naturally immune to pinning issues since you could offer to pay a\n\u003e\u003e\u003e fee for any TXID and the number of fee adding offers does not need to be\n\u003e\u003e\u003e restricted in the same way the descendant transactions would need to be.\n\u003e\u003e\u003e\n\u003e\u003e\u003e *Without a fork?*\n\u003e\u003e\u003e\n\u003e\u003e\u003e This type of design could be done as a federated network that bribes\n\u003e\u003e\u003e miners -- potentially even retroactively after a block is formed. That\n\u003e\u003e\u003e might be sufficient to prove the concept works before a consensus upgrade\n\u003e\u003e\u003e is deployed, but such an approach does mean there is a centralizing layer\n\u003e\u003e\u003e interfering with normal mining.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Happy new year!!\n\u003e\u003e\u003e\n\u003e\u003e\u003e Jeremy\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220118/3c72c1c7/attachment-0001.html\u003e"}