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

[Billy Tetrud <billy.tetrud@gmail.com>]

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

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: 15859 bytes --]