From dave at dtrt.org  Fri Nov 11 12:19:07 2016
From: dave at dtrt.org (David A. Harding)
Date: Fri, 11 Nov 2016 07:19:07 -0500
Subject: [Lightning-dev] Analysis: alternative DoS prevention concept
In-Reply-To: <1478819514.1752.63.camel@ultimatestunts.nl>
References: <1478819514.1752.63.camel@ultimatestunts.nl>
Message-ID: <20161111121907.GA1860@fedora-23-dvm>

On Fri, Nov 11, 2016 at 12:11:54AM +0100, CJP wrote:
> [...] possible for the attacker by sending many large transactions to
> himself, over a long route, and letting them time out [...] a lot of
> funds get locked up, and the total cost of lost opportunity to
> innocent nodes is a lot higher than that of the attacker.
>
> [...] a solution for this DoS mode [is] where nodes require either a
> fast commit or roll-back within a short amount of time (say 30
> seconds), or a proof that another channel was closed
>
> [...] This basically limits the freedom in channel design to a design
> space that can be understood by all nodes in the network.

> Instead of being an individual decision between two peers, channel
> design now becomes a collective network decision.  This interferes
> with my vision, presented in Montreal, of a heterogeneous network. 

I'm trying to reason about this, and I may have made a mistake, but I
don't think this DoS mitigation proposal requires a homogeneous network
because the only person from which you need to receive a (1) commit, (2)
roll-back, or (3) channel close proof is your direct peer---so as long
as your direct peer knows how to read the channel close proofs you
provide them, you can use any style channel close proofs you want.

So if we have Alice routing through Bob,

    Alice -> Bob -> ?

Alice has to understand whatever proofs Bob gives her.  But if Zed
routes through Alice (who routes through Bob),

    Zed -> Alice -> Bob -> ?

Then Zed doesn't need to understand Bob's proofs; he only needs to
understand Alice's proofs, which could be for a different network or
network protocol than what Bob's using.

To be more specific, I'll work your examples below.

> Some examples of things that will become impossible, or very difficult
> to accomplish:
> * Transparent routing between side chains: nodes that don't know about a
> certain side chain can't verify a channel close on that side chain.
> * Trust-free de-centralized exchange between different block chains:
> different block chains, so same story.

Let's imagine the following route:

    [......bitcoin....] | [FooChain]
                        |
    Zed -> Alice -> Bob | Bob -> ?

1. Zed tells Alice that he only knows about Bitcoin, and routes the
   payment through her.

2. Alice tells Bob that she knows about Bitcoin as well as FooChain, and
   routes the payment through him.

3. Bob has channels open both on Bitcoin and FooChain, and he routes the
   payment to one of his peers on FooChain.

If,

  a: Bob's peer tarpits the payment, Bob can close his FooChain channel
     and show the proof to Alice (who knows about FooChain and can
     understand the transaction).

  Or,

  b: Bob tarpits the the payment, Alice can close her Bitcoin channel to
     Bob and show the proof to Zed (who doesn't need to know anything about
     FooChain).

  Or,

  c: If Alice tarpits the payment, Zed can close his channel to Alice.

So, in this case, we have individual negotiation between peers about what
blockchains they support, providing for heterogeneity among client
implementations.

> * Trust-free de-centralized exchange of different assets on the same
> block chain (e.g. colored coins): other nodes might reject this if they
> don't understand the amount locked in the HTLC.

I think this is the same story as above except instead of having assets
on both Bitcoin and FooChain, Bob has both satoshis and another
blockchain asset ("footoshis").

    [.....satoshis....] | [footoshis]
                        |
    Zed -> Alice -> Bob | Bob -> ?

> * Channel design upgrade: we're probably first going to deploy Rusty's
> channel design; I suppose some variation of the Poon/Dryja design will
> have benefits over Rusty's design, once Bitcoin is ready for it. I
> expect there will probably be other channel design upgrades in the
> future.

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, which
would be a constraint on upgrading in any case).

    Zed ->  Alice  -> Bob -> ?
    [v1]   [v1,v2]    [v2]

For example, Zed may only understand protocol version 1 (v1), while
Alice understand both v1 and v2, and Bob only understands v2.

-Dave