From: Jeremy <jlrubin@mit•edu>
To: Bitcoin development mailing list
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] [Pre-BIP] Fee Accounts
Date: Sat, 1 Jan 2022 12:04:00 -0800 [thread overview]
Message-ID: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5622 bytes --]
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>
[-- Attachment #2: Type: text/html, Size: 11988 bytes --]
next reply other threads:[~2022-01-01 20:04 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 20:04 Jeremy [this message]
2022-01-18 16:12 ` Billy Tetrud
2022-01-18 17:43 ` Jeremy
2022-01-19 2:37 ` Billy Tetrud
2022-01-19 2:51 ` Jeremy
2022-01-19 4:53 ` Billy Tetrud
2022-01-19 7:32 ` Jeremy
2022-01-19 16:51 ` Billy Tetrud
2022-01-19 20:08 ` Jeremy
2022-01-20 5:23 ` Billy Tetrud
2022-02-10 6:58 ` Peter Todd
2022-02-10 8:08 ` Jeremy Rubin
2022-02-18 23:50 ` Peter Todd
2022-02-19 0:38 ` Jeremy Rubin
2022-02-19 9:39 ` Peter Todd
2022-02-19 17:20 ` [bitcoin-dev] [Lightning-dev] " darosior
2022-02-19 20:35 ` Peter Todd
2022-02-20 2:24 ` ZmnSCPxj
2022-02-20 2:39 ` ZmnSCPxj
[not found] ` <590cf52920040c9cf7517b219624bbb5@willtech.com.au>
2022-02-20 14:24 ` ZmnSCPxj
2022-02-20 16:29 ` Jeremy Rubin
[not found] ` <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
2022-02-20 16:34 ` ZmnSCPxj
2022-02-20 16:45 ` Jeremy Rubin
2022-02-20 16:29 ` [bitcoin-dev] " Jeremy Rubin
2022-04-10 19:32 ` Peter Todd
2022-04-11 13:18 ` Jeremy Rubin
2022-04-15 14:52 ` Peter Todd
2022-04-17 20:57 ` Jeremy Rubin
2022-04-28 12:15 ` Peter Todd
2022-05-02 15:59 ` Jeremy Rubin
2022-06-14 11:12 ` [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd
2022-06-14 11:39 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 11:53 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 12:28 ` rot13maxi
2022-06-14 12:45 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 13:55 ` Bryan Bishop
2022-06-14 15:06 ` digital vagabond
2022-06-14 15:34 ` Peter Todd
2022-06-14 17:15 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 20:33 ` Andrew Poelstra
2022-06-15 1:16 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-15 1:21 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-19 11:04 ` Peter Todd
2022-06-14 15:22 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox