Payment Channels review#1
Conversation
|
|
||
| ### Create Payment Channel | ||
|
|
||
| Choose a globally unique identifier for `paymentChannel` and create it. Optionally provide a `rawtx` for the initial transaction statte. |
|
|
||
| ```javascript | ||
| { | ||
| "rawtx": '003222...' // Optional initial rawtx to initialize with. If left empty then use "Updates" to change |
There was a problem hiding this comment.
Just to confirm, so if I initialize a payment channel with TXQ and the server is restarted before the channel is closed, I would need to re-initialize the payment channel with rawtx of the original initiation and this would work. Is that correct?
There was a problem hiding this comment.
No. The payment channel will be persisted to DB, so if TXQ reboots you can continue where you left off.
I haven't updated the database schema yet, as this is just a proposal first to make sure it's the correct thing to build.
| "result": { | ||
| "closed": false, // Whether the channel is closed manually or one of the inputs was spent by an actual tx broadcasted | ||
| "state": { | ||
| "id": 135, |
There was a problem hiding this comment.
What exactly is id here? A random int?
There was a problem hiding this comment.
Only asking because we already have paymentchannelid
There was a problem hiding this comment.
id is the primary key of the tx (rawtx) in the database. The number is always guaranteed to be unique and increasing (but not necessarily consecutive, in other words it is monotonically increasing)
The purpose is an alternate id that you know is unique and chronologically ordered. It let's you know if a state is newer than another one by mere virtue of the fact that the latest state has a higher id.
It's not necessarily to expose to the client, perhaps I can hide it here. It may be useful to keep this in the sse updates because then it's easy to see when a state is newer.
| **Note:** The payment channel will automatically be closed if a transaction is broadcast via `/mapi` or `/tx` | ||
| when one of the inputs being spent collide with any transactions associated with a payment channel. | ||
|
|
||
| Client may forcefully close payment channel without broadcasting a transaction. No further additional transactions may be added |
There was a problem hiding this comment.
When the channel is closed and the tx is not broadcasted, just save the rawtx locally and can broadcast whenever.
Q: Are payment channels pruned from TXQ? Or will all payment channels always exist in the database?
There was a problem hiding this comment.
Looking at the SQL file I noticed that we don't store in the database whether the channel was closed and the transaction was broadcasted. Would this be valuable to add?
There was a problem hiding this comment.
When the channel is closed and the tx is not broadcasted, just save the rawtx locally and can broadcast whenever.
Good point! The client can fetch the rawtx/latest state of the channel and broadcast, perfect!
Looking at the SQL file I noticed that we don't store in the database whether the channel was closed and the transaction was broadcasted. Would this be valuable to add?
I haven't really finished the schema. But very good points, I'll add them both in :)
2 participants
No description provided.