David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-19 📝 Original message: On Fri, Jun 19, 2020 at ...
📅 Original date posted:2020-06-19
📝 Original message:
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be broadcasting the latest
state, so the honest counterparty would only need to send one blind
child. However, the blind child will only be relayed by a Bitcoin peer
if the peer also has the parent transaction (the latest state) and, if
it has the parent transaction, you should be able to just getdata('tx',
$txid) that transaction from the peer without CPFPing anything. That
will give you the preimage and so you can immediately resolve the HTLC
with the upstream channel.
Revising my conclusion from the previous post:
I think the strongman argument for the attack would be that the attacker
will be able to perform a targeted relay of the low-feerate
preimage-containing transaction to just miners---everyone else on the
network will receive the honest user's higher-feerate expired-timelock
transaction. Unless the honest user happens to have a connection to a
miner's node, the user will neither be able to CPFP fee bump nor use
getdata to retrieve the preimage.
Sorry for the confusion.
-Dave
-------------- 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/20200619/917b77aa/attachment.sig>;
📝 Original message:
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be broadcasting the latest
state, so the honest counterparty would only need to send one blind
child. However, the blind child will only be relayed by a Bitcoin peer
if the peer also has the parent transaction (the latest state) and, if
it has the parent transaction, you should be able to just getdata('tx',
$txid) that transaction from the peer without CPFPing anything. That
will give you the preimage and so you can immediately resolve the HTLC
with the upstream channel.
Revising my conclusion from the previous post:
I think the strongman argument for the attack would be that the attacker
will be able to perform a targeted relay of the low-feerate
preimage-containing transaction to just miners---everyone else on the
network will receive the honest user's higher-feerate expired-timelock
transaction. Unless the honest user happens to have a connection to a
miner's node, the user will neither be able to CPFP fee bump nor use
getdata to retrieve the preimage.
Sorry for the confusion.
-Dave
-------------- 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/20200619/917b77aa/attachment.sig>;