The problem arises because claiming the offchain side is dependent on claiming the onchain side, which can be slow and forces the swap service to pay the hold fees.One suggestion is for the swap service to collect fees from the user to cover these costs. However, another suggestion is for the user to exploit the system by timing out the onchain HTLC, causing the swap service to pay for both the onchain HTLC and the hold fee.This issue has been addressed in Boltz by implementing a separate mining-fee invoice that must be paid before the creation of the onchain HTLC. It is suggested to include the hold fee in the mining-fee invoice as well.The proposal introduces certain properties of an HTLC received by a routing node, such as the amount, forward up-front payment, backward up-front payment, and grace period. The routing node forwards the HTLC to the next hop with lower amounts and payments but higher backward up-front payment and shorter grace period.However, there is an issue related to trustless offchain-to-onchain swaps where the swap service is forced to pay the hold fees since the claiming of the offchain side depends on the onchain side, which is slow. To address this, a combined mining-fee+hold-fee invoice would need to be issued alongside the "real" swap invoice.In a different conversation, concerns were raised about the possibility of amounts being too high for honest users or certain uses in proposed changes to Bitcoin's Lightning Network. The proposal includes an upfront payment made by the sender to combat uncontrolled spam attacks. However, it was noted that if an attacker is on the other end of the uncontrolled spam payment, they could still collect forward payments. To address this, penalization measures may need to be implemented. The proposal also includes properties such as HTLC amount, forward up-front payment, backward up-front payment, and grace periods. Routing nodes would forward payments with lower forward up-front payments and higher backward up-front payments to deter attackers.In another discussion about delaying refunds in Lightning Network transactions, the issue of C unfairly delaying D's refund by delaying its own commitment_signed was brought up. It was suggested to extend the commitment_signed with a TLV field indicating "I refunded myself for HTLC N" to help C compute the same commit tx and verify signatures. However, it was noted that the potential loss of a viable channel and on-chain fees might outweigh the benefits of taking the hold fee at this point. The discussion also touched upon interoperability issues caused by rules involving "SHOULD/MUST fail the channel," as seen in the mass channel closures between C-Lightning and lnd nodes due to sudden on-chain fee movements.The process of revoking and acknowledging a channel in case of a griefing attack was explained in a technical discussion. The revoke_and_ack function drops the channel on-chain with the HTLC instantiated. Concerns were raised about the possibility of amounts being too high for honest users or certain uses in a proposal for backwards upfront payments in Lightning Network. The proposal allows for refunds within a grace period and penalizes nodes if they exceed the grace period. Potential controlled spam attacks were also discussed, and it was noted that penalization could be possible by decrementing the forward fee at each hop.In a conversation about delaying refunds in Lightning Network transactions, it was explained that if the final recipient delays settling the HTLC before the grace period ends, it is fair for them to pay the intermediary node C for this. However, C can only safely propagate its own upstream update_fail_htlc once it receives revoke_and_ack from D. The grace period between C and D should be measured from C sending update_add_htlc to C receiving revoke_and_ack from D in case the HTLC fails. For a successful case of update_fulfill_htlc, C can immediately propagate this back to its upstream. The start point of the grace period is C->commitment_signed->D containing the HTLC. The D grace period has two smaller grace periods that protect against C-side griefing.In a discussion about payment channels and spam attacks, it was noted that forward and backward payments are relatively independent of each other. The proposal includes an upfront payment made by the sender to fight uncontrolled spam and a backward payment to fight controlled spam. Concerns were raised about the amounts required to thwart attacks being too high for honest users or certain uses. Calculations were done to determine the appropriate fees, taking into account the annual return needed and the "damage" caused by uncontrolled spam. The discussion also touched upon potential weaknesses and the need to collectively figure out implementation details.The participants in an email thread discussed the implementation of upfront payments for offering and receiving hash time-locked contracts (HTLCs) in the Lightning Network. A fixed forward payment of