-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Background
In order for the spending signature to be generated (by the buyer) and validated (by the seller), then the amount of funds locked up must be directly, or indirectly, be communicated from the buyer to the seller before the paid download begins. As a result, both sides also know when the last valid payment was sent, since each payment has a known price.
Problem
Protocol
The fact that the last valid payment has been made is not explicitly represented in the connection state machines of either side. As a result, its up to the signature generation/validation step on each side to correctly prevent additiona
The signature validation and generation cannot, in of itself, catch this error
Our implementation
-
The buyer side will experience an unhandled exception from the underlying
payment_channel::Payorobject. This will prevent making a bad payment, but it also corrupts the state machine, as an unhandled exception in a boost state chart reaction leaves the state machine in limbo. -
Its not clear that the seller even correctly prevents payments exceeding funds.
Solution
- Update the protocol to explicitly handle this case, such that the state machine on both ends enter into a state for when funds are exhausted.
PS: Currently we have opted for solving this at a higher level in our extensino, but this issue shuold be resolved here at this lower level also.