[bitcoin-dev] Out-of-band transaction fees

[bitcoin-dev] Out-of-band transaction fees

[Sebastian Geisler]

Hi all,

the possibility of out of band transaction fee payments is a well known
fact. Yet it has been mostly discussed as an annoying inevitability that
can be problematic if on-chain fees are to be used as a consensus
parameter. The potential use cases have seen little interest though
(please correct me if I'm wrong).

One such use case is sending UTXOs "intact". Let's assume we get to a
point where Bitcoin is primarily a settlement layer for L2 systems.
These L2 systems might want to protect their privacy and keep UTXOs of a
common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement
applications these can be transferred as a whole, but currently fee
requirements force the system to add another input for fees which will
introduce taint (because it's used repeatedly). If instead a fee could
be paid out of band in a privacy preserving way the TXO chain would leak
little about the intermediate holders.

Taking this concept even further CoinJoin-like protocols could also be
used to introduce further ambiguity without leaking that a certain
entity took part in the CJ (which fee inputs/reused "toxic waste"
inevitably do afaik). Such a mechanism would probably also make CJ
transactions much smaller as _no_ fee inputs had to be provided
(assuming the inputs already have the right size).

Out-of-band transaction "accelerators" already exist and taking fee
payment out-of-band can not be effectively prevented. So even though any
such proposal will probably have slight centralizing effects I believe
that having a standard for it is preferable to having every pool
implement their own API making it harder for small pools to get into the
market.

Imo the central questions are:
 * how to build such a out-of-band "transaction bounty" system
 * how to standardized it
 * how can the centralizing effects from it be mitigated

Imo fees are small enough to not really care about counter party risk
that much. It's more important that it is easy to run so that there is
some choice for users and miners. In that sense I consider
single-operator services providing both standardized user and miner APIs
as well as an optional UI suitable. I would still take into account that
this could change and might consider the needs of federated services in
the protocol.

Each such service would need to announce which means of payment it
supports and allow users and miners to choose when paying/redeeming
fees. Users should be able to submit transactions and either be
presented with a single payment method dependent "invoice" or one per
input (for the CoinJoin use case). As soon as all invoices are paid the
bounty goes live and is visible to miners through an API.

Miners that included a transaction need a way to authenticate when
claiming the bounty. One possibility would be to optionally include a
unique public key e.g. in the coinbase scriptsig after the height push
(is this feasible?). This could be used to claim any bounties after 100,
120, or even a user-defined confirmation threshold is met. If the key is
unique for every block there won't be a problem with pool accountability
which might become a risk down the road (so this should also be enforced
at least in the bounty protocol to avoid lazy implementations leading to
dangerous precedents).

Any feedback is welcome :)

tl;dr Out-of-band fee payment services are inevitable and useful, so we
should at least standardize them and mitigate negative effects as much
as possible.

Best,
Sebastian

Re: [bitcoin-dev] Out-of-band transaction fees

[eric]

Hi Sebastian,

It's important to consider here that anonymity is the reason fees are incorporated into transactions. One must generally trust the party with whom one transacts. But since integral fees are paid to any miner, this does not apply to fees. In paying fees externally one must find another way to associate a fee with its transaction. This of course increases the possibility of taint, as you describe in part here:

> Miners that included a transaction need a way to authenticate when claiming the bounty.

It is also the case that the "bounty" must be associated with the transaction. Even with miner and payer mutual anonymity, the fee inputs and outputs will be associated with the transaction inputs and outputs by the miner, rendering the proposal counterproductive.

Total transaction sizing is not reduced by paying fees externally, in fact it would be increased. The only possible reduction would come from aggregation of fees. Yet it is not clear how that aggregation would occur privately in less overall block space. At least with integral fees, it's *possible* to spend and pay a fee with a single input and output. That is not the case with externalized fees.

e

-----Original Message-----
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On Behalf Of Sebastian Geisler via bitcoin-dev
Sent: Monday, November 30, 2020 3:03 PM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Out-of-band transaction fees

Hi all,

the possibility of out of band transaction fee payments is a well known fact. Yet it has been mostly discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter. The potential use cases have seen little interest though (please correct me if I'm wrong).

One such use case is sending UTXOs "intact". Let's assume we get to a point where Bitcoin is primarily a settlement layer for L2 systems.
These L2 systems might want to protect their privacy and keep UTXOs of a common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement applications these can be transferred as a whole, but currently fee requirements force the system to add another input for fees which will introduce taint (because it's used repeatedly). If instead a fee could be paid out of band in a privacy preserving way the TXO chain would leak little about the intermediate holders.

Taking this concept even further CoinJoin-like protocols could also be used to introduce further ambiguity without leaking that a certain entity took part in the CJ (which fee inputs/reused "toxic waste"
inevitably do afaik). Such a mechanism would probably also make CJ transactions much smaller as _no_ fee inputs had to be provided (assuming the inputs already have the right size).

Out-of-band transaction "accelerators" already exist and taking fee payment out-of-band can not be effectively prevented. So even though any such proposal will probably have slight centralizing effects I believe that having a standard for it is preferable to having every pool implement their own API making it harder for small pools to get into the market.

Imo the central questions are:
 * how to build such a out-of-band "transaction bounty" system
 * how to standardized it
 * how can the centralizing effects from it be mitigated

Imo fees are small enough to not really care about counter party risk that much. It's more important that it is easy to run so that there is some choice for users and miners. In that sense I consider single-operator services providing both standardized user and miner APIs as well as an optional UI suitable. I would still take into account that this could change and might consider the needs of federated services in the protocol.

Each such service would need to announce which means of payment it supports and allow users and miners to choose when paying/redeeming fees. Users should be able to submit transactions and either be presented with a single payment method dependent "invoice" or one per input (for the CoinJoin use case). As soon as all invoices are paid the bounty goes live and is visible to miners through an API.

Miners that included a transaction need a way to authenticate when claiming the bounty. One possibility would be to optionally include a unique public key e.g. in the coinbase scriptsig after the height push (is this feasible?). This could be used to claim any bounties after 100, 120, or even a user-defined confirmation threshold is met. If the key is unique for every block there won't be a problem with pool accountability which might become a risk down the road (so this should also be enforced at least in the bounty protocol to avoid lazy implementations leading to dangerous precedents).

Any feedback is welcome :)

tl;dr Out-of-band fee payment services are inevitable and useful, so we should at least standardize them and mitigate negative effects as much as possible.

Best,
Sebastian

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Out-of-band transaction fees

[Sebastian Geisler]

Hi Eric,

> In paying fees externally one must find another way to associate a fee with its transaction. This of course increases the possibility of taint, as you describe in part here:

I'm not sure I follow, do you see a problem beyond the facts that miners
would need to authenticate somehow? This can be done in a privacy
preserving way per block. I don't think transactions would need to
change in any way. The bounty-transaction link is upheld by a third
party service which the miners have to trust that it will pay out if the
transaction is included (not perfect, but a business decision they can
make).

> It is also the case that the "bounty" must be associated with the transaction. Even with miner and payer mutual anonymity, the fee inputs and outputs will be associated with the transaction inputs and outputs by the miner, rendering the proposal counterproductive.
> Total transaction sizing is not reduced by paying fees externally, in fact it would be increased. The only possible reduction would come from aggregation of fees. Yet it is not clear how that aggregation would occur privately in less overall block space. At least with integral fees, it's *possible* to spend and pay a fee with a single input and output. That is not the case with externalized fees.

I should have made this more clear, I don't imagine anyone to pay these
fees with L1 transactions, but rather some L2 system like Lightning or a
BTC backed chaumian token issued for that purpose by the bounty service
provider. Even Lightning would be far more private for the use cases I
described that don't allow fee deduction from inputs. But if one accepts
more counter party risk with e.g. some centrally pegged chaumian token
it can be anonymous.

I see that this might not be very useful today, but I imagine a future
in which Bitcoin is mostly a settlement and reserve layer. This would
make it feasible to keep most UTXOs in common sizes. Only large, round
transactions happen on-chain, the rest can happen on L2. This would
allow tumbling these already evenly-sized UTXOs on spend without toxic
waste if we can somehow tackle the fee payment problem. I know of the
following solutions:

 * everyone has to add a second UTXO per input
 * Someone is chosen fairly at random to pay the total fee
 * pay a service on L2 to add an input/output for fee payment
 * out-of-band L2 fee payments

Only L2 fee payments can hide who is involved in such a tumbling
operation as additional fee inputs that get reused would indicate the
same entity was present in two tumbling operations. The out-of-band
approach saves one input and one output and appears more general (e.g.
could be used like rbf).

This is also not a general solution for fee payments. In many cases it
will still be preferable to pay on-chain fees. But having the option to
avoid that in a standardized way could help some protocols imo.

Best,
Sebastian


> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On Behalf Of Sebastian Geisler via bitcoin-dev
> Sent: Monday, November 30, 2020 3:03 PM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Out-of-band transaction fees
> 
> Hi all,
> 
> the possibility of out of band transaction fee payments is a well known fact. Yet it has been mostly discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter. The potential use cases have seen little interest though (please correct me if I'm wrong).
> 
> One such use case is sending UTXOs "intact". Let's assume we get to a point where Bitcoin is primarily a settlement layer for L2 systems.
> These L2 systems might want to protect their privacy and keep UTXOs of a common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement applications these can be transferred as a whole, but currently fee requirements force the system to add another input for fees which will introduce taint (because it's used repeatedly). If instead a fee could be paid out of band in a privacy preserving way the TXO chain would leak little about the intermediate holders.
> 
> Taking this concept even further CoinJoin-like protocols could also be used to introduce further ambiguity without leaking that a certain entity took part in the CJ (which fee inputs/reused "toxic waste"
> inevitably do afaik). Such a mechanism would probably also make CJ transactions much smaller as _no_ fee inputs had to be provided (assuming the inputs already have the right size).
> 
> Out-of-band transaction "accelerators" already exist and taking fee payment out-of-band can not be effectively prevented. So even though any such proposal will probably have slight centralizing effects I believe that having a standard for it is preferable to having every pool implement their own API making it harder for small pools to get into the market.
> 
> Imo the central questions are:
>  * how to build such a out-of-band "transaction bounty" system
>  * how to standardized it
>  * how can the centralizing effects from it be mitigated
> 
> Imo fees are small enough to not really care about counter party risk that much. It's more important that it is easy to run so that there is some choice for users and miners. In that sense I consider single-operator services providing both standardized user and miner APIs as well as an optional UI suitable. I would still take into account that this could change and might consider the needs of federated services in the protocol.
> 
> Each such service would need to announce which means of payment it supports and allow users and miners to choose when paying/redeeming fees. Users should be able to submit transactions and either be presented with a single payment method dependent "invoice" or one per input (for the CoinJoin use case). As soon as all invoices are paid the bounty goes live and is visible to miners through an API.
> 
> Miners that included a transaction need a way to authenticate when claiming the bounty. One possibility would be to optionally include a unique public key e.g. in the coinbase scriptsig after the height push (is this feasible?). This could be used to claim any bounties after 100, 120, or even a user-defined confirmation threshold is met. If the key is unique for every block there won't be a problem with pool accountability which might become a risk down the road (so this should also be enforced at least in the bounty protocol to avoid lazy implementations leading to dangerous precedents).
> 
> Any feedback is welcome :)
> 
> tl;dr Out-of-band fee payment services are inevitable and useful, so we should at least standardize them and mitigate negative effects as much as possible.
> 
> Best,
> Sebastian
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Out-of-band transaction fees

[ZmnSCPxj]

Good morning Sebastian and e,

> Hi Eric,
>
> > In paying fees externally one must find another way to associate a fee with its transaction. This of course increases the possibility of taint, as you describe in part here:
>
> I'm not sure I follow, do you see a problem beyond the facts that miners
> would need to authenticate somehow? This can be done in a privacy
> preserving way per block. I don't think transactions would need to
> change in any way. The bounty-transaction link is upheld by a third
> party service which the miners have to trust that it will pay out if the
> transaction is included (not perfect, but a business decision they can
> make).

There has to be an association of "how much do I get if I include *this* particular transaction" to "*this* particular transaction", so that the miners have an informed decision of how much they stand to earn.
Unless fees are also standardized, this can be used to leak the same information ("sombody offered this specific amount of money to the bounty server, and the bounty server associated this particular amount to this particular transaction").


More concerningly, [a trusted third party is hard to get out of](https://nakamotoinstitute.org/trusted-third-parties/).
If there are only a few of them, it becomes easy to co-opt, and then a part of the mining infrastructure is now controllable from central points of failure.
If there are many of them, then evaluating which ones cheat and which ones do not will take a lot of effort, and the system as a whole may not provide benefits commensurate to the overall system cost in finding good third parties.


> > It is also the case that the "bounty" must be associated with the transaction. Even with miner and payer mutual anonymity, the fee inputs and outputs will be associated with the transaction inputs and outputs by the miner, rendering the proposal counterproductive.
> > Total transaction sizing is not reduced by paying fees externally, in fact it would be increased. The only possible reduction would come from aggregation of fees. Yet it is not clear how that aggregation would occur privately in less overall block space. At least with integral fees, it's possible to spend and pay a fee with a single input and output. That is not the case with externalized fees.
>
> I should have made this more clear, I don't imagine anyone to pay these
> fees with L1 transactions, but rather some L2 system like Lightning or a
> BTC backed chaumian token issued for that purpose by the bounty service
> provider. Even Lightning would be far more private for the use cases I
> described that don't allow fee deduction from inputs. But if one accepts
> more counter party risk with e.g. some centrally pegged chaumian token
> it can be anonymous.

Since such L2 mechanisms themselves are dependent on L1 and require a facility to bump up fees for e.g. commitment transactions in Lightning Network, this brings up the possibility of getting into a bootstrapping problem, where the security of L2 is dependent on the existence of a reliable fee-bumping mechanism at L1, but the fee-bumping mechanism at L1 is dependent on the security of L2.
Not impossible, but such strange loops give me pause; I am uncertain if we have the tools to properly analyze such.

>
> I see that this might not be very useful today, but I imagine a future
> in which Bitcoin is mostly a settlement and reserve layer. This would
> make it feasible to keep most UTXOs in common sizes. Only large, round
> transactions happen on-chain, the rest can happen on L2. This would
> allow tumbling these already evenly-sized UTXOs on spend without toxic
> waste if we can somehow tackle the fee payment problem. I know of the
> following solutions:
>
> -   everyone has to add a second UTXO per input
> -   Someone is chosen fairly at random to pay the total fee
> -   pay a service on L2 to add an input/output for fee payment
> -   out-of-band L2 fee payments
>
>     Only L2 fee payments can hide who is involved in such a tumbling
>     operation as additional fee inputs that get reused would indicate the
>     same entity was present in two tumbling operations. The out-of-band
>     approach saves one input and one output and appears more general (e.g.
>     could be used like rbf).
>
>     This is also not a general solution for fee payments. In many cases it
>     will still be preferable to pay on-chain fees. But having the option to
>     avoid that in a standardized way could help some protocols imo.
>
>     Best,
>     Sebastian
>
>
> > -----Original Message-----
> > From: bitcoin-dev bitcoin-dev-bounces@lists.linuxfoundation.org On Behalf Of Sebastian Geisler via bitcoin-dev
> > Sent: Monday, November 30, 2020 3:03 PM
> > To: bitcoin-dev@lists.linuxfoundation.org
> > Subject: [bitcoin-dev] Out-of-band transaction fees
> > Hi all,
> > the possibility of out of band transaction fee payments is a well known fact. Yet it has been mostly discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter. The potential use cases have seen little interest though (please correct me if I'm wrong).
> > One such use case is sending UTXOs "intact". Let's assume we get to a point where Bitcoin is primarily a settlement layer for L2 systems.
> > These L2 systems might want to protect their privacy and keep UTXOs of a common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement applications these can be transferred as a whole, but currently fee requirements force the system to add another input for fees which will introduce taint (because it's used repeatedly). If instead a fee could be paid out of band in a privacy preserving way the TXO chain would leak little about the intermediate holders.
> > Taking this concept even further CoinJoin-like protocols could also be used to introduce further ambiguity without leaking that a certain entity took part in the CJ (which fee inputs/reused "toxic waste"
> > inevitably do afaik). Such a mechanism would probably also make CJ transactions much smaller as no fee inputs had to be provided (assuming the inputs already have the right size).
> > Out-of-band transaction "accelerators" already exist and taking fee payment out-of-band can not be effectively prevented. So even though any such proposal will probably have slight centralizing effects I believe that having a standard for it is preferable to having every pool implement their own API making it harder for small pools to get into the market.
> > Imo the central questions are:
> >
> > -   how to build such a out-of-band "transaction bounty" system
> > -   how to standardized it
> > -   how can the centralizing effects from it be mitigated
> >
> > Imo fees are small enough to not really care about counter party risk that much. It's more important that it is easy to run so that there is some choice for users and miners. In that sense I consider single-operator services providing both standardized user and miner APIs as well as an optional UI suitable. I would still take into account that this could change and might consider the needs of federated services in the protocol.
> > Each such service would need to announce which means of payment it supports and allow users and miners to choose when paying/redeeming fees. Users should be able to submit transactions and either be presented with a single payment method dependent "invoice" or one per input (for the CoinJoin use case). As soon as all invoices are paid the bounty goes live and is visible to miners through an API.
> > Miners that included a transaction need a way to authenticate when claiming the bounty. One possibility would be to optionally include a unique public key e.g. in the coinbase scriptsig after the height push (is this feasible?). This could be used to claim any bounties after 100, 120, or even a user-defined confirmation threshold is met. If the key is unique for every block there won't be a problem with pool accountability which might become a risk down the road (so this should also be enforced at least in the bounty protocol to avoid lazy implementations leading to dangerous precedents).
> > Any feedback is welcome :)
> > tl;dr Out-of-band fee payment services are inevitable and useful, so we should at least standardize them and mitigate negative effects as much as possible.
> > Best,
> > Sebastian
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Out-of-band transaction fees

[ZmnSCPxj]

Good morning e, and Sebastian,

So it seems, the goals are the below:

* Someone wants to pay a fee to get a transaction confirmed.
* Miners want to know how much they earn if they confirm a transaction.
* The one paying for the fee does not want to link its other coins to the transaction it wants confirmed.

Would that be a fair restatement of the goal?

If so, it seems to me we can make a CoinJoin-like approach using only L1, and combine fees by a kind of FeeJoin.

The issue with linking is that if for example the one paying a fee to get a transaction confirmed wants to CPFP the transaction, it may need to take another UTXO it controls into the child transaction, thereby linking its "another UTXO" with the "transaction it wants confirmed".

However, if multiple such individuals were to CoinJoin their transactions, the linking becomes much harder to trace.

So a possible mechanism, with a third-party that is trusted only to keep the service running (and cannot cheat the system and abscond with the fees and leave miners without money) would be:

* The third-party service divides its service into fixed-feerate bins.
* Clients select a preferred feerate bin they want to use.
* For each client:
  * Connects to the service by Tor to register a transaction it wants to have CPFPed.
  * Connects to the service by a different Tor circuit to register a UTXO it will use to spend fees.
* The server passes through the CPFPed outputs in the whole value.
* The server deducts the fee from the fee-paying UTXO and creates an output with all the fees (CPFP output spend, UTXO input spend, CPFP output re-creation, UTXO output re-creation) deducted from the UTXO.
* The server gives the resulting transaction to the clients.
* The clients sign the transaction after checking that its interested CPFPed outputs and fee-paying UTXOs are present.

This results in a transaction with many CPFPed inputs and fee-paying UTXOs, and no easy way to link the latter with the former.

* Miners and chain analysis cannot link them, as they see only the resulting tx.
* The service cannot link them, as clients talk to them on two separate Tor connections.

The above is blatantly the Wasabi way of CoinJoining; using the JoinMarket way of CoinJoining should be possible as well, and is left as an exercise to the reader.

Now, you have mentioned a number of times that you believe Bitcoin will eventually be a settlement layer, and somehow link this with standardized UTXO sizes.
But I think the end goal should be:

* To improve Bitcoin blockchain layer privacy.

It should not matter how we achieve this, whether it involves standardized UTXO sizes or not; if you want to use this solution, you need to present a good reason why this is the best solution for Bitcoin privacy, and better than other solutions.

For example, the JoinMarket way of CoinJoining does not require any particular standardized UTXO size.
The upcoming SwapMarket that Chris Belcher is working on, also does not require such a standardized UTXO size, as it is based as well on the JoinMarket technique, where the client can select whatever sizes it wants.
Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes for privacy, if apparently JoinMarket and SwapMarket can improve privacy without this?

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Out-of-band transaction fees

[Sebastian Geisler]

Hi ZmnSCPxj,

thank you for your detailed comments. I agree that the centralization
risk is a big problem. I didn't fully take into account how hard it
might be to distinguish honest service providers, which makes that
problem so much worse. I think I'll not pursue this approach for that
reason. While such a system can't be prevented I don't need to encourage it.

I might look into the "pay someone to add their UTXO to a tx for fees
and give them back the remainder" approach though, it doesn't seem as
hazardous and might even be possible to do in a decentralized fashion.

> Now, you have mentioned a number of times that you believe Bitcoin will eventually be a settlement layer, and somehow link this with standardized UTXO sizes.
> But I think the end goal should be:
> 
> * To improve Bitcoin blockchain layer privacy.
> 
> It should not matter how we achieve this, whether it involves standardized UTXO sizes or not; if you want to use this solution, you need to present a good reason why this is the best solution for Bitcoin privacy, and better than other solutions.

I completely agree.

> For example, the JoinMarket way of CoinJoining does not require any particular standardized UTXO size.
> The upcoming SwapMarket that Chris Belcher is working on, also does not require such a standardized UTXO size, as it is based as well on the JoinMarket technique, where the client can select whatever sizes it wants.
> Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes for privacy, if apparently JoinMarket and SwapMarket can improve privacy without this?

These efforts are great! Yet all CoinJoin based protocols I have seen
(mostly academic ones tbh, that provide strong guarantees) have some
amount of overhead in the form of creating more UTXOs and bigger
transactions than minimally possible or even "toxic waste" we don't know
what to do with. As far as I understand it there's now way around that
without relaxing anonymity guarantees. Maybe I'm not up to date in that
regard.

I also think that the privacy properties/the actual anonymity set of
unequal output size CoinJoins (i.e. knapsack mixing) is not as well
understood as for evenly-sized output CoinJoins. If we are only talking
about user-defined CoinJoin output sizes it comes down to efficiency
again. This will nearly always lead to change and not many parties will
be interested in the particular output size so you even need to pay them
to participate.

Please bear with me as the following part is _very_ speculative:

I believe that if Bitcoin becomes mainstream (I take no stance whether
this is good or not, but consider it a possibility) transaction prices
are bound to increase dramatically, which would make such protocols
uneconomical. This also means most people will rely on some L2
technology. But the fees might even make Lightning nodes uneconomical
for the majority of people. So if we are lucky federated L2 systems, or
if we are unlucky centralized ones, will play an important role imo.

In such an environment, where on-chain transactions are mostly used as
settlements between somewhat big players, having (multiple tiers of)
evenly sized UTXOs makes a lot of sense. You don't need exact valued
transfers and get free/cheaper than free and effective mixing on spends
if you just combine your transactions.

So imo the pros of this technique are:
 * as simple as possible (easy to assess exact anonymity set)
 * cheap, so it could be made a default, leading to a large anon set

while the cons are:
 * only makes sense when exact values aren't important (e.g. L2 funding)
 * needs fee hacks

I don't want to derail this any further. I agree that my initial idea
bears too great risks of regulatory capture. While I find the
evenly-sized UTXO idea intriguing I'd be even happier about a
arbitrary-amount scheme that gives the same strong assurances in an
_efficient_ manner, I just haven't seen a way to achieve this so far.

Best,
Sebastian