-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payment Channels review #1
base: master
Are you sure you want to change the base?
Conversation
|
||
### Create Payment Channel | ||
|
||
Choose a globally unique identifier for `paymentChannel` and create it. Optionally provide a `rawtx` for the initial transaction statte. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
statte
state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will, fix thank you
|
||
```javascript | ||
{ | ||
"rawtx": '003222...' // Optional initial rawtx to initialize with. If left empty then use "Updates" to change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly is id
here? A random int?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only asking because we already have paymentchannelid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :)
No description provided.