diff options
| author | Burak Keceli <burak@buraks.blog> | 2023-05-26 14:56:00 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-26 11:56:05 +0000 |
| commit | b355434a77c4d5741fca9ae2d42ade0d1ae58f77 (patch) | |
| tree | 5ef4cf52002dd8a7bb69a06ae055737cf5be45c8 | |
| parent | b11c3a1774b2ea212a9846076d9c5892c12fbd7b (diff) | |
| download | pi-bitcoindev-b355434a77c4d5741fca9ae2d42ade0d1ae58f77.tar.gz pi-bitcoindev-b355434a77c4d5741fca9ae2d42ade0d1ae58f77.zip | |
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
| -rw-r--r-- | c9/1de18599798517ae4b867cf0767a48fc6e1a1c | 230 |
1 files changed, 230 insertions, 0 deletions
diff --git a/c9/1de18599798517ae4b867cf0767a48fc6e1a1c b/c9/1de18599798517ae4b867cf0767a48fc6e1a1c new file mode 100644 index 000000000..1202aac24 --- /dev/null +++ b/c9/1de18599798517ae4b867cf0767a48fc6e1a1c @@ -0,0 +1,230 @@ +Return-Path: <burak@buraks.blog> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id B607FC002A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 26 May 2023 11:56:05 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 99AB683F02 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 26 May 2023 11:56:05 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 99AB683F02 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: 1.004 +X-Spam-Level: * +X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 + tests=[ADVANCE_FEE_3_NEW=0.001, BAYES_20=-0.001, BITCOIN_XPRIO=1.004, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + 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 TDNu7o0xaFq2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 26 May 2023 11:56:04 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DEABE83927 +Received: from p3plwbeout17-04.prod.phx3.secureserver.net + (p3plsmtp17-04-2.prod.phx3.secureserver.net [173.201.193.168]) + by smtp1.osuosl.org (Postfix) with ESMTPS id DEABE83927 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 26 May 2023 11:56:03 +0000 (UTC) +X-MW-NODE: +X-CMAE-Analysis: v=2.4 cv=QPKt+iHL c=1 sm=1 tr=0 ts=64709e52 + a=dFffxkGDbYo3ckkjzRcKYg==:117 a=dFffxkGDbYo3ckkjzRcKYg==:17 + a=6GeFC0id-SIA:10 a=IkcTkHD0fZMA:10 a=VvWRDUFFAAAA:8 a=wf4EKVFVs9k_ZhyHmPkA:9 + a=QEXdDO2ut3YA:10 a=5nbp0vzXTMvN-i4CCed7:22 a=SwlHTeVR8cTTWBXPrjoE:22 +X-SECURESERVER-ACCT: burak@buraks.blog +X-SID: 2W36qfWcpXY7S +Date: Fri, 26 May 2023 14:56:00 +0300 (TRT) +From: Burak Keceli <burak@buraks.blog> +To: "David A. Harding" <dave@dtrt.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <558171558.1686821.1685102160441@eu1.myprofessionalmail.com> +In-Reply-To: <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org> +References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com> + <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Priority: 3 +Importance: Normal +X-Mailer: Open-Xchange Mailer v8.12.73 +X-Originating-IP: 178.240.249.63 +X-Originating-Client: open-xchange-appsuite +X-CMAE-Envelope: MS4xfJcb1Ffd97iNgkLo/SRPAXBNMaSgjiKDFTzXYhtNG7+0LJJIEAdzxCQd568vBqs7R7K3RMQTlTnmMNnylYacaio2edoTRzJuswQDeuqWV72MVSaDZl12 + KJVbra89BE3bMkXo//28OtKu/s1CFsFdVKQWD4SxNDrVn2vq5pQkupOI+222BIXqtFk9SkrEqr3iSSI8efmcPadXgv+yqSiSbBx40L7SkATZTIpw5ScfvdtC + v1SLzKAS4bKateOc7XoQ/HsID4D+1SDKuxN33BigQnY= +X-Mailman-Approved-At: Fri, 26 May 2023 15:27:10 +0000 +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: Fri, 26 May 2023 11:56:05 -0000 + +Hi David,=20 + +Ark can be used for three purposes: + +1. Mixing coins. +Ark is a scalable, footprint-minimal off-chain mixer. People can use Ark to= + mix their coins with others. This doesn=E2=80=99t require waiting for on-c= +hain confirmations since you=E2=80=99re mixing your own coins with others. + +2. Paying lightning invoices +Ark is interoperable with Lightning, and you can use your Ark funds to pay = +Lightning invoices in a conjoin. This also doesn=E2=80=99t require waiting = +for on-chain confirmations since you consider your payment =E2=80=9Cdone=E2= +=80=9D when you obtain the vendor's preimage. + +3. Making internal transfers +You can use your Ark funds to make internal money transfers without introdu= +cing inbound liquidity assumptions. The recipient-end has to wait for sever= +al on-chain confirmations to consider their payment =E2=80=9Cfinal=E2=80=9D= +, however, their payment has immediate availability to them. Recipients can= + spend their zero-conf funds to pay Lightning invoices in coordination with= + their service provider. If we want to enable Lightning-style instant settl= +ement assurances for the internal transfers, we need OP_XOR or OP_CAT on th= +e base layer [1]. + + +I think you get the gist of it, but I lost you after =E2=80=9DBob wants to = +deposit 1 BTC with Alice.=E2=80=9D sorry. + +The initial onboarding phase is non-interactive, and there is no PSBT invol= +ved. Onboarding (or lifting) is as simple as funding a Bitcoin address.=20 + +Here I have refactored it for you: +Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to send = +1 BTC to an on-chain Bitcoin address whose script is: +pk(B) && (older(4 weeks) || pk(A)) + + From here, there are several things that Bob can do: +- *Unilaterally withdraw:* +If Alice happens to be non-collaborative or non-responsive, Bob can simply = +take his 1 BTC back after four weeks.=20 + +- *Collaboratively withdraw:* +Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC an= +ytime. + +- *Collaboratively trade commitments:* +Alice crafts a transaction containing three outputs; (a) a commitment outpu= +t, (b) a connector output, and (c) a change output. We call this transactio= +n =E2=80=9Cpool=E2=80=9D. +(a) commitment output +Commitment output (either using CTV or n-of-n multisig) constrains its desc= +endant transaction to a set of transaction outputs. To simplify things, let= +=E2=80=99s say there are no other participants in this transaction besides = +Bob, and the descendant transaction has only one output. We call this outpu= +t Bob=E2=80=99s vTXO. Bob=E2=80=99s vTXO also constrains (using CTV or 2-of= +-2 multisig) its descendant transaction to a single transaction output call= +ed Bob=E2=80=99s ATLC. Bob=E2=80=99s ATLC contains the following script: +pk(B) && (older(4 weeks) || pk(A)) +As you realize =E2=80=9CATLC=E2=80=9D script is identical to the =E2=80=9CF= +unding address=E2=80=9D script.=20 + +(b) connectors output +Connectors output is simply a single-sig output spendable by Alice herself: +pk(A) + +Alice locally crafts a descending transaction from this output, spending = +=E2=80=9Cconnectors output=E2=80=9D to fund a new output. We call this outp= +ut a =E2=80=9Dconnector,=E2=80=9D which always carries a dust value and is= + spendable by Alice herself: +pk(A) + +In short, Alice crafts a Bitcoin transaction that spends an input that she = +controls and funds an output that she controls. Alice does not broadcast th= +is transaction and keeps it secret. + +(c) change output +money not used for the other two outputs gets sent back to Alice. + +1. Alice places one (or more) input(s) to her =E2=80=9Cpool=E2=80=9D transa= +ction to supply funds to commitment output, connectors output, change outpu= +t, and transaction fees. + +2. Bob creates an unsigned PSBT, placing the input that Charlie was previou= +sly funded. + +3. Bob passes his PSBT to Alice.=20 + +4. Alice places one input to PSBT, the =E2=80=9Dconnector output,=E2=80=9D = + which is a descendant of the (b) connectors output she is crafting. + +5. Alice places one output to PSBT, a single-sig output that sweeps all mon= +ey to herself (pk(A)). + +6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this tra= +nsaction private. This transaction is not valid yet, since the connector=E2= +=80=99s outpoint context does not exist. + +7. Alice signs her one-in, three-out and broadcasts it.=20 + +8. Alice can now claim 1 BTC Charlie has previously funded by revealing the= + descendant transaction of (b) connectors output. She should claim this bef= +ore four weeks. +=20 +9. Bob now has a 1 BTC worth UTXO representation as a descendant of the (a)= + commitment output (a virtual UTXO). He can unilaterally claim this 1 BTC b= +y revealing the child (Bob=E2=80=99s vTXO) and grandchild (Bob=E2=80=99s AT= +LC) of the (a) commitments output, then waiting a 24-hour window period. + +So far, Charlie polluted on-chain by funding an address, and Alice by claim= +ing funds from that address. Further steps from here will be footprint mini= +mal.=20 + +1. Say, Bob wants to send 1 BTC to Dave.=20 + +2. Alice crafts a transaction containing three outputs; (a) a commitment ou= +tput, (b) a connector output, and (c) a change output. This time descendant= + of (a) commitment output is Daves=E2=80=99s vTXO instead of Bob=E2=80=99s.= + Similarly descendant of Daves=E2=80=99s vTXO is Dave=E2=80=99s ATLC. Dave= +=E2=80=99s ATLC is: +pk(D) && (older(4 weeks) || pk(A)) + +3. Alice places one connector output as a descendant of (b) connectors outp= +ut, just like before.=20 + +4. Alice places one input to her one-in, three-out transaction to supply fu= +nds to commitment output, connectors output, change output, and transaction= + fees. + +5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from = +the (a) commitment output descendants that Alice previously=20 + +6. Bob passes his PSBT to Alice.=20 + +7. Alice places one input to PSBT, the =E2=80=9Dconnector output,=E2=80=9D = + which is a descendant of the (b) connectors output she is crafting.=20 + +8. Alice places one output to PSBT, a single-sig output that sweeps all mon= +ey to herself (pk(A)). + +9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this tra= +nsaction private.=20 + +10. Alice signs her one-in, three-out transaction and broadcasts it.=20 + +11. Bob lets Dave know about this transaction (Alice=E2=80=99s transaction = +id, Dave=E2=80=99s vTXO output index) out-of-band.=20 + +12. When Dave comes back online, he sees from the out-of-band message that = +Bob sent him 1-BTC. He then verifies whether Alice=E2=80=99s transaction id= + exists, whether his vTXO output index is correct, and a set of other valid= +ations. + +13. If Dave had been online all this time, he would have had to wait for en= +ough confirmations to consider his payment =E2=80=9Cfinal.=E2=80=9D + +[1] https://eprint.iacr.org/2017/394.pdf + |