Author: Antoine Riard 2022-05-10 00:38:36
Published on: 2022-05-10T00:38:36+00:00
The email conversation between Antoine and Billy revolves around the challenges of partitioning multi-party constructions and preventing double-spending. Billy suggests two possible solutions, creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, they agree that equivocation is still a hard issue with partitioning multi-party constructions.Billy also shares his idea of offline lightning receiving, which involves each lightning node in a channel having two separate keys: a spending-key and a receiving-key. He suggests enabling the logic of ensuring the state is more favorable with an on-chain mechanism. The receiving-key would sign receiving transactions that are only valid when the most recent state signed by the spending-key is also included in the script sig in some way.The bitcoin-dev mailing list has discussed the interactivity issue affecting payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. One solution proposed is non-interactive off-chain pool partitions, where 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. A safety issue arises with pool partitioning where 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. Several publication spaces can be drawn out, with different trust-minimization trade-offs. Multiple partition statement publication spaces can be drawn out, with different trust-minimization trade-offs.The context also discusses the process of partitioning in a Bitcoin mining pool. Alice and Bob initiate the process by committing a hash of the partitioning update transaction as a Taproot tree leaf and spending the pool authoritative UTXO, sending a copy to an archive server. Later, when Alice proposes to Caroll to start a partition, Caroll follows the chain of transactions forming the on-chain authoritative board, fetching the merkle branches and leaves data payload from an archive server to verify authenticity. The cost can be shared across pool instances if the authoritative signers set is made of multiple pool instances signer sets.To avoid 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. 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.
Updated on: 2023-06-15T19:56:44.191960+00:00