Hi John, Thanks for the read!
> Agreed that signing updates and monitoring the blockchain both create always-online requirements that are not compatible with casual users' desires. I think > it's helpful to separate these two cases, as they affect different parties and their solutions differ. > In particular, limited availability to sign updates affects one's partners and can be addressed by having fewer partners, not partnering with casual users, evicting > unresponsive users, etc. > Limited availability to monitor the blockchain affects the security of one's own funds and can be addressed by increasing one's safety parameters (such as the > to_self_delay parameter in Lightning). Yes, I think effectively the logical coordination of the signed off-chain updates and the chain monitoring is defining the problem space. Of course, there is the solution of having less off-chain partners and bumping safety timelocks. Though here I think it comes at the downside of more UTXO storage requirements for base-layer nodes and an average increase in the price of liquidity for LN users due to more extensive timevalue. I think an intermediary solution can be to make the signing updates (and the fraud proofs or "partition statements" in the post) a structure enforceable by Bitcoin Script in a way than all the "revoked" on-chain partitions can be punished, like with some OP_MERKLE_ADD/TAPROOT_LEAF_UPDATE_VERIFY to ensure the cheater cannot escape the clawback ? > I would argue that we want a completely trust-free solution, if at all possible, while respecting users' actual availability. > We should only consider solutions that require trust if we can't find a trust-free solution that meets all other requirements. I would love to find a completely trust-free solution. One of the hard things is defining trust :) Note, as soon as you start to consider off-chain Bitcoin trust models you have a multi-dimensional risks model to solve e.g miners incentives, network connectivity, mempools congestion, proactive security of your threshold signing shares in face of your counterparty liveliness, consensus upgrades altering network-wide transaction-relay rules, ... > Actually, there's a third class of solutions that are possible, namely ones that use separate control transactions and value transactions (where the value > transactions "spend", and therefore depend on, the control transactions). > If an invalid control transaction is put on-chain, it can be blocked by another user by spending its output(s) before the output(s) can affect the value transaction. > Thus, control transactions can be viewed as proposals for state updates, and those proposals are blocked if they aren't valid. > These solutions differ from prophylactic solutions, as they allow incorrect transactions to be put on-chain and require another user to block them. > They also differ from your definition of a corrective security model, as they never allow the state update to be applied to the value in the channel or pool, so > there's nothing to be corrected. > An example of this third class of solutions is the Tunable-Penalty Factory protocol [1]. > Of course, this example was not available when you noted that solutions are either prophylactic or corrective. FYI, I think the idea of separating control transactions and value transactions (as done in electronic engineering between control signal and actual voltage) has been explored in the past [0]. I still believe this family of solutions can be fitted in the corrective class, as you have an invalid control transaction that can be corrected by another *valid* control transaction, and I still think it's incentive-based as there is a risk of the valid control transaction never confirming ? Or the funds getting frozen due to a miscellaneous broadcast? > On the other hand, protocols that use separate control and value transactions do not have this limitation. > For example, the Tunable-Penalty Factory protocol is a multi-party protocol in which every dishonest party is penalized and there is no economic disequilibrium. Yes, I think this is a good observation. For the partitioned-payment pool this can be corrected by ensuring only the honest party can enforce the partitioned statement and you have to timestamp them in the chain for Bitcoin Script itself to order them, I think. Do the Tunable-Penalty Factory protocol have any "partition-throughput" limit due to a subsidiary reliance on the chain or the liveliness of the N counterparties ? > If I understand this correctly, I think a penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition. > Consider the case where Alice is an honest user who joins a partition with Bob, where Bob and Carol are in a malicious coalition. > Alice believes she has pooled her funds with Bob's and so she is able to work with Bob to implement an off-line update of their balances, with Alice believing > that she has gained ownership over some of Bob's funds. > However, when the partitioning Update transaction that joins Alice's and Bob's funds is put on-chain, Carol pretends to have been "wronged" by Bob and uses > the penalty mechanism to seize Bob's funds. > In this case, Alice won't be able to get the funds that she thought she had obtained from Bob. Yes you need to order the "partition-statements" otherwise you're falling on this issue and the ordering happening in a proof-of-non-publication space, I think [1]. Best, Antoine [0] https://rubin.io/talks/2017/01/26/multi-txn-contracts/ [1] https://petertodd.org/2016/state-machine-consensus-building-blocks Le ven. 17 mars 2023 à 20:55, jlspc <jl...@protonmail.com> a écrit : > Hi Antoine, > > Thanks for your insightful post on the interactivity issue. > > Some thoughts are inline below. > > > 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. > > Agreed that signing updates and monitoring the blockchain both create > always-online requirements that are not compatible with casual users' desires. > I think it's helpful to separate these two cases, as they affect different > parties and their solutions differ. > In particular, limited availability to sign updates affects one's partners > and can be addressed by having fewer partners, not partnering with casual > users, evicting unresponsive users, etc. > Limited availability to monitor the blockchain affects the security of one's > own funds and can be addressed by increasing one's safety parameters (such as > the to_self_delay parameter in Lightning). > > > 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. > > I would argue that we want a completely trust-free solution, if at all > possible, while respecting users' actual availability. > We should only consider solutions that require trust if we can't find a > trust-free solution that meets all other requirements. > > > 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. > > > 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. > > Actually, there's a third class of solutions that are possible, namely ones > that use separate control transactions and value transactions (where the > value transactions "spend", and therefore depend on, the control > transactions). > If an invalid control transaction is put on-chain, it can be blocked by > another user by spending its output(s) before the output(s) can affect the > value transaction. > Thus, control transactions can be viewed as proposals for state updates, and > those proposals are blocked if they aren't valid. > > These solutions differ from prophylactic solutions, as they allow incorrect > transactions to be put on-chain and require another user to block them. > They also differ from your definition of a corrective security model, as they > never allow the state update to be applied to the value in the channel or > pool, so there's nothing to be corrected. > An example of this third class of solutions is the Tunable-Penalty Factory > protocol [1]. > Of course, this example was not available when you noted that solutions are > either prophylactic or corrective. > > > 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. > > > 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. > > On the other hand, protocols that use separate control and value transactions > do not have this limitation. > For example, the Tunable-Penalty Factory protocol is a multi-party protocol > in which every dishonest party is penalized and there is no economic > disequilibrium. > > > 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. > > If I understand this correctly, I think a penalty mechanism that allows a > "wronged" user to take some or all of a dishonest user's funds could be > exploited by a malicious coalition. > Consider the case where Alice is an honest user who joins a partition with > Bob, where Bob and Carol are in a malicious coalition. > Alice believes she has pooled her funds with Bob's and so she is able to work > with Bob to implement an off-line update of their balances, with Alice > believing that she has gained ownership over some of Bob's funds. > However, when the partitioning Update transaction that joins Alice's and > Bob's funds is put on-chain, Carol pretends to have been "wronged" by Bob and > uses the penalty mechanism to seize Bob's funds. > In this case, Alice won't be able to get the funds that she thought she had > obtained from Bob. > > Does that make sense? > > Regards, > John > > [1] Law, "Efficient Factories For Lightning Channels", available at > https://github.com/JohnLaw2/ln-efficient-factories. > > > > > Sent with Proton Mail <https://proton.me/> secure email. > > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
