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

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

[Jeremy]

[-- 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 --]

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

[Billy Tetrud]

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

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

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

[Jeremy]

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

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

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

[Billy Tetrud]

[-- 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 --]

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

[Jeremy]

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

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

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

[Billy Tetrud]

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

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

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

[Jeremy]

[-- 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 --]

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

[Billy Tetrud]

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

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@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@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: 26019 bytes --]

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

[Jeremy]

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

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@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@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@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: 28513 bytes --]

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

[Billy Tetrud]

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

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@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@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@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@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: 29178 bytes --]

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

[Peter Todd]

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

On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev 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".

<snip>

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

So it's important to recognize that fee accounts introduce their own kind of
transaction pinning attacks: third parties would be able to attach arbitrary
fees to any transaction without permission. This isn't necessarily a good
thing: I don't want third parties to be able to grief my transaction engines by
getting obsolete transactions confirmed in liu of the replacments I actually
want confirmed. Eg a third party could mess up OpenTimestamps calendars at
relatively low cost by delaying the mining of timestamp txs.

Of course, there's an obvious way to fix this: allow transactions to designate
a pubkey allowed to add further transaction fees if required. Which Bitcoin
already has in two forms: Replace-by-Fee and Child Pays for Parent.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeremy Rubin]

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

That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.

Often times in these protocols "the call is coming inside the house". It's
not a third party adding fees we are scared of, it's a direct party to the
protocol!

Sponsors or fee accounts would enable you to ensure the protocol you're
working on makes forward progress. For things like Eltoo the internal
ratchet makes this work well.

Protocols which depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.

Cheers,

Jeremy

On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev 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".
>
> <snip>
>
> > 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.
>
> So it's important to recognize that fee accounts introduce their own kind
> of
> transaction pinning attacks: third parties would be able to attach
> arbitrary
> fees to any transaction without permission. This isn't necessarily a good
> thing: I don't want third parties to be able to grief my transaction
> engines by
> getting obsolete transactions confirmed in liu of the replacments I
> actually
> want confirmed. Eg a third party could mess up OpenTimestamps calendars at
> relatively low cost by delaying the mining of timestamp txs.
>
> Of course, there's an obvious way to fix this: allow transactions to
> designate
> a pubkey allowed to add further transaction fees if required. Which Bitcoin
> already has in two forms: Replace-by-Fee and Child Pays for Parent.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Peter Todd]

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

On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:
> That's not really pinning; painning usually refers to pinning something to
> the bottom of the mempool whereas these mechanisms make it easier to
> guarantee that progress can be made on confirming the transactions you're
> interested in.

As I said, it's a new kind of pinning attack, distinct from other types of
pinning attack.

> Often times in these protocols "the call is coming inside the house". It's
> not a third party adding fees we are scared of, it's a direct party to the
> protocol!

Often times that is true. But other times that is not true! I gave examples of
use-cases where being able to arbitrary add fees to transactions is harmful;
the onus is on you to argue why that is acceptable to burden those users with a
new class of attack.

> Sponsors or fee accounts would enable you to ensure the protocol you're
> working on makes forward progress. For things like Eltoo the internal
> ratchet makes this work well.
> 
> Protocols which depend on in mempool replacements before confirmation
> already must be happy (should they be secure) with any prior state being
> mined. If a third party pays the fee you might even be happier since the
> execution wasn't on your dime.

"Must be able to deal with" is not the same thing as "Must be happy". While
those use-cases do have to deal with those exceptional cases happening
occasionally, it's harmful if an attacker can harass you by making those
exceptional cases happen frequently.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeremy Rubin]

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

> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.

I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).

Something that only increases possibility to make progress cannot be
pinning.

If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).

I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.

Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.

In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.

By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.

Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.

Best,

Jeremy

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

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

[Peter Todd]

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

On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > As I said, it's a new kind of pinning attack, distinct from other types
> of pinning attack.
> 
> I think pinning is "formally defined" as sequences of transactions which
> prevent or make it less likely for you to make any progress (in terms of
> units of computation proceeding).

Mentioning "computation" when talking about transactions is misleading:
blockchain transactions have nothing to do with computation.

> Something that only increases possibility to make progress cannot be
> pinning.

It is incorrect to say that all use-cases have the property that any version of
a transaction being mined is progress.

> If you want to call it something else, with a negative connotation, maybe
> call it "necromancing" (bringing back txns that would otherwise be
> feerate/fee irrational).

Necromancing might be a reasonable name for attacks that work by getting an
out-of-date version of a tx mined.

> In particular, for the use case you mentioned "Eg a third party could mess
> up OpenTimestamps calendars at relatively low cost by delaying the mining
> of timestamp txs.", this is incorrect. A third party can only accelerate
> the mining on the timestamp transactions, but they *can* accelerate the
> mining of any such timestamp transaction. If you have a single output chain
> that you're RBF'ing per block, then at most they can cause you to shift the
> calendar commits forward one block. But again, they cannot pin you. If you
> want to shift it back one block earlier, just offer a higher fee for the
> later RBF'd calendar. Thus the interference is limited by how much you wish
> to pay to guarantee your commitment is in this block as opposed to the next.

Your understanding of how OpenTimestamps calendars work appears to be
incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars
use RBF to _update_ the timestamp tx with a new merkle tip hash for to all
outstanding per-second commitments once per new block. In high fee situations
it's normal for there to be dozens of versions of that same tx, each with a
slightly higher feerate.

OTS calendars can handle any of those versions getting mined. But older
versions getting mined wastes money, as the remaining commitments still need to
get mined in a subsequent transaction. Those remaining commitments are also
delayed by the time it takes for the next tx to get mined.

There are many use-cases beyond OTS with this issue. For example, some entities
use "in-place" replacement for update low-time-preference settlement
transactions by adding new txouts and updating existing ones. Older versions of
those settlement transactions getting mined rather than the newer version
wastes money and delays settlement for the exact same reason it does in OTS.

If fee accounts or any similar mechanism get implemented, they absolutely
should be opt-in. Obviously, using a currently non-standard nVersion bit is a
possible approach. Conversely, with CPFP it may be desirable in the settlement
case to be able to *prevent* outputs from being spent in the same block. Again,
an nVersion bit is a possible approach.

> By the way, you can already do out-of-band transaction fees to a very
> similar effect, google "BTC transaction accelerator". If the attack were at
> all valuable to perform, it could happen today.

I just checked: all the BTC transaction accellerator services I could find look
to be either scams, or very expensive. We need compelling reasons to make this
nuisance attack significantly cheaper.

> Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> third party for OTS, you should be relatively happy because it cost you
> less fees overall, since the undoing of your later RBF surely returned some
> satoshis to your wallet.

As I said above, no it doesn't.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[darosior]

> Necromancing might be a reasonable name for attacks that work by getting an
> out-of-date version of a tx mined.

It's not an "attack"? There is no such thing as an out-of-date transaction, if
you signed and broadcasted it in the first place. You can't rely on the fact that
a replacement transaction would somehow invalidate a previous version of it.

------- Original Message -------

Le samedi 19 février 2022 à 10:39 AM, Peter Todd <pete@petertodd.org> a écrit :

> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
>
> > > As I said, it's a new kind of pinning attack, distinct from other types
> > >
> > > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions which
> >
> > prevent or make it less likely for you to make any progress (in terms of
> >
> > units of computation proceeding).
>
> Mentioning "computation" when talking about transactions is misleading:
>
> blockchain transactions have nothing to do with computation.
>
> > Something that only increases possibility to make progress cannot be
> >
> > pinning.
>
> It is incorrect to say that all use-cases have the property that any version of
>
> a transaction being mined is progress.
>
> > If you want to call it something else, with a negative connotation, maybe
> >
> > call it "necromancing" (bringing back txns that would otherwise be
> >
> > feerate/fee irrational).
>
> Necromancing might be a reasonable name for attacks that work by getting an
>
> out-of-date version of a tx mined.
>
> > In particular, for the use case you mentioned "Eg a third party could mess
> >
> > up OpenTimestamps calendars at relatively low cost by delaying the mining
> >
> > of timestamp txs.", this is incorrect. A third party can only accelerate
> >
> > the mining on the timestamp transactions, but they can accelerate the
> >
> > mining of any such timestamp transaction. If you have a single output chain
> >
> > that you're RBF'ing per block, then at most they can cause you to shift the
> >
> > calendar commits forward one block. But again, they cannot pin you. If you
> >
> > want to shift it back one block earlier, just offer a higher fee for the
> >
> > later RBF'd calendar. Thus the interference is limited by how much you wish
> >
> > to pay to guarantee your commitment is in this block as opposed to the next.
>
> Your understanding of how OpenTimestamps calendars work appears to be
>
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars
>
> use RBF to update the timestamp tx with a new merkle tip hash for to all
>
> outstanding per-second commitments once per new block. In high fee situations
>
> it's normal for there to be dozens of versions of that same tx, each with a
>
> slightly higher feerate.
>
> OTS calendars can handle any of those versions getting mined. But older
>
> versions getting mined wastes money, as the remaining commitments still need to
>
> get mined in a subsequent transaction. Those remaining commitments are also
>
> delayed by the time it takes for the next tx to get mined.
>
> There are many use-cases beyond OTS with this issue. For example, some entities
>
> use "in-place" replacement for update low-time-preference settlement
>
> transactions by adding new txouts and updating existing ones. Older versions of
>
> those settlement transactions getting mined rather than the newer version
>
> wastes money and delays settlement for the exact same reason it does in OTS.
>
> If fee accounts or any similar mechanism get implemented, they absolutely
>
> should be opt-in. Obviously, using a currently non-standard nVersion bit is a
>
> possible approach. Conversely, with CPFP it may be desirable in the settlement
>
> case to be able to prevent outputs from being spent in the same block. Again,
>
> an nVersion bit is a possible approach.
>
> > By the way, you can already do out-of-band transaction fees to a very
> >
> > similar effect, google "BTC transaction accelerator". If the attack were at
> >
> > all valuable to perform, it could happen today.
>
> I just checked: all the BTC transaction accellerator services I could find look
>
> to be either scams, or very expensive. We need compelling reasons to make this
>
> nuisance attack significantly cheaper.
>
> > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> >
> > third party for OTS, you should be relatively happy because it cost you
> >
> > less fees overall, since the undoing of your later RBF surely returned some
> >
> > satoshis to your wallet.
>
> As I said above, no it doesn't.
>
> ----------------------------------
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> Lightning-dev mailing list
>
> Lightning-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Peter Todd]

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

On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
> > Necromancing might be a reasonable name for attacks that work by getting an
> > out-of-date version of a tx mined.
> 
> It's not an "attack"? There is no such thing as an out-of-date transaction, if
> you signed and broadcasted it in the first place. You can't rely on the fact that
> a replacement transaction would somehow invalidate a previous version of it.

Anyone on the internet can send you a packet; a secure system must be able to
receive any packet without being compromised. Yet we still call packet floods
as DoS attacks. And internet standards are careful to avoid making packet
flooding cheaper than it currently is.

The same principal applies here: in many situations transactions _do_ become
out of date, in the sense that you would rather a different transaction be
mined instead, and the out-of-date tx being mined is expensive and annoying.
While you have to account for the _possibility_ of any transaction you have
signed being mined, Bitcoin standards should avoid making unwanted necromancy a
cheap and easy attack.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[ZmnSCPxj]

Good morning Peter and Jeremy,

> On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
>
> > > Necromancing might be a reasonable name for attacks that work by getting an
> > > out-of-date version of a tx mined.
> >
> > It's not an "attack"? There is no such thing as an out-of-date transaction, if
> > you signed and broadcasted it in the first place. You can't rely on the fact that
> > a replacement transaction would somehow invalidate a previous version of it.
>
> Anyone on the internet can send you a packet; a secure system must be able to
> receive any packet without being compromised. Yet we still call packet floods
> as DoS attacks. And internet standards are careful to avoid making packet
> flooding cheaper than it currently is.
>
> The same principal applies here: in many situations transactions do become
> out of date, in the sense that you would rather a different transaction be
> mined instead, and the out-of-date tx being mined is expensive and annoying.
> While you have to account for the possibility of any transaction you have
> signed being mined, Bitcoin standards should avoid making unwanted necromancy a
> cheap and easy attack.
>

This seems to me to restrict the only multiparty feebumping method to be some form of per-participant anchor outputs a la Lightning anchor commitments.

Note that multiparty RBF is unreliable.
While the initial multiparty signing of a transaction may succeed, at a later time with the transaction unconfirmed, one or more of the participants may regret cooperating in the initial signing and decide not to cooperate with the RBF.
Or for that matter, a participant may, through complete accident, go offline.

Anchor outputs can be keyed to only a specific participant, so feebumping of particular transaction can only be done by participants who have been authorized to feebump.

Perhaps fee accounts can include some kind of proof-this-transaction-authorizes-this-fee-account?

Regards,
ZmnSCPxj

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

[ZmnSCPxj]

Good morning Peter and Jeremy,

> Good morning Peter and Jeremy,
>
> > On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
> >
> > > > Necromancing might be a reasonable name for attacks that work by getting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an "attack"? There is no such thing as an out-of-date transaction, if
> > > you signed and broadcasted it in the first place. You can't rely on the fact that
> > > a replacement transaction would somehow invalidate a previous version of it.
> >
> > Anyone on the internet can send you a packet; a secure system must be able to
> > receive any packet without being compromised. Yet we still call packet floods
> > as DoS attacks. And internet standards are careful to avoid making packet
> > flooding cheaper than it currently is.
> > The same principal applies here: in many situations transactions do become
> > out of date, in the sense that you would rather a different transaction be
> > mined instead, and the out-of-date tx being mined is expensive and annoying.
> > While you have to account for the possibility of any transaction you have
> > signed being mined, Bitcoin standards should avoid making unwanted necromancy a
> > cheap and easy attack.
>
> This seems to me to restrict the only multiparty feebumping method to be some form of per-participant anchor outputs a la Lightning anchor commitments.
>
> Note that multiparty RBF is unreliable.
> While the initial multiparty signing of a transaction may succeed, at a later time with the transaction unconfirmed, one or more of the participants may regret cooperating in the initial signing and decide not to cooperate with the RBF.
> Or for that matter, a participant may, through complete accident, go offline.
>
> Anchor outputs can be keyed to only a specific participant, so feebumping of particular transaction can only be done by participants who have been authorized to feebump.
>
> Perhaps fee accounts can include some kind of proof-this-transaction-authorizes-this-fee-account?

For example:

* We reserve one Tapscript version for fee-account-authorization.
  * Validation of this tapscript version always fails.
* If a transaction wants to authorize a fee account, it should have at least one Taproot output.
  * This Taproot output must have tapleaf with the fee-account-authorization Tapscript version.
* In order for a fee account to feebump a transaction, it must also present the Taproot MAST path to the fee-account-authorization tapleaf of one output of that transaction.

This gives similar functionality to anchor outputs, without requiring an explicit output on the initial transaction, saving blockspace.
In particular, once the number of participants grows, the number of anchor outputs must grow linearly with the number of participants being authorized to feebump.
Only when the feerate turns out to be too low do we need to expose the authorization.
Revelation of the fee-account-authorization is O(log N), and if only one participant decides to feebump, then only a single O(log N) MAST treepath is published.

Regards,
ZmnSCPxj

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

[ZmnSCPxj]

Good morning DA,


> Agreed, you cannot rely on a replacement transaction would somehow
> invalidate a previous version of it, it has been spoken into the gossip
> and exists there in mempools somewhere if it does, there is no guarantee
> that anyone has ever heard of the replacement transaction as there is no
> consensus about either the previous version of the transaction or its
> replacement until one of them is mined and the block accepted. -DA.

As I understand from the followup from Peter, the point is not "this should never happen", rather the point is "this should not happen *more often*."

Regards,
ZmnSCPxj

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

[Jeremy Rubin]

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

opt-in or explicit tagging of fee account is a bad design IMO.

As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan.... suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
precommitted key you have to maintain? What happens to your ability to bump
should it be compromised (which may be more likely if it's intended to be a
hot-wallet function for bumping).

Furthermore, it's quite often the case that someone might do a transaction
that pays you that is low fee that you want to bump but they choose to
opt-out... then what? It's better that you should always be able to fee
bump.


--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning DA,
>
>
> > Agreed, you cannot rely on a replacement transaction would somehow
> > invalidate a previous version of it, it has been spoken into the gossip
> > and exists there in mempools somewhere if it does, there is no guarantee
> > that anyone has ever heard of the replacement transaction as there is no
> > consensus about either the previous version of the transaction or its
> > replacement until one of them is mined and the block accepted. -DA.
>
> As I understand from the followup from Peter, the point is not "this
> should never happen", rather the point is "this should not happen *more
> often*."
>
> Regards,
> ZmnSCPxj
>

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

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

[ZmnSCPxj]

Good morning Jeremy,

> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit key required means you have to pre-plan.... suppose you're building a vault meant to distribute funds over many years, do you really want a *specific* precommitted key you have to maintain? What happens to your ability to bump should it be compromised (which may be more likely if it's intended to be a hot-wallet function for bumping).
>
> Furthermore, it's quite often the case that someone might do a transaction that pays you that is low fee that you want to bump but they choose to opt-out... then what? It's better that you should always be able to fee bump.

Good point.

For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves relative locktimes, of course.


Once could point out as well that Peter Todd gave just a single example, OpenTimeStamps, for this, and OpenTimeStamps is not the only user of the Bitcoin blockchain.

So we can consider: who benefits and who suffers, and does the benefit to the former outweigh the detriment of the latter?


It seems to me that the necromancing attack mostly can *only* target users of RBF that might want to *additionally* add outputs (or in the case of OTS, commitments) when RBF-ing.
For example, a large onchain-paying entity might lowball an onchain transaction for a few withdrawals, then as more withdrawals come in, bump up their feerate and add more withdrawals to the RBF-ed transaction.
Such an entity might prefer to confirm the latest RBF-ed transaction, as if an earlier transaction (which does not include some other withdrawals requested later) is necromanced, they would need to make an *entire* *other* transaction (which may be costlier!) to fulfill pending withdrawal requests.

However, to my knowledge, there is no actual entity that *currently* acts this way (I do have some sketches for a wallet that can support this behavior, but it gets *complicated* due to having to keep track of reorgs as well... sigh).

In particular, I expect that many users do not really make outgoing payments often enough that they would actually benefit from such a wallet feature.
Instead, they will generally make one payment at a time, or plan ahead and pay several in a batch at once, and even if they RBF, they would just keep the same set of outputs and just reduce their change output.
For such low-scale users, a rando third-party necromancing their old transactions could only make them happy, thus this nuisance attack cannot be executed.

We could also point out that this is really a nuisance attack and not an economic-theft attack.
The attacker cannot gain, and can only pay in order to impose costs on somebody else.
Rationally, the only winning move is not to play.


So --- has anyone actually implemented a Bitcoin wallet that has such a feature (i.e. make a lowball send transaction now, then you can add another send later and if the previous send transaction is unconfirmed, RBF it with a new transaction that has the previous send and the current send) and if so, can you open-source the code and show me?


Regards,
ZmnSCPxj

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

[Jeremy Rubin]

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

Morning!

>
> For the latter case, CPFP would work and already exists.
> **Unless** you are doing something complicated and offchain-y and involves
> relative locktimes, of course.
>
>
The "usual" design I recommend for Vaults contains something that is like:

{<maturity> CSV <pk_hot> CHECKSIG, <pk_cold> CHECKSIG}
or
{<maturity> CSV <pk_hot> CHECKSIG, <H(tx to: <pk_cold> CHECKSIG)> CTV}


where after an output is created, it has to hit maturity before hot
spendable but can be kicked to recovery any time before (optional: use CTV
to actually transition on chain removing hot wallet, if cold key is hard to
access).


Not that this means if you're waiting for one of these outputs to be
created on chain, you cannot spend from the hot key since it needs to
confirm on chain first. Spending from the cold key for CPFP'ing the hot is
an 'invalid move' (emergency key for non emergency sitch)

Thus in order to CPFP, you would need a separate output just for CPFPing
that is not subject to these restrictions, or some sort of RBF-able addable
input/output. Or, Sponsors.


Jeremy

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

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

[Jeremy Rubin]

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

--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sat, Feb 19, 2022 at 1:39 AM Peter Todd <pete@petertodd.org> wrote:

> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > As I said, it's a new kind of pinning attack, distinct from other types
> > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions which
> > prevent or make it less likely for you to make any progress (in terms of
> > units of computation proceeding).
>
> Mentioning "computation" when talking about transactions is misleading:
> blockchain transactions have nothing to do with computation.
>

It is in fact computation. Branding it as "misleading" is misleading... The
relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
sponsors helps get rid of deadlocking so that any thread can be guaranteed
to make progress. E.g., this is critical in Eltoo, which is effectively a
coordinated multi-party computation on-chain to compute the highest
sequence number known by any worker.

That transactions are blobs of "verification" (which is also itself a
computation) less so than dynamic computations is irrelevant to the fact
that series of transactions do represent computations.



> > Something that only increases possibility to make progress cannot be
> > pinning.
>
> It is incorrect to say that all use-cases have the property that any
> version of
> a transaction being mined is progress.
>

It is progress, tautologically. Progress is formally definable as a
transaction of any kind getting mined. Pinning prevents progress by an
adversarial worker. Sponsoring enables progress, but it may not be your
preferred interleaving. That's OK, but it's inaccurate to say it is not
progress.

Your understanding of how OpenTimestamps calendars work appears to be
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS
> calendars
> use RBF to _update_ the timestamp tx with a new merkle tip hash for to all
> outstanding per-second commitments once per new block. In high fee
> situations
> it's normal for there to be dozens of versions of that same tx, each with a
> slightly higher feerate.
>

I didn't claim there to be a chain of unconfirmed, I claimed that there
could be single output chain that you're RBF'ing one step per block.

E.g., it could be something like

A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}

such that A_i provably can't have an unconfirmed descendant. The notion
would be that you're replacing one with another. E.g., if you're updating
the calendar like:


Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}

and version 1 gets mined, then in A_1's spend you simply shift delta to
that (next) calendar.

A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}

Thus my claim that someone sponsoring a old version only can delay by 1
block the calendar commit.





