btcbanksy on Nostr: ARK … from Burak on Telegram: Here's Alice & Bob payment flow: Suppose Alice owns ...
ARK … from Burak on Telegram:
Here's Alice & Bob payment flow:
Suppose Alice owns 1234 sats and wants to send 500 sats to Bob, where Charlie is the Ark service provider; Alice joins Charlie’s next pool session to pay Bob. This is akin to joining a coinjoin session where Charlie is the blinded coordinator. Unlike coinjoins, however, (1) pool sessions take place in very short periods, (2) the intention is to pay someone in an aggregate transaction, and (3) there is no on-chain footprint except for the pool outputs and inputs that fund the pool outputs, everything else is off-chain commitments that nests in the pooled output.
Alice’s 1234 sats are made of ten coins; a 1000 sats coin, two 100 sats coins, three ten sats coins, and four one sat coins. These coins are off-chain commitments that live in pools from which Alice was previously paid. Alice can unilaterally revert her coins to on-chain by revealing and claiming her nested coins from these pools.
A pool expires after four weeks of its creation. After expiration, a pool becomes solely claimable by the service operator who funded the pool in the first place. This is so that nested coins can only be revealed within the first four weeks of a pool's creation. Users must spend their coins in this timeframe or send coins back to themselves under a new pool to reset the four-week timer.
The pool content may be revealed if the service provider happens to be non-collaborative or non-responsive for a long period. In the optimistic big picture, however, the final result is almost always a pool transaction with few inputs, the pooled output, the connectors output, and change output where the factory content is rarely revealed on-chain. Therefore, coins remain almost always off the chain.
Each coin has a 2-of-2 key path where the coin owner and the factory operator are co-signers. Coins are also given a script-path refund closure secured by a timelock if the service provider is non-collaborative co-signing from the 2-of-2 key path.
After Alice joins Charlie’s factory session, Alice registers for her ten coins (1234 sats) to spend in the pool, each under a unique Tor identity, similar to registering UTXOs in a coinjoin round. Charlie previously provided liquidity for these coins in his pools and is the co-signer of every single one. He can therefore authorize Alice’s coins for registration based on whether they are invalid, banned, or expired. Charlie, of course, doesn’t know who Alice is; he sees ten different Tor identities who want to register their coins. Charlie gives Alice blinded credentials based on her registered ten coins.
Alice rejoins the pool session, this time to register for payout coins. Alice unblinds credentials she previously received from Charlie and registers for Bob’s payout coins plus her change under a unique Tor identity each. To pay Bob 500 sats, she registers for five payout coins, each carrying 100 sats. Each of these five coins is a 2-of-2 multisig between Charlie and Bob. To calculate Bob’s co-signer key for each payout, Alice tweaks Bob’s dedicated well-known public key (i.e., Nostr key) with a unique payment commitment to (1) preserve Bob’s privacy by eliminating address reuse and (2) obtain proof of payment from this payout when Bob claims his coins. Alice sends these payment commitments to Bob out-of-band (i.e., Nostr DM). Alice also registers for a 734 sats change, made of 14 coins; seven 100 sats coins, three 30 sats coins, and four one sat coins. Alice has registered for 19 payout coins in total; 5 coins to pay Bob and 14 coins to pay herself.
Once the registration phase is over, Charlie crafts his pool template by adding Alice’s 19 payout coins mixed with other participants’ coins under the vtxos output. He adds the vtxos output to the overall pool transaction he is crafting. Charlie then adds a set of additional outputs called vtxo connectors to his pool template under a separate transaction output called connectors output. A vtxo connector output is a single-sig P2TR output spendable by Charlie himself, and it carries a dust value (450 sats). Vtxo connectors are added to the pool number of registered spending coin times. Since Alice has registered ten coins to spend, Charlie adds ten coin connector outputs to his pool, mixed with other participants’ vtxo connectors. Alice has 29 total associated outputs in Charlie’s new pool template; 5 payout coins for Bob, 14 change coins for herself, and ten vtxo connectors for her coins to plug in.
Alice and Charlie collaboratively sign off-chain transactions from the 2-of-2 key path of her coins to connect to her vtxo connectors. The first input in this off-chain transaction is the coin itself, and the second is the vtxo connector from the new pool template, plus one output for Charlie to sweep the funds. The coin (first input) is signed using SH_ALL; therefore, the vtxo connector’s (second input) outpoint in the sighash preimage commits to the pool transaction id. To claim this coin in a dispute resolution, the service provider must point to the agreed pool template by spending the corresponding vtxo connector (second input). This provides an atomic payout construction as the payout coins nest in the same pool as the vtxo connectors.
Here's Alice & Bob payment flow:
Suppose Alice owns 1234 sats and wants to send 500 sats to Bob, where Charlie is the Ark service provider; Alice joins Charlie’s next pool session to pay Bob. This is akin to joining a coinjoin session where Charlie is the blinded coordinator. Unlike coinjoins, however, (1) pool sessions take place in very short periods, (2) the intention is to pay someone in an aggregate transaction, and (3) there is no on-chain footprint except for the pool outputs and inputs that fund the pool outputs, everything else is off-chain commitments that nests in the pooled output.
Alice’s 1234 sats are made of ten coins; a 1000 sats coin, two 100 sats coins, three ten sats coins, and four one sat coins. These coins are off-chain commitments that live in pools from which Alice was previously paid. Alice can unilaterally revert her coins to on-chain by revealing and claiming her nested coins from these pools.
A pool expires after four weeks of its creation. After expiration, a pool becomes solely claimable by the service operator who funded the pool in the first place. This is so that nested coins can only be revealed within the first four weeks of a pool's creation. Users must spend their coins in this timeframe or send coins back to themselves under a new pool to reset the four-week timer.
The pool content may be revealed if the service provider happens to be non-collaborative or non-responsive for a long period. In the optimistic big picture, however, the final result is almost always a pool transaction with few inputs, the pooled output, the connectors output, and change output where the factory content is rarely revealed on-chain. Therefore, coins remain almost always off the chain.
Each coin has a 2-of-2 key path where the coin owner and the factory operator are co-signers. Coins are also given a script-path refund closure secured by a timelock if the service provider is non-collaborative co-signing from the 2-of-2 key path.
After Alice joins Charlie’s factory session, Alice registers for her ten coins (1234 sats) to spend in the pool, each under a unique Tor identity, similar to registering UTXOs in a coinjoin round. Charlie previously provided liquidity for these coins in his pools and is the co-signer of every single one. He can therefore authorize Alice’s coins for registration based on whether they are invalid, banned, or expired. Charlie, of course, doesn’t know who Alice is; he sees ten different Tor identities who want to register their coins. Charlie gives Alice blinded credentials based on her registered ten coins.
Alice rejoins the pool session, this time to register for payout coins. Alice unblinds credentials she previously received from Charlie and registers for Bob’s payout coins plus her change under a unique Tor identity each. To pay Bob 500 sats, she registers for five payout coins, each carrying 100 sats. Each of these five coins is a 2-of-2 multisig between Charlie and Bob. To calculate Bob’s co-signer key for each payout, Alice tweaks Bob’s dedicated well-known public key (i.e., Nostr key) with a unique payment commitment to (1) preserve Bob’s privacy by eliminating address reuse and (2) obtain proof of payment from this payout when Bob claims his coins. Alice sends these payment commitments to Bob out-of-band (i.e., Nostr DM). Alice also registers for a 734 sats change, made of 14 coins; seven 100 sats coins, three 30 sats coins, and four one sat coins. Alice has registered for 19 payout coins in total; 5 coins to pay Bob and 14 coins to pay herself.
Once the registration phase is over, Charlie crafts his pool template by adding Alice’s 19 payout coins mixed with other participants’ coins under the vtxos output. He adds the vtxos output to the overall pool transaction he is crafting. Charlie then adds a set of additional outputs called vtxo connectors to his pool template under a separate transaction output called connectors output. A vtxo connector output is a single-sig P2TR output spendable by Charlie himself, and it carries a dust value (450 sats). Vtxo connectors are added to the pool number of registered spending coin times. Since Alice has registered ten coins to spend, Charlie adds ten coin connector outputs to his pool, mixed with other participants’ vtxo connectors. Alice has 29 total associated outputs in Charlie’s new pool template; 5 payout coins for Bob, 14 change coins for herself, and ten vtxo connectors for her coins to plug in.
Alice and Charlie collaboratively sign off-chain transactions from the 2-of-2 key path of her coins to connect to her vtxo connectors. The first input in this off-chain transaction is the coin itself, and the second is the vtxo connector from the new pool template, plus one output for Charlie to sweep the funds. The coin (first input) is signed using SH_ALL; therefore, the vtxo connector’s (second input) outpoint in the sighash preimage commits to the pool transaction id. To claim this coin in a dispute resolution, the service provider must point to the agreed pool template by spending the corresponding vtxo connector (second input). This provides an atomic payout construction as the payout coins nest in the same pool as the vtxo connectors.