diff options
| author | David A. Harding <dave@dtrt.org> | 2023-05-27 10:36:47 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-27 20:36:51 +0000 |
| commit | 9ebc15a14ffb85829575973d1cb1437533cf739b (patch) | |
| tree | 228c9221484e0e6138577d69b9594446651bdc12 | |
| parent | b355434a77c4d5741fca9ae2d42ade0d1ae58f77 (diff) | |
| download | pi-bitcoindev-9ebc15a14ffb85829575973d1cb1437533cf739b.tar.gz pi-bitcoindev-9ebc15a14ffb85829575973d1cb1437533cf739b.zip | |
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
| -rw-r--r-- | 8a/92b52af600e0009f3efab308ad5ebe9be63453 | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/8a/92b52af600e0009f3efab308ad5ebe9be63453 b/8a/92b52af600e0009f3efab308ad5ebe9be63453 new file mode 100644 index 000000000..4bec0757b --- /dev/null +++ b/8a/92b52af600e0009f3efab308ad5ebe9be63453 @@ -0,0 +1,215 @@ +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. + |