Marcella Hastings
Marcella Hastings
Add a call to expiry for test execution.
# Motivation The customer architecture was originally created to be completely ephemeral: it would execute an operation (like a payment) and then cease to exist. However, this was an incorrect...
As a first draft of our chain agnostic design, we'll try to decouple the zeekoe implementation from the specific Tezos instantiation. We anticipate that closing will be similar for most...
The channel ID currently has two representations: as a `[u8; 32]` and as a `Scalar`. These representations do not have a bijective relationship -- there are more byte arrays than...
Make sure zeekoe has all the appropriate security properties in place e.g. - session ids are securely generated (jointly) - entity authentication during sessions - standard security audit checks (ask...
Right now, there's no validation of these values throughout close in places where we have certain invariants e.g. - when finalizing expiry, the customer should get no money - when...
Right now, a payment isn't rejected for not-enough-balance until the customer tries to form a pay proof. This is very late and puts the customer into a difficult-to-recover state. Also,...
The customer function `with_channel_state` returns a nested `Result`, where the outer `Result` indicates a database or internal failure, and the inner `Result` indicates a failure to execute the closure parameter....
In order to tightly bind each zero-knowledge proof (in zkAbacus's Establish and Pay protocols), it is important to integrate the current session transcript into the proof challenge (so the proof...
I think there is some discrepancy between the behavior of the code, the documentation of the code, and the documentation of the spec re: verification of contract status/updates on Tezos....