path: root/28/5f6ad75a97509a23ad33729e6c90644efd003e

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3912AC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Aug 2023 22:44:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0B0054099F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Aug 2023 22:44:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0B0054099F
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=jd93g8c7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[ADVANCE_FEE_3_NEW=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id B5pfEgf6OxDr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Aug 2023 22:44:08 +0000 (UTC)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
 [IPv6:2607:f8b0:4864:20::d32])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0AA144097F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Aug 2023 22:44:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0AA144097F
Received: by mail-io1-xd32.google.com with SMTP id
 ca18e2360f4ac-790ab117bd5so134178439f.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Aug 2023 15:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1691361847; x=1691966647;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=hAc4PkdoC7j1bkP+pyPqgKudnZSTnv0DN8MrSf04yRg=;
 b=jd93g8c7UW4oJLsOqFQCFuknjdE9VgD7V/LCfUvY4dhBjkIV4fJmPOZYA0tAy2jwQZ
 06nmh9UeUCeW/mbPB935yk7S5M16vTwhecZUh4CYMNlrPM65dovD0SD/h8Q3VQCTRI55
 Vs9NKFEIhKLJb3qOGgk0SnZLB/htpVllLCpT9L/jpIC0IuPJ64bsAxF3sCN4uWSLbXAa
 H1Lw5FXvqLQQaBno97oZHamAFc9ocNqQSWUMbB2g3/4XB3K/s+CY9QVIvUq0SGP1fsmc
 1DkjWg0YIQ1kHN8ECaTkMb1VLuZGRMGEXkK9YyDw3kNropIdt2YOBG23JXM/CrorTTmI
 6Hsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691361847; x=1691966647;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=hAc4PkdoC7j1bkP+pyPqgKudnZSTnv0DN8MrSf04yRg=;
 b=TjO8H0QwqYSMUYrsp+qgbaG0f9mWoWjEnALb4Bse7Yk20x6taMZ22qmC7hjtSJhIyM
 4uLgonENyDlWC+3A39jAvbl2XJn/+vKlARv81VvtsFny3VabPJsGO/GiBnIR4CBVHzuf
 IH+kWQmNXqEhfaIv0PNYBvIoJOPQ6I8BQnoZ51sKrxJSjwqmliwaLfCHs3Ju7mOM0Gm7
 3Jsji8NPJQgXJxcPQe8sRMgJvry2ZEDqCrL+OrPBeW/efuAN1OIfTaLaWokmAfcA5RHq
 Id4WUFa+tHWAL3B2XVWoplObUtMKloDMEQyfs6pOp2VM4Lodqz+9CAi3yI07m5TCCNZs
 oLkg==
X-Gm-Message-State: AOJu0YyhBNEIYCPIIhGAegJ7peP5q7KtUn+Pb2p09Mlpx52Xo5AI6k+z
 J6ImjFKCmnhlt7fIappcfA17iHzJW53ICH1DIFWeMN8h
X-Google-Smtp-Source: AGHT+IH416R3R5gIpzALQHLVXoFbdLty8dCqfUG4Ss2mzCIe8fWig43KaP27pqFWTy50M1bff59Gw2Timd+YBEydGGY=
X-Received: by 2002:a5e:8805:0:b0:787:1568:5df7 with SMTP id
 l5-20020a5e8805000000b0078715685df7mr8691256ioj.9.1691361846764; Sun, 06 Aug
 2023 15:44:06 -0700 (PDT)
MIME-Version: 1.0
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
 <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org>
 <558171558.1686821.1685102160441@eu1.myprofessionalmail.com>
In-Reply-To: <558171558.1686821.1685102160441@eu1.myprofessionalmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 6 Aug 2023 23:43:55 +0100
Message-ID: <CALZpt+E0pjHfDaby32Qyjgq_YzJc0h8MLrP243zbgYgm3pOB7w@mail.gmail.com>
To: Burak Keceli <burak@buraks.blog>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000102c86060248de41"
X-Mailman-Approved-At: Sun, 06 Aug 2023 22:46: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: Sun, 06 Aug 2023 22:44:11 -0000

--000000000000102c86060248de41
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Burak,

Thanks for the interesting Ark proposal.

From my understanding the protocol is played between 3 entities: the
sender, the receiver and the ASP and you have 3 types of transactions:
- the pool_tx
- the ATLC-connection_tx
- the ATLC-refund_tx

