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