If you intend on paying someone, why would it be a problem if they took the payment? If the waitress broadcasts the commitment you just sent but you hadn't received the secret yet, then you aren't losing anything. You already paid her, so what's the problem?
In fact, the waitress would be incentivized to respond with the revocation secret and complete the commitment update before broadcasting the transaction because there is the risk that if she broadcast before the customer's commitment is revoked that the customer can broadcast his older commitment where she was paid less. There is the risk that his transaction is confirmed before hers is so she could lose money. The waitress is fine with sending the revocation key and the commitment update for the customer because she doesn't to use her old commitment because that would mean she gets less money.
Of course there is the issue of the receiver taking payment and failing to deliver the product or service, but that's not a problem unique to the Lightning Network or to Bitcoin at all. That's why things like escrows are used - to ensure that both parties receive their agreed upon payment or good/service.
Topic: Present phenomena in Lightning Network (Read 121 times)
Hello,
I see in Lightning Network some small issue which besides defends the transfer of big amount of BTC. I use the example with café. Have you noticed that in case of sending secret, two transactions are actually valid and two would pass? The third transaction from the front is invalidated by the exchange of the secret, but not the two most recent before the exchange of the secret. That is why the waitress will bring the third coffee only when the secret is exchanged for the second transaction (the customer might broadcast older transaction without penalty at now). The process is always one "paying" as if behind. But before that, there are two transactions - the two latest. In the exchange of the second transaction commitment, the third transaction is already signed and the waitress can broadcast it and have her coffee paid for, without waiting for a secret.
Can this small problem be solved by atomicity - namely, between signing a second commitment, exchanging secret from first commitment and serving a second coffee (these actions must be totally contemporary (atomic) for maximum safety and how?
I speak about big amount of BTC at the beginning because if you are transferring more bitcoins, then the receiver is paid in advance and that is not safety.
I see in Lightning Network some small issue which besides defends the transfer of big amount of BTC. I use the example with café. Have you noticed that in case of sending secret, two transactions are actually valid and two would pass? The third transaction from the front is invalidated by the exchange of the secret, but not the two most recent before the exchange of the secret. That is why the waitress will bring the third coffee only when the secret is exchanged for the second transaction (the customer might broadcast older transaction without penalty at now). The process is always one "paying" as if behind. But before that, there are two transactions - the two latest. In the exchange of the second transaction commitment, the third transaction is already signed and the waitress can broadcast it and have her coffee paid for, without waiting for a secret.
Can this small problem be solved by atomicity - namely, between signing a second commitment, exchanging secret from first commitment and serving a second coffee (these actions must be totally contemporary (atomic) for maximum safety and how?
I speak about big amount of BTC at the beginning because if you are transferring more bitcoins, then the receiver is paid in advance and that is not safety.
Jump to: