summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid A. Harding <dave@dtrt.org>2023-05-24 13:02:40 -1000
committerbitcoindev <bitcoindev@gnusha.org>2023-05-24 23:02:45 +0000
commit8250ef97043edf450337199c799bb01e698a761d (patch)
tree2bda4349c2442762e50e1a16de4c17d60866e73a
parent4ade271d99ebcda50d076f6b67fc9198d6d44afa (diff)
downloadpi-bitcoindev-8250ef97043edf450337199c799bb01e698a761d.tar.gz
pi-bitcoindev-8250ef97043edf450337199c799bb01e698a761d.zip
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
-rw-r--r--ab/534b6ab58b02856cf88450d22afa8679a078db237
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
+