Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

From: Jeremy <jlrubin@mit•edu>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
Date: Tue, 18 Jan 2022 23:32:36 -0800	[thread overview]
Message-ID: <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDYxCGkpbiiHFgFrY3=oCwRBY7c_vLQfQg3a_Dwx7pEUTA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 12681 bytes --]

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@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@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@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@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@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
>>>>>>
>>>>>

[-- Attachment #2: Type: text/html, Size: 24652 bytes --]