Pay your own fees, so the peer will sign without caring.  Even if it doesn't relay.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The shutdown section says:

```
  - MUST NOT send multiple `shutdown` messages.
```

But the reconnection section says:

```
  - upon reconnection:
    - if it has sent a previous `shutdown`:
      - MUST retransmit `shutdown`.
```

So clearly, remove the former.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

* Adds both directions to the diagram.
* Rename closee_output to has_closee_output.
* Refer explicitly to BOLT 3 for "null output" defn.
* Pad the OP_RETURN to make 65 bytes.

More MUST, less SHOULD.

You have to give them something which will propagate.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…output.

If both are dust, you should lowball fees.  The next patch adds OP_RETURN
as a valid shutdown scriptpubkey though if you really want to do this.

This also addresses the case where people send a new `shutdown` with a *different* scriptpubkey.  This could previously cause a race where you receive a bad signature (because it hasn't received the updated shutdown), so we ignore these cases.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This gets around "but both our outputs are dust!" problems, as
recommended by Anthony Towns.

I hope I interpreted the standardness rules correctly (technically,
you can have multiple pushes in an OP_RETURN as long as the total is
under 83 bytes, but let's keep it simple).

Add an explicit note that "OP_RETURN" is never considered "uneconomic".

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

- Make it clear why the OP_RETURN restrictions have two forms.
- Cross-reference existing dust threshold
- Lots of typo fixes
- Don't set closer_and_closee if we're larger/equal, and closee is dust.
- Remove Rationale on delete zero-output tx hack.

We don't care, as long as it's RBF-able.  This will be nicer for
Taproot when mutual closes are otherwise indistinguishable from normal
spends.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>