The pool_tx spends an on-chain funding input and 3 outputs:
- the commitment output, committing to a set of N vTXOs outputs (e.g a tree
of promised outputs)
- the connector output, spendable by the ASP signature
- the change output, from the value overflow of the on-chain funding input

A "receiver" vTXO scriptpubkey on pool_tx N includes the following
pseudo-script: multisig(receiver, ASP) or ((pk(receiver)+24h) or
(pk(ASP)+4weeks)). From the PoV of the next pool_tx state, the receiver
becomes the sender.

A ATLC-connection_tx is associated with a pool_tx N is spending one or more
vTXOs outputs from the "sender" (i.e receiver at pool_tx N-1) and one or
more connector outputs from pool_tx N. The initial
uplifting ATLC- connection_tx spends an on-chain input from the initial
sender.

I think there is a loss of funds weakness during the vTXLO transfer phase,
i.e by leveraging an ATLC-refund transaction using the unilateral exit path=
.

Let's say you have Alice (the sender), Bob (the receiver) and the ASP at
state N. Alice owns a vTXO on pool_tx N:
- after 24, her vTXO N can be spend unilaterally with only her own signatur=
e
- she engages with the ASP to construct a new pool_tx N+1 paying a vTXO to
Bob (this vTXO has same relative locktime 24h)
- she reveals her signature to the ASP for the ATLC-connection_tx N+1
spending her vTXO at state N and the connector output at state N+1
- the ASP broadcasts the pool_tx N+1 and the transaction is pending in
network mempools
- Alice broadcasts her ATLC refund tx using the mature unilateral exit path
- this ATLC refund tx replaces any ATLC-connection tx pending in network
mempools
- both the ATLC refund tx for vTXO at state N and the pool_tx at state N+1
confirms
- Bob the receiver can wait 24h and then he can spend the vTXO at state N+1
unilaterally

Alice and Bob successfully colluded to "double-spend" the ASP, without this
service provider earning compensation for the pool_tx state N+1 funding
input.

If I'm correct, I don't know if this weakness can be fixed by adding
another round of interactivity between the sender and the ASP, e.g
disclosing a revocation secret for the ATLC-refund transaction, without
opening the door for the ASP to steal user by stalling the next pool_tx N+1
broadcast and waiting 4 weeks time lock expiration.

All mistakes, confusion or misunderstanding are my own. More details about
transactions, scripts and protocol phases would be appreciated.

Cheers,
Antoine

