From: "David A. Harding" <dave@dtrt•org>
To: Burak Keceli <burak@buraks•blog>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Date: Sat, 27 May 2023 10:36:47 -1000 [thread overview]
Message-ID: <c78b9e621e994f3cf3500e4480b61b0e@dtrt.org> (raw)
In-Reply-To: <558171558.1686821.1685102160441@eu1.myprofessionalmail.com>
Hi Burak,
Thanks for your response! I found it very helpful. I'm going to reply
to your email a bit out of order.
> 4. Alice places one input to her one-in, three-out transaction to
> supply funds to commitment output, connectors output, change
> output, and transaction fees.
You don't mention it in your reply, but was I correct in my earlier
email in assuming that Alice can claim any funds paid to a commitment
output after four weeks if its commitments haven't been published
onchain? E.g., that in the best case this allows a ~50 vbyte commitment
output that pays an arbitrary number of users to be spent as a ~100
vbyte input (P2TR scriptpath for pk(A) && older(4 weeks))?
> 1. Mixing coins.
> 2. Paying lightning invoices
> 3. Making internal transfers
If commitment outputs can't normally be spent by Alice for four weeks,
then Alice needs to keep enough capital on hand to pay out all amounts
involved in the activities listed above. I've seen many people make
this point, but I wanted to run some rough numbers to estimate the
extent of that capital load.
Let's say Alice has a million customers who each receive all of their
income and pay all of their expenses with her. In my country, the
median income is a bit less than $36,000 USD, or about $3,000 a month.
I imagine spending is not evenly distributed over time, so let's say
Alice needs to hold 3x the average to be prepared for a busy period.
That implies Alice's capital requirements are about $9 billion USD (3 *
3000 * 1e6).
At a hypothetical risk-free interest rate of 1.5% annual, that's about
$135 that will need to be recovered from each user per year (9e9 * 0.015
/ 1e6).
Additionally, if we assume the cost of an onchain transaction is $100
and the service creates one transaction per five seconds, that's $630 in
fee costs that will need to be recovered from each user per year ((60 /
5) * 60 * 24 * 365 * 100 / 1e6).
I'll come back to this financial analysis later.
> If we want to enable Lightning-style instant settlement assurances for
> the internal transfers, we need OP_XOR or OP_CAT on the base layer
> [...] https://eprint.iacr.org/2017/394.pdf
What do you mean by "instant"? Do you mean "settlement as soon as the
next onchain pool transaction is published"? For example, within 5
seconds if the coinjoining completes on time? That's significantly
slower than LN today, at least in the typical case for a well-connected
node.[1]
I think 5 seconds is fine for a lot of purposes (at both point-of-sale
terminals and on websites, I very often need to wait >5 seconds for a
credit card transaction to process), but I think it's worth noting the
speed difference in a technical discussion.
Additionally, I think the idea described significantly predates that
paper's publication, e.g.:
"Well while you can't prevent it you could render it insecure enabling
miners to take funds. That could work via a one-show signature
[...]"[2]
A problem with the idea of using one-show signatures as double-spend
protection is that miner-claimable fidelity bonds don't work as well
against adversaries that are not just counterparties but also miners
themselves. This same problem has been described for other ideas[3],
but to summarize:
Bob has something valuable. Alice offers him the output of an
unconfirmed transaction in exchange for that thing. She also provides a
bond that will pay its amount to any miner who can prove that Alice
double spent her input to the unconfirmed transaction.
If Alice is miner, she can privately create candidate blocks that double
spend the payment to Bob and which also claim the bond. If she fails to
find a PoW solution for those candidate blocks, she lets Bob have his
money. If she does find a PoW solution, she publishes the block, taking
Bob's money, securing her bond, and also receiving all the regular block
rewards (sans the fees from whatever space she used for her
transaction).
I haven't exactly[4] seen this mentioned before, but I think it's
possible to weaken Alice's position by putting a timelock on the
spending of the bond, preventing it from being spent in the same block
as the double-spend. For example, a one-block timelock (AKA: 1 CSV)
would mean that she would need to mine both the block containing her
unconfirmed transactions (to double spend them) and the next block (to
pay the fidelity bonds back to herself).
Ignoring fee-sniping (bond-sniping in this case), selfish mining, and
51% attacks, her chance of success at claiming the fidelity bond is
equal to her portion of the network hashrate, e.g. if she has 33%, she's
33% likely to succeed at double spending without paying a penalty. The
value of the fidelity bond can be scaled to compensate for that, e.g. if
you're worried about Alice controlling up to 50% of hashrate, you make
the fidelity bond at least 2x the base amount (1 / 50%). Let's again
assume that Alice has a million users making $3,000 USD of payments per
month (28 days), or about on average $75,000 per minute (1e6 * 3000 / 28
/ 24 / 60). If Alice bonds 2x the payment value and her bonds don't
expire for 6 blocks (which might take 3 hours), she needs an additional
$27 million worth of BTC on hand (75000 * 2 * (3 * 60)), which I admit
is trivial compared to the other capital requirements mentioned above.
* * *
Taken all together, it seems to me that Alice might need to keep several
billion dollars worth of BTC in a hot wallet in order to serve a million
users. The per-user cost in fees and capital service would be around
$1,000 per year. If we assume onchain transaction costs are about $100,
that would be equal to 10 channels that could be opened or closed by
each user for the same amount (i.e. an average of 5 channel rotations
per year).
Did I miss something in my analysis that would indicate the capital
costs would be significantly lower or that there wouldn't be other
tradeoffs (slower settlement than LN and a need to use a timelocked
fidelity bond)?
Thanks!,
-Dave
[1] https://twitter.com/Leishman/status/1661138737009442818
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018010.html
[4] Years ago, I think I saw a reply by Peter Todd to some idea about
paying money to miners in a fair way and he noted that it was
critical to pay miners far enough in the future that the current set
of miners wouldn't be incentivized to manipulate who got the money
by choosing which block to include the transaction in now. I wasn't
able to quickly find that post, but it definitely influenced my
thinking here.
next prev parent reply other threads:[~2023-05-27 20:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 7:54 Burak Keceli
2023-05-22 13:03 ` ZmnSCPxj
2023-05-23 4:31 ` Burak Keceli
2023-05-23 22:06 ` G. Andrew Stone
2023-05-24 0:40 ` ZmnSCPxj
2023-05-24 0:45 ` ZmnSCPxj
2023-05-24 7:53 ` Burak Keceli
2023-05-24 6:28 ` Burak Keceli
2023-05-24 20:20 ` adiabat
2023-05-24 23:02 ` David A. Harding
2023-05-26 11:56 ` Burak Keceli
2023-05-27 20:36 ` David A. Harding [this message]
2023-06-07 13:30 ` Burak Keceli
2023-08-06 22:43 ` Antoine Riard
2023-05-25 12:12 Ali Sherief
2023-05-26 7:33 jk_14
2023-05-28 6:02 Ali Sherief
2023-06-07 18:20 David A. Harding
2023-06-11 9:19 moonsettler
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=c78b9e621e994f3cf3500e4480b61b0e@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=burak@buraks$(echo .)blog \
/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