aruokhai

I have an idea of using Ark for Escrow related services. ( I am thinking about it )

The idea lies in the finality of sweep and unilateral exit.

aruokhai

Objectives

The Ark Protocol, a very splendid UTXO based Bitcoin OffChain Protocol, in its current non-convenant iteration, is presently faced with some not so splendid UX Flaws. These Flaws are categorized into two:

Liquidity Flaw (Short Sweep Duration):

In cases where a premature sweep is conducted using the linear properties of Schnorr signatures, the recovered liquidity from such a sweep remains dependent on the transaction frequency of users and the depth of the Ark tree, given that a binary tree structure is employed. A proposed solution by João Bordalo involves utilizing a splitting function for VTXOs based on a predefined ratio. Building on this idea, I suggest a more dynamic splitting approach that accounts for the average transaction size. This adjustment could better optimize the protocol by reducing both the cost of unilateral exits and the overall size of the Ark tree. Regardless of the specific approach taken, a reduction in liquidity requirements is likely to result.

Reliabi

aruokhai

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

aruokhai

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

aruokhai

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

aruokhai

**Problem**

The Current Iteration Of The Watchtower Specification (Bolt 13 Draft), makes use of signatures for accountability purpose. While appropriate for this usecase, it is frought with very perculiar problems, which spans but not limited to
1) The linear storage cost growth of message and Signatures in respective to appointments O(n), client must store both message and data  [Client Problem].
2) The inability of Towers to fully delete Appointments, its Signature must live on , due to non zero probability of rufuting claims in the future. [Tower Problem]
3) In the advent of a breach that wasn't dealt with, there is a chance of Client not  being able to prove because the lose of data.

**Solution**

The usage of accumulators would prove to solve the problems caused by signatures, but there are some design goals, such constaints should adhere.