Le ven. 26 mai 2023 =C3=A0 16:27, Burak Keceli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hi David,
>
> 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-chain
> 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 pa=
y
> Lightning invoices in a conjoin. This also doesn=E2=80=99t require waitin=
g 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
> introducing inbound liquidity assumptions. The recipient-end has to wait
> for several on-chain confirmations to consider their payment =E2=80=9Cfin=
al=E2=80=9D,
> however, their payment has immediate availability to them. Recipients can
> spend their zero-conf funds to pay Lightning invoices in coordination wit=
h
> their service provider. If we want to enable Lightning-style instant
> settlement assurances for the internal transfers, we need OP_XOR or OP_CA=
T
> on the base layer [1].
>
>
> I think you get the gist of it, but I lost you after =E2=80=9DBob wants t=
o deposit
> 1 BTC with Alice.=E2=80=9D sorry.
>
> The initial onboarding phase is non-interactive, and there is no PSBT
> involved. Onboarding (or lifting) is as simple as funding a Bitcoin
> address.
>
> Here I have refactored it for you:
> Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to sen=
d
> 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 simpl=
y
> take his 1 BTC back after four weeks.
>
> - *Collaboratively withdraw:*
> Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC
> anytime.
>
> - *Collaboratively trade commitments:*
> Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. We call this
> transaction =E2=80=9Cpool=E2=80=9D.
> (a) commitment output
> Commitment output (either using CTV or n-of-n multisig) constrains its
> descendant transaction to a set of transaction outputs. To simplify thing=
s,
> let=E2=80=99s say there are no other participants in this transaction bes=
ides Bob,
> and the descendant transaction has only one output. We call this output
> 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 called Bob=E2=80=99=
s 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=
=9CFunding address=E2=80=9D script.
>
> (b) connectors output
> Connectors output is simply a single-sig output spendable by Alice hersel=
f:
> 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 ou=
tput a
> =E2=80=9Dconnector,=E2=80=9D which always carries a dust value  and is sp=
endable by Alice
> herself:
> pk(A)
>
> In short, Alice crafts a Bitcoin transaction that spends an input that sh=
e
> controls and funds an output that she controls. Alice does not broadcast
> this 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 tran=
saction to supply
> funds to commitment output, connectors output, change output, and
> transaction fees.
>
> 2. Bob creates an unsigned PSBT, placing the input that Charlie was
> previously funded.
>
> 3. Bob passes his PSBT to Alice.
>
> 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
> money to herself (pk(A)).
>
> 6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction 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.
>
> 8. Alice can now claim 1 BTC Charlie has previously funded by revealing
> the descendant transaction of (b) connectors output. She should claim thi=
s
> before four weeks.
>
> 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 by revealing the child (Bob=E2=80=99s vTXO) and grandchild (Bob=E2=80=
=99s ATLC) 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
> claiming funds from that address. Further steps from here will be footpri=
nt
> minimal.
>
> 1. Say, Bob wants to send 1 BTC to Dave.
>
> 2. Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. This time
> descendant of (a) commitment output is Daves=E2=80=99s vTXO instead of Bo=
b=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
> output, just like before.
>
> 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.
>
> 5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO fro=
m
> the (a) commitment output descendants that Alice previously
>
> 6. Bob passes his PSBT to Alice.
>
> 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.
>
> 8. Alice places one output to PSBT, a single-sig output that sweeps all
> money to herself (pk(A)).
>
> 9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction private.
>
> 10. Alice signs her one-in, three-out transaction and broadcasts it.
>
> 11. Bob lets Dave know about this transaction (Alice=E2=80=99s transactio=
n id,
> Dave=E2=80=99s vTXO output index) out-of-band.
>
> 12. When Dave comes back online, he sees from the out-of-band message tha=
t
> 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 validations.
>
> 13. If Dave had been online all this time, he would have had to wait for
> enough confirmations to consider his payment =E2=80=9Cfinal.=E2=80=9D
>
> [1] https://eprint.iacr.org/2017/394.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000102c86060248de41
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Burak,<div><br></div><div>Thanks for the interesting Ar=
k proposal.</div><div><br></div><div>From my understanding the protocol is =
played between 3 entities: the sender, the receiver and the ASP and you hav=
e 3 types of transactions:</div><div>- the pool_tx</div><div>- the=C2=A0ATL=
C-connection_tx</div><div>- the ATLC-refund_tx</div><div><br></div><div>The=
 pool_tx spends an on-chain funding input and 3 outputs:</div><div>- the co=
mmitment output, committing to a set of N vTXOs outputs (e.g a tree of prom=
ised outputs)</div><div>- the connector output, spendable by the ASP signat=
ure</div><div>- the change output, from the value overflow of the on-chain =
funding input</div><div><br></div><div>A &quot;receiver&quot; vTXO scriptpu=
bkey on pool_tx N includes the following pseudo-script: multisig(receiver, =
ASP) or ((pk(receiver)+24h) or (pk(ASP)+4weeks)). From the PoV of the next =
pool_tx state, the receiver becomes the sender.</div><div><br></div><div>A =
ATLC-connection_tx is associated with a pool_tx N is spending one or more v=
TXOs outputs from the &quot;sender&quot; (i.e receiver at pool_tx N-1) and =
one or more connector outputs from pool_tx N. The initial uplifting=C2=A0AT=
LC-=C2=A0connection_tx spends an on-chain input from the initial sender.</d=
iv><div><br></div><div>I think there is a loss of funds weakness during the=
 vTXLO transfer phase, i.e by leveraging an ATLC-refund transaction using t=
he unilateral exit path.</div><div><br></div><div>Let&#39;s say you have Al=
ice (the sender), Bob (the receiver) and the ASP at state N. Alice owns a v=
TXO on pool_tx N:</div><div>- after 24, her vTXO N can be spend unilaterall=
y with only her own signature</div><div>- she engages with the ASP to const=
ruct a new pool_tx N+1 paying a vTXO to Bob (this vTXO has same relative lo=
cktime 24h)</div><div>- she reveals her signature to the ASP for the ATLC-c=
onnection_tx N+1 spending her vTXO at state N and the connector output at s=
tate N+1</div><div>- the ASP broadcasts the pool_tx N+1 and the transaction=
 is pending in network mempools</div><div>- Alice broadcasts her ATLC refun=
d tx using the mature unilateral exit path</div><div>- this ATLC refund tx =
replaces any ATLC-connection tx pending in network mempools</div><div>- bot=
h the ATLC refund tx for vTXO at state N and the pool_tx at state N+1 confi=
rms</div><div>- Bob the receiver can wait 24h and then he can spend the vTX=
O at state N+1 unilaterally</div><div><br></div><div>Alice and Bob successf=
ully colluded to &quot;double-spend&quot; the ASP, without this service pro=
vider earning compensation for the pool_tx state N+1 funding input.</div><d=
iv><br></div><div>If I&#39;m correct, I don&#39;t know if this weakness can=
 be fixed by adding another round of interactivity between the sender and t=
he ASP, e.g disclosing a revocation secret for the ATLC-refund transaction,=
 without opening the door for the ASP to steal user by stalling the next po=
ol_tx N+1 broadcast and waiting 4 weeks time lock expiration.</div><div><br=
></div><div>All mistakes, confusion or misunderstanding are my own. More de=
tails about transactions, scripts and protocol phases would be appreciated.=
</div><div><br></div><div>Cheers,</div><div>Antoine</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 26 ma=
i 2023 =C3=A0=C2=A016:27, Burak Keceli via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi David, <br>
<br>
Ark can be used for three purposes:<br>
<br>
1. Mixing coins.<br>
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.<=
br>
<br>
2. Paying lightning invoices<br>
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&#39;s preimage.<br>
<br>
3. Making internal transfers<br>
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].<br>
<br>
<br>
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.<br>
<br>
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. <br=
>
<br>
Here I have refactored it for you:<br>
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:<br>
pk(B) &amp;&amp; (older(4 weeks) || pk(A))<br>
<br>
=C2=A0From here, there are several things that Bob can do:<br>
- *Unilaterally withdraw:*<br>
If Alice happens to be non-collaborative or non-responsive, Bob can simply =
take his 1 BTC back after four weeks. <br>
<br>
- *Collaboratively withdraw:*<br>
Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC an=
ytime.<br>
<br>
- *Collaboratively trade commitments:*<br>
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.<br>
(a) commitment output<br>
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:<br=
>
pk(B) &amp;&amp; (older(4 weeks) || pk(A))<br>
As you realize =E2=80=9CATLC=E2=80=9D script is identical to the =E2=80=9CF=
unding address=E2=80=9D script. <br>
<br>
(b) connectors output<br>
Connectors output is simply a single-sig output spendable by Alice herself:=
<br>
pk(A)<br>
<br>
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=C2=A0 a=
nd is spendable by Alice herself:<br>
pk(A)<br>
<br>
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.<br>
<br>
(c) change output<br>
money not used for the other two outputs gets sent back to Alice.<br>
<br>
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.<br>
<br>
2. Bob creates an unsigned PSBT, placing the input that Charlie was previou=
sly funded.<br>
<br>
3. Bob passes his PSBT to Alice. <br>
<br>
4. Alice places one input to PSBT, the =E2=80=9Dconnector output,=E2=80=9D=
=C2=A0 which is a descendant of the (b) connectors output she is crafting.<=
br>
<br>
5. Alice places one output to PSBT, a single-sig output that sweeps all mon=
ey to herself (pk(A)).<br>
<br>
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.<br>
<br>
7. Alice signs her one-in, three-out and broadcasts it. <br>
<br>
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.<br>
<br>
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.<br=
>
<br>
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. <br>
<br>
1. Say, Bob wants to send 1 BTC to Dave. <br>
<br>
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:<br>
pk(D) &amp;&amp; (older(4 weeks) || pk(A))<br>
<br>
3. Alice places one connector output as a descendant of (b) connectors outp=
ut, just like before. <br>
<br>
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.<br>
<br>
5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from =
the (a) commitment output descendants that Alice previously <br>
<br>
6. Bob passes his PSBT to Alice. <br>
<br>
7. Alice places one input to PSBT, the =E2=80=9Dconnector output,=E2=80=9D=
=C2=A0 which is a descendant of the (b) connectors output she is crafting. =
<br>
<br>
8. Alice places one output to PSBT, a single-sig output that sweeps all mon=
ey to herself (pk(A)).<br>
<br>
9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this tra=
nsaction private. <br>
<br>
10. Alice signs her one-in, three-out transaction and broadcasts it. <br>
<br>
11. Bob lets Dave know about this transaction (Alice=E2=80=99s transaction =
id, Dave=E2=80=99s vTXO output index) out-of-band. <br>
<br>
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.<br>
<br>
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<br>
<br>
[1] <a href=3D"https://eprint.iacr.org/2017/394.pdf" rel=3D"noreferrer" tar=
get=3D"_blank">https://eprint.iacr.org/2017/394.pdf</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000102c86060248de41--