ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2020-06-17 đź“ť Original message: Good morning Rene, Thank ...
đź“… Original date posted:2020-06-17
đź“ť Original message:
Good morning Rene,
Thank you for the report, this is good.
> 1. The current solution is to just not use up the max value of htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences correctly) is coming from this PR to bitcoin core (c.f. https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it correctly with that we could always have low fees and ask the person who want to claim their outputs to pay fees. This excludes overpayment and could happen at a later stage when fees are not spiked. Still the victim who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the future anyway
Fee futures could help against this.
I remember writing about this some time ago but cannot find where (not sure if it was in lightning-dev or bitcoin-dev).
As a rough sketch, a client contacts a fee insurance service.
For a fixed fee, the client arranges such that the fee insurance service pays for fees in case of a condition where feerates increase.
This is done by arranging a 2-of-2 output spending the insurance premium payment and some maximum fee the insurance service provides.
Initially sign an `nLockTime`d transaction that represents the end of the insurance service contract.
Then at each commitment tx, sign a variety of feerates spending the CPFP carve-out and the insurance 2-of-2, utilizing the insurnace funds for doing the CPFP.
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs value (like we do with sub dust amounts and sub satoshi amounts. This would at least make the attack expensive as the attacker would have to bind a lot of liquidity.
Seems a reasonable heuristic.
> 5. Somehow be able to aggregate htlc's. In a world where we use payment points instead of preimages we might be able to do so. It would be really cool if separate HTLC's could be combined to 1 single output. I played around a little bit but I have not come up with a scheme that is more compact in all cases. Thus I just threw in the idea.
This seems impossible; once you add the points of two unrelated PTLCs, in order to separate them again once you learn the aggregate scalar, you need to learn the scalar of one separately from the scalar of the other, but the aggregate PTLC does not impose the requirement from the receiver to reveal each of the scalars separately.
You *could* require multiple signatures instead of a single signature, in which case each completed signature can reveal a separate scalar behind a point.
Revealing the points and the signatures is 96 bytes, plus a few more bytes for opcodes, divided by 4 because witness, so about equivalent to 24 block space per PTLC you merge.
This cost would be paid by the receiver of the HTLC.
The timelock branch can be made not to have to reveal any of the points, by Taproot-signing the timelock branch, or using a separate tapscript (at the cost of additional 32 witness bytes to select branches, if my taproot understanding holds).
--
Combining timelocks is also bad.
If you combine two PTLCs with different timelocks, which do you choose, the larger or the smaller?
* If you choose the larger, the sender of the PTLCs could have a larger outgoing timelock than the its incoming PTLC, then possibly might lose money when the incoming PTLC times out but the outgoing timelock is not yet timed out and can still be claimed by scalar revelation.
* If you choose the smaller, then the next hop might not have enough block time to deliver the payment, in which case later hops on the route will fail more often (possibly an acceptable tradeoff? c-lightning does shadow routing which overallocates timelock anyway...).
* If you cannot combine different timelocks, the attacker can arrange PTLCs with timelocks from now+2 to now+484 to mount the attack.
--
You could try aggregating using `OP_CHECKTEMPLATEVERIFY`, or equivalently with a pre-signed transaction, but that just moves the revelation cost to the receiver of the PTLC, which multiple signatures above does just as well.
It does have the advantage of retaining the timelocks.
Regards,
ZmnSCPxj
đź“ť Original message:
Good morning Rene,
Thank you for the report, this is good.
> 1. The current solution is to just not use up the max value of htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences correctly) is coming from this PR to bitcoin core (c.f. https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it correctly with that we could always have low fees and ask the person who want to claim their outputs to pay fees. This excludes overpayment and could happen at a later stage when fees are not spiked. Still the victim who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the future anyway
Fee futures could help against this.
I remember writing about this some time ago but cannot find where (not sure if it was in lightning-dev or bitcoin-dev).
As a rough sketch, a client contacts a fee insurance service.
For a fixed fee, the client arranges such that the fee insurance service pays for fees in case of a condition where feerates increase.
This is done by arranging a 2-of-2 output spending the insurance premium payment and some maximum fee the insurance service provides.
Initially sign an `nLockTime`d transaction that represents the end of the insurance service contract.
Then at each commitment tx, sign a variety of feerates spending the CPFP carve-out and the insurance 2-of-2, utilizing the insurnace funds for doing the CPFP.
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs value (like we do with sub dust amounts and sub satoshi amounts. This would at least make the attack expensive as the attacker would have to bind a lot of liquidity.
Seems a reasonable heuristic.
> 5. Somehow be able to aggregate htlc's. In a world where we use payment points instead of preimages we might be able to do so. It would be really cool if separate HTLC's could be combined to 1 single output. I played around a little bit but I have not come up with a scheme that is more compact in all cases. Thus I just threw in the idea.
This seems impossible; once you add the points of two unrelated PTLCs, in order to separate them again once you learn the aggregate scalar, you need to learn the scalar of one separately from the scalar of the other, but the aggregate PTLC does not impose the requirement from the receiver to reveal each of the scalars separately.
You *could* require multiple signatures instead of a single signature, in which case each completed signature can reveal a separate scalar behind a point.
Revealing the points and the signatures is 96 bytes, plus a few more bytes for opcodes, divided by 4 because witness, so about equivalent to 24 block space per PTLC you merge.
This cost would be paid by the receiver of the HTLC.
The timelock branch can be made not to have to reveal any of the points, by Taproot-signing the timelock branch, or using a separate tapscript (at the cost of additional 32 witness bytes to select branches, if my taproot understanding holds).
--
Combining timelocks is also bad.
If you combine two PTLCs with different timelocks, which do you choose, the larger or the smaller?
* If you choose the larger, the sender of the PTLCs could have a larger outgoing timelock than the its incoming PTLC, then possibly might lose money when the incoming PTLC times out but the outgoing timelock is not yet timed out and can still be claimed by scalar revelation.
* If you choose the smaller, then the next hop might not have enough block time to deliver the payment, in which case later hops on the route will fail more often (possibly an acceptable tradeoff? c-lightning does shadow routing which overallocates timelock anyway...).
* If you cannot combine different timelocks, the attacker can arrange PTLCs with timelocks from now+2 to now+484 to mount the attack.
--
You could try aggregating using `OP_CHECKTEMPLATEVERIFY`, or equivalently with a pre-signed transaction, but that just moves the revelation cost to the receiver of the PTLC, which multiple signatures above does just as well.
It does have the advantage of retaining the timelocks.
Regards,
ZmnSCPxj