Ark Liquidity Issue Fix

Arkissue.md

Ark Liquidity Lock Fix

The unresolved issue of liquidity lock requirements must be addressed before the Ark protocol can be deemed ready for public deployment. This issue pertains specifically to the mechanics of spending outputs within the Ark protocol, which directly impact its scalability and efficiency in managing off-chain transactions.

In the Ark Protocol, a timelock is imposed on non-leaf transactions, allowing the Ark Server to reclaim the associated outputs once the timelock expires. However, this timelock mechanism significantly amplifies the Ark Server's liquidity requirements, as it necessitates maintaining locked funds over extended periods, thereby impacting the system's overall capital efficiency.

To address this issue, I propose utilizing a multi-key address scheme analogous to the structure employed in Silent Payments. This approach not only mitigates the liquidity challenges but also introduces the added advantage of enabling Ark Providers to reorganize and group transactions based on anticipated spending intervals, thereby optimizing liquidity managemnt.

Parties Involved ( Keys )

• Ark ( A ) --> The Ark Server
• Bob ( nonce n , Bob_scan_key B_c, Bob_spend_key B_s )
• Charlie ( nonce n , Charlie_scan_key C_c, Charile_spend_key C_s )

Bob Keys Derivation

• Bob_nonce (n) = hash(b_s.A) + hash(random_secret_known_to_bob)
• Bob_scan_key (B_c) = (b_s.A || random_secret_know_to_bob).G
• Bob_scan_secret (b_c) = (b_s.A || random_secret_know_to_bob).G
• Bob_spend_key (B_s) = b_s.G

Note:

• Bob (n, B_c, B_s) ---> Bob Ark Address
• Note that a new Ark Address is always generated by the receiver whenever payment is to be made, which (B_s) is expected to be static.

Scenrio (Bob send to Charlie)

In Ark, payments work in such flow: Bob -> Ark -> Charlie (atomic)

• Bob gives Charlie Ark Address to the Ark Server
• Server Decodes and derives ( n , C_c, C_s )
• Server computes k = hash(random_secret_known_to_charlie) = n - hash(a.C_s)
• Ark creates a leaf transaction and includes a forefeitig tapscript spending condtion for Charlie and Ark:
  • forfeiting_tapscript = OP_SHA256 k OP_EQUAL OP_DATA_32 <asp_pubkey> OP_CHECKSIGVERIFY OP_DATA_32 C_s OP_CHECKSIG.
  • P = NUMS_H + [taproot].G
• Ark sends fund to P.
• If Bob also sends fund to Dave, Ark provider then creates a non leaf transaction which includes a key spend path, using Musig key aggregation:
  • Internal_Pubkey = H(B_c, D_c, A). B_c + D_c + A
  • Internal_Privkey = H(B_c, D_c, A). b_c + d_c + a
  • Q = Internal_Key + [scirpt_path].G The Inernal Key can be created recursively to the root transaction.

Bonus

By ensuring that B_s remains static, the Ark Provider can group transactions more effectively, separating keys with frequent transactions into a distinct branch from those with infrequent transactions. This approach helps to significantly enhance liquidity management.