diff options
author | David A. Harding <dave@dtrt.org> | 2023-05-24 13:02:40 -1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-24 23:02:45 +0000 |
commit | 8250ef97043edf450337199c799bb01e698a761d (patch) | |
tree | 2bda4349c2442762e50e1a16de4c17d60866e73a | |
parent | 4ade271d99ebcda50d076f6b67fc9198d6d44afa (diff) | |
download | pi-bitcoindev-8250ef97043edf450337199c799bb01e698a761d.tar.gz pi-bitcoindev-8250ef97043edf450337199c799bb01e698a761d.zip |
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
-rw-r--r-- | ab/534b6ab58b02856cf88450d22afa8679a078db | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/ab/534b6ab58b02856cf88450d22afa8679a078db b/ab/534b6ab58b02856cf88450d22afa8679a078db new file mode 100644 index 000000000..39a8724ff --- /dev/null +++ b/ab/534b6ab58b02856cf88450d22afa8679a078db @@ -0,0 +1,237 @@ +Return-Path: <dave@dtrt.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id BF77DC002A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 May 2023 23:02:45 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 9615941C5D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 May 2023 23:02:45 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9615941C5D +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.902 +X-Spam-Level: +X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id rueAOSBtwQt9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 May 2023 23:02:43 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 841C840424 +Received: from smtpauth.rollernet.us (smtpauth.rollernet.us + [IPv6:2607:fe70:0:3::d]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 841C840424 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 May 2023 23:02:43 +0000 (UTC) +Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) + by smtpauth.rollernet.us (Postfix) with ESMTP id D7B982801802; + Wed, 24 May 2023 16:02:40 -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; + Wed, 24 May 2023 16:02:40 -0700 (PDT) +MIME-Version: 1.0 +Date: Wed, 24 May 2023 13:02:40 -1000 +From: "David A. Harding" <dave@dtrt.org> +To: Burak Keceli <burak@buraks.blog>, Bitcoin Protocol Discussion + <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com> +References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com> +User-Agent: Roundcube Webmail/1.4.10 +Message-ID: <3c6c3b8b562bb56bbb855dc2b2b71f78@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 7a92.646e9790.ac3b0.0 +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: Wed, 24 May 2023 23:02:45 -0000 + +Hi Burak, + +Thanks for this really interesting protocol! I tend to analyze +complicated ideas like this by writing about them in my own words, so +I've pasted my summary of your idea to the end of this email in case +it's useful, either to other people or to you in helping understand my +one concern. + +My concern is the same one I think Olaoluwa Osuntokun mentioned on +Twitter[1] and (less clear to me) might be related to ZmnSCPxj's +concern[2]: + +It seems to me that receiving a payment on the protocol, including +conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting +for the transaction containing that payment to confirm to a sufficient +depth (e.g., I'd wait 6 blocks for small payments and longer for huge +payments). Am I missing something? + +My summary of how I think that part of the protocol works is in the +sections labeled "Make an unconditioned payment" and "Make a conditional +payment" below. In short, it's clear to me how the service provider and +the customer can make instant atomic swaps with each other---they can +either spend instantly cooperatively, or they have to wait for a +timeout. But how can a receiver of funds be assured that they will +actually get those funds unless there's already a timelock and +cooperative spend path placed on those funds? + +-Dave + +Rough initial summary of Ark protocol: + +Alice runs an Ark service provider. Every 5 seconds, she broadcasts a +new unconfirmed onchain transaction that pays three outputs (the +three Cs): + +1. *Change Output:* money not used for the other two Cs that gets sent + back to the the transaction creator. + +2. *Connector Output:* an output that will be used in a future + transaction created by Alice as protection against double spends. + +3. *Commitment Output:* a CTV-style commitment to a set of outputs that + can be published later in a descendant transaction (alternatively, + the commitment output may be spent unilaterally by Alice after 4 + weeks). + +Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT +with an input of his and a change output. She updates the PSBT with a +commitment output that refunds Bob the 1 BTC and a connector output with +some minimum value. They both sign the PBST and it is broadcast. We'll +ignore fees in our examples, both onchain transaction fees and fees paid +to Alice. + + From here, there are several things that Bob can do: + +- *Unilaterally withdraw:* Bob can spend from the commitment output to + put his refund onchain. The refund can only be spent after a 24-hour + time delay, allowing Bob to optionally come to an agreement with Alice + about how to spend the funds before Bob can spend them unilaterally + (as we'll see in a moment). For example, the script might be[3]: + + pk(B) && (older(1 day) || pk(A)) + +- *Collaboratively withdraw:* as seen above, Bob has the ability to come + to a trustless agreement with Alice about how to spend his funds. + They can use that ability to allow Bob to trade his (unpublished) UTXO + for a UTXO that Alice funds and broadcasts. For example: + + - Alice creates an unsigned PSBT that uses as one of its inputs the + connector from Bob's deposit transaction. This will ensure that + any attempt by Bob to double-spend his deposit transaction will + invalidate this withdrawal transaction, preventing Bob from being + able to steal any of Alice's funds. + + Also included in Alice's unsigned PSBT is another connector + output plus the output that pays Bob his 1 BTC. + + - Bob receives Alice's unsigned PSBT and creates a separate PSBT + that includes his unpublished UTXO as an input, giving its value + to Alice in an output. The PSBT also includes as an input the + connector output from Alice's PSBT. This will ensure that any + attempt by Alice to double spend her transaction paying him will + invalidate his transaction paying her. + + - Bob signs his PSBT and gives it to Alice. After verifying it, + Alice signs her PSBT and broadcasts it. + +- *Collaboratively trade commitments:* as mentioned, the commitment + output that pays Bob may be claimed instead by Alice after 4 weeks, so + Bob will need to either withdraw or obtain a new commitment within +that + time. To trade his existing commitment for a new commitment looks + similar to the collaborative withdrawal procedure but without the + creation of an immediately-spendable onchain output: + + - Alice creates an unsigned PSBT that uses as one of its inputs the + connector from Bob's deposit transaction, again preventing double + spending by Bob. Alice also includes a new connector and a new + commitment that again allows Bob to later claim 1 BTC. + + - Bob receives Alice's PSBT and creates a PSBT transferring his + existing commitment to her, with the new connector again being + included as an input to ensure atomicity. + + - Bob signs; Alice signs and broadcasts. + +- *Make an unconditioned payment:* using the mechanisms described above, + it's possible to make either an onchain payment or an offchain + payment---just have Carol receive the new output or commitment rather + than Bob. That payment would have no conditions (except its + atomicity). + +- *Make a conditional payment:* imagine that Carol knows a secret (e.g. + a preimage) that Bob is willing to pay for. + + - Alice creates an unsigned PSBT depending on the connector from + Bob's deposit transaction and creating a new connector. The PSBT + includes an output paying Carol (either onchain or via a + commitment) with an HTLC, allowing Carol to claim the funds if +she + reveals the secret or allowing Bob to claim the funds after a + timeout. + + - Bob receives Alice's PSBT and creates a PSBT transferring his + existing commitment to her with the HTLC condition attached and, + again, with connectors being used to ensure atomicity. + + - Bob signs; Alice signs and broadcasts. + + - Carol can settle her HTLC by either revealing the secret onchain + or by trading her commitment containing the HTLC clause for a + commitment from Alice that doesn't contain the clause (which + Alice will only accept by learning the secret, since Alice has + to settle with Bob). Alice can then either settle onchain or + trade commitments with Bob after giving him the secret. + +- *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice + can claim the funds from the commitment output (i.e., takes his + money). + + If Bob did actually do something, and if every other user who also + had an unpublished output in the commitment transaction did + something, then they all exchanged their portion of the funds in + this output to Alice, so Alice can now claim all of those funds + onchain in a highly efficient manner. + +Regarding the connector outputs, although all of the examples above show +Alice directly spending from the connector output in Bob's deposit +transaction, atomicity is also ensured if Alice spends from any output +descended from Bob's connector output. Connector outputs from different +deposits can be used as inputs into the same transaction, merging their +histories. This allows all operations made by Alice to be fully atomic, +ensuring that she doesn't lose any money during a reorg of any length. + +Users are not so well protected during reorgs, e.g. if Bob double-spends +a transaction whose funds were later used in a payment to Carol, then +Carol loses the money. For this reason, Alice will probably want to +prove to users that no funds they receive in a payment derive from any +deposit less than safe_confirmation_depth blocks. + +[1] https://twitter.com/roasbeef/status/1661266771784126464 + +[2] +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.html + +[3] +https://min.sc/#c=pk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29 + |