path: root/8a/92b52af600e0009f3efab308ad5ebe9be63453

Return-Path: <dave@dtrt.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9B9F8C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 May 2023 20:36:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 7697681F85
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 May 2023 20:36:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7697681F85
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level: 
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MILLION_USD=0.001,
 MONEY_NOHTML=2.499, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_MONEY_PERCENT=0.01] autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id v_dOD_acUtgd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 May 2023 20:36:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3019581F29
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3019581F29
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 May 2023 20:36:50 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
 by smtpauth.rollernet.us (Postfix) with ESMTP id AE7A52800862;
 Sat, 27 May 2023 13:36:47 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
 [IPv6:2607:fe70:0:14::a])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by smtpauth.rollernet.us (Postfix) with ESMTPSA;
 Sat, 27 May 2023 13:36:47 -0700 (PDT)
MIME-Version: 1.0
Date: Sat, 27 May 2023 10:36:47 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Burak Keceli <burak@buraks.blog>
In-Reply-To: <558171558.1686821.1685102160441@eu1.myprofessionalmail.com>
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
 <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org>
 <558171558.1686821.1685102160441@eu1.myprofessionalmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <c78b9e621e994f3cf3500e4480b61b0e@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
 http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 55ec.647269df.a342d.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
 Layer Solution
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 27 May 2023 20:36:51 -0000

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.