> OTS calendars can handle any of those versions getting mined. But older
> versions getting mined wastes money, as the remaining commitments still
> need to
> get mined in a subsequent transaction. Those remaining commitments are also
> delayed by the time it takes for the next tx to get mined.
>
> There are many use-cases beyond OTS with this issue. For example, some
> entities
> use "in-place" replacement for update low-time-preference settlement
> transactions by adding new txouts and updating existing ones. Older
> versions of
> those settlement transactions getting mined rather than the newer version
> wastes money and delays settlement for the exact same reason it does in
> OTS.
>
>
> > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> > third party for OTS, you should be relatively happy because it cost you
> > less fees overall, since the undoing of your later RBF surely returned
> some
> > satoshis to your wallet.
>
> As I said above, no it doesn't.
>
>
It does save money since you had to pay to RBF, the N+1st txn will be
paying higher fee than the Nth. So if someone else sponsors an earlier
version, then you save whatever feerate/fee bumps you would have paid and
the funds are again in your change output (or something). You can apply
those change output savings to your next batch, which can include any
entries that have been dropped .

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

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

[Peter Todd]

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

On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote:
> > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > > As I said, it's a new kind of pinning attack, distinct from other types
> > > of pinning attack.
> > >
> > > I think pinning is "formally defined" as sequences of transactions which
> > > prevent or make it less likely for you to make any progress (in terms of
> > > units of computation proceeding).
> >
> > Mentioning "computation" when talking about transactions is misleading:
> > blockchain transactions have nothing to do with computation.
> >
> 
> It is in fact computation. Branding it as "misleading" is misleading... The
> relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
> sponsors helps get rid of deadlocking so that any thread can be guaranteed
> to make progress. E.g., this is critical in Eltoo, which is effectively a
> coordinated multi-party computation on-chain to compute the highest
> sequence number known by any worker.
> 
> That transactions are blobs of "verification" (which is also itself a
> computation) less so than dynamic computations is irrelevant to the fact
> that series of transactions do represent computations.

It's misleading in the blockchain environment where lots of people have been
trying to portray blockchain schemes as "world computers" and other nonsense
marketing. You would have been better off just saying "make any progress"
without mentioning "computation" at all.

> > > Something that only increases possibility to make progress cannot be
> > > pinning.
> >
> > It is incorrect to say that all use-cases have the property that any
> > version of
> > a transaction being mined is progress.
> >
> 
> It is progress, tautologically. Progress is formally definable as a
> transaction of any kind getting mined. Pinning prevents progress by an
> adversarial worker. Sponsoring enables progress, but it may not be your
> preferred interleaving. That's OK, but it's inaccurate to say it is not
> progress.

Let's try to use terminology with straight-forward meanings. I've yet to see
any other protocol where "progess" can also mean useless work being done.

> I didn't claim there to be a chain of unconfirmed, I claimed that there
> could be single output chain that you're RBF'ing one step per block.
> 
> E.g., it could be something like
> 
> A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}
> 
> such that A_i provably can't have an unconfirmed descendant. The notion
> would be that you're replacing one with another. E.g., if you're updating
> the calendar like:
> 
> 
> Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
> Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}
> 
> and version 1 gets mined, then in A_1's spend you simply shift delta to
> that (next) calendar.
> 
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}
> 
> Thus my claim that someone sponsoring a old version only can delay by 1
> block the calendar commit.

You seem to still be confused about OpenTimestamps. There is no output chain at
all; OTS has no reason to use CheckSequenceVerify and does not. OTS
transactions are, from the point of view of the timestamp proofs, entirely
independent of one another.

Remember that OTS simply proves data in the past. Nothing more.

> > > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> > > third party for OTS, you should be relatively happy because it cost you
> > > less fees overall, since the undoing of your later RBF surely returned
> > some
> > > satoshis to your wallet.
> >
> > As I said above, no it doesn't.
> >
> >
> It does save money since you had to pay to RBF, the N+1st txn will be
> paying higher fee than the Nth. So if someone else sponsors an earlier
> version, then you save whatever feerate/fee bumps you would have paid and
> the funds are again in your change output (or something). You can apply
> those change output savings to your next batch, which can include any
> entries that have been dropped .

Again, that is not true. Because OTS doesn't have a chain of transactions, I'd
rather do one transaction with all pending commitments at a particular time
rather than waste money on mining two transactions for a given set of
commitments that need timestamping.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeremy Rubin]

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

> nonsense marketing

I'm sure the people who are confused about "blockchain schemes as \"world
computers\" and other nonsense
marketing" are avid and regular readers of the bitcoin devs mailing list so
I offer my sincerest apologies to all members of the intersection of those
sets who were confused by the description given.

> useless work

progress is not useless work, it *is* useful work in this context. you have
committed to some subset of data that you requested -- if it was 'useless',
why did you *ever* bother to commit it in the first place? However, it is
not 'maximally useful' in some sense. However, progress is progress --
suppose you only confirmed 50% of the commitments, is that not progress? If
you just happened to observe 50% of the commitments commit because of
proximity to the time a block was mined and tx propagation naturally would
you call it useless?

> Remember that OTS simply proves data in the past. Nothing more.
> OTS doesn't have a chain of transactions
Gotcha -- I've not been able to find an actual spec of Open Time Stamps
anywhere, so I suppose I just assumed based on how I think it *should*
work. Having a chain of transactions would serve to linearize history of
OTS commitments which would let you prove, given reorgs, that knowledge of
commit A was before B a bit more robustly.

>  I'd rather do one transaction with all pending commitments at a
particular time
rather than waste money on mining two transactions for a given set of
commitments

This sounds like a personal preference v.s. a technical requirement.

You aren't doing any extra transactions in the model i showed, what you're
doing is selecting the window for the next based on the prior conf.

See the diagram below, you would have to (if OTS is correct) support this
sort of 'attempt/confirm' head that tracks attempted commitments and
confirmed ones and 'rewinds' after a confirm to make the next commit
contain the prior attempts that didn't make it.

[.........................................................................]
 ------^ confirm head tx 0 at height 34
        ------------------------^ attempt head after tx 0
         -----------^ confirm head tx 1 at height 35
                      --------------------------^ attempt head after tx 1
                      ------------^ confirm head tx 2 at height 36
                                     -------------------------------^
attempt head after tx 2
                                      -------------------------------^
confirm head tx 3 at height 37

you can compare this to a "spherical cow" model where RBF is always perfect
and guaranteed inclusion:


[.........................................................................]
 ------^ confirm head tx 0 at height 34
       -------------------------^ confirm head tx 1 at height 35
                                       -----------^ confirm head at tx 1
height 36
                                                       -----------------^
confirm head tx 3 at height 37

The same number of transactions gets used over the time period.

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

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

[Peter Todd]

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

On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > nonsense marketing
> 
> I'm sure the people who are confused about "blockchain schemes as \"world
> computers\" and other nonsense
> marketing" are avid and regular readers of the bitcoin devs mailing list so
> I offer my sincerest apologies to all members of the intersection of those
> sets who were confused by the description given.

Of course, uninformed people _do_ read all kinds of technical materials. And
more importantly, those technical materials get quoted by journalists,
scammers, etc.

> > useless work
> 
> progress is not useless work, it *is* useful work in this context. you have
> committed to some subset of data that you requested -- if it was 'useless',
> why did you *ever* bother to commit it in the first place? However, it is
> not 'maximally useful' in some sense. However, progress is progress --
> suppose you only confirmed 50% of the commitments, is that not progress? If
> you just happened to observe 50% of the commitments commit because of
> proximity to the time a block was mined and tx propagation naturally would
> you call it useless?

Please don't trim quoted text to the point where all context is lost. Lots of
people read this mailing list and doing that isn't helpful to them.

