thank you for taking the time to explain it.
Topic: Micropayment Channels questions (Read 942 times)
ok I get it now.
thank you for taking the time to explain it.
thank you for taking the time to explain it.
ok here in detail how and why it works:
1. payer and payee agree on a 2-of-2 address and own addresses
2. payer crafts a bond transaction that deposits X to the common address, but sends only the hash (outpoint) of it to payee. payer does not yet broadcast it, hence no risk to him.
3. payee crafts and signs a refund transaction that spends the outpoint back to payee time locked, such that it can not be included into the block chain until that time point. Payee can safely sign since if he does not own any coin with the outpoint.
4. payer verifies that the refund transaction if counter-signed and broadcasted by him would return the bond to him and if so broadcasts the bond transaction. He can safely do so, since if payee would not proceed, but he could get his money back on his own after the timeout.
5. now payer wanst to use some service of payee and crafts and signs a settlement transaction spending the same outpoint that pays him X-delta and delta to payee. The transaction is not yet valid since it needs payee's signature, hence payer can not broadcast it. Payer sends it to Payee.
6. Payee verifies that the settlement transaction has valid signature of payer and that it gives him enough to offer the service. Payee could countersign and broadcast the settlement transaction thereby closing the channel and also invalidating (double spending) the refund transaction.
7. Payer keeps sending new versions of the settlement transaction with increasing deltas while using the service. If delta does not increase sufficiently Payee closes the channel.
8. At close of the channel Payee will counter-sign and broadcast latest version, since that is most favorable to him.
9. Payee will close the channel well before the refund timout to avoid a race of the two alternatives.
1. payer and payee agree on a 2-of-2 address and own addresses
2. payer crafts a bond transaction that deposits X to the common address, but sends only the hash (outpoint) of it to payee. payer does not yet broadcast it, hence no risk to him.
3. payee crafts and signs a refund transaction that spends the outpoint back to payee time locked, such that it can not be included into the block chain until that time point. Payee can safely sign since if he does not own any coin with the outpoint.
4. payer verifies that the refund transaction if counter-signed and broadcasted by him would return the bond to him and if so broadcasts the bond transaction. He can safely do so, since if payee would not proceed, but he could get his money back on his own after the timeout.
5. now payer wanst to use some service of payee and crafts and signs a settlement transaction spending the same outpoint that pays him X-delta and delta to payee. The transaction is not yet valid since it needs payee's signature, hence payer can not broadcast it. Payer sends it to Payee.
6. Payee verifies that the settlement transaction has valid signature of payer and that it gives him enough to offer the service. Payee could countersign and broadcast the settlement transaction thereby closing the channel and also invalidating (double spending) the refund transaction.
7. Payer keeps sending new versions of the settlement transaction with increasing deltas while using the service. If delta does not increase sufficiently Payee closes the channel.
8. At close of the channel Payee will counter-sign and broadcast latest version, since that is most favorable to him.
9. Payee will close the channel well before the refund timout to avoid a race of the two alternatives.
Bob does not broadcast the refund at start as it would not be included to the block chain or mem pool until its time has come.
The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.
The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.
The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.
The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.
What prevents the payer (bob) from spending the bond before the settlement? If it is not on the network?
When you say settlement transaction? You mean the two separate transactions, bond and final refund? You mean to say that they are both broadcast at the same time at the 'end of work day'?
Quote
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
After payer (bob) signs the bond, what prevents Payee (Alice) Spending the bond therefore invalidating refund? The way I understand it if the inputs of a time-locked transaction (refund) are spent before time elapses the time-locked transaction is invalid.
Bob does not broadcast the refund at start as it would not be included to the block chain or mem pool until its time has come.
The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.
The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.
The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.
The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.
Hi,
I just want to know if my understanding of payment channels is correct. I also have some questions that I highlighted in bold. Would be grateful if somebody could answer them.
So based on this: https://bitcoin.org/en/developer-guide#micropayment-channel.
Scenario: Alice is going to do work and get paid in a micro-channel by Bob.
-----------------------
- Bob creates and signs a multisig 2-of-2 transaction for 100 mBTC bond, this has no lock time.
-Bob creates and signs a 2-of-2 refund transaction that uses outputs from bond, with time delay, for 100mBTC.
-Bob Gives refund transaction to Alice.
-Alice checks refund has time delay .
-Alice signs refund.
-Bob broadcasts refund (correct??)
-Bob gives bond transaction to Alice.
-Alice signs bond and broadcasts it on network.
Does Alice need to wait for at least one confirmation here to prevent Bob double spending bond through eg. transaction malleability or reversing block(s)?
-Alice checks refund uses outputs of bond.
?? what prevents this bond being spent by Alice invalidating refund?
-Alice does some work.
Alice creates 2-of-2 refund for 99 mBTC and gets bob to sign it. She does not sign it.The refund has no time lock and will invalidate the original refund if broadcast before its time lock.
-Alice does more work
.
.
.
-Alice finishes 30 units of work total.
-She signs refund for 70 mBTC and gives Bob to sign.
-Alice or Bob broadcast latest refund.
-This has to occur before the time delay of the original refund is reached.
- the end
I just want to know if my understanding of payment channels is correct. I also have some questions that I highlighted in bold. Would be grateful if somebody could answer them.
So based on this: https://bitcoin.org/en/developer-guide#micropayment-channel.
Scenario: Alice is going to do work and get paid in a micro-channel by Bob.
-----------------------
- Bob creates and signs a multisig 2-of-2 transaction for 100 mBTC bond, this has no lock time.
-Bob creates and signs a 2-of-2 refund transaction that uses outputs from bond, with time delay, for 100mBTC.
-Bob Gives refund transaction to Alice.
-Alice checks refund has time delay .
-Alice signs refund.
-Bob broadcasts refund (correct??)
-Bob gives bond transaction to Alice.
-Alice signs bond and broadcasts it on network.
Does Alice need to wait for at least one confirmation here to prevent Bob double spending bond through eg. transaction malleability or reversing block(s)?
-Alice checks refund uses outputs of bond.
?? what prevents this bond being spent by Alice invalidating refund?
-Alice does some work.
Alice creates 2-of-2 refund for 99 mBTC and gets bob to sign it. She does not sign it.The refund has no time lock and will invalidate the original refund if broadcast before its time lock.
-Alice does more work
.
.
.
-Alice finishes 30 units of work total.
-She signs refund for 70 mBTC and gives Bob to sign.
-Alice or Bob broadcast latest refund.
-This has to occur before the time delay of the original refund is reached.
- the end
Jump to: