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
Importance: Normal
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
 Layer Solution
Precedence: list

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