BOLT 11, real time micro payments, and route redundancy

At present, paying the same payment request twice is not possible because it can be an opportunity for anyone in the middle to take your funds. However, with version 1.1, they may change the way payment hashes work so that this becomes possible. It would be similar to bip32, but for lightning. They also discussed the idea of allowing for amount adjustments while the payment has not been resolved. This could enable incremental payments from the sender to the recipient. The recipient would issue a payment request indicating support for adjustments. The sender then sends an initial transfer to the recipient through a route of her choosing. The recipient does not immediately claim the transfer by revealing the preimage, instead it serves the sender and keeps the transfer open. The sender increments the amount by sending an updated add_htlc message with matching payment hash and higher value. Nodes along the route notice that this is an update to an existing HTLC and forward it along the route, resetting any timeouts to unlock the HTLCs.This approach could allow for payments similar to simple Spillman-style payment channels, which are routed along a path or multiple hops. However, it opens up new DoS vectors where an attacker can lock up funds for longer periods, so careful implementation is necessary.