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 signature
- 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 à 16:27, Burak Keceli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :
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’t require waiting for on-chain confirmations since you’re 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’t require waiting for on-chain confirmations since you consider your payment “done” 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 “final”, 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 settlement assurances for the internal transfers, we need OP_XOR or OP_CAT on the base layer [1].


I think you get the gist of it, but I lost you after ”Bob wants to deposit 1 BTC with Alice.” 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 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.

- *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 “pool”.
(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 things, let’s say there are no other participants in this transaction besides Bob, and the descendant transaction has only one output. We call this output Bob’s vTXO. Bob’s vTXO also constrains (using CTV or 2-of-2 multisig) its descendant transaction to a single transaction output called Bob’s ATLC. Bob’s ATLC contains the following script:
pk(B) && (older(4 weeks) || pk(A))
As you realize “ATLC” script is identical to the “Funding address” 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 “connectors output” to fund a new output. We call this output a ”connector,” 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 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 “pool” transaction 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 ”connector output,”  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’s 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 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’s vTXO) and grandchild (Bob’s 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 footprint 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’s vTXO instead of Bob’s. Similarly descendant of Daves’s vTXO is Dave’s ATLC. Dave’s 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 from the (a) commitment output descendants that Alice previously

6. Bob passes his PSBT to Alice.

7. Alice places one input to PSBT, the ”connector output,”  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’s transaction id, Dave’s 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’s 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 “final.”

[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