From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Out-of-band transaction fees
Date: Tue, 01 Dec 2020 16:24:11 +0000 [thread overview]
Message-ID: <OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com> (raw)
In-Reply-To: <a_ytmG7wahHYE15SU_JER_s2dLFVpI8fRLBZTuV32QuXVOoOq2r7Dyof1tugJUFoE1bDAbYMffJ21HGNPVhh2dLGIWPkIPfEryT2Jk_sg3Y=@protonmail.com>
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
next prev parent reply other threads:[~2020-12-01 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 23:03 Sebastian Geisler
2020-12-01 1:06 ` eric
2020-12-01 14:19 ` Sebastian Geisler
2020-12-01 15:49 ` ZmnSCPxj
2020-12-01 16:24 ` ZmnSCPxj [this message]
2020-12-01 19:14 ` Sebastian Geisler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox