path: root/46/3a3f67ff8e9f94b2fa8ec93260d2e2a9cec7ee

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2C62EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 13:18:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 08D1C60D6D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 13:18:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id r1sVF9vYifA9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 13:18:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com
 [IPv6:2607:f8b0:4864:20::112c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id AA53A60BA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 13:18:17 +0000 (UTC)
Received: by mail-yw1-x112c.google.com with SMTP id
 00721157ae682-2ebf4b91212so52586177b3.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 06:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=zv/yRGjYJCz2M5tDRzPDSG6qD4iwyVLP5mYBixvrl/s=;
 b=oxI+9sRKF949RHHTjaq0zxNW5FIufzPXqKpuRAWihAiluI0SJqxQObW4RCLeApRcDy
 YX/vzVN+h0LMvtU6Pd3YBqPxzILxez7sbyOXnRF56XGTNCMidgD5yanI3p1Lo5bgJvKY
 WDVm3j8cSNAOVqZnx5wdGtwOCsu5m8HVQG8Y3FrlTDlCzNlkrOdTG4LW6otqV7Rc7kmb
 X4Ahpe+dZNxuJQbGi4AzQyQyRydJomr4PeM1y1czwTBtAa2CKpr6KNzGP4b18zBnX2S0
 R3pFz3BgH1tjinIsHMsgwN5QM2zxFAWEBKJ+aqa5Bg28yb19yyzUYsYegIMuZvRyWdYF
 YTNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=zv/yRGjYJCz2M5tDRzPDSG6qD4iwyVLP5mYBixvrl/s=;
 b=cGtDwnfmzi/R+siUgTAMZqW3PwQj+E2+/wUKMlFdsTLUOKdQtzoZ1fchwor23TpZHc
 mN32+qkTPBnX8nAKYiCctCf8Ogja2lDwKgcVEQ6io+8kwzZbXTsBytsB76SbRzD0H+ac
 aWDrM52E7qEog3bJnKd+kd9195ZjwuvpydaQFbAjptt1YcSIrOVLDXFQoTGpcpg8tXVK
 aU+eBk28zwWngggi/f1r3y9OLf5Df51TmLjhE2F8Tf6c7xX/X3JZmdcZzNpNfMOuGvm1
 N59202JYkxh9N5VgImvA4OuwPdIXyXksAtXxWzJbTs5KPMvhMOTg1BkO9xbi6+JPxy9v
 d97g==
X-Gm-Message-State: AOAM531PfNdmOQvh6zg8FXEV37gosO2FttA8QAwrkKJR9d0S41ylkG+2
 jmQrGY1l+M8AHQKlPYf4MjULu++aceSSDIEtiefRLYM9vW6Skg==
X-Google-Smtp-Source: ABdhPJytXVrPyk/+SvEwC/6HmcXq+5Uu+jzNHA2E24RSUwoo2lpfCIaxmTgupyO87zLUAyJE1zJaRPwauYLGjGwZE2A=
X-Received: by 2002:a81:eca:0:b0:2f8:9b5:e2eb with SMTP id
 193-20020a810eca000000b002f809b5e2ebmr17135108ywo.410.1651151896022; 
 Thu, 28 Apr 2022 06:18:16 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 28 Apr 2022 09:18:05 -0400
Message-ID: <CALZpt+GNoRdbtfeBtpnitiAZ4jGwSsRpSRXOyX7mzrhwewmBcw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003b92e705ddb6c2cd"
X-Mailman-Approved-At: Thu, 28 Apr 2022 13:20:12 +0000
Subject: [bitcoin-dev] Conjectures on solving the high interactivity issue
 in payment pools and channel factories
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 13:18:20 -0000

--0000000000003b92e705ddb6c2cd
Content-Type: text/plain; charset="UTF-8"

Hi,

This post recalls the noticeable interactivity issue encumbering payment
pools and channel factories in the context of a high number of
participants, describes how the problem can be understood and proposes few
solutions with diverse trust-minizations and efficiency assumptions. It is
intended to capture the theoretical bounds of the "interactivity issue",
where technical completeness of the solutions is exposed in future works.

The post assumes a familiarity with the CoinPool paper concepts and
terminology [0].

# The interactivity requirement grieving payment pools/channel factories

Payment pools and channel factories are multi-party constructions enabling
to share the ownership of a single on-chain UTXO among many
off-chain/promised balances. Payment pool improves on the channel factory
construction fault-tolerance by reducing the number of balance outputs
disclosed  on-chain to a single one in case of unilateral user exits.

However, those constructions require all the users to be online and
exchange rounds of signatures to update the balance distribution. Those
liveliness/interactivity requirements are increasing with the number of
users, as there are higher odds of *one* lazzy/buggy/offline user stalling
the pool/factory updates.

In echo, the design of LN was envisioned for a network of
always-online/self-hosted participants, the early deployment of LN showed
the resort to delegated channel hosting solutions, relieving users from the
liveliness requirement. While the trust trade-offs of those solutions are
significant, they answer the reality of a world made of unreliable networks
and mobile devices.

Minding that observation, the attractiveness of pools/factories might be
questioned.

# The interactivity requirement palliatives and their limits

Relatively straightforward solutions to lower the interactivity
requirement, or its encumbered costs, can be drawn out. Pools/factories
users could own (absolute) timelocked kick-out abilities to evict offline
users who are not present before expiration.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Each of them owns a Withdraw transaction to exit their individual balances
at any time. Each user should have received the pre-signed components from
the others guaranteeing the unilateral ability to publish the Withdraw.

A kick-out ability playable by any pool user could be provided by
generating a second set of Withdraw transactions, with the difference of
the nLocktime field setup to an absolute height T + X, where T is the
height at which the corresponding Update transaction is generated and X the
kick-out delay.  For this set of kick-out transactions, the complete
witnesses should be fully shared among Alice, Bob, Caroll and Dave. That
way, if Caroll is unresponsive to move the pool state forward after X, any
one of Alice, Bob or Dave can publish the Caroll kick-out Withdraw
transaction, and pursue operations without that unresponsive party.

While decreasing the interactivity requirement to the timelock delay, this
solution is constraining the kicked user to fallback on-chain encumbering
the UTXO set with one more entry.

Another solution could be to assume the widespread usage of node towers
among the pool participants. Those towers would host the full logic and key
state necessary to receive an update request and produce a user's approval
of it. As long as one tower instance is online per-user, the pool/factory
can move forward. Yet this is forcing the pool/factory user to share their
key materials with potentially lower trusted entities, if they don't
self-host the tower instances.

Ideally, I think we would like a trust-minimized solution enabling
non-interactive, off-chain updates of the pool/factory, with no or minimal
consumption of blockspace.

For the remainder of this post, only the pool use-case will be mentioned.
Though, I think the observations/implications can be extended to factories
as well.

# Non-interactive Off-chain Pool Partitions

If a pool update fails because of lack of online unanimity, a partition
request could be exchanged among the online subset of users ("the
actives"). They decide to partition the pool by introducing a new layer of
transactions gathering the promised/off-chain outputs of the actives. The
set of outputs belonging to the passive users remains unchanged.

The actives spend their Withdraw transactions `user_balance` outputs back
to a new intermediate Update transaction. This "intermediate" Update
transaction is free to re-distribute the pool balances among the active
users. To guarantee the unilateral withdraw ability of a partitioned-up
balance, the private components of the partitioned Withdraw transactions
should be revealed among the set of active users.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Pool is at state N, Bob and Dave are offline. Alice and Caroll agree to
partition the pool, each of them owns a Withdraw transaction
ready-to-be-attached on the Update transaction N. They generate a new
partitioning Update transaction with two inputs spending respectively
Alice's Withdraw transaction `user_balance` output and Caroll's Withdraw
transaction `user-balance` output. From this partitioning Update
transaction, two new second-layer Withdraw ones are issued.

Alice and Caroll reveal to each other the private components of their
first-layer Withdraw transactions, allowing to publish the full branch :
first-layer Update transaction, first-layer Withdraw transactions,
second-layer partitioning Update transaction, second-layer partitioned
Withdraw transaction. At that step, I think the partitioning should be
complete.

Quickly, a safety issue arises with pool partitioning. A participant of the
active set A could equivocate the partition state by signing another spend
of her Withdraw transaction allocating her balance to an Update transaction
of a "covert" set of active users B.

This equivocation exists because there is no ordering of the off-chain
spend of the Withdraw transactions and any Withdraw transaction can be
freely spent by its owner. This issue appears as similar to solving the
double-spend problem.

Equivocation is a different case than multiple *parallel* partitions, where
there is no intersection between the partitioned balances. The parallel
partitions are still rooting from the same Update transaction N. I think
the safety of parallel partitions is yet to be explored.

# Current solutions to the double-spend problem : Bitcoin base-layer &
Lightning Network

Of course, the double-spend issue is already addressed on the Bitcoin
base-layer due to nodes consensus convergence on the most-proof-of-work
accumulated valid chain of blocks. While reorg can happen, a UTXO cannot be
spent twice on the same chain. This security model can be said to be
prophylactic, i.e an invalid block cannot be applied to a node's state and
should be rejected.

The double-spend issue is also solved in its own way in payment channels.
If a transaction is published, of which the correctness has been revoked
w.r.t negotiated, private channel state, the wronged channel users must
react in consequence. This security model can be said to be corrective,
states updates are applied first on the global ledger then eventually
corrected.

A solution to the pool partition equivocation issue appears as either based
on a prophylactic one or a corrective security model.

Let's examine first, a reactive security model similar to LN-Penalty. At
pool partition proposals, the owners of the partitioned-up Withdraw
transactions could reveal a revocation secret enabling correction in case
of wrongdoing (e.g single-show signatures). However, such off-chain
revocation can be committed towards multiple sets of honest "active" users.
Only one equivocating balance spend can succeed, letting the remaining set
of honest users still be deprived of their expected partitioned balances.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Alice contacts Bob to form a first partition, then Caroll to form a second
one, then Dave to form a last one. If she is successful in that
equivocation trick, she can *triple*-spend her balance against any goods or
out-of-pool payments.

Assuming the equivocation is discovered once realized, Bob, Caroll and Dave
are all left with a branch of transactions all including Alice's Withdraw
one. However only one branch can be fully published, as a Withdraw
transaction can be played only once following the pool semantic.
Game-theory-wise, Bob, Caroll and Dave have an interest to enter in a fee
race to be the first to confirm and earn the Alice balance spend.

The equivocation is only bounded by the maximal number of equivocating sets
one can form, namely the number of pool users. However, correction can only
be limited to the equivocated balance. Therefore, it appears that
corrective security models in the context of multi-party are always
producing an economic disequilibrium.

An extension of this corrective model could be to require off-pool
collaterals locked-up, against which the revocation secret would be
revealed at partition generation. However, this fix is limited to the
collateral liquidity available. One collateral balance should be guaranteed
for each potential victim, thus the collateral liquidity should be equal to
the number of pool users multiplied by the equivocatable balance amount.

It sounds like a more economic-efficient security model of the pool
partitioning can be established with a prophylactic technique.

# Trusted coordinator

A genuine solution could be to rely on a coordinator collecting the
partition declaration and order them canonically. The pool partition
candidates can then fetch them and decide their partitions acceptance
decisions on that. Of course, the coordinator is trusted and can drop or
dissimulate any partition, thus enabling partitioned balance equivocation.

# Trust-minimized : Partition Statements

A pool partition invalidity can be defined by the existence of two
second-layer Update transactions at the same state number spending the same
Withdraw transaction balance output. Each Update transaction signature can
be considered as a "partition statement". A user wishing to join a
partition should ensure there is no conflicting partition statement before
applying the partition to her local state.

The open question is from where the conflict should be observed. A
partition statement log could be envisioned and monitored by pool users
before to accept any partition.

I think multiple partition statement publication spaces can be drawn out,
with different trust-minization trade-offs.

# Publication space : Distributed Bulletin Boards

The set of "active" pool users could host their own boards of partition
statements. They would coordinate on the statement order through a
consensus algorithm (e.g Raft). For redundancy, a user can have multiple
board instances. If a user falls offline, they can fetch the statement
order from the other users boards.

However, while this solution distributes the trust across all the other
users, it's not safe in case of malicious user coalitions agreeing among
themselves to drop a partition statement. Therefore, a user catching up
online can be feeded with an incorrect view of the existing partitions, and
thus enter into an equivocated partition.

# Publication space : On-chain Authoritative Board

Another solution could be to designate an authoritative UTXO at pool setup.
This UTXO could be spent by any user of the pool set (1-of-N) to a
covenanted transaction sending back to a Taproot output with the same
internal key. The Merkelized tree tweaked could be modified by the spender
to stamp the partition statements as leaves hashes. The statement data is
not committed in the leaves itself and the storage can be delegated to
out-of-band archive servers.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Alice and Bob decide to start a partition, they commit a hash of the
partitioning Update transaction as a Taproot tree leaf and they spend the
pool authoritative UTXO. They also send a copy of the Update transaction to
an archive server.

At a later time, Alice proposes to Caroll to start a partition. Caroll
follows the chain of transactions forming the on-chain authoritative board,
she fetches the merkle branches and leaves data payload from an archive
server, verifying the authenticity of the branches and payload. As Alice
has already published a partition statement spending her Withdraw, Caroll
should refuse the partition proposal.

Even if a pool user goes offline, she can recover the correct partition
statement logs, as it has been committed in the chain from the
authoritative UTXO. If the statement data is not available from servers,
the pool user should not engage in partitions.

Assuming the spend confirms in every block, this solution enables
partitions every 10min. The cost can be shared across pool instances, if
the authoritative signers set is made of multiple pool instances signers
sets. A threshold signature scheme could be used to avoid interactivity
beyond the aggregated key setup. However, batching across pool instances
increases the set of data to verify by the partition candidate users, which
could be a grievance for bandwidth-constrained clients.

# Fiability of the Publication of Partition Statements

Whatever ends up being used as a partition statement log, there is still
the question of the incentives of pool users to publish the partition
statements. A malicious user could act in coalition with the equivocating
entity to retain the publication of her partition statement. Thus, an
honest user would only be aware of her own partition statement and accept
the partition proposal from the will-be equivocating entity.

I think that leveraging covenants a revocation mechanism could be attached
on any equivocating branch of transactions, allowing in the above case a
single honest user to punish the publication. While a revocation mechanism
does not work in case of multiple defrauded users, I believe the existence
of a revocation mechanism makes the formation of malicious coalitions
unsafe for their conjurers.

Indeed, any user entering in the coalition is not guaranteed to be blinded
to other equivocating branches generated by the partition initiator.
Therefore, the publication of a partition statement by everyone is
holistically optimal to discover any equivocating candidate among the pool
users.

Further research should establish the soundness of the partition statement
publication game-theory.

# Writing the Partition Statements to a new Consensus Data Structure

To avoid a solution relying on game-theory, a new consensus data structure
could be introduced to register and order the partition statements. This
off-chain contract register could be a Merkle tree, where every leaf is a
pool balance identified by a key. This register would be established
on-chain at the same time the pool is set up.

Every time the pool is partitioned, the tree leaves would be updated with
the partition statement committed to. Only one partition could be
registered per user by state number. The publication branch would be
invalid if it doesn't point back to the corresponding contract register
tree entries. When the first-layer pool Update transaction is replaced, the
tree should transition to a blank state too.

Beyond the high cost of yet-another softfork to introduce such consensus
data structure, the size of the witness to write into the contract register
could be so significant that the economic attractiveness of pool
partitioning is decreased in consequence.

If you have read so far, thank you. And curious if anyone has more ideas or
thoughts on  the high interactivity issue ?

Thanks Gleb for the review.

Cheers,
Antoine

[0] https://coinpool.dev/

--0000000000003b92e705ddb6c2cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>This post recalls the noticeable interactivity =
issue encumbering payment pools and channel factories in the context of a h=
igh number of participants, describes how the problem can be understood and=
 proposes few solutions with diverse trust-minizations and efficiency assum=
ptions. It is intended to capture the theoretical bounds of the &quot;inter=
activity issue&quot;, where technical completeness of the solutions is expo=
sed in future works.<br><br>The post assumes a familiarity with the CoinPoo=
l paper concepts and terminology [0].<br><br># The interactivity requiremen=
t grieving payment pools/channel factories<br><br>Payment pools and channel=
 factories are multi-party constructions enabling to share the ownership of=
 a single on-chain UTXO among many off-chain/promised balances. Payment poo=
l improves on the channel factory construction fault-tolerance by reducing =
the number of balance outputs disclosed=C2=A0 on-chain to a single one in c=
ase of unilateral user exits.<br><br>However, those constructions require a=
ll the users to be online and exchange rounds of signatures to update the b=
alance distribution. Those liveliness/interactivity requirements are increa=
sing with the number of users, as there are higher odds of *one* lazzy/bugg=
y/offline user stalling the pool/factory updates.<br><br>In echo, the desig=
n of LN was envisioned for a network of always-online/self-hosted participa=
nts, the early deployment of LN showed the resort to delegated channel host=
ing solutions, relieving users from the liveliness requirement. While the t=
rust trade-offs of those solutions are significant, they answer the reality=
 of a world made of unreliable networks and mobile devices.<br><br>Minding =
that observation, the attractiveness of pools/factories might be questioned=
.<br><br># The interactivity requirement palliatives and their limits<br><b=
r>Relatively straightforward solutions to lower the interactivity requireme=
nt, or its encumbered costs, can be drawn out. Pools/factories users could =
own (absolute) timelocked kick-out abilities to evict offline users who are=
 not present before expiration.<br><br>E.g, let&#39;s say you have Alice, B=
ob, Caroll and Dave as pool participants. Each of them owns a Withdraw tran=
saction to exit their individual balances at any time. Each user should hav=
e received the pre-signed components from the others guaranteeing the unila=
teral ability to publish the Withdraw.<br><br>A kick-out ability playable b=
y any pool user could be provided by generating a second set of Withdraw tr=
ansactions, with the difference of the nLocktime field setup to an absolute=
 height T + X, where T is the height at which the corresponding Update tran=
saction is generated and X the kick-out delay.=C2=A0 For this set of kick-o=
ut transactions, the complete witnesses should be fully shared among Alice,=
 Bob, Caroll and Dave. That way, if Caroll is unresponsive to move the pool=
 state forward after X, any one of Alice, Bob or Dave can publish the Carol=
l kick-out Withdraw transaction, and pursue operations without that unrespo=
nsive party.<br><br>While decreasing the interactivity requirement to the t=
imelock delay, this solution is constraining the kicked user to fallback on=
-chain encumbering the UTXO set with one more entry.<br><br>Another solutio=
n could be to assume the widespread usage of node towers among the pool par=
ticipants. Those towers would host the full logic and key state necessary t=
o receive an update request and produce a user&#39;s approval of it. As lon=
g as one tower instance is online per-user, the pool/factory can move forwa=
rd. Yet this is forcing the pool/factory user to share their key materials =
with potentially lower trusted entities, if they don&#39;t self-host the to=
wer instances.<br><br>Ideally, I think we would like a trust-minimized solu=
tion enabling non-interactive, off-chain updates of the pool/factory, with =
no or minimal consumption of blockspace.<br><br>For the remainder of this p=
ost, only the pool use-case will be mentioned. Though, I think the observat=
ions/implications can be extended to factories as well.<br><br># Non-intera=
ctive Off-chain Pool Partitions<br><br>If a pool update fails because of la=
ck of online unanimity, a partition request could be exchanged among the on=
line subset of users (&quot;the actives&quot;). They decide to partition th=
e pool by introducing a new layer of transactions gathering the promised/of=
f-chain outputs of the actives. The set of outputs belonging to the passive=
 users remains unchanged.<br><br>The actives spend their Withdraw transacti=
ons `user_balance` outputs back to a new intermediate Update transaction. T=
his &quot;intermediate&quot; Update transaction is free to re-distribute th=
e pool balances among the active users. To guarantee the unilateral withdra=
w ability of a partitioned-up balance, the private components of the partit=
ioned Withdraw transactions should be revealed among the set of active user=
s.<br><br>E.g, let&#39;s say you have Alice, Bob, Caroll and Dave as pool p=
articipants. Pool is at state N, Bob and Dave are offline. Alice and Caroll=
 agree to partition the pool, each of them owns a Withdraw transaction read=
y-to-be-attached on the Update transaction N. They generate a new partition=
ing Update transaction with two inputs spending respectively Alice&#39;s Wi=
thdraw transaction `user_balance` output and Caroll&#39;s Withdraw transact=
ion `user-balance` output. From this partitioning Update transaction, two n=
ew second-layer Withdraw ones are issued.<br><br>Alice and Caroll reveal to=
 each other the private components of their first-layer Withdraw transactio=
ns, allowing to publish the full branch : first-layer Update transaction, f=
irst-layer Withdraw transactions, second-layer partitioning Update transact=
ion, second-layer partitioned Withdraw transaction. At that step, I think t=
he partitioning should be complete.<br><br>Quickly, a safety issue arises w=
ith pool partitioning. A participant of the active set A could equivocate t=
he partition state by signing another spend of her Withdraw transaction all=
ocating her balance to an Update transaction of a &quot;covert&quot; set of=
 active users B.<br><br>This equivocation exists because there is no orderi=
ng of the off-chain spend of the Withdraw transactions and any Withdraw tra=
nsaction can be freely spent by its owner. This issue appears as similar to=
 solving the double-spend problem.<br><br>Equivocation is a different case =
than multiple *parallel* partitions, where there is no intersection between=
 the partitioned balances. The parallel partitions are still rooting from t=
he same Update transaction N. I think the safety of parallel partitions is =
yet to be explored.<br><br># Current solutions to the double-spend problem =
: Bitcoin base-layer &amp; Lightning Network<br><br>Of course, the double-s=
pend issue is already addressed on the Bitcoin base-layer due to nodes cons=
ensus convergence on the most-proof-of-work accumulated valid chain of bloc=
ks. While reorg can happen, a UTXO cannot be spent twice on the same chain.=
 This security model can be said to be prophylactic, i.e an invalid block c=
annot be applied to a node&#39;s state and should be rejected.<br><br>The d=
ouble-spend issue is also solved in its own way in payment channels. If a t=
ransaction is published, of which the correctness has been revoked w.r.t ne=
gotiated, private channel state, the wronged channel users must react in co=
nsequence. This security model can be said to be corrective, states updates=
 are applied first on the global ledger then eventually corrected.<br><br>A=
 solution to the pool partition equivocation issue appears as either based =
on a prophylactic one or a corrective security model.<br><br>Let&#39;s exam=
ine first, a reactive security model similar to LN-Penalty. At pool partiti=
on proposals, the owners of the partitioned-up Withdraw transactions could =
reveal a revocation secret enabling correction in case of wrongdoing (e.g s=
ingle-show signatures). However, such off-chain revocation can be committed=
 towards multiple sets of honest &quot;active&quot; users. Only one equivoc=
ating balance spend can succeed, letting the remaining set of honest users =
still be deprived of their expected partitioned balances.<br><br>E.g, let&#=
39;s say you have Alice, Bob, Caroll and Dave as pool participants. Alice c=
ontacts Bob to form a first partition, then Caroll to form a second one, th=
en Dave to form a last one. If she is successful in that equivocation trick=
, she can *triple*-spend her balance against any goods or out-of-pool payme=
nts.<br><br>Assuming the equivocation is discovered once realized, Bob, Car=
oll and Dave are all left with a branch of transactions all including Alice=
&#39;s Withdraw one. However only one branch can be fully published, as a W=
ithdraw transaction can be played only once following the pool semantic. Ga=
me-theory-wise, Bob, Caroll and Dave have an interest to enter in a fee rac=
e to be the first to confirm and earn the Alice balance spend.<br>=C2=A0<br=
>The equivocation is only bounded by the maximal number of equivocating set=
s one can form, namely the number of pool users. However, correction can on=
ly be limited to the equivocated balance. Therefore, it appears that correc=
tive security models in the context of multi-party are always producing an =
economic disequilibrium.<br><br>An extension of this corrective model could=
 be to require off-pool collaterals locked-up, against which the revocation=
 secret would be revealed at partition generation. However, this fix is lim=
ited to the collateral liquidity available. One collateral balance should b=
e guaranteed for each potential victim, thus the collateral liquidity shoul=
d be equal to the number of pool users multiplied by the equivocatable bala=
nce amount.<br><br>It sounds like a more economic-efficient security model =
of the pool partitioning can be established with a prophylactic technique.<=
br><br># Trusted coordinator<br><br>A genuine solution could be to rely on =
a coordinator collecting the partition declaration and order them canonical=
ly. The pool partition candidates can then fetch them and decide their part=
itions acceptance decisions on that. Of course, the coordinator is trusted =
and can drop or dissimulate any partition, thus enabling partitioned balanc=
e equivocation.<br><br># Trust-minimized : Partition Statements<br><br>A po=
ol partition invalidity can be defined by the existence of two second-layer=
 Update transactions at the same state number spending the same Withdraw tr=
ansaction balance output. Each Update transaction signature can be consider=
ed as a &quot;partition statement&quot;. A user wishing to join a partition=
 should ensure there is no conflicting partition statement before applying =
the partition to her local state.<br><br>The open question is from where th=
e conflict should be observed. A partition statement log could be envisione=
d and monitored by pool users before to accept any partition.<br><br>I thin=
k multiple partition statement publication spaces can be drawn out, with di=
fferent trust-minization trade-offs.<br><br># Publication space : Distribut=
ed Bulletin Boards<br><br>The set of &quot;active&quot; pool users could ho=
st their own boards of partition statements. They would coordinate on the s=
tatement order through a consensus algorithm (e.g Raft). For redundancy, a =
user can have multiple board instances. If a user falls offline, they can f=
etch the statement order from the other users boards.<br><br>However, while=
 this solution distributes the trust across all the other users, it&#39;s n=
ot safe in case of malicious user coalitions agreeing among themselves to d=
rop a partition statement. Therefore, a user catching up online can be feed=
ed with an incorrect view of the existing partitions, and thus enter into a=
n equivocated partition.<br><br># Publication space : On-chain Authoritativ=
e Board<br><br>Another solution could be to designate an authoritative UTXO=
 at pool setup. This UTXO could be spent by any user of the pool set (1-of-=
N) to a covenanted transaction sending back to a Taproot output with the sa=
me internal key. The Merkelized tree tweaked could be modified by the spend=
er to stamp the partition statements as leaves hashes. The statement data i=
s not committed in the leaves itself and the storage can be delegated to ou=
t-of-band archive servers.<br><br>E.g, let&#39;s say you have Alice, Bob, C=
aroll and Dave as pool participants. Alice and Bob decide to start a partit=
ion, they commit a hash of the partitioning Update transaction as a Taproot=
 tree leaf and they spend the pool authoritative UTXO. They also send a cop=
y of the Update transaction to an archive server.<br><br>At a later time, A=
lice proposes to Caroll to start a partition. Caroll follows the chain of t=
ransactions forming the on-chain authoritative board, she fetches the merkl=
e branches and leaves data payload from an archive server, verifying the au=
thenticity of the branches and payload. As Alice has already published a pa=
rtition statement spending her Withdraw, Caroll should refuse the partition=
 proposal.<br><br>Even if a pool user goes offline, she can recover the cor=
rect partition statement logs, as it has been committed in the chain from t=
he authoritative UTXO. If the statement data is not available from servers,=
 the pool user should not engage in partitions.<br><br>Assuming the spend c=
onfirms in every block, this solution enables partitions every 10min. The c=
ost can be shared across pool instances, if the authoritative signers set i=
s made of multiple pool instances signers sets. A threshold signature schem=
e could be used to avoid interactivity beyond the aggregated key setup. How=
ever, batching across pool instances increases the set of data to verify by=
 the partition candidate users, which could be a grievance for bandwidth-co=
nstrained clients.<br><br># Fiability of the Publication of Partition State=
ments<br><br>Whatever ends up being used as a partition statement log, ther=
e is still the question of the incentives of pool users to publish the part=
ition statements. A malicious user could act in coalition with the equivoca=
ting entity to retain the publication of her partition statement. Thus, an =
honest user would only be aware of her own partition statement and accept t=
he partition proposal from the will-be equivocating entity.<br><br>I think =
that leveraging covenants a revocation mechanism could be attached on any e=
quivocating branch of transactions, allowing in the above case a single hon=
est user to punish the publication. While a revocation mechanism does not w=
ork in case of multiple defrauded users, I believe the existence of a revoc=
ation mechanism makes the formation of malicious coalitions unsafe for thei=
r conjurers.<br><br>Indeed, any user entering in the coalition is not guara=
nteed to be blinded to other equivocating branches generated by the partiti=
on initiator. Therefore, the publication of a partition statement by everyo=
ne is holistically optimal to discover any equivocating candidate among the=
 pool users.<br><br>Further research should establish the soundness of the =
partition statement publication game-theory.<br><br># Writing the Partition=
 Statements to a new Consensus Data Structure<br><br>To avoid a solution re=
lying on game-theory, a new consensus data structure could be introduced to=
 register and order the partition statements. This off-chain contract regis=
ter could be a Merkle tree, where every leaf is a pool balance identified b=
y a key. This register would be established on-chain at the same time the p=
ool is set up. <br><br>Every time the pool is partitioned, the tree leaves =
would be updated with the partition statement committed to. Only one partit=
ion could be registered per user by state number. The publication branch wo=
uld be invalid if it doesn&#39;t point back to the corresponding contract r=
egister tree entries. When the first-layer pool Update transaction is repla=
ced, the tree should transition to a blank state too.<br><br>Beyond the hig=
h cost of yet-another softfork to introduce such consensus data structure, =
the size of the witness to write into the contract register could be so sig=
nificant that the economic attractiveness of pool partitioning is decreased=
 in consequence.<br><br>If you have read so far, thank you. And curious if =
anyone has more ideas or thoughts on=C2=A0 the high interactivity issue ?<b=
r><br>Thanks Gleb for the review.<br><br>Cheers,<br>Antoine<br><br>[0] <a h=
ref=3D"https://coinpool.dev/">https://coinpool.dev/</a><br></div>

--0000000000003b92e705ddb6c2cd--