For what I could understand, reading a bit about the use of Bulletproof in Monero, it is used to prove that the amounts in the transaction are between 0 and 2^N-1, where N is the number of bits, currently 64, but could be any other number.
I was thinking of a method to be able to publicly prove the order of magnitude of each transaction without revealing the actual value of the transaction. This could have several uses, of which two could be quite useful: 1. have more "democratic" fees that are proportional to the value of transactions, so the rich pay more :), 2. prove publicly the (approximate) volume of transactions and thus the actual use of Monero. It could be discussed if having fees proportional to the value of transactions is a good or a bad thing, but it is not the point here. I am merely interested in the simplest method to achieve such result.
It is different from "Reserve proof" https://github.com/monero-project/monero/pull/3027 because 1. Reserve proof is not public, it is something that is produced on request, 2. I'd like to show publicly the order of magnitude of each transaction. It is similar to Proving amount of Monero - Range Proofs but here the question is much more complex.
The simplest method I could imagine is to add a public number N (0 < N <= 64) to the transaction stating what is its order of magnitude. Bulletproof would prove that the transaction is between 0 and 2^N-1. Since the fees would be proportional to 2^N (fixed fee for each "step/order of magnitude"), it is in the interest of the user to set N to its possible lowest.
For what I read about RingCT, Bulletproof, etc. it would be feasible, but I'd like A. a confirmation that it would really work (the math behind Bulleproof are a bit too complex for me).
My interest is anyway about the possible (practical) problems that could arise and the possible solutions.
B. If a user owns a UTXO of 1000 XMR and needs to send only 0.1 XMR, he would nevertheless pay the fee for 1000 XMR.
This could be resolved by automatically create several outputs when sending money, with different orders of magnitude, as it happens with banknotes. When the receiver needs to spend the money he would choose the input(s) with the same order of magnitude. Surely, from time to time, he will need to "change" a larger UTXO and pay higher fees. The fee table could take into account this "double taxation" and be proportionally lower for high amounts.
C. A user could use several inputs and outputs of smaller order of magnitude in order to pay less fees, given that the fees are decided based on the order of magnitude of the whole transaction.
Given the existing limit in the number of inputs and outputs in a transaction, this problem is already limited, although not solved (and I see no solution).
D. There would be few transactions of big amounts and this could make these transactions traceable.
Probably the transaction amounts follow a Zipf distribution, so there are fewer transactions with big amounts. It would make these transactions traceable if their order of magnitude is public. This is the biggest problem I see. I image some possible solutions, but they don't seem satisfactory. So this is the real question (although I'd like to read opinions also on the rest). Or maybe this is not a problem at all, in which case I'm interested to know why.
D1. One solution would be to create fake transactions composed only of decoy inputs and outputs, of each order of magnitude, but then also their fees should be fake, and since fees are public, that would automatically mark those transactions as fake. I don't see how to make fees private (so the fake transactions would contain zero fees), or how to make fake fees unspendable without revealing which transactions are fake.
D2. Some "authority" could collect all the fees and "recycle" them to create transactions with high order of magnitude. The paid fees would then return to the miners to be distributed. In the scenario I have in mind this could work (in the real Monero it wouldn't because there could not exist such central authority), but I see a privacy problem. The authority would know which are the fake and the real transactions, and therefore it would be able to trace the real transactions of high order of magnitude.
D3. The miner could create fake transactions (like in D1) spending the fees that will return to him. The problem here is that usually the fees go to the pool, so the miner would need to know the pool's spending key, or there must be some mechanism to refund the miner of the fees paid upfront. The other problem is that few miners would be able to pay upfront large fees for fake transactions of big amounts. A third problem would be how to make such fake transaction creation mandatory, without being able to verify how many fake transactions are in a block.
Maybe the solution is in some of the ideas presented, plus some cryptographic magic that I cannot figure out...
And please indulge me and do not just reply "what you propose would be useless/bad". I'm not interested in that discussion (although it would be interesting, but that's for another question) but in the technical and practical ways to implement it.
