add sharedtaproot.go

[louisinger]

This PR adds sharedtaproot.go file into sdk package, greatly inspired by https://github.com/louisinger/shared-utxo

SharedTaprootScript struct lets to create a shared output script thanks to introspection opcodes OP_INSPECTOUTPUTSCRIPTPUBKEY & OP_INSPECTOUTPUTVALUE enforcing a "remaining" output to be set while exiting the shared output.

The struct has two exported functions:

• Requirements is useful to spend the shared output: describe the expected change.
• NextSharedTaprootScript lets to compute the new SharedTaprootScript struct from a spent one.

@tiero @altafan please review this

[tiero]

no need to have an SDK now imho, best to have a common package

[louisinger]

here is a table comparing the two methods. It may miss some points cc/ @tiero @altafan

	shared taproot tree	psbt binary tree
unilateral exit	1 tx to redeem. a "dynamic" taproot tree branch: must be recomputed each time an user is exiting the pool	a constant branch of the binary tree, a set of psbt to broadcast. CPFP for fees
forfeit transaction	Must be a message signed by both user and ASP using CSFS because the redeem tx is unknown	spend the constant redeem tx, signed by ASP and the user
send VTXO / collaborative exit	CSFS + introspections lets to sign 1 unique message	sign x forfeit transactions where x is the number of VTXO created by the pool
number of leaves	due to the algorithm complexity without any optimizations (n!) it may limit the number of VTXOs in the pool (~30 ?)	the number of psbt to broadcast may limit the number of VTXOs due to the amount of fees to pay to broadcast a big branch

[altafan]

no need to have an SDK now imho, best to have a common package

@tiero we will change the name of the package.

Based on louis' table, can you share your opinion on whether we should use this kind of shared utxo? If you have other suggestions on how to "mock" this specific component of the Ark protocol please share them here.

This is my resume on what we can/can't see by using this kind of shared outuput instead of the "binary tree" one defined in the spec:

• we can see the same kind of interactivity between user and ASP when the former wants to spend his coins
• we can see how the registration/finalization of the inputs and outputs works (there are no differences between the 2 versions)
• we can't see the real computation effort made by the ASP when creating the shared output. The job of the ASP would be simplified in louis' proposed version (no binary tree of pre-signed txs created but just a single covenant)
• the unilateral exit path is completely different, but we shouldn't really care since we're not interested in this feature of the protocol for the PoC

In conclusion, I think that using this kind of shared utxo would allow us to explore most of the aspects of the ASP's real duty but the effort it makes to compute and sign the binary tree of pre-signed txs.

IMO it could be a decent trade off for the PoC, I'd like to know yours.

[tiero]

1 tx to redeem. a "dynamic" taproot tree branch: must be recomputed each time an user is exiting the pool

How can this process be trustless then? also it requires a signature from everybody everytime there is an exit. Seem same issue CoinPool and other proposals have compared to Ark

[tiero]

allow us to explore most of the aspects

But not the PSBT binary tree construction, management tho?

[louisinger]

1 tx to redeem. a "dynamic" taproot tree branch: must be recomputed each time an user is exiting the pool

How can this process be trustless then?

It is trustless, the user has to "remove" the spent leaf to recompute the new tree, so it can be derived from the initial taproot tree. However, he needs to know the amounts of the pool VTXOS to compute the right "new" change output. Those data (leaf hashes + stakeholders amounts) would be shared while the VTXO is created.

also it requires a signature from everybody everytime there is an exit. Seem same issue CoinPool and other proposals have compared to Ark

Only the user exiting has to sign the leaf he owns, other pool guys are not involved here.

[altafan]

Instead of trying to find a way to implement the shared output and make offchain payments effective, let's completely fake it by still doing the job that a real ASP is supposed to do:

Since we're not interested in providing the unilateral exit feature, the onchain outcome of a round can be a simple pool tx with ASP inputs, and 2 outputs mocking the shared and the connector output. They would be simple singlesig outputs owned by the ASP.
Under the hood, the ASP still does the job of creating the tree of txs so they still receive their vTXOs that they can spend. Internally, the ASP makes an association between a mocked shared output and a tree of txs.
The outputs of the txs of the tree don't need to be locked by any complex covenant like the "real version", we could use simple singlesig for the outputs of the intermediate txs, and (A+ASP) || (ASP in 4 weeks) for the outputs of the leaves txs (vTXOs) .

Basically we would simplify all implementational details, but sill have the same operations done by the ASP and also the users.