Aug 22 - Aug 22, 2016
It was suggested that if the second-to-last hop is malicious, they could create a new onion blob and potentially compromise the payment. In response to this concern, it was proposed that the sender and receiver could agree on a shared secret value, such as the hash of the contract, that would be included in the per-hop payload for the final hop. If the payload does not match this value, then the payment should be rejected as a prior node has unsuccessfully attempted to recreate the onion packet. This solution would add an extra layer of security to the payment negotiation process.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback