Date: Thu, 23 Apr 2020 04:50:09 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
In-Reply-To: <4def6907-d380-c053-d361-5a7f12202b34@mattcorallo.com>
References: <CAO3Pvs8Dx8ATXfQRA3p7DzzHcYZz1nF4g=+ZHvSukL0jMbxAOw@mail.gmail.com>
 <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com>
 <CAO3Pvs_hNhEjX_tAatnij-4vd1cgPk8DPxOdrgDVuia7h=z5UQ@mail.gmail.com>
 <4def6907-d380-c053-d361-5a7f12202b34@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
Precedence: list

Good morning lists et al,

Let me try to summarize things a little:

* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blockson=
ly` mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sending an `e=
rror` message, which will usually cause the other side to drop the channel =
onchain using its commitment transaction.
* The dropped B<->C channel has an HTLC (that was set up during the A->B->C=
 forwarding).
* The HTLC, being used in a Poon-Dryja channel, actually has the following =
contract text:
  * The fund may be claimed by either of these clauses:
    * C can claim, if C shows the preimage of some hash H (hashlock branch)=
.
    * B and C must agree, and claim after time L (timelock branch).
* B holds a signature from C that can claim the timelock branch of the HTLC=
, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIF=
Y`.
  * The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate.
* C can "pin" the HTLC output by spending using the hashlock branch, and cr=
eating a large fee, low fee-rate (tree of) transactions.
  * As it is a low fee-rate, miners have no incentive to put this in a bloc=
k, especially if unrelated higher-fee-rate transactions exist that would ea=
rn them more money.
  * Even in a full RBF universe, because of the anti-DoS mempool rules, B c=
annot evict this pinned transaction by just bidding up the feerate.
    * A replacing transaction cannot evict alternatives unless its absolute=
 fee is greater than the absolute fee of the alternative.
    * The pinning transaction has a high fee, but is blockspace-wasteful, s=
o it is:
      * Undesirable to mine (low feerate).
      * Difficult to evict (high fee).
* Thus, B is unable to get its timelock-branch transaction in the mempools =
of miners.
* C waits until the A->B HTLC times out, then:
  * C directly contacts miners with an out-of-band proposal to replace its =
transaction with an alternative that is much smaller and has a low fee, but=
 much better feerate.
  * Miners, being economically rational, accept this proposal and include t=
his in a block.

The proposal by Matt is then:

* The hashlock branch should instead be:
  * B and C must agree, and show the preimage of some hash H (hashlock bran=
ch).
* Then B and C agree that B provides a signature spending the hashlock bran=
ch, to a transaction with the outputs:
  * Normal payment to C.
  * Hook output to B, which B can use to CPFP this transaction.
  * Hook output to C, which C can use to CPFP this transaction.
* B can still (somehow) not maintain a mempool, by:
  * B broadcasts its timelock transaction.
  * B tries to CPFP the above hashlock transaction.
    * If CPFP succeeds, it means the above hashlock transaction exists and =
B queries the peer for this transaction, extracting the preimage and claimi=
ng the A->B HTLC.

Is that a fair summary?

--

Naively, and remembering I am completely ignorant of the exact details of t=
he mempool rules, it seems to me quite strange that we are allowing an unde=
sirable transaction (tree) into the mempool:

* Undesirable to mine (low fee-rate).
* Difficult to evict (high fee).

Miners are not interested in low fee-rate transactions, as long as higher f=
ee-rate transactions exist.
And being difficult to evict means miners cannot get alternatives that are =
more lucrative for them.

The reason (as I understand it) eviction is purposely made difficult here i=
s to prevent certain DoS attacks on Bitcoin nodes, specifically:

1. Attacker sends a low fee-rate tx as a "root" transaction.
2  Attacker sends thousands of low fee-rate tx that build off the above roo=
t.
3. Attacker sends a slightly higher fee-rate alternative to the root, evict=
ing the above tree of txes.
4. Attacker sends thousands of low fee-rate tx that build off the latest ro=
ot.
5. GOTO 3.

However, it seems to me, naively, that "an ounce of prevention is worth a p=
ound of cure".

As I understand it, the mempool is organized already into "packages" of tra=
nsactions, and adding a transaction into the mempool involves extending and=
 merging packages.
Perhaps the size of a package with low fee-rate (relative to the other pack=
ages in the mempool) can be limited, so that mempools drop incoming txes th=
at extend a low-fee-rate tree of transactions.
This means an attacker cannot send thousands of low fee-rate tx that build =
off some low fee-rate root tx in the first place, so it can still be evicte=
d easily later without much impact.

Naively, it seems to me to prevent the DoS attack as well, as at step 2 it =
would be prevented from sending thousands of low fee-rate tx building off t=
he root.

As well, as I understand it, this merely tightens the mempool acceptance ru=
les, preventing low fee-rate packages from growing (analogous to a consensu=
s-layer softfork).
The "cannot evict high absolute fee" rule can be retained, as the low-fee-r=
ate package is prevented from reaching a large size.

Would that be workable as a general solution to solve (what I think is) the=
 root cause of this problem?

(This assumes full RBF, I suppose.)

Regards,
ZmnSCPxj