search

interledger / rfcs

Specifications for Interledger and related protocols
https://interledger.org
Other
454 stars 111 forks source link

Add STREAM receipts #570

Closed wilsonianb closed 4 years ago

wilsonianb commented 4 years ago

https://github.com/interledger/rfcs/issues/568

sharafian commented 4 years ago

https://github.com/interledger/rfcs/issues/481

This suggests that leap second support isn't really a valid reason to use InterledgerTime, making me lean towards just a Unix timestamp.

kincaidoneil commented 4 years ago

Since money can be sent over multiple streams, the verifier's accounting might be more complicated since they have to support tracking and totaling the amount received over each stream.

What if receipts attested the amount received over the whole connection instead? What are the arguments for/against a per-connection receipt vs a per-stream receipt?

wilsonianb commented 4 years ago

https://github.com/wilsonianb/receipt-verifier/ :point_up_2: The current verifier implementation aggregates receipt amounts by a specified id (not necessarily the receipt nonce), so per-connection receipts wouldn't save it that much complexity.

I think it's still worth considering though. Would one type of accounting be easier to add to the Rust and Java STREAM implementations than the other?

wilsonianb commented 4 years ago

On second thought now that I'm trying to update the verifier for receipts without the timestamp, per-connection receipts would simplify things. The verifier can create a cache entry with an expiry for the receipt nonce when the SPSP query happens. This entry can be used to store the latest receipt amount as well as determining when a submitted receipt is too old (the entry will have expired).

sharafian commented 4 years ago

Since money can be sent over multiple streams, the verifier's accounting might be more complicated since they have to support tracking and totaling the amount received over each stream.

I was imagining that the key in the verifier's store would be the receipt nonce concatenated to stream ID. I'm not seeing right now how it's significantly simpler to just key with the receipt nonce.

The verifier can create a cache entry with an expiry for the receipt nonce when the SPSP query happens. This entry can be used to store the latest receipt amount as well as determining when a submitted receipt is too old (the entry will have expired).

Gotcha, so it saves a lookup because we don't need a separate key tracking the expiration of the connection as a whole?

In general I'm not hugely opposed to dropping the STREAM id but I want to make sure it doesn't mess anything else up in the future. STREAM was designed with multiplexing as a 'first-class' feature, where the idea is everything is done on streams and you might have long-lived connections on which you do many streams (like a long-lived QUIC connection with several HTTP calls over it).

We always have the option of making a new version of the receipt format but I think it could save us from future work if the receipts conceptually make sense with the rest of STREAM by working with the Stream abstraction

wilsonianb commented 4 years ago

so it saves a lookup because we don't need a separate key tracking the expiration of the connection as a whole?

More or less yeah. This gives an idea of how the verifier might change from using a redis hash to a single value for per-connection receipts: https://github.com/wilsonianb/receipt-verifier/commit/13f77b975c2510284e4807e5b084d34c0af26b3b

I don't have a strong opinion either way.