> > Remember that OTS simply proves data in the past. Nothing more.
> > OTS doesn't have a chain of transactions
> Gotcha -- I've not been able to find an actual spec of Open Time Stamps

The technical spec of OpenTimestamps is of course the normative validation
source code, currently python-opentimestamps, similar to how the technical spec
of Bitcoin is the consensus parts of the Bitcoin Core codebase. The explanatory
docs are linked on https://opentimestamps.org under the "How It Works" section.
It'd be good to take the linked post in that section and turn it into better
explanatory materials with graphics (esp interactive/animated graphics).

> anywhere, so I suppose I just assumed based on how I think it *should*
> work. Having a chain of transactions would serve to linearize history of
> OTS commitments which would let you prove, given reorgs, that knowledge of
> commit A was before B a bit more robustly.

I'll reply to this as a separate email as this discussion - while useful - is
getting quite off topic for this thread.

> >  I'd rather do one transaction with all pending commitments at a
> particular time
> rather than waste money on mining two transactions for a given set of
> commitments
> 
> This sounds like a personal preference v.s. a technical requirement.
> 
> You aren't doing any extra transactions in the model i showed, what you're
> doing is selecting the window for the next based on the prior conf.

...the model you showed is wrong, as there is no reason to have a linearized
transaction history. OpenTimestamps proofs don't even have the concept of
transactions: the proof format proves that data existed prior to a merkle root
of a particular Bitcoin block. Not a Bitcoin transaction.

> See the diagram below, you would have to (if OTS is correct) support this
> sort of 'attempt/confirm' head that tracks attempted commitments and
> confirmed ones and 'rewinds' after a confirm to make the next commit
> contain the prior attempts that didn't make it.
> 
> [.........................................................................]
>  ------^ confirm head tx 0 at height 34
>         ------------------------^ attempt head after tx 0
>          -----------^ confirm head tx 1 at height 35
>                       --------------------------^ attempt head after tx 1
>                       ------------^ confirm head tx 2 at height 36
>                                      -------------------------------^
> attempt head after tx 2
>                                       -------------------------------^
> confirm head tx 3 at height 37
> 
> you can compare this to a "spherical cow" model where RBF is always perfect
> and guaranteed inclusion:
> 
> 
> [.........................................................................]
>  ------^ confirm head tx 0 at height 34
>        -------------------------^ confirm head tx 1 at height 35
>                                        -----------^ confirm head at tx 1
> height 36
>                                                        -----------------^
> confirm head tx 3 at height 37
> 
> The same number of transactions gets used over the time period.

None of the above has anything to do with how OpenTimestamps works.

Anyway, getting back to the topic at hand, I remain of the opinion that in the
unlikely event that fee accounts is ever implemented, it should be opt-in.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeremy Rubin]

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

the 'lots of people' stuff (get confused, can't figure out what i'm
quoting, actually are reading this conversation) is an appeal to an
authority that doesn't exist. If something is unclear to you, let me know.
If it's unclear to a supposed existential person or set of persons, they
can let me know.


