Conjectures on solving the high interactivity issue in payment pools and channel factories



Summary:

The post addresses the issue of interactivity in payment pools and channel factories with a high number of participants. As the number of users increases, the liveliness/interactivity requirements also increase because one lazy/buggy/offline user can stall pool/factory updates for everyone else. Various solutions to lower the interactivity requirement or its costs can be drawn out, and it is desirable to have a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory.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. However, 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.The post also discusses a potential security issue in pool partitioning where a user can triple-spend their balance against any goods or out-of-pool payments by forming multiple partitions with different users. Proposed solutions include a trusted coordinator, trust-minimized partition statements, distributed bulletin boards, and on-chain authoritative boards. The incentives of pool users to publish partition statements are also discussed, and a revocation mechanism is proposed as a solution.Another potential solution is to introduce a new consensus data structure to register and order the partition statements, but this may be costly and decrease the economic attractiveness of pool partitioning. 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. The double-spend issue is also solved in its own way in payment channels.


Updated on: 2023-05-22T19:48:25.961373+00:00