View Revisions: Issue #4840

Summary 0004840: /keys cherry picking
Revision 2016-12-16 10:04 by Marcello Stanisci
Description Problem about the signature of the cumulative hash of al DKs, namely the
'eddsa_sig' field sent along in the /keys response:

(1) it makes it difficult to optimize the /keys response. I.e. we might
want to leave out DKs that the wallet already knows. If the wallet were
to tell us: only send DKs later than XXX (timestamp), we could possibly
save a LOT of bandwidth. If we want to do this optimization, we need a
different way to indicate which set of keys the signature is over (if
the client already has the DKs, they can obviously be included in the
hash, but we still need an _efficient_ way to communicate the set of DKs
to use, i.e. by numbering them per-exchange). Future work...
Revision 2016-12-16 10:02 by Marcello Stanisci
Description Problem about the signature of the cumulative hash of al DKs, the 'eddsa_sig'
field sent along in the /keys response:

(1) it makes it difficult to optimize the /keys response. I.e. we might
want to leave out DKs that the wallet already knows. If the wallet were
to tell us: only send DKs later than XXX (timestamp), we could possibly
save a LOT of bandwidth. If we want to do this optimization, we need a
different way to indicate which set of keys the signature is over (if
the client already has the DKs, they can obviously be included in the
hash, but we still need an _efficient_ way to communicate the set of DKs
to use, i.e. by numbering them per-exchange). Future work...