Author: David A. Harding 2016-11-11 12:19:07
Published on: 2016-11-11T12:19:07+00:00
In a mailing list discussion, a potential denial-of-service attack was brought up where an attacker could send large transactions to themselves over a long route and let them time out to lock up a lot of funds. To mitigate this, nodes could require either a fast commit or roll-back within a short amount of time (e.g. 30 seconds) or a proof that another channel was closed. This proposal limits the freedom in channel design to a design space that can be understood by all nodes in the network, which interferes with the vision of a heterogeneous network. However, it was pointed out that this mitigation proposal does not necessarily require a homogeneous network as only direct peers need to receive a commit, roll-back or channel close proof. For example, if Zed routes through Alice who routes through Bob, Zed only needs to understand Alice's proofs, which could be for a different network or network protocol than what Bob is using. Several examples were given of things that would become impossible or difficult to accomplish with this proposal in place. One such example was transparent routing between side chains where nodes that don't know about a certain side chain can't verify a channel close on that side chain. Another example was trust-free decentralized exchange between different block chains, where different block chains have the same story. However, individual negotiation between peers about what blockchains they support provides for heterogeneity among client implementations. In terms of channel design upgrades, peers can declare what protocol designs/versions they support, with any peer needing to match the version only among its peers, not among the whole route. Provided compatible hashlock mechanisms are used, this would be a constraint on upgrading in any case.
Updated on: 2023-05-24T00:46:53.654508+00:00