From rusty at rustcorp.com.au  Thu Aug 12 05:04:58 2021
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Thu, 12 Aug 2021 14:34:58 +0930
Subject: [Lightning-dev] Turbo channels spec?
In-Reply-To: <871r8lcjz9.fsf@rustcorp.com.au>
References: <871r8lcjz9.fsf@rustcorp.com.au>
Message-ID: <87y29745j9.fsf@rustcorp.com.au>

Sorry this took so long.

https://github.com/lightningnetwork/lightning-rfc/pull/895

This changed quite a bit, based on discussion here and more coherent
thinking.

1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust the
   other side.  Without that, you can neither accept payments nor route
   them; in theory if they used push_msat you could send payments out,
   but that seems a niche case.
3. We do want to know the short_channel_id they're going to use for the
   channel, so we can add it to routehints for incoming payments.

Adding the scid is nice anyway, for chainsplit scenarios.

Here is the new text, a little formatted:

	1. `tlv_stream`: `funding_locked_tlvs`
	2. types:
	    1. type: 1 (`short_channel_id`)
	    2. data:
	        * [`short_channel_id`:`short_channel_id`]
 
        #### Requirements

        The sender:
...
         - SHOULD set `short_channel_id`

         - if it is the sole contributor to the funding transaction, or
           has reason to trust the peer:

            - MAY send `funding_locked` before the funding transaction
              has reached `minimum_depth`
        	- MAY set `short_channel_id` to a fake value, if it will
                  route payments to that `short_channel_id`.
          - otherwise:
            - MUST wait until the funding transaction has reached
              `minimum_depth` before sending this message.

          - SHOULD re-transmit `funding_locked` if the
            `short_channel_id` for this chanel has changed.
...
        The receiver:
          - SHOULD ignore the `funding_locked` if it knows the
            `short_channel_id` of the channel and it differs from the
            value in `funding_locked`.

...

        Nodes which have funded the channel or trust their peers to have done,
        can simply start using the channel instantly by sending
        `funding_locked`.  This raises the problem of how to use this new
        channel in route hints, since it does not yet have a block number.
        For this reason, a convincing fake number can be use; when the real
        funding transaction is finally mined, it can re-send `funding_locked`
        with the real value.