Hmm, I don't know anything about SIGHASH_BUNDLE. The only references online I can find are just mentions (mostly from you). What is SIGHASH_BUNDLE?
> unless you're binding a WTXID That could work, but it would exclude cases where you have a transaction that has already been partially signed and someone wants to, say, only sign that transaction if some 3rd party signs a transaction paying part of the fee for it. Kind of a niche use case, but it would be nice to support it if possible. If the transaction hasn't been signed at all yet, a new transaction can just be created that includes the prospective fee-payer, and if the transaction is fully signed then it has a WTXID to use. > then you can have fee bumping cycles What kind of cycles do you mean? You're saying these cycles would make it less robust to reorgs? > OP_VER I assume you mean something other than pushing the version onto the stack <https://bitcoin.stackexchange.com/questions/97258/given-op-ver-was-never-used-is-disabled-and-not-considered-useful-can-its-meani>? Is that related to your fee account idea? On Wed, Jan 19, 2022 at 1:32 AM Jeremy <jlru...@mit.edu> wrote: > 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 <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <billy.tet...@gmail.com> > 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 <jlru...@mit.edu> 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 <https://twitter.com/JeremyRubin> >>> <https://twitter.com/JeremyRubin> >>> >>> >>> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tet...@gmail.com> >>> 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 <jlru...@mit.edu> 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 <https://twitter.com/JeremyRubin> >>>>> <https://twitter.com/JeremyRubin> >>>>> >>>>> >>>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tet...@gmail.com> >>>>> 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 <https://twitter.com/JeremyRubin> >>>>>>> <https://twitter.com/JeremyRubin> >>>>>>> _______________________________________________ >>>>>>> bitcoin-dev mailing list >>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>> >>>>>>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
