Amount Organization

[nopara73]

Motivation

In this issue I would like to gain consensus slowly on the amount organization by establishing a stable base and expanding it with various ideas.

Objectives

• User can receive arbitrary amounts of coins.
• The received coins are disconnected from the sent coins.
• User can send arbitrary amounts of coins.

Question: What about the changes in sends?

Changes can be considered as received coins.

Step by Step Protocol

1. Maximum Privacy

From here on, up until noted otherwise

0. Network fees are non-existent.
1. Coordinator fees are non-existent.
2. isStandard checks are non-existents (dust limit, max tx size, max mempool chain, max input number, etc..)
3. Every participant is honest: no participants are DoS attacking.

Our objectives with maximum privacy could be achieved by

1. Break down the received coin into 1 satoshi amounts in a transaction.
2. Coinjoin those 1 satoshi amounts one by one.
3. Send arbitrary amounts.

Issue: Costs

An immediate issue we must resolve is that this scheme would operate with millions of inputs and outputs.

2. Introducing Standard Denominations

There are numerous ways standard denominations could be introduced to resolve our issue with the cost. It's most reasonable to introduce standard denominations those can be decomposed with each other, so for example using prime numbers would be a bad idea.

Design Decision to be made:

• preferred value series?
• powers of 2
• powers of 10

In this case, our scheme would look like this:

1. Break down the received coin into standard denominations in a transaction.
2. Coinjoin these standard denominations one by one in different pools those only handle these pool sizes.
3. Send arbitrary amounts.

[nopara73]

I think the next steps are so that the starting comment of this issue

0. @nothingmuch @nopara73 @seresistvanandras and @lontivero agrees that it's a stable basis for further improvements.
1. Design decision on the denominations are to be made.
2. This issue gets polished up.

[nopara73]

Regarding agreement, I don't know if it's the best way to progress, but I suppose any plan is better than no plan.

[nothingmuch]

I think "stable base" doesn't quite capture it, since this is a straw man. To me our conversation was more about about defining the boundaries of the design space, using extreme examples.

The other side is cost/weight optimal: assuming no fees, or more realistically fee market is efficient (unpredictable) the cost optimal strategy is to always spend all of the wallet's UTXOs whenever a payment needs to be made, so that after every payment the entire balance is consolidated to just a single UTXO (so the only way to grow the wallet's UTXO pool is to receive new coins which will be consolidated on the next payment).

Between these two extremes we can imagine strategies that optimize for a healthier balance instead of privacy at all costs or smallest blockspace requirement.

Weakening the simplifying assumptions about fees, standardness etc further constrains this space, but fortunately solutions present themselves to these real world issues when trying to provide a more balanced approach. Going through these in a systematic way is precisely the reason why I wanted to introduce these straw men examples.

For example for the standard denominations in use I think the choice is not just a binary choice between powers of two and powers of ten, and I have many opinions about how fees should be structured (both the mechanism design/incentive model, and the practical considerations). Anyway the point of this is that we can just use powers of two or powers of ten in the discussions interchangiably depending on which is clearer in the context of the discussion, since we're still in straw man territory it realy doesn't matter right now (in math speak, "assume x without loss of generality").

The next step I would like to take is to start building from the privacy optimal side with cost/weight optimizations that are equivalent in terms of privacy, and first remove our simplifying assumptions, and then revisit the questions of starndard denominations, incentives, prepaid fee tokens, etc.