Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

[Matt Corallo <lf-lists@mattcorallo.com>]

Yep! That is the attack I had in mind - just in general any time you have a non-relative time limit (ie an HTLC) for
confirmation, relay attacks become critical and its no longer just about revocation (which is fine when your time limit
is CSV-based).

In general, SIGHASH_NOINPUT makes these issues much, much simpler to address, but only if we assume that nodes can
somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else
in the mempool already spends (potentially a different input than the relaying node thinks the transaction should
spend). While ideally we'd be able to shove that (significant) complexity into the Bitcoin P2P network, that may not be
feasible, but we could imagine a relay network of lightning nodes doing that calculation and then passing the
transactions to their local full nodes.

Given such an overlay network would represent an increase in local mempool fees, it is not unreasonable to expect at
least some miners to run a local node which can submit such transactions to their template-generating nodes.

Matt

On 8/4/20 10:59 AM, ZmnSCPxj wrote:
> Good morning Matt,
> 
>> Hmm, apologies that little context was provided - this was meant in the context of the current crop of relay-based attacks that have been discovered. As we learned in those contexts, “just handle it when it confirms” doesn’t provide the types of guarantees we were hoping for as placing commitment transactions in mempools can be used to prevent honest nodes from broadcasting the latest state. This implies that HTLC security may be at risk.
>>
> 
> Ah, okay.
> 
> So the attack is this:
> 
> * Attacker connects twice to the LN: one to any node near the victim, one to the victim.
> * Attacker arranges for the attacker-victim channel to have most funds in the side of the victim.
> * The attacker routes a circular payment terminating in the victim-attacker channel.
>   * The victim accepts some incoming HTLC, and provides an outgoing HTLC to the attacker via the victim-attacker channel.
> * The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel, one that is too low-fee to practically get confirmed, just before the HTLC timeout.
> * The victim-outgoing HTLC times out, making the victim broadcast a unilateral close attempt for the victim-attacker channel in order to enforce the HTLC onchain.
>   * Unfortunately for the victim, relay shenanigans prevent the latest commitment from being broadcast.
> * The attacker waits for the victim-incoming HTLC to timeout, which forces the victim to `update_htlc_failed` the incoming HTLC or risk having that channel closed (and losing future routing fees).
>   * The attacker now gets back its outgoing funds.
> * The attacker lets the old-state transaction get relayed, and then re-seats the latest update transaction to that.
> * Once the latest transaction allows the HTLCs to be published, the attacker claims the victim-outgoing HTLC with the hashlock branch.
>   * The attacker now gets its incoming funds, doubling its money, because that is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works right?
> 
> Hmmm.
> 
> The only thing I can imagine helping here is for the forwarding node to drop channels onchain "early", i.e. if the HTLC will time out in say 14 blocks we drop the channel onchain, so we have a little leeway in bumping up fees for the commitment transaction.
> Maybe.
> I am sure Matt can find yet another relay attack that prevents that, at this point, haha.
> 
> "Are we *still* talking about onchain fees....?" - Adelaide 2018
> 
> Regards,
> ZmnSCPxj
> 
> 
> 
> 
>>> On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>>> Good morning Matt,
>>>
>>>> While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
>>>> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
>>>> This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
>>>> The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
>>>
>>> Ah, right.
>>> A feasible attack, without the above, would be to connect to the fullnode of the victim, and connect to miners separately.
>>> Then you broadcast to the victim one of the old txes, call it tx A, but you broadcast to the miners a different old tx, call it B.
>>> The victim reacts only to tA, but does not react to B since it does not see B in the mempool.
>>> On the other hand --- what the victim needs to react to is onchain confirmed transactions.
>>> So I think all the victim needs to do, in a Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and ignore mempool events.
>>> So if we give fairly long timeouts for our mechanisms, it should be enough, I think, since once a transaction is confirmed its txid does not malleate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, unless a reorg unconfirms the transaction.
>>> We only need to be aware of deep reorgs and re-broadcast with a malleated prevout until the tx being spent is deeply confirmed.
>>> In addition, we want to implement scorch-the-earth, keep-bumping-the-fee strategies anyway, so we would keep rebroadcasting new versions of the spending transaction, and spending from a transaction that is confirmed.
>>> Or are there other attack vectors you can see that I do not?
>>> I think this is fixed by looking at the blockchain.
>>> Regards,
>>> ZmnSCPxj
> 
>