{"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:\u003e  because you make transactions third party malleable it becomes possible\nto bundle and unbundle transactions.\n\nWhat I was suggesting doesn't make it possible to malleate someone else's\ntransaction. I guess maybe my proposal of using a sighash flag might have\nbeen unclear. Imagine it as a script opcode that just says \"this\ntransaction must be mined with this other transaction\" - the only\ndifference being that you can use any output with any encumberance as an\ninput for fee bumping. It doesn't prevent the original transaction from\nbeing mined on its own. So adding junk inputs would be no more of a problem\nthan dust attacks already are. It would be used exactly like cpfp, except\nit doesn't spend the parent.\n\nI don't think what I was suggesting is as different from your proposal. All\nthe problems of fee revenue optimization and feerate rules that you\nmentioned seem like they'd also exist for your proposal, or for cpfp. Let\nme know if I should clarify further.\n\nOn Tue, Jan 18, 2022 at 8:51 PM Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\n\u003e The issue with sighash flags is that because you make transactions third\n\u003e party malleable it becomes possible to bundle and unbundle transactions.\n\u003e\n\u003e This means there are circumstances where an attacker could e.g. see your\n\u003e txn, and then add a lot of junk change/inputs + 25 descendants and strongly\n\u003e anchor your transaction to the bottom of the mempool.\n\u003e\n\u003e because of rbf rules requiring more fee and feerate, this means you have\n\u003e to bump across the whole package and that can get really messy.\n\u003e\n\u003e more generally speaking, you could imagine a future where mempools track\n\u003e many alternative things that might want to be in a transaction.\n\u003e\n\u003e suppose there are N inputs each with a weight and an amount of fee being\n\u003e added and the sighash flags let me pick any subset of them. However, for a\n\u003e txn to be standard it must be \u003c 100k bytes and for it to be consensus \u003c\n\u003e 1mb. Now it is possible you have to solve a knapsack problem in order to\n\u003e rationally bundle this transaction out of all possibilities.\n\u003e\n\u003e This problem can get even thornier, suppose that the inputs I'm adding\n\u003e themselves are the outputs of another txn in the mempool, now i have to\n\u003e track and propagate the feerates of that child back up to the parent txn\n\u003e and track all these dependencies.\n\u003e\n\u003e perhaps with very careful engineering these issues can be tamed. however\n\u003e it seems with sponsors or fee accounts, by separating the pays-for from the\n\u003e participates-in concerns we can greatly simplify it to something like:\n\u003e compute effective feerate for a txn, including all sponsors that pay more\n\u003e than the feerate of the base txn. Mine that txn and it's subsidies using\n\u003e the normal algo. If you run out of space, all subsidies are same-sized so\n\u003e just take the ones that pay the highest amount up until the added marginal\n\u003e feerate is less than the next eligible txn.\n\u003e\n\u003e\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 6:38 PM Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e I see, its not primarily to make it cheaper to append fees, but also\n\u003e\u003e allows appending fees in cases that aren't possible now. Is that right? I\n\u003e\u003e can certainly see the benefit of a more general way to add a fee to any\n\u003e\u003e transaction, regardless of whether you're related to that transaction or\n\u003e\u003e not.\n\u003e\u003e\n\u003e\u003e How would you compare the pros and cons of your account-based approach to\n\u003e\u003e something like a new sighash flag? Eg a sighash flag that says \"I'm signing\n\u003e\u003e this transaction, but the signature is only valid if mined in the same\n\u003e\u003e block as transaction X (or maybe transactions LIST)\". This could be named\n\u003e\u003e SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin\n\u003e\u003e transactions, and no special account would need to be created. Any\n\u003e\u003e transaction could specify this. At least that's the first thought I would\n\u003e\u003e have in designing a way to arbitrarily bump fees. Have you compared your\n\u003e\u003e solution to something more familiar like that?\n\u003e\u003e\n\u003e\u003e On Tue, Jan 18, 2022 at 11:43 AM Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Can you clarify what you mean by \"improve the situation\"?\n\u003e\u003e\u003e\n\u003e\u003e\u003e There's a potential mild bytes savings, but the bigger deal is that the\n\u003e\u003e\u003e API should be much less vulnerable to pinning issues, fix dust leakage for\n\u003e\u003e\u003e eltoo like protocols, and just generally allow protocol designs to be fully\n\u003e\u003e\u003e abstracted from paying fees. You can't easily mathematically quantify API\n\u003e\u003e\u003e improvements like that.\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\n\u003e\u003e\u003e On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Do you have any back-of-the-napkin math on quantifying how much this\n\u003e\u003e\u003e\u003e would improve the situation vs existing methods (eg cpfp)?\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev \u003c\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Happy new years devs,\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e I figured I would share some thoughts for conceptual review that have\n\u003e\u003e\u003e\u003e\u003e been bouncing around my head as an opportunity to clean up the fee paying\n\u003e\u003e\u003e\u003e\u003e semantics in bitcoin \"for good\". The design space is very wide on the\n\u003e\u003e\u003e\u003e\u003e approach I'll share, so below is just a sketch of how it could work which\n\u003e\u003e\u003e\u003e\u003e I'm sure could be improved greatly.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Transaction fees are an integral part of bitcoin.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e However, due to quirks of Bitcoin's transaction design, fees are a\n\u003e\u003e\u003e\u003e\u003e part of the transactions that they occur in.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e While this works in a \"Bitcoin 1.0\" world, where all transactions are\n\u003e\u003e\u003e\u003e\u003e simple on-chain transfers, real world use of Bitcoin requires support for\n\u003e\u003e\u003e\u003e\u003e things like Fee Bumping stuck transactions, DoS resistant Payment Channels,\n\u003e\u003e\u003e\u003e\u003e and other long lived Smart Contracts that can't predict future fee rates.\n\u003e\u003e\u003e\u003e\u003e Having the fees paid in band makes writing these contracts much more\n\u003e\u003e\u003e\u003e\u003e difficult as you can't merely express the logic you want for the\n\u003e\u003e\u003e\u003e\u003e transaction, but also the fees.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Previously, I proposed a special type of transaction called a\n\u003e\u003e\u003e\u003e\u003e \"Sponsor\" which has some special consensus + mempool rules to allow\n\u003e\u003e\u003e\u003e\u003e arbitrarily appending fees to a transaction to bump it up in the mempool.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e As an alternative, we could establish an account system in Bitcoin as\n\u003e\u003e\u003e\u003e\u003e an \"extension block\".\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *Here's how it might work:*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e 1. Define a special anyone can spend output type that is a \"fee\n\u003e\u003e\u003e\u003e\u003e account\" (e.g. segwit V2). Such outputs have a redeeming key and an amount\n\u003e\u003e\u003e\u003e\u003e associated with them, but are overall anyone can spend.\n\u003e\u003e\u003e\u003e\u003e 2. All deposits to these outputs get stored in a separate UTXO\n\u003e\u003e\u003e\u003e\u003e database for fee accounts\n\u003e\u003e\u003e\u003e\u003e 3. Fee accounts can sign only two kinds of transaction: A: a fee\n\u003e\u003e\u003e\u003e\u003e amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and\n\u003e\u003e\u003e\u003e\u003e an address\n\u003e\u003e\u003e\u003e\u003e 4. These transactions are committed in an extension block merkle tree.\n\u003e\u003e\u003e\u003e\u003e While the actual signature must cover the TXID/Outpoint, the committed data\n\u003e\u003e\u003e\u003e\u003e need only cover the index in the block of the transaction. The public key\n\u003e\u003e\u003e\u003e\u003e for account lookup can be recovered from the message + signature.\n\u003e\u003e\u003e\u003e\u003e 5. In any block, any of the fee account deposits can be: released into\n\u003e\u003e\u003e\u003e\u003e fees if there is a corresponding tx; consolidated together to reduce the\n\u003e\u003e\u003e\u003e\u003e number of utxos (this can be just an OP_TRUE no metadata needed); or\n\u003e\u003e\u003e\u003e\u003e released into fees *and paid back* into the requested withdrawal key\n\u003e\u003e\u003e\u003e\u003e (encumbering a 100 block timeout). Signatures must be unique in a block.\n\u003e\u003e\u003e\u003e\u003e 6. Mempool logic is updated to allow attaching of account fee spends\n\u003e\u003e\u003e\u003e\u003e to transactions, the mempool can restrict that an account is not allowed\n\u003e\u003e\u003e\u003e\u003e more spend more than it's balance.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *But aren't accounts \"bad\"?*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Yes, accounts are bad. But these accounts are not bad, because any\n\u003e\u003e\u003e\u003e\u003e funds withdrawn from the fee extension are fundamentally locked for 100\n\u003e\u003e\u003e\u003e\u003e blocks as a coinbase output, so there should be no issues with any series\n\u003e\u003e\u003e\u003e\u003e of reorgs. Further, since there is no \"rich state\" for these accounts, the\n\u003e\u003e\u003e\u003e\u003e state updates can always be applied in a conflict-free way in any order.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *Improving the privacy of this design:*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e This design could likely be modified to implement something like\n\u003e\u003e\u003e\u003e\u003e Tornado.cash or something else so that the fee account paying can be\n\u003e\u003e\u003e\u003e\u003e unlinked from the transaction being paid for, improving privacy at the\n\u003e\u003e\u003e\u003e\u003e expense of being a bit more expensive.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Other operations could be added to allow a trustless mixing to be done\n\u003e\u003e\u003e\u003e\u003e by miners automatically where groups of accounts with similar values are\n\u003e\u003e\u003e\u003e\u003e trustlessly  split into a common denominator and change, and keys are\n\u003e\u003e\u003e\u003e\u003e derived via a verifiable stealth address like protocol (so fee balances can\n\u003e\u003e\u003e\u003e\u003e be discovered by tracing the updates posted). These updates could also be\n\u003e\u003e\u003e\u003e\u003e produced by individuals rather than miners, and miners could simply honor\n\u003e\u003e\u003e\u003e\u003e them with better privacy. While a miner generating an update would be able\n\u003e\u003e\u003e\u003e\u003e to deanonymize their mixes, if you have your account mixed several times by\n\u003e\u003e\u003e\u003e\u003e independent miners that could potentially add sufficient privacy.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e The LN can also be used with PTLCs to, in theory, have another\n\u003e\u003e\u003e\u003e\u003e individual paid to sponsor a transaction on your behalf only if they reveal\n\u003e\u003e\u003e\u003e\u003e a valid sig from their fee paying account, although under this model it's\n\u003e\u003e\u003e\u003e\u003e hard to ensure that the owner doesn't pay a fee and then 'cancel' by\n\u003e\u003e\u003e\u003e\u003e withdrawing the rest. However, this could be partly solved by using\n\u003e\u003e\u003e\u003e\u003e reputable fee accounts (reputation could be measured somewhat\n\u003e\u003e\u003e\u003e\u003e decentralized-ly by longevity of the account and transactions paid for\n\u003e\u003e\u003e\u003e\u003e historically).\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *Scalability*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e This design is fundamentally 'decent' for scalability because adding\n\u003e\u003e\u003e\u003e\u003e fees to a transaction does not require adding inputs or outputs and does\n\u003e\u003e\u003e\u003e\u003e not require tracking substantial amounts of new state.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Paying someone else to pay for you via the LN also helps make this\n\u003e\u003e\u003e\u003e\u003e more efficient if the withdrawal issues can be fixed.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *Lightning:*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e This type of design works really well for channels because the\n\u003e\u003e\u003e\u003e\u003e addition of fees to e.g. a channel state does not require any sort of\n\u003e\u003e\u003e\u003e\u003e pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags).\n\u003e\u003e\u003e\u003e\u003e This sort of design is naturally immune to pinning issues since you could\n\u003e\u003e\u003e\u003e\u003e offer to pay a fee for any TXID and the number of fee adding offers does\n\u003e\u003e\u003e\u003e\u003e not need to be restricted in the same way the descendant transactions would\n\u003e\u003e\u003e\u003e\u003e need to be.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e *Without a fork?*\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e This type of design could be done as a federated network that bribes\n\u003e\u003e\u003e\u003e\u003e miners -- potentially even retroactively after a block is formed. That\n\u003e\u003e\u003e\u003e\u003e might be sufficient to prove the concept works before a consensus upgrade\n\u003e\u003e\u003e\u003e\u003e is deployed, but such an approach does mean there is a centralizing layer\n\u003e\u003e\u003e\u003e\u003e interfering with normal mining.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Happy new year!!\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Jeremy\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e --\n\u003e\u003e\u003e\u003e\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e\u003e\u003e\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220118/59a75bc9/attachment-0001.html\u003e"}