From: Sebastian Geisler <sebastian@gnet•me>
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 19:14:26 +0000 [thread overview]
Message-ID: <d7f827f2-b56d-f439-6c27-f22b46306e36@gnet.me> (raw)
In-Reply-To: <OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com>
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
prev parent reply other threads:[~2020-12-01 19:14 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
2020-12-01 19:14 ` Sebastian Geisler [this message]
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=d7f827f2-b56d-f439-6c27-f22b46306e36@gnet.me \
--to=sebastian@gnet$(echo .)me \
--cc=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