The proposal involves adding a hold_grace_period_delta field to channel_update, two new fields in the TLV extension of update_add_htlc, and an outgoing_hold_grace_period field in the onion per-hop payload. Nodes receiving an HTLC verify that fees and grace periods are reasonable and that the difference between the hold grace period and the outgoing hold grace period is greater than the delta value. A forward upfront payment of 1 msat is made unconditionally when offering an HTLC, and a backwards upfront payment of hold fees is required when receiving an HTLC. If the HTLC is settled before the hold grace period ends, the backwards upfront payment is refunded. The writer also presents scenarios involving quick settlements, delays in settling, or channel closures. However, they note that this proposal may allow intermediate nodes to deanonymize sender/recipient, so the base grace period and hold fees should be randomized. The most significant challenge will be handling the grace period, including when to start counting, accounting for disconnections, and dealing with remote refunds after the grace period.In another context, the writer suggests that there should be some leeway given to those who make mistakes but record their actions. However, if they continue to perform the same actions repeatedly, channels should be closed and they should be banned. Additionally, the writer discusses the risk of communication latency delaying responses and introduces a fixed upfront payment instead of a scaling approach. They believe that this approach is less complex and reduces potential griefing against honest nodes. The forward upfront payment is set at a constant 1 msat, which the writer acknowledges may not deter anyone. They humorously mention that a small amount like a satoshi would not even buy a single piece of fish ball.