concretely, I am confused by how OTS can both support RBF for updating to
larger commitments (the reason you're arguing with me) and not have an
epoch based re-comittings scheme and still be correct. My assumption now,
short of a coherent spec that's not just 'read the code', is that OTS
probably is not formally correct and has some holes in what is
committed to, or relies on clients re-requesting proofs if they fail to be
committed. in any case, you would be greatly aided by having an actual spec
for OTS since i'm not interested in the specifics of OTS software, but I'm
willing to look at the protocol. So if you do that, maybe we can talk more
about the issue you see with how sponsors works.

further, I think that if there is something that sponsors does that could
make a hypothetical OTS-like service work better, in a way that would be
opaque (read: soft-fork like wrt compatibility) to clients, then we should
just change what OTS is rather than committing ourselves to a worse design
in service of some unstated design goals. In particular, it seems that
OTS's servers can be linearized and because old clients aren't looking for
linearization, then the new linearization won't be a breaking change for
old clients, just calendar servers. And new clients can benefit from
linearization.
--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Fri, Apr 15, 2022 at 7:52 AM Peter Todd <pete@petertodd.org> wrote:

> On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > > nonsense marketing
> >
> > I'm sure the people who are confused about "blockchain schemes as \"world
> > computers\" and other nonsense
> > marketing" are avid and regular readers of the bitcoin devs mailing list
> so
> > I offer my sincerest apologies to all members of the intersection of
> those
> > sets who were confused by the description given.
>
> Of course, uninformed people _do_ read all kinds of technical materials.
> And
> more importantly, those technical materials get quoted by journalists,
> scammers, etc.
>
> > > useless work
> >
> > progress is not useless work, it *is* useful work in this context. you
> have
> > committed to some subset of data that you requested -- if it was
> 'useless',
> > why did you *ever* bother to commit it in the first place? However, it is
> > not 'maximally useful' in some sense. However, progress is progress --
> > suppose you only confirmed 50% of the commitments, is that not progress?
> If
> > you just happened to observe 50% of the commitments commit because of
> > proximity to the time a block was mined and tx propagation naturally
> would
> > you call it useless?
>
> Please don't trim quoted text to the point where all context is lost. Lots
> of
> people read this mailing list and doing that isn't helpful to them.
>
> > > Remember that OTS simply proves data in the past. Nothing more.
> > > OTS doesn't have a chain of transactions
> > Gotcha -- I've not been able to find an actual spec of Open Time Stamps
>
> The technical spec of OpenTimestamps is of course the normative validation
> source code, currently python-opentimestamps, similar to how the technical
> spec
> of Bitcoin is the consensus parts of the Bitcoin Core codebase. The
> explanatory
> docs are linked on https://opentimestamps.org under the "How It Works"
> section.
> It'd be good to take the linked post in that section and turn it into
> better
> explanatory materials with graphics (esp interactive/animated graphics).
>
> > anywhere, so I suppose I just assumed based on how I think it *should*
> > work. Having a chain of transactions would serve to linearize history of
> > OTS commitments which would let you prove, given reorgs, that knowledge
> of
> > commit A was before B a bit more robustly.
>
> I'll reply to this as a separate email as this discussion - while useful -
> is
> getting quite off topic for this thread.
>
> > >  I'd rather do one transaction with all pending commitments at a
> > particular time
> > rather than waste money on mining two transactions for a given set of
> > commitments
> >
> > This sounds like a personal preference v.s. a technical requirement.
> >
> > You aren't doing any extra transactions in the model i showed, what
> you're
> > doing is selecting the window for the next based on the prior conf.
>
> ...the model you showed is wrong, as there is no reason to have a
> linearized
> transaction history. OpenTimestamps proofs don't even have the concept of
> transactions: the proof format proves that data existed prior to a merkle
> root
> of a particular Bitcoin block. Not a Bitcoin transaction.
>
> > See the diagram below, you would have to (if OTS is correct) support this
> > sort of 'attempt/confirm' head that tracks attempted commitments and
> > confirmed ones and 'rewinds' after a confirm to make the next commit
> > contain the prior attempts that didn't make it.
> >
> >
> [.........................................................................]
> >  ------^ confirm head tx 0 at height 34
> >         ------------------------^ attempt head after tx 0
> >          -----------^ confirm head tx 1 at height 35
> >                       --------------------------^ attempt head after tx 1
> >                       ------------^ confirm head tx 2 at height 36
> >                                      -------------------------------^
> > attempt head after tx 2
> >                                       -------------------------------^
> > confirm head tx 3 at height 37
> >
> > you can compare this to a "spherical cow" model where RBF is always
> perfect
> > and guaranteed inclusion:
> >
> >
> >
> [.........................................................................]
> >  ------^ confirm head tx 0 at height 34
> >        -------------------------^ confirm head tx 1 at height 35
> >                                        -----------^ confirm head at tx 1
> > height 36
> >                                                        -----------------^
> > confirm head tx 3 at height 37
> >
> > The same number of transactions gets used over the time period.
>
> None of the above has anything to do with how OpenTimestamps works.
>
> Anyway, getting back to the topic at hand, I remain of the opinion that in
> the
> unlikely event that fee accounts is ever implemented, it should be opt-in.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

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

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

[Peter Todd]

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

On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote:
> the 'lots of people' stuff (get confused, can't figure out what i'm
> quoting, actually are reading this conversation) is an appeal to an
> authority that doesn't exist. If something is unclear to you, let me know.
> If it's unclear to a supposed existential person or set of persons, they
> can let me know.

It's pretty simple: bitcoin-dev is read by hundreds of people. This has nothing
to do with authority. It's about not wasting the time of those people.

> concretely, I am confused by how OTS can both support RBF for updating to
> larger commitments (the reason you're arguing with me) and not have an
> epoch based re-comittings scheme and still be correct. My assumption now,
> short of a coherent spec that's not just 'read the code', is that OTS
> probably is not formally correct and has some holes in what is
> committed to, or relies on clients re-requesting proofs if they fail to be
> committed. in any case, you would be greatly aided by having an actual spec
> for OTS since i'm not interested in the specifics of OTS software, but I'm
> willing to look at the protocol. So if you do that, maybe we can talk more
> about the issue you see with how sponsors works.

OpenTimestamps is, as the name suggests, for cryptographic timestamping. As is
obvious to anyone with a good knowledge of cryptography, a cryptographic
timestamp proves that data existed prior to some point in time. That's it.

> further, I think that if there is something that sponsors does that could
> make a hypothetical OTS-like service work better, in a way that would be
> opaque (read: soft-fork like wrt compatibility) to clients, then we should
> just change what OTS is rather than committing ourselves to a worse design
> in service of some unstated design goals. In particular, it seems that
> OTS's servers can be linearized and because old clients aren't looking for
> linearization, then the new linearization won't be a breaking change for
> old clients, just calendar servers. And new clients can benefit from
> linearization.

The fact you keep bringing up linearization for a timestmaping service makes me
think something is missing in your understanding of cryptography. Tell me, how
exactly do you think linearization would help in an example use-case? More
specifically, what attack would be prevented?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeremy Rubin]

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

Ok, got it. Won't waste anyone's time on terminology pedantism.


The model that I proposed above is simply what *any* correct timestamping
service must do. If OTS does not follow that model, then I suspect whatever
OTS is, is provably incorrect or, in this context, unreliable, even when
servers and clients are honest. Unreliable might mean different things to
different people, I'm happy to detail the types of unreliability issue that
arise if you do not conform to the model I presented above (of which,
linearizability is one way to address it, there are others that still
implement epoch based recommitting that could be conceptually sound without
requiring linearizability).

Do you have any formal proof of what guarantees OTS provides against which
threat model? This is likely difficult to produce without a formal model of
what OTS is, but perhaps you can give your best shot at producing one and
we can carry the conversation on productively from there.

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

[bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Peter Todd]

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

On Mon, May 02, 2022 at 08:59:49AM -0700, Jeremy Rubin wrote:
> Ok, got it. Won't waste anyone's time on terminology pedantism.
> 
> 
> The model that I proposed above is simply what *any* correct timestamping
> service must do. If OTS does not follow that model, then I suspect whatever
> OTS is, is provably incorrect or, in this context, unreliable, even when
> servers and clients are honest.

Do you think RFC 3628 is "provably incorrect" too? It's just a standard for
Trusted Time-Stamping Authorities to issue timestamp proofs via digital
signatures, in the most straight forward manner of signing a message claiming
that some digest existed as of some time.

As the RFC says in the introduction:

    The TSA's role is to time-stamp a datum to establish evidence indicating that a
    datum existed before a particular time.  This can then be used, for example, to
    verify that a digital signature was applied to a message before the
    corresponding certificate was revoked thus allowing a revoked public key
    certificate to be used for verifying signatures created prior to the time of
    revocation.

Simple and straight forward.

The problem here is starts with the fact that you're asking timestamp services
to do things that they're not claiming they do; a timestamp proof simply proves
that some message m existed prior to some time t. Nothing more.

Worse though, linearization is a busted approach.

> Unreliable might mean different things to
> different people, I'm happy to detail the types of unreliability issue that
> arise if you do not conform to the model I presented above (of which,
> linearizability is one way to address it, there are others that still
> implement epoch based recommitting that could be conceptually sound without
> requiring linearizability).
> 
> Do you have any formal proof of what guarantees OTS provides against which
> threat model? This is likely difficult to produce without a formal model of
> what OTS is, but perhaps you can give your best shot at producing one and
> we can carry the conversation on productively from there.

So as you know, an OpenTimestamps proof consists of a series of commitment
operations that act on an initial message m, leading to a message known to have
been created at some point in time. Almost always a Bitcoin block header. But
other schemes like trusted timestamps are possible too.

A commitment operation (namely hashes + concatenation) simply needs the
property that for a given input message m, the output H(m) can't be predicted
without knowledge of m. In the case of concatenation, this property is achieved
trivially by the fact that the output includes m verbatim. Similarly, SHA1 is
still a valid commitment operation.

Behind the scenes the OTS infrastructure builds merkle trees of commitment
operations for scalability reasons. But none of those details are relevant to
the validity of OTS proofs - the OTS infrastructure could magically mine a
block per transaction with the digest in the coinbase, and from the client's
point of view, everything would work the same.


The important thing to recognize is that timestamp proof is simply a one-sided
bound on when a given message existed, proving a message existed _prior_ to
some point in time. For example:

    $ ots verify hello-world.txt.ots
    Assuming target filename is 'hello-world.txt'
    Success! Bitcoin block 358391 attests existence as of 2015-05-28 EDT

Obviously, the message "Hello World!" existed prior to 2015 (Indeed, it's such
a short message it's brute-forcable. But for sake of example, we'll ignore
that).

Thus your claim re: linearization that:

> Having a chain of transactions would serve to linearize history of
> OTS commitments which would let you prove, given reorgs, that knowledge of
> commit A was before B a bit more robustly.

...misunderstands the problem. We care about proving statements about messages.
Not timestamp proofs. Building infrastructure to order timestamp proofs
themselves is pointless.


What you're alluding to is dual-sided bounds on when messages were created.
That's solved by random beacons: messages known to have been created *after* a
point in time, and unpredictable prior. A famous example of course being the
genesis block quote:

    The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Bitcoin block hashes make for a perfectly good random beacon for use-cases with
day to hour level precision. For higher precision, absolute time, there are
many trusted alternatives like the NIST random beacon, Roughtime, etc.


OpenTimestamps could offer a trustless _relative_ random beacon service by
making the per-second commitments a merkle mountain range, and publishing the
tip digests. In fact, that's how I came up with merkle mountain ranges in the
first place, and there's code from 2012 to do exactly that in depths of the git
repo. But that's such a niche use-case I decided against that approach for now;
I'll probably resurrect it in the future for trusted timestamps/clock sync.

Again, involving the transactions themselves in any of this random beacon stuff
is pointless.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

hey various,

it's been obvious since its inception that opentimestamps is designed
to be broken.

if you have energy to normalise a better system, or support one of the
other better systems that already exists, that's wonderful.

i suspect the opentimestamps ecosystem is very experienced at defending itself.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

I was privately asked for more opinions. I am sharing them publicly below:

It's always been clear that OTS proves longness of duration but not
shortness. It doesn't demonstrate that an earlier work was not
published, because it hashes each document hash with private material
the author must separately publicize. Any unpublished private material
could be an earlier equivalent to a public proof.

the reason i call this 'designed to be broken' is that it lets people
rewrite history to their stories by republishing other people's
documents under different contexts.

I would not be surprised if OTS also fails to add tx history
containing its hashes to associated wallets, letting them be lost in
chain forks.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[rot13maxi]

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

Good morning Undiscussed Horrific Abuse, One Victim of Many,

> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.

The basic service that a timestamp service provides is “this content (or at least a digest of this content) existed at least as early as this timestamp.” It says nothing about how long before the timestamp the content existed, and says nothing about how long after the timestamp the content continues to exist. It also says nothing about uniqueness or validity of the content. For example, a document that existed for a year before its timestamp and was deleted immediately afterwards, and a document that was created the instant before its timestamp and was retained “forever” afterwards would have timestamp that are equally valid (provided you retained the digest of the document to validate the timestamp in the former case). Assurances around uniqueness (for example, preventing double spends) are a proof-of-publication or set-consistency problem, and assurances around validity are a validation problem. These other semantics can be built into systems that also rely on timestamps, but you can have a useful time stamping system without them. This is what OTS provides. When you say it’s “designed to be broken” do you mean that it claims to provide assurances that it doesn’t, or that the set of assurances that it provides are not a useful set.

> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.

I’ve always used OTS through the cli, which just spits out and works with .ots files, which are sterilized commitment operations. Storage of the ots files for later checking has always been a “problem left to the application” for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to see them!

Best,
rot13maxi

On Tue, Jun 14, 2022 at 7:53 AM, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I was privately asked for more opinions. I am sharing them publicly below:
>
> It's always been clear that OTS proves longness of duration but not
> shortness. It doesn't demonstrate that an earlier work was not
> published, because it hashes each document hash with private material
> the author must separately publicize. Any unpublished private material
> could be an earlier equivalent to a public proof.
>
> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.
>
> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

hi r1m, i'll talk with you as long as it's fun to do so.

>> the reason i call this 'designed to be broken' is that it lets people
>> rewrite history to their stories by republishing other people's
>> documents under different contexts.
>
> The basic service that a timestamp service provides is “this content (or at
> least a digest of this content) existed at least as early as this
> timestamp.” It says nothing about how long before the timestamp the content

OTS needlessly adds the requirement that the user publicize their .ots
files to everybody who will make use of the timestamp.

This does not provide the service you describe. It would be trivial to
include enough cryptographic information in the original OP_RETURN, so
as to obviate the need for publicizing the .ots file.

If I send my .ots file to another party, a 4th party can replace it
with their own, because there is no cryptographic pinning ensuring its
contents. This changes the timestamp to one later, no longer proving
the earliness of the data.

>> I would not be surprised if OTS also fails to add tx history
>> containing its hashes to associated wallets, letting them be lost in
>> chain forks.

> for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to

I mean the cryptographic wallets that hold the funds spent in etching
the hash to the chain.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Bryan Bishop]

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

