Hi, Antoine.
A brief update on this:
I created a demo script for the unilateral exit of 2-of-4 participants in a
Coinpool using OP_CCV:
https://github.com/halseth/tapsim/tree/matt-demo/examples/matt/coinpool/v2.
It shows how pubkeys and balances can be committed, how traversal and
modification
Hi,
Yes, one would need to have the be a merkle root of all
participants' keys and balances. Then, as you say, the scripts would
have to enforce that one correctly creates new merkle roots according
to the coin pool rules when spending it.
- Johan
On Thu, Oct 5, 2023 at 3:13 AM Antoine Riard
Hi Johan,
Thanks for the insight.
>From the proposed semantics of OP_CHECKCONTRACTVERIFY iirc:
I think this is not yet indicated how the participant's pubkeys and
balances can be disaggregated from , a partial subset push on the
stack and verifying that corresponding signatures are valid.
Hi, Antoine.
It sounds like perhaps OP_CHECKCONTRACTVERIFY can achieve what you are
looking for:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html
By committing the participants' pubkeys and balances in the dynamic
data instead of the taptree one can imagine a subset
Hi Zeeman,
See my comments at the time of OP_EVICT original publication.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019939.html
"I think in the context of (off-chain) payment pool, OP_EVICT requires
participant cooperation *after* the state update to allow a single
Good morning Antoine,
Does `OP_EVICT` not fit?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-dev
Payment pools and channel factories are afflicted by severe interactivity
constraints worsening with the number of users owning an off-chain balance
in the construction. The security of user funds is paramount on the ability
to withdraw unilaterally from the off-chain construction. As such any
