Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3912AC0032 for ; 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 ; 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 ; 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 ; 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 ; 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 Date: Sun, 6 Aug 2023 23:43:55 +0100 Message-ID: To: Burak Keceli , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Burak,

Thanks for the interesting Ar= k proposal.

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:
- the pool_tx
- the=C2=A0ATL= C-connection_tx
- the ATLC-refund_tx

The= pool_tx spends an on-chain funding input and 3 outputs:
- the co= mmitment output, committing to a set of N vTXOs outputs (e.g a tree of prom= ised outputs)
- the connector output, spendable by the ASP signat= ure
- the change output, from the value overflow of the on-chain = funding input

A "receiver" 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.

A = ATLC-connection_tx is associated with a pool_tx N is spending one or more v= TXOs 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=C2=A0AT= LC-=C2=A0connection_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 t= he unilateral exit path.

Let'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:
- after 24, her vTXO N can be spend unilaterall= y with only her own signature
- 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)
- 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
- the ASP broadcasts the pool_tx N+1 and the transaction= is pending in network mempools
- Alice broadcasts her ATLC refun= d tx using the mature unilateral exit path
- this ATLC refund tx = replaces any ATLC-connection tx pending in network mempools
- bot= h the ATLC refund tx for vTXO at state N and the pool_tx at state N+1 confi= rms
- Bob the receiver can wait 24h and then he can spend the vTX= O at state N+1 unilaterally

Alice and Bob successf= ully colluded to "double-spend" the ASP, without this service pro= vider 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 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.
All mistakes, confusion or misunderstanding are my own. More de= tails about transactions, scripts and protocol phases would be appreciated.=

Cheers,
Antoine

Le=C2=A0ven. 26 ma= i 2023 =C3=A0=C2=A016:27, Burak Keceli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> a =C3=A9crit=C2=A0:
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-c= hain confirmations since you=E2=80=99re mixing your own coins with others.<= br>
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.
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))

=C2=A0From 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.

- *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.

(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=C2=A0 a= nd 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.

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>
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.

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.

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.

1. Say, Bob wants to send 1 BTC to Dave.

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.

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

6. Bob passes his PSBT to Alice.

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. =

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.

10. Alice signs her one-in, three-out transaction and broadcasts it.

11. Bob lets Dave know about this transaction (Alice=E2=80=99s transaction = 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 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000102c86060248de41--