David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-16 📝 Original message: On Mon, Dec 16, 2019 at ...
📅 Original date posted:2019-12-16
📝 Original message:
On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:
> If well executed, attacks described stay stealth until it's too late
> to react.
I suspect the attacks you described are pretty easy to detect (assuming
block relay is significantly delayed) by simply comparing the time of
the latest block header to real time. If the difference is too large,
then an emergency action should be taken.[1]
You mention IBD as confounding this strategy, but I don't think that's
the case. Compare the normal case to the pathological case:
- Normal: when Alice is requesting blocks from honest nodes because
she's far behind, those nodes are telling her their current block
height and are promptly serving any blocks she requests.
- Pathological: when Alice is requesting blocks from a eclipse attacker,
those dishonest nodes are telling her she's already at the chain tip
even though the latest block they serve her has a header timestamp
that's hours or days old. (Alternatively, they're reporting the
latest block height but refusing to serve her blocks/headers past a
certain point in the past.)
It seems pretty easy to me to detect the difference between the normal
case (Alice's chaintip is old but she's still successfully downloading
blocks) and the pathological case (Alice's chaintip is old and she's
unable to obtain more recent blocks).
A possibly optimal attack strategy would be to combine
commitment/penalty transaction censorship with plausible block delays.
To a point, transaction censorship just looks a failure to pay a
sufficient feerate---so a node will probably fee bump a
commitment/penalty transaction a few times before it starts to panic.
Also to a point, a delay of up to several hours[2] just looks like
regular stochastic block production. By using both deceits in the same
attack to the maximum possible degree without triggering an alarm, an
attacker can maximum their chance of stealing funds.
-Dave
[1] There is an interesting case where a large miner or cartel of miners
could deliberately trigger a false positive of block delay
protection by manipulating Median Time Past (MTP) to allow them to
set their header nTime fields to values from hours or days ago. I
don't believe the fix for the time warp proposed in the consensus
cleanup soft fork fixes this, since it only directly affects the
first block in a new difficulty period (preventing difficulty gaming
but not header time gaming). This problem is partly mitigated by
miners keeping MTP far in the past being unable to claim fees from
recent time locked transactions (see BIP113), though I'm not sure
how many transactions are actually using nLockTime-as-a-time (LN and
anti-fee sniping use it as a height).
[2] If we suddenly lose half of Bitcoin's hashrate so that the average
time between blocks is 20 minutes, there's a once-in-a-century
chance of a block taking more than 310 minutes to produce:
1 / (exp(-310/20) * 144 * 365)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191216/a987f10e/attachment.sig>;
📝 Original message:
On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:
> If well executed, attacks described stay stealth until it's too late
> to react.
I suspect the attacks you described are pretty easy to detect (assuming
block relay is significantly delayed) by simply comparing the time of
the latest block header to real time. If the difference is too large,
then an emergency action should be taken.[1]
You mention IBD as confounding this strategy, but I don't think that's
the case. Compare the normal case to the pathological case:
- Normal: when Alice is requesting blocks from honest nodes because
she's far behind, those nodes are telling her their current block
height and are promptly serving any blocks she requests.
- Pathological: when Alice is requesting blocks from a eclipse attacker,
those dishonest nodes are telling her she's already at the chain tip
even though the latest block they serve her has a header timestamp
that's hours or days old. (Alternatively, they're reporting the
latest block height but refusing to serve her blocks/headers past a
certain point in the past.)
It seems pretty easy to me to detect the difference between the normal
case (Alice's chaintip is old but she's still successfully downloading
blocks) and the pathological case (Alice's chaintip is old and she's
unable to obtain more recent blocks).
A possibly optimal attack strategy would be to combine
commitment/penalty transaction censorship with plausible block delays.
To a point, transaction censorship just looks a failure to pay a
sufficient feerate---so a node will probably fee bump a
commitment/penalty transaction a few times before it starts to panic.
Also to a point, a delay of up to several hours[2] just looks like
regular stochastic block production. By using both deceits in the same
attack to the maximum possible degree without triggering an alarm, an
attacker can maximum their chance of stealing funds.
-Dave
[1] There is an interesting case where a large miner or cartel of miners
could deliberately trigger a false positive of block delay
protection by manipulating Median Time Past (MTP) to allow them to
set their header nTime fields to values from hours or days ago. I
don't believe the fix for the time warp proposed in the consensus
cleanup soft fork fixes this, since it only directly affects the
first block in a new difficulty period (preventing difficulty gaming
but not header time gaming). This problem is partly mitigated by
miners keeping MTP far in the past being unable to claim fees from
recent time locked transactions (see BIP113), though I'm not sure
how many transactions are actually using nLockTime-as-a-time (LN and
anti-fee sniping use it as a height).
[2] If we suddenly lose half of Bitcoin's hashrate so that the average
time between blocks is 20 minutes, there's a once-in-a-century
chance of a block taking more than 310 minutes to produce:
1 / (exp(-310/20) * 144 * 365)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191216/a987f10e/attachment.sig>;