This may seem far-fetched but I do think it applies:
Suppose loopId's have long been established, and two loops are competing with each other over a shared sections:
<<<<<<
v ^
v loop 1 ^
v ^
>>>>>> <- shared section
^ v
^ loop 2 v
^ v
<<<<<<
A node that's part of loop 1 could spam fake packets with loopId 2 into the shared section, thus making loopId 2 almost unusable, and directing more traffic to itself.
This is the equivalent of the 'make your competitor look bad' attack which is a known problem in Interledger connector design.
I can think of two ways to solve it:
stick to hashlocks, and use asymmetric signatures on top.
use asymmetric signatures instead of preimage hashes. they are slightly more expensive to check, and it's slightly more cumbersome that you need to communicate the pubkey alongside the puzzle in the crypto condition, and they require an extra mechanism for master-selection when the loop master goes down (e.g. create a new loopId that refers to the one that stopped streaming because its loop master went down)
Since LedgerLoops is designed from scratch (not on top of existing ledgers which may support hashlock checks but not signature checks), I think for LedgerLoops the second option is better. (for Interledger, I could imagine the first option turns out to be better).
This may seem far-fetched but I do think it applies:
Suppose loopId's have long been established, and two loops are competing with each other over a shared sections:
A node that's part of loop 1 could spam fake packets with loopId 2 into the shared section, thus making loopId 2 almost unusable, and directing more traffic to itself.
This is the equivalent of the 'make your competitor look bad' attack which is a known problem in Interledger connector design.
I can think of two ways to solve it:
stick to hashlocks, and use asymmetric signatures on top.
use asymmetric signatures instead of preimage hashes. they are slightly more expensive to check, and it's slightly more cumbersome that you need to communicate the pubkey alongside the puzzle in the crypto condition, and they require an extra mechanism for master-selection when the loop master goes down (e.g. create a new loopId that refers to the one that stopped streaming because its loop master went down)
Since LedgerLoops is designed from scratch (not on top of existing ledgers which may support hashlock checks but not signature checks), I think for LedgerLoops the second option is better. (for Interledger, I could imagine the first option turns out to be better).