On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of
Many via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.


Publication is not a component of the OTS system.

This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
>

(Why would it be needless to require everyone to publish OTS files but not
needless to require everyone to publish via OP_RETURN? In fact, now you
have blockchain users that don't ever use your OP_RETURN data.)


> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
>

You can't replace a timestamp in the OTS system; you can only make a new
timestamp. To use the earlier timestamp, you would have to use the earlier
timestamp. At any time it is allowed to make a new timestamp based on the
current clock. The use case for OTS is proving document existence as of a
certain time and that if you had doctored a file then said doctoring was no
later than the earliest timestamp that can be provided.

I was just talking about this the other day actually...
https://news.ycombinator.com/item?id=31640752

- Bryan
https://twitter.com/kanzure

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

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[digital vagabond]

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

If someone wants more linearity and uniqueness guarantees from a timestamp,
that isnt what OTS was designed for. Here is a protocol that was:
https://www.commerceblock.com/mainstay/

On Tue, Jun 14, 2022, 3:56 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of
> Many via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> OTS needlessly adds the requirement that the user publicize their .ots
>> files to everybody who will make use of the timestamp.
>
>
> Publication is not a component of the OTS system.
>
> This does not provide the service you describe. It would be trivial to
>> include enough cryptographic information in the original OP_RETURN, so
>> as to obviate the need for publicizing the .ots file.
>>
>
> (Why would it be needless to require everyone to publish OTS files but not
> needless to require everyone to publish via OP_RETURN? In fact, now you
> have blockchain users that don't ever use your OP_RETURN data.)
>
>
>> If I send my .ots file to another party, a 4th party can replace it
>> with their own, because there is no cryptographic pinning ensuring its
>> contents. This changes the timestamp to one later, no longer proving
>> the earliness of the data.
>>
>
> You can't replace a timestamp in the OTS system; you can only make a new
> timestamp. To use the earlier timestamp, you would have to use the earlier
> timestamp. At any time it is allowed to make a new timestamp based on the
> current clock. The use case for OTS is proving document existence as of a
> certain time and that if you had doctored a file then said doctoring was no
> later than the earliest timestamp that can be provided.
>
> I was just talking about this the other day actually...
> https://news.ycombinator.com/item?id=31640752
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Peter Todd]

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

On Tue, Jun 14, 2022 at 08:45:43AM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> > The basic service that a timestamp service provides is “this content (or at
> > least a digest of this content) existed at least as early as this
> > timestamp.” It says nothing about how long before the timestamp the content
> 
> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.
>
> This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.

That approach does not scale. Via merkle trees, the OpenTimestamps system
routinely timestamps tens of thousands of messages with a single transaction:

https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation

Client-side validated .ots files are a necessary requirement to achieve this
scalability.

FWIW the most I've personally done is timestamped 750 million items from the
Internet Archive with a single transaction.

> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.

They can also simply delete their copy of the data, making it impossible to
prove anything about it.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

I'm replying to Peter, skipping the other emails.

I perceive all these emails as disruptive trolling, ignoring the
importance of real timestamping, while handwaving about things that
are roughly false and harmful.

Since the start of cryptocurrency, Bitcoin has been used to write
timestamps that stay intact despite malicious action to arbitrary
systems and records, showing the earliest on-chain publication of
data. It seems misleading that OTS does not do that, when it is such a
prominent system.

>> This does not provide the service you describe. It would be trivial to
>> include enough cryptographic information in the original OP_RETURN, so
>> as to obviate the need for publicizing the .ots file.
>
> That approach does not scale. Via merkle trees, the OpenTimestamps system
> routinely timestamps tens of thousands of messages with a single
> transaction:
>
> https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation

This makes total sense to reduce the expense and size of etching these
very short hashes.

But the OTS approach hashes in a _private nonce_ for every document,
preventing anybody from validating the earliness of an item in a
merkle tree without access to every proof.

Do you think OTS would be interested in publicizing nonces and
document hashes, if the user consents?

Non-developers need a tool where they can choose to pay funds to write
a strong timestamp that guarantees earliness of publication of a
document, and for free discern the earliness of timestamped data they
provide to the tool.

> Client-side validated .ots files are a necessary requirement to achieve
> this
> scalability.

Nothing in an engineering task is a strict requirement, aside from the
specification. The data could be publicised elsewhere, or funds
provided to store it on-chain.

> FWIW the most I've personally done is timestamped 750 million items from
> the
> Internet Archive with a single transaction.

That's impressive. It's always great when we write something that can
condense something huge into something tiny and keep working, and use
it reliably.

I would have put the files in a shared datalad repository, and put the
tip commit of the repository in an OP_RETURN along with a tag such as
'DL' or 'IA'.

Then a tool could look for all 'DL' or 'IA' transactions, and verify
that mine was the earliest. You would of course need access to the
etched repositories' git commits.

If the hash can't be verified by an anonymous observer, the archive is
only timestamped for people with the proof. How is the challenge of
protecting many proofs different from the challenge of protecting the
data they prove?

>> If I send my .ots file to another party, a 4th party can replace it
>> with their own, because there is no cryptographic pinning ensuring its
>> contents. This changes the timestamp to one later, no longer proving
>> the earliness of the data.
>
> They can also simply delete their copy of the data, making it impossible to
> prove anything about it.

If they can destroy your .ots proof, the information on the blockchain
no longer demonstrates anything.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Andrew Poelstra]

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

On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> I'm replying to Peter, skipping the other emails.
> 
> I perceive all these emails as disruptive trolling, ignoring the
> importance of real timestamping, while handwaving about things that
> are roughly false and harmful.
> 
> Since the start of cryptocurrency, Bitcoin has been used to write
> timestamps that stay intact despite malicious action to arbitrary
> systems and records, showing the earliest on-chain publication of
> data. It seems misleading that OTS does not do that, when it is such a
> prominent system.
>

Please be cautious with tone and when assuming bad faith. I don't believe
that Peter is trolling. Also, as politely as I can, when something like
OTS whose model is dead-simple, well-documented, and has been running for
years providing significant value to many people, comes under attack for
being underspecified or failing to do what it says ... this is a
surprising claim, to say the least.


After talking to a few people offline, all of whom are baffled at this
entire conversation, I think the issue might come down to the way that
people interpret "timestamping".

If you believe that "timestamping" means providing a verifiable ordering
to events, then of course OTS does not accomplish this, nor has it ever
claimed to. If you think that "timestamping" means proving that some
data existed at a particular time, then this is exactly what OTS does.

Personally -- and I suspect this is true of Peter as well -- I have always
read the word as having the latter meaning, and it never occurred to me
until now that others might have a different interpretation.


I apologize for contributing to a thread that is getting a bit out of hand,
but I hope this can help the different parties see where the confusion is.




-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

On 6/14/22, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:
> On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One
> Victim of Many via bitcoin-dev wrote:
>> I'm replying to Peter, skipping the other emails.
>>
>> I perceive all these emails as disruptive trolling, ignoring the
>> importance of real timestamping, while handwaving about things that
>> are roughly false and harmful.
>>
>> Since the start of cryptocurrency, Bitcoin has been used to write
>> timestamps that stay intact despite malicious action to arbitrary
>> systems and records, showing the earliest on-chain publication of
>> data. It seems misleading that OTS does not do that, when it is such a
>> prominent system.
>>
>
> Please be cautious with tone and when assuming bad faith. I don't believe
> that Peter is trolling. Also, as politely as I can, when something like
> OTS whose model is dead-simple, well-documented, and has been running for
> years providing significant value to many people, comes under attack for
> being underspecified or failing to do what it says ... this is a
> surprising claim, to say the least.

Thank you for your reply, Andrew. I don't think Peter is trolling, but
I do suspect some body like a spy agency of strengthening the
timestamping solutions that have nonces in their merkle trees,
avoiding usability for storing public records in a way that could be
verified by anonymous and censored third parties.

> After talking to a few people offline, all of whom are baffled at this
> entire conversation, I think the issue might come down to the way that
> people interpret "timestamping".
>
> If you believe that "timestamping" means providing a verifiable ordering
> to events, then of course OTS does not accomplish this, nor has it ever
> claimed to. If you think that "timestamping" means proving that some
> data existed at a particular time, then this is exactly what OTS does.
>
> Personally -- and I suspect this is true of Peter as well -- I have always
> read the word as having the latter meaning, and it never occurred to me
> until now that others might have a different interpretation.

I looked some into the history of timestamping and I see that what you
are saying is the academic norm.

I don't see OTS as proving the data existed at a particular time,
because the proof is held in a document the user must protect. I
understand somewhat now that it is designed for users who can actually
protect that data sufficiently.

I do reiterate that it is blindingly easy to pin a public hash to the
bitcoin blockchain that asserts the earliest publication of a document
or collection of documents, and that this is desperately needed, to
protect the accuracy of history when it is not safe.

I worry that this form of "rfc timestamping" misleads its users into
believing the timestamps of their documents are preserved. These kinds
of user interaction issues can be very dangerous.

I would recommend uploading .ots files to chains with cheap storage,
such as arweave or bitcoin sv. This way people can prove which one was
first, when there is more than one. For that to work, we need a norm
of how and where to do it, so that users look in the same place, and
it is the people who make the public services and standards, that set
that norm.

Thank you for your reply, and I apologise for my poor support.

It is obvious that Peter has put incredible hard and long work into
providing OTS to the community in a clean and robust fashion, and that
is always very wonderful, and I have very thoroughly failed to
acknowledge that.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Undiscussed Horrific Abuse, One Victim of Many]

> I do reiterate that it is blindingly easy to pin a public hash to the
> bitcoin blockchain that asserts the earliest publication of a document
> or collection of documents, and that this is desperately needed, to
> protect the accuracy of history when it is not safe.

The concern raised here relates to scaling, and here we disagree on
the proper direction of Bitcoin. To me it seems clear that Bitcoin was
designed to scale better than it has. It honestly looks like
developers are arbitrarily avoiding storing much data on chain, with
quickly shoehorned solutions like the lightning protocol. Bitcoin
simply got big too fast. I believe it was intended to handle large
data smoothly: not with single gigabyte blocks that every user must
store, but with simplistically designed and well-backed decentralised
propagation and storage of data. I see that not having happened due to
mostly political issues, and that's unfortunate, but other chains have
made strides here.

I don't think satoshi was familiar with how people behave when they
have a lot of money.

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Peter Todd]

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

On Tue, Jun 14, 2022 at 09:16:55PM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> I worry that this form of "rfc timestamping" misleads its users into
> believing the timestamps of their documents are preserved. These kinds
> of user interaction issues can be very dangerous.
> 
> I would recommend uploading .ots files to chains with cheap storage,
> such as arweave or bitcoin sv.

According to Coingeek, Bitcoin SV's transaction fees are currently
0.1sats/byte. With BSV's price at $60, that works out to $644/GB.

Meanwhile, Amazon Glacier Deep Archive costs $0.012/GB/year.

Assuming a 25 year data lifetime, Bitcoin SV is still 2000x more expensive than
Amazon. And with the number of BSV nodes quickly dwindling, I'd be inclined to
trust Amazon more for long term storage.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Peter Todd]

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

On Tue, Jun 14, 2022 at 07:53:29AM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> I was privately asked for more opinions. I am sharing them publicly below:
> 
> It's always been clear that OTS proves longness of duration but not
> shortness. It doesn't demonstrate that an earlier work was not
> published, because it hashes each document hash with private material
> the author must separately publicize. Any unpublished private material
> could be an earlier equivalent to a public proof.
> 
> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.

See "What Can and Can't Timestamps Prove?":

https://petertodd.org/2016/opentimestamps-announcement#what-can-and-cant-timestamps-prove

OpenTimestamps makes a trade-off: timestamps have significant limitations as to
what they're able to prove. But in exchange, they have exceptionally good
scalability, making them essentially free to use. Timestamps are also much
easier to add on to existing processes and systems such as Git repositories.
Schemes that prove uniqueness require much more engineering and redesign work
to actually accomplish anything.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]