-
Notifications
You must be signed in to change notification settings - Fork 1
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
VLS Policy management #37
Comments
For example, when receiving a 1000 sat payment for an invoice of the same amount, we crash on a policy failure as shown below:
|
And once we go above the dust limit, receiving a 5'000 sat payment, we crash like this:
|
Guru Meditation Error: Illegal Instruction seems to come from any panic in the rust code. Its too bad the actual panic message is not returned :( But I wonder if we need to go through and |
Discussion on the errors shown aboveThe second error I raised in this thread is fixed by this MR from Ken: https://gitlab.com/lightning-signer/validating-lightning-signer/-/merge_requests/265 I'm still in touch with Ken about the first error though - it seems to be a disconnect between what the node sets as the dust minimum, and what the signer will accept as the dust minimum. This is because on my regtest nodes, when I do a
I then made the following diff in the vls code, and the 1000 sat payment went through:
Policy error recoveryI asked Ken whether there is currently anything more graceful we can do other than to throw a panic here for example: It doesn't look like VLS provides an easy way to recover from potential failures in the
Definitely! Here nonetheless the errors are logged right before the line below so these changes aren't needed immediately:
|
For now, I have a branch here that silences the two errors mentioned in the above thread: https://gitlab.com/Evanfeenstra/validating-lightning-signer/-/tree/ken-mr-265 See this branch for this repo to get those changes here: https://github.com/stakwork/sphinx-key/tree/silence-policy-errors |
The two errors above have been resolved by: Aside from there not being a standard way to recover from a policy failure yet, I have also confirmed that we also don't yet have an API to make changes to the policy. |
Our own policy struct can be serialize/deserialized and stored on SD, and passed in RootHandler init. Lets figure out how to
|
Do we need some kind of "error" persistence in broker, so the hardware can publish errors and policy breaches? |
Im thinking for authorizing Control messages, the "signed timestamp" that the tribe server uses is not ideal. Because recent requests must be cached to prevent replays, but that can lead to denial-of-service by flooding (persisting to the SD will slow things down) Instead I'm thinking a nonce-based approach where each message is appended with a unique nonce (an incrementing u64). Each message must have a higher nonce than the last. The ESP32 will only need to keep track of its current nonce (and the app as well). That way the broker admin cannot DoS the ESP by replaying messages See here: https://github.com/stakwork/sphinx-rs/blob/master/auther/src/nonce.rs |
FlashPersist trait: https://github.com/stakwork/sphinx-key/blob/broker-ctrl/parser/src/control.rs impl here for sphinx-key using EspNsvStorage https://github.com/stakwork/sphinx-key/blob/broker-ctrl/sphinx-key/src/core/control.rs#L17 |
how do we change policies?
recovering from policy "crash"... the key should not panic
The text was updated successfully, but these errors were encountered: