Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-20 📝 Original message: Thanks for the info. > ...
📅 Original date posted:2022-01-20
📝 Original message:
Thanks for the info.
> you could "sponsor yourself" directly or through a cycle involving > 1
txn.
Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste of bytes. The
fee-sponsoring OP_VER looks good too tho.
On Wed, Jan 19, 2022 at 2:08 PM Jeremy <jlrubin at mit.edu> wrote:
> SIGHASH_BUNDLE
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
>
> By cycles I meant that if you commit to the sponsors by TXID from the
> witness, you could "sponsor yourself" directly or through a cycle involving
> > 1 txn.
>
> With OP_VER I was talking about the proposal I linked here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
> in the output space, and uses TXIDs, it is cycle-free.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> 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 <jlrubin at 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.tetrud at 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 <jlrubin at 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.tetrud at 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 <jlrubin at 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.tetrud at 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 at 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 at lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220119/1724e2e9/attachment-0001.html>;
📝 Original message:
Thanks for the info.
> you could "sponsor yourself" directly or through a cycle involving > 1
txn.
Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste of bytes. The
fee-sponsoring OP_VER looks good too tho.
On Wed, Jan 19, 2022 at 2:08 PM Jeremy <jlrubin at mit.edu> wrote:
> SIGHASH_BUNDLE
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
>
> By cycles I meant that if you commit to the sponsors by TXID from the
> witness, you could "sponsor yourself" directly or through a cycle involving
> > 1 txn.
>
> With OP_VER I was talking about the proposal I linked here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
> in the output space, and uses TXIDs, it is cycle-free.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> 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 <jlrubin at 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.tetrud at 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 <jlrubin at 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.tetrud at 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 <jlrubin at 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.tetrud at 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 at 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 at lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220119/1724e2e9/attachment-0001.html>;