Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
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) com
[bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Hi All, I have a question about the often touted statement that "APO can emulate CTV". From what I have found in the specs and the inquisition codebase: > BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction > by hardcoding a 65-byte signature and a 33-byte unknown public key type in a > script. Alternatively, BIP-119 CTV can directly constrain transaction outputs > to a template hash. APO/AS SIGHASH does not commit to the number of inputs (nor obviously the other input outpoints themselves). This has some interesting consequences for Ark, which relies on TXID non-malleability for it's ATLCs. Either one of these cases seem to be true depending on how the contracts are constructed: - APO only: Users can double spend the ASP (USER CAN STEAL) - APO + ASP single sig: ASP can stop users from unilateral exit and sweep funds after 4 weeks (ASP CAN STEAL) - n-of-n musig on the vTXO tree: trustless, APO however is not needed, full interactivity, analogous to key deletion covenant (NOBODY CAN STEAL) APO/AS can also not be used for the ATLC itself, as it has to commit to the TX outpoint of the connector transaction. OP_CTV however commits to the number of inputs explicitly, thus committing to a single input prevents TXID malleability and ensures the ATLC is going to be enforceable. I would like to ask what the devs who are deeper into covenant research think about this, and if I'm missing something? - moonsettler___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
> A problem with the idea of using one-show signatures as double-spend > protection is that miner-claimable fidelity bonds don't work as well > against adversaries that are not just counterparties but also miners > themselves. Hey David, The fidelity bonds in the Ark context are nothing but the vTXOs themselves, which in simple terms, have two possible closures: (1) a key-path collaborative closure with higher precedence and (2) a script-path closure with lower precedence. The key-path closure is a 2-of-2 between the rightful owner of the vTXO and the service provider. The script path closure, on the other hand, lets the service provider sweep funds after a relative lock time. The key-path closure has higher precedence over the script-path closure since it can be triggered immediately with a satisfying signature. If the service provider double-spends a transaction that enforces a one-time signature where Bob is the vendor, Bob can forge the service provider’s signature from the 2-of-2 and can immediately claim his previously-spent vTXO(s). If Alice (or the service provider) is a miner she won’t be able steal funds regardless, since she won’t be able co-sign from the Bob’s key. Best, Burak ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
On 2023-06-07 03:30, Burak Keceli wrote: If the service provider double-spends a transaction that enforces a one-time signature where Bob is the vendor, Bob can forge the service provider’s signature from the 2-of-2 and can immediately claim his previously-spent vTXO(s). Hi Burak, I'm confused. Bob owns some bitcoins that are timelocked against immediate withdrawal, but where he can spend immediately with the cooperation of service provider Sally. Bob transfers some bitcoins to Sally contingent on her spending an equal amount of bitcoins (minus a fee) to Carol. You already have a mechanism to enforce this contingency (tx outpoints), so if Carol doesn't receive the bitcoins from Sally, then Sally also doesn't receive the bitcoins from Bob. In other words, you already have atomicity for a single transfer. Are you describing the effect over multiple transfers? For example, Bob previously transferred bitcoins to Sally and she paid users X, Y, and Z in transactions that are now confirmed onchain, although she hasn't yet swept Bob's funds. Now when Sally double spends the payment to Carol, Bob can not only reclaim the funds he gave Sally to pay to Carol (which was guaranteed by the atomicity), he can also reclaim the unswept funds he gave Sally to pay X, Y, and Z. If so, I don't think that works. In a private protocol, Carol can't be sure that Bob and Sally are separate individuals. If they're the same entity, then any forfeit that Sally needs to pay Bob is just an internal transfer, not a penalty. I'd appreciate any clarification you can offer. Thanks!, -Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Burak, I don't remember if this has been mentioned previously in the conversation about Ark, but a disadvantage in the protocol as it is currently is that "Ark require users to come online and "refresh" their coins every few weeks, otherwise the ASP can sweep the funds." (putting that in quotes because although I copied this from a forum, it may have originally been said on this list.) However, yesterday I have come up with a scheme to mitigate this disadvantage, in a way that works similar to LN watchtowers. This watchtower program for Ark would be made that runs on an internet-connected server and inputs your wallet password and the date in the future to perform the refreshing. A child process can then be spawned that acts similar to a cronjob, and stores the wallet password with AES encryption in memory. The key to this cipher is the time stored in ISO 8601 format as a byte string. It is promptly discarded from memory. Every second, the watchtower child process will attempt to decrypt the cipher using the current ISO 8601 time looking like "-mm-ddTHH:MM:SSZ" as the key. Naturally this will only succeed at the requisite time at which the wallet is to be unlocked by the watchtower child process - following which the coins inside the ASP are refreshed, and the watchtower child process is terminated and the encrypted wallet password destroyed. Of course, memory scrubbing should be applied to the region that has the decrypted wallet password. If at any point the user comes online by themselves, they can simply cancel the watchtower refreshing task, which will terminate the watchtower child process without opening your wallet and refreshing coins. The key feature is that nobody will be able to decrypt the wallet password unless they know the exact time it is to be unlocked as an ISO 8601 string. It cannot be unlocked at any time in the future, just at that particular instant, as long as the key is discarded and the software randomly guesses the decryption by attempting each second the new time as the encryption key. Even if the watchtower is hacked after the task has been made, the hacker still won't be able to decrypt the wallet password unless they brute-force the encryption key by exhaustively trying all timestamps in the future. Alternatively, instead of encrypting the wallet password, it can encrypt a signed transaction which is used by Ark to refresh the coins. In this case, the wallet password would still need to be collected, but only for the purpose of signing the transaction, after which the password is promptly erased from memory. How this can be extended to repeatedly arming the watchtower program with refreshes remains to be seen, but using the wallet password as the encryption directly is one option albeit not a secure one A better and more secure option would be to take note of the UTXOs created by the coin refreshing transaction, use those as inputs to a second refreshing transaction that is created immediately after the first one, sign it, and similarly create a third, fourth, etc. as many as are desirable for the user. Then every 4 weeks, one of these transactions can be broadcasted, in the order that they were created obviously. Looking forward to your feedback on this. -Ali___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Hi Burak, Thanks for your response! I found it very helpful. I'm going to reply to your email a bit out of order. 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. You don't mention it in your reply, but was I correct in my earlier email in assuming that Alice can claim any funds paid to a commitment output after four weeks if its commitments haven't been published onchain? E.g., that in the best case this allows a ~50 vbyte commitment output that pays an arbitrary number of users to be spent as a ~100 vbyte input (P2TR scriptpath for pk(A) && older(4 weeks))? 1. Mixing coins. 2. Paying lightning invoices 3. Making internal transfers If commitment outputs can't normally be spent by Alice for four weeks, then Alice needs to keep enough capital on hand to pay out all amounts involved in the activities listed above. I've seen many people make this point, but I wanted to run some rough numbers to estimate the extent of that capital load. Let's say Alice has a million customers who each receive all of their income and pay all of their expenses with her. In my country, the median income is a bit less than $36,000 USD, or about $3,000 a month. I imagine spending is not evenly distributed over time, so let's say Alice needs to hold 3x the average to be prepared for a busy period. That implies Alice's capital requirements are about $9 billion USD (3 * 3000 * 1e6). At a hypothetical risk-free interest rate of 1.5% annual, that's about $135 that will need to be recovered from each user per year (9e9 * 0.015 / 1e6). Additionally, if we assume the cost of an onchain transaction is $100 and the service creates one transaction per five seconds, that's $630 in fee costs that will need to be recovered from each user per year ((60 / 5) * 60 * 24 * 365 * 100 / 1e6). I'll come back to this financial analysis later. 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 [...] https://eprint.iacr.org/2017/394.pdf What do you mean by "instant"? Do you mean "settlement as soon as the next onchain pool transaction is published"? For example, within 5 seconds if the coinjoining completes on time? That's significantly slower than LN today, at least in the typical case for a well-connected node.[1] I think 5 seconds is fine for a lot of purposes (at both point-of-sale terminals and on websites, I very often need to wait >5 seconds for a credit card transaction to process), but I think it's worth noting the speed difference in a technical discussion. Additionally, I think the idea described significantly predates that paper's publication, e.g.: "Well while you can't prevent it you could render it insecure enabling miners to take funds. That could work via a one-show signature [...]"[2] A problem with the idea of using one-show signatures as double-spend protection is that miner-claimable fidelity bonds don't work as well against adversaries that are not just counterparties but also miners themselves. This same problem has been described for other ideas[3], but to summarize: Bob has something valuable. Alice offers him the output of an unconfirmed transaction in exchange for that thing. She also provides a bond that will pay its amount to any miner who can prove that Alice double spent her input to the unconfirmed transaction. If Alice is miner, she can privately create candidate blocks that double spend the payment to Bob and which also claim the bond. If she fails to find a PoW solution for those candidate blocks, she lets Bob have his money. If she does find a PoW solution, she publishes the block, taking Bob's money, securing her bond, and also receiving all the regular block rewards (sans the fees from whatever space she used for her transaction). I haven't exactly[4] seen this mentioned before, but I think it's possible to weaken Alice's position by putting a timelock on the spending of the bond, preventing it from being spent in the same block as the double-spend. For example, a one-block timelock (AKA: 1 CSV) would mean that she would need to mine both the block containing her unconfirmed transactions (to double spend them) and the next block (to pay the fidelity bonds back to herself). Ignoring fee-sniping (bond-sniping in this case), selfish mining, and 51% attacks, her chance of success at claiming the fidelity bond is equal to her portion of the network hashrate, e.g. if she has 33%, she's 33% likely to succeed at double spending without paying a penalty. The value of the fidelity bond can be scaled to compensate for that, e.g. if you're worried about Alice controlling up to 50% of hashrate, you make the fidelity bond at least 2x the base amount (1 / 50%). Let's again assume that Alice has a million users making $3,000 USD of payments per month (28 days), or about on average $75,000 per mi
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
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 ATL
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
"Alice runs an Ark service provider. Every 5 seconds, she broadcasts a new unconfirmed onchain transaction"Is that means each such instance adding ~15k vB to single block, i.e. every 10 minutes?In such case only 200 of such nodes - would utilize the whole tx throughput of Bitcoin?RegardsJaroslaw W dniu 2023-05-25 01:03:02 użytkownik David A. Harding via bitcoin-dev napisał: Hi Burak, Thanks for this really interesting protocol! I tend to analyze complicated ideas like this by writing about them in my own words, so I've pasted my summary of your idea to the end of this email in case it's useful, either to other people or to you in helping understand my one concern. My concern is the same one I think Olaoluwa Osuntokun mentioned on Twitter[1] and (less clear to me) might be related to ZmnSCPxj's concern[2]: It seems to me that receiving a payment on the protocol, including conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting for the transaction containing that payment to confirm to a sufficient depth (e.g., I'd wait 6 blocks for small payments and longer for huge payments). Am I missing something? My summary of how I think that part of the protocol works is in the sections labeled "Make an unconditioned payment" and "Make a conditional payment" below. In short, it's clear to me how the service provider and the customer can make instant atomic swaps with each other---they can either spend instantly cooperatively, or they have to wait for a timeout. But how can a receiver of funds be assured that they will actually get those funds unless there's already a timelock and cooperative spend path placed on those funds? -Dave Rough initial summary of Ark protocol: Alice runs an Ark service provider. Every 5 seconds, she broadcasts a new unconfirmed onchain transaction that pays three outputs (the three Cs): 1. *Change Output:* money not used for the other two Cs that gets sent back to the the transaction creator. 2. *Connector Output:* an output that will be used in a future transaction created by Alice as protection against double spends. 3. *Commitment Output:* a CTV-style commitment to a set of outputs that can be published later in a descendant transaction (alternatively, the commitment output may be spent unilaterally by Alice after 4 weeks). Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT with an input of his and a change output. She updates the PSBT with a commitment output that refunds Bob the 1 BTC and a connector output with some minimum value. They both sign the PBST and it is broadcast. We'll ignore fees in our examples, both onchain transaction fees and fees paid to Alice. From here, there are several things that Bob can do: - *Unilaterally withdraw:* Bob can spend from the commitment output to put his refund onchain. The refund can only be spent after a 24-hour time delay, allowing Bob to optionally come to an agreement with Alice about how to spend the funds before Bob can spend them unilaterally (as we'll see in a moment). For example, the script might be[3]: pk(B) && (older(1 day) || pk(A)) - *Collaboratively withdraw:* as seen above, Bob has the ability to come to a trustless agreement with Alice about how to spend his funds. They can use that ability to allow Bob to trade his (unpublished) UTXO for a UTXO that Alice funds and broadcasts. For example: - Alice creates an unsigned PSBT that uses as one of its inputs the connector from Bob's deposit transaction. This will ensure that any attempt by Bob to double-spend his deposit transaction will invalidate this withdrawal transaction, preventing Bob from being able to steal any of Alice's funds. Also included in Alice's unsigned PSBT is another connector output plus the output that pays Bob his 1 BTC. - Bob receives Alice's unsigned PSBT and creates a separate PSBT that includes his unpublished UTXO as an input, giving its value to Alice in an output. The PSBT also includes as an input the connector output from Alice's PSBT. This will ensure that any attempt by Alice to double spend her transaction paying him will invalidate his transaction paying her. - Bob signs his PSBT and gives it to Alice. After verifying it, Alice signs her PSBT and broadcasts it. - *Collaboratively trade commitments:* as mentioned, the commitment output that pays Bob may be claimed instead by Alice after 4 weeks, so Bob will need to either withdraw or obtain a new commitment within that time. To trade his existing commitment for a new commitment looks similar to the collaborative withdrawal procedure but without the creation of an immediately-spendable onchain output: - Alice creates an unsigned PSBT that uses as one of its inputs the connector from Bob's deposit transaction, again preventing double spending by Bob.
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Regarding this: > Users are not so well protected during reorgs, e.g. if Bob double-spends > a transaction whose funds were later used in a payment to Carol, then > Carol loses the money. For this reason, Alice will probably want to > prove to users that no funds they receive in a payment derive from any > deposit less than safe_confirmation_depth blocks. I'm of the opinion that any L2 protocol having a similar concept of block mining but for L2 transactions is a pretty good idea, but the reorgs trapdoor you mentioned could theoretically be mitigated ARK nodes considering their settling transactions on L1 as final after say, 3 blocks, or maybe even 6 blocks. I'm leaning towards the standard 6 blocks, as this delay is invisible to users anyway, and only node operators will really notice it. It is kind of the same way how miners can't spend coinbase transactions for 100 blocks. It's a pretty good idea from Burak though, and I can't wait to see nodes in action with this. - Ali > Hi Burak, > > Thanks for this really interesting protocol! I tend to analyze > complicated ideas like this by writing about them in my own words, so > I've pasted my summary of your idea to the end of this email in case > it's useful, either to other people or to you in helping understand my > one concern. > > My concern is the same one I think Olaoluwa Osuntokun mentioned on > Twitter[1] and (less clear to me) might be related to ZmnSCPxj's > concern[2]: > > It seems to me that receiving a payment on the protocol, including > conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting > for the transaction containing that payment to confirm to a sufficient > depth (e.g., I'd wait 6 blocks for small payments and longer for huge > payments). Am I missing something? > > My summary of how I think that part of the protocol works is in the > sections labeled "Make an unconditioned payment" and "Make a conditional > payment" below. In short, it's clear to me how the service provider and > the customer can make instant atomic swaps with each other---they can > either spend instantly cooperatively, or they have to wait for a > timeout. But how can a receiver of funds be assured that they will > actually get those funds unless there's already a timelock and > cooperative spend path placed on those funds? > > -Dave > > Rough initial summary of Ark protocol: > > Alice runs an Ark service provider. Every 5 seconds, she broadcasts a > new unconfirmed onchain transaction that pays three outputs (the > three Cs): > > 1. Change Output: money not used for the other two Cs that gets sent > back to the the transaction creator. > > 2. Connector Output: an output that will be used in a future > transaction created by Alice as protection against double spends. > > 3. Commitment Output: a CTV-style commitment to a set of outputs that > can be published later in a descendant transaction (alternatively, > the commitment output may be spent unilaterally by Alice after 4 > weeks). > > Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT > with an input of his and a change output. She updates the PSBT with a > commitment output that refunds Bob the 1 BTC and a connector output with > some minimum value. They both sign the PBST and it is broadcast. We'll > ignore fees in our examples, both onchain transaction fees and fees paid > to Alice. > > From here, there are several things that Bob can do: > > - Unilaterally withdraw: Bob can spend from the commitment output to > put his refund onchain. The refund can only be spent after a 24-hour > time delay, allowing Bob to optionally come to an agreement with Alice > about how to spend the funds before Bob can spend them unilaterally > (as we'll see in a moment). For example, the script might be[3]: > > pk(B) && (older(1 day) || pk(A)) > > - Collaboratively withdraw: as seen above, Bob has the ability to come > to a trustless agreement with Alice about how to spend his funds. > They can use that ability to allow Bob to trade his (unpublished) UTXO > for a UTXO that Alice funds and broadcasts. For example: > > - Alice creates an unsigned PSBT that uses as one of its inputs the > connector from Bob's deposit transaction. This will ensure that > any attempt by Bob to double-spend his deposit transaction will > invalidate this withdrawal transaction, preventing Bob from being > able to steal any of Alice's funds. > > Also included in Alice's unsigned PSBT is another connector > output plus the output that pays Bob his 1 BTC. > > - Bob receives Alice's unsigned PSBT and creates a separate PSBT > that includes his unpublished UTXO as an input, giving its value > to Alice in an output. The PSBT also includes as an input the > connector output from Alice's PSBT. This will ensure that any > attempt by Alice to double spend her transaction paying him will > invalidate his transaction paying her. > > - Bob signs his PSBT and gives it to Alice. After verifying it, > Alice
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Hi Burak, Thanks for this really interesting protocol! I tend to analyze complicated ideas like this by writing about them in my own words, so I've pasted my summary of your idea to the end of this email in case it's useful, either to other people or to you in helping understand my one concern. My concern is the same one I think Olaoluwa Osuntokun mentioned on Twitter[1] and (less clear to me) might be related to ZmnSCPxj's concern[2]: It seems to me that receiving a payment on the protocol, including conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting for the transaction containing that payment to confirm to a sufficient depth (e.g., I'd wait 6 blocks for small payments and longer for huge payments). Am I missing something? My summary of how I think that part of the protocol works is in the sections labeled "Make an unconditioned payment" and "Make a conditional payment" below. In short, it's clear to me how the service provider and the customer can make instant atomic swaps with each other---they can either spend instantly cooperatively, or they have to wait for a timeout. But how can a receiver of funds be assured that they will actually get those funds unless there's already a timelock and cooperative spend path placed on those funds? -Dave Rough initial summary of Ark protocol: Alice runs an Ark service provider. Every 5 seconds, she broadcasts a new unconfirmed onchain transaction that pays three outputs (the three Cs): 1. *Change Output:* money not used for the other two Cs that gets sent back to the the transaction creator. 2. *Connector Output:* an output that will be used in a future transaction created by Alice as protection against double spends. 3. *Commitment Output:* a CTV-style commitment to a set of outputs that can be published later in a descendant transaction (alternatively, the commitment output may be spent unilaterally by Alice after 4 weeks). Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT with an input of his and a change output. She updates the PSBT with a commitment output that refunds Bob the 1 BTC and a connector output with some minimum value. They both sign the PBST and it is broadcast. We'll ignore fees in our examples, both onchain transaction fees and fees paid to Alice. From here, there are several things that Bob can do: - *Unilaterally withdraw:* Bob can spend from the commitment output to put his refund onchain. The refund can only be spent after a 24-hour time delay, allowing Bob to optionally come to an agreement with Alice about how to spend the funds before Bob can spend them unilaterally (as we'll see in a moment). For example, the script might be[3]: pk(B) && (older(1 day) || pk(A)) - *Collaboratively withdraw:* as seen above, Bob has the ability to come to a trustless agreement with Alice about how to spend his funds. They can use that ability to allow Bob to trade his (unpublished) UTXO for a UTXO that Alice funds and broadcasts. For example: - Alice creates an unsigned PSBT that uses as one of its inputs the connector from Bob's deposit transaction. This will ensure that any attempt by Bob to double-spend his deposit transaction will invalidate this withdrawal transaction, preventing Bob from being able to steal any of Alice's funds. Also included in Alice's unsigned PSBT is another connector output plus the output that pays Bob his 1 BTC. - Bob receives Alice's unsigned PSBT and creates a separate PSBT that includes his unpublished UTXO as an input, giving its value to Alice in an output. The PSBT also includes as an input the connector output from Alice's PSBT. This will ensure that any attempt by Alice to double spend her transaction paying him will invalidate his transaction paying her. - Bob signs his PSBT and gives it to Alice. After verifying it, Alice signs her PSBT and broadcasts it. - *Collaboratively trade commitments:* as mentioned, the commitment output that pays Bob may be claimed instead by Alice after 4 weeks, so Bob will need to either withdraw or obtain a new commitment within that time. To trade his existing commitment for a new commitment looks similar to the collaborative withdrawal procedure but without the creation of an immediately-spendable onchain output: - Alice creates an unsigned PSBT that uses as one of its inputs the connector from Bob's deposit transaction, again preventing double spending by Bob. Alice also includes a new connector and a new commitment that again allows Bob to later claim 1 BTC. - Bob receives Alice's PSBT and creates a PSBT transferring his existing commitment to her, with the new connector again being included as an input to ensure atomicity. - Bob signs; Alice signs and broadcasts. - *Make an unconditioned payment:* using the mechanisms described above,
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Hi - thanks for the Ark write up; I have a bunch of questions but here's 2: --- Q1: "Pool transactions are created by ark service providers perpetually every 5 seconds" What exactly happens every 5 seconds? From the 15.44.21-p-1080.png diagram [1], a pool transaction is a bitcoin transaction, with all the inputs coming from the ASP. My understanding is that every 5 seconds, we progress from PoolTx(N) to PoolTx(N+1). Does the ASP sign a new transaction which spends the same ASP funding inputs as the previous pool transaction, which is a double spend or fee bump? Or does it spend the outputs from the previous PoolTx? In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending the same inputs (call this method A), or does PoolTx(2) spend an output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for PoolTx(2) to become valid (method B)? Or are they completely separate transactions with unconflicting inputs (method C)? When the ASP creates a pool transaction, what do they do with it? Do they broadcast it to the gossip network? Or share it with other pool participants? With method A, if the ASP shares pool transactions with other people, there Doesn't seem to be any way to ensure which PoolTx gets confirmed, invalidating all the other ones. They're all valid so whichever gets into a block first wins. With method B, there seems to be a large on-chain load, with ~120 chained transactions trying to get in every block. This wouldn't play nicely with mempool standardness and doesn't seem like you could ever "catch up". With method C, ASPs would need a pretty large number of inputs but could recycle them as blocks confirm. It would cost a lot but maybe could work. --- Q2: The other part I'm missing is: what prevents the ASP from taking all the money? Before even getting to vTXOs and connector outputs, from the diagram there are only ASP inputs funding the pool transaction. If the pool transaction is confirmed, the vTXOs are locked in place, since the vTXO output cannot be changed and commits to all "constrained outs" via OP_CTV. If the pool transaction is unconfirmed, the ASP can create & sign a transaction spending all ASP funding inputs sending the money back to the ASP, or anywhere else. In this case, users don't have any assurance that their vTXO can ever turn into a real UTXO; the ASP can "rug-pull" at any time, taking all the money in the pool. Adding other inputs not controlled by the ASP to the transaction wouldn't seem to fix the problem, because then any user removing their inputs would cancel the whole transaction. More detail about how these transactions work would be appreciated, thanks! -Tadge [1] https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
> You can also do the same in Lightning, with the same risk profile: the LSP > opens a 0-conf channel to you, you receive over Lightning, send out over > Lightning again, without waiting for onchain confirmations. This is not correct. If an LSP opens a zero-conf channel to me, I cannot receive over lightning immediately because I have to wait for that channel to confirm before revealing my preimage for the payment. If I don’t, LSP takes the sender’s money yet double-spends my channel. This is not the case with Ark. Ark ensures "absolute atomicity" by using ATLCs instead of HTLCs. Users can receive payments and forward them further without waiting for on-chain confirmations. A double-spend attempt breaks the entire atomicity. An ASP cannot redeem senders’ vTXO(s) if they double-spend recipients' vTXO(s). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
> 0-conf transactions are unsafe since it is possible to double-spend the > inputs they consume, invalidating the 0-conf transaction. A future extension of Ark can potentially utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. If a double-spend occurs in a pool transaction, users can forge ASP's signature to claim their previously redeemed vTXOs. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design. For the time being, you have to wait for on-chain confirmations to consider a payment 'final'. However, this doesn't prevent you from paying lightning invoices with your zero-conf coins. Ark has immediate availability with delayed finality. Best, Burak ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Here is an old write-up that should be read by everyone trying to design a NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html Sent with Proton Mail secure email. --- Original Message --- On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev wrote: > Good morning Burak, > > > > As the access to Lightning is also by the (same?) ASP, it seems to me > > > that the ASP will simply fail to forward the payment on the broader > > > Lightning network after it has replaced the in-mempool transaction, > > > preventing recipients from actually being able to rely on any received > > > funds existing until the next pool transaction is confirmed. > > > > Yes, that's correct. Lightning payments are routed through ASPs. ASP may > > not cooperate in forwarding HTLC(s) AFTER double-spending their pool > > transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE > > double-spending their pool transaction. > > > This is why competent coders test their code for footguns before deploying in > production. > > > What makes Ark magical is, in the collaborative case, users' ability to pay > > lightning invoices with their zero-conf vTXOs, without waiting for on-chain > > confirmations. > > > You can also do the same in Lightning, with the same risk profile: the LSP > opens a 0-conf channel to you, you receive over Lightning, send out over > Lightning again, without waiting for onchain confirmations. > Again the LSP can also steal the funds by double-spending the 0-conf channel > open, like in the Ark case. > > The difference here is that once confirmed, the LSP can no longer attack you. > As I understand Ark, there is always an unconfirmed transaction that can be > double-spent by the ASP, so that the ASP can attack at any time. > > > This is the opposite of swap-ins, where users SHOULD wait for on-chain > > confirmations before revealing their preimage of the HODL invoice; > > otherwise, the swap service provider can steal users' sats by > > double-spending their zero-conf HTLC. > > > If by "swap-in" you mean "onchain-to-offchain swap" then it is the user who > can double-spend their onchain 0-conf HTLC, not the swap service provider. > As the context is receiving money and then sending it out, I think that is > what you mean, but I think you also misunderstand the concept. > > Regards, > ZmnSPCxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Good morning Burak, > > As the access to Lightning is also by the (same?) ASP, it seems to me that > > the ASP will simply fail to forward the payment on the broader Lightning > > network after it has replaced the in-mempool transaction, preventing > > recipients from actually being able to rely on any received funds existing > > until the next pool transaction is confirmed. > > > Yes, that's correct. Lightning payments are routed through ASPs. ASP may not > cooperate in forwarding HTLC(s) AFTER double-spending their pool transaction. > However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spending their > pool transaction. This is why competent coders test their code for footguns before deploying in production. > What makes Ark magical is, in the collaborative case, users' ability to pay > lightning invoices with their zero-conf vTXOs, without waiting for on-chain > confirmations. You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations. Again the LSP can also steal the funds by double-spending the 0-conf channel open, like in the Ark case. The difference here is that once confirmed, the LSP can no longer attack you. As I understand Ark, there is always an unconfirmed transaction that can be double-spent by the ASP, so that the ASP can attack at any time. > This is the opposite of swap-ins, where users SHOULD wait for on-chain > confirmations before revealing their preimage of the HODL invoice; otherwise, > the swap service provider can steal users' sats by double-spending their > zero-conf HTLC. If by "swap-in" you mean "onchain-to-offchain swap" then it is the user who can double-spend their onchain 0-conf HTLC, not the swap service provider. As the context is receiving money and then sending it out, I think that is what you mean, but I think you also misunderstand the concept. Regards, ZmnSPCxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Do you have any write up that presents a fully detailed architecture, including mechanisms like bitcoin scripts, transactions and L2 protocols, and then derives claims from that base? On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > As the access to Lightning is also by the (same?) ASP, it seems to me > that the ASP will simply fail to forward the payment on the broader > Lightning network after it has replaced the in-mempool transaction, > preventing recipients from actually being able to rely on any received > funds existing until the next pool transaction is confirmed. > > Yes, that's correct. Lightning payments are routed through ASPs. ASP may > not cooperate in forwarding HTLC(s) AFTER double-spending their pool > transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE > double-spending their pool transaction. > > What makes Ark magical is, in the collaborative case, users' ability to > pay lightning invoices with their zero-conf vTXOs, without waiting for > on-chain confirmations. > > This is the opposite of swap-ins, where users SHOULD wait for on-chain > confirmations before revealing their preimage of the HODL invoice; > otherwise, the swap service provider can steal users' sats by > double-spending their zero-conf HTLC. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
> As the access to Lightning is also by the (same?) ASP, it seems to me that > the ASP will simply fail to forward the payment on the broader Lightning > network after it has replaced the in-mempool transaction, preventing > recipients from actually being able to rely on any received funds existing > until the next pool transaction is confirmed. Yes, that's correct. Lightning payments are routed through ASPs. ASP may not cooperate in forwarding HTLC(s) AFTER double-spending their pool transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE double-spending their pool transaction. What makes Ark magical is, in the collaborative case, users' ability to pay lightning invoices with their zero-conf vTXOs, without waiting for on-chain confirmations. This is the opposite of swap-ins, where users SHOULD wait for on-chain confirmations before revealing their preimage of the HODL invoice; otherwise, the swap service provider can steal users' sats by double-spending their zero-conf HTLC. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Good morning Burak, I have not gone through the deep dive fully yet, but I find myself confused about this particular claim: > A pool transaction can be double-spent by the Ark service provider while it > remains in the mempool. However, in the meantime, the recipient can pay a > lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for > the service operator to double-spend in this case. Given that you make this claim: > ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin > coordinators, and (3) Lightning service providers. ASPs main job is to create > rapid, blinded coinjoin sessions every five seconds, also known as pools. As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed. Even if the Lightning access is somehow different from the ASP you are receiving funds on, one ASP cannot prove that another ASP is not its sockpuppet except via some expensive process (i.e. locking funds or doing proof-of-work). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Hi list, I'm excited to publicly publish a new second-layer protocol design I've been working on over the past few months called Ark. Ark is an alternative second-layer scaling approach that allows the protocol users to send and receive funds without introducing liquidity constraints. This means a recipient can get paid without an onboarding setup, such as acquiring inbound liquidity. The protocol also consumes orders of magnitude less on-chain footprint than Lightning, as there is no concept of opening and closing channels. Ark has a UTXO set that lives off the chain. These UTXOs are referred to as virtual UTXOs or vTXOs in short. Virtual UTXOs are like short-lived notes that expire after four weeks. Users must spend their vTXOs upon receiving them within this four-week timeframe or return them to themselves to reset the four-week timer. Virtual UTXOs live under a shared UTXO and can be revealed on-chain. When a payment is made on the protocol, existing vTXOs are redeemed, and new vTXOs are created, similar to how on-chain funds flow. To improve the anonymity set of the coin ownership, vTXOs values are restricted to a set of sats values ranging from one sat to a million sats. Users can acquire vTXOs from someone who already owns them or use a process called lifting, an atomic two-way peg mechanism that doesn't require trust. Lifting lets users lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO. Users can unilaterally redeem a virtual UTXO for an on-chain UTXO without asking for cooperation. When sending funds, users coin-select & destroy their virtual UTXOs and create new ones for the recipient (plus change) in an off-chain mixing round. Keys for each new virtual UTXO are tweaked with a shared secret that reveals proof of payment when spent. The payment destination is a dedicated well-known public key similar to silent payments; however, the payment trace is obfuscated through plain tweaking and blinded mixing. Ark enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (ASP). ASPs are always-on servers that provide liquidity to the network and charge liquidity fees, similar to how Lightning service providers work. ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools. A user joins a pool session to make a payment, initially coin-selecting and registering their vTXOs to spend, registering vTXOs for intended recipients, and finally co-signing from their vTXOs to redeem them. Ark can be built on Bitcoin today, but we have to compromise on non-interactivity to do so. Recipients must be online to sign from n-of-n multisig to constrain the outputs of a shared UTXO, outputs as in vTXOs. With this approach, users won’t be able to receive offline payments; they need to self-host an Ark client (like Lightning). To make Ark work without running a server, we need a covenant primitive such as BIP-118 or BIP-119. BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash. Other alternatives would be (1) TXHASH, (2) CAT + CSFS + TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations. Ark uses a new locktype primitive called txlock to ensure the absolute atomicity of a transfer schedule. Txlock is a condition in which only the existence of a mutually agreed transaction identifier can unlock the condition. A txlock condition could be satisfied by a hypothetical opcode called OP_CHECKPREVTXIDFROMTHEUTXOSETVERIFY. However, Ark uses an alternative approach to achieving the same outcome using connectors. Connectors are a special output type on the protocol. The primitive is that if we want the Bitcoin script to check if a particular transaction id exists, we simply attach an output from that transaction into our spending transaction and check a pre-signed signature against prevouts of our spending transaction. The connector outpoint in the sighash preimage commits to the transaction id for which we want to satisfy the txlock condition. In the Ark context, this is the pool transaction containing vTXOs of intended recipients. Txlocks are used in Anchor Time Locked Contracts (ATLCs) to provide an atomic single-hub payment schedule. Anchor Time Locked Contracts (ATLCs) are conditional payments used on the Ark protocol. When a vTXO was created in the first place, an ATLC was attached to it, similar to how an eltoo:trigger is attached to a funding output during Eltoo channel formation. When a vTXO is spent, the pre-attached ATLC connects to a connector to form a txlock. This txlock formation ensures that, for the attached ATLC to be claimed
