What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-07 18:27:39
in reply to nevent1q…t77w

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-01 📝 Original message:Good morning e, and ...

📅 Original date posted:2020-12-01
📝 Original message: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
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l