Re: [OpenCoin-devel] Status update and protocol and implementation questions

[Nils T. <ni...@op...>]

Hi!

What's the correct noun to the verb "redeem" - "redemption"?


Am Montag, den 21.01.2008, 12:27 +0000 schrieb Joerg Baach:=20
> > On Tue, 2008-01-15 at 16:38 +0100, Nils Toedtmann wrote:
> >> On Sun, 2008-01-13 at 20:53 +0100, Joerg Baach wrote:
> >>> On Sat, 2008-01-12 at 00:01 -0600, mathew ryden wrote:
> >>>> - The DSDB does not unlock the coins if the time expires and
> >>>>   they aren't spent
> >>>> - The IssuerService does not change the status of the coins
> >>>>   to spent when they are spent
> >>> Why would it do that? I thought the coins get added to a list in
> >>> the dsdb?
> >> I guess Mathew that's what Mathew meant, right? When a coin gets
> >> reported the first time to the DSDB it is put on the list and gets
> >> marked "LOCKED". I read Mathew that the DSDB neither unlocks/forgets
> >> the coin ater lock expiration nor changes the mark from LOCKED to
> >> SPENT, yet.
> >>
> >> BTW: The DSDB should forget, not unlock, right?


> >>>> - The code only supports one type of currency during a
> >>>>   transaction between wallets
> >>> Fine for now
> >> ack


> >>>> - A RedeemCoinsRequest may fail if the MintRequest isn't already
> >>>>   in.=20
> >>> ???
> >> I read: when coins get exchanged (=3D redeemed against fresh coins), t=
he
> >> minting request must happen before the redeeming request - correct?
> >>
> >> What happens on final redeemtion (=3D not against fresh coins but
> >> something else like RM (RealMoneyTM))?
> >=20
> > More on coin exchange below.


> >>>> Now protocol questions:
> >>>> 1) I have made the assumption (and plan to stick with it) that the
> >>>> DSDB and IS are located at different addresses. It may even be true
> >>>> that they are seperate entities! (Imagine the different ISs all
> >>>> contract with the same DSDB service).
> >>>>
> >>>> 1a) For this to be viable, we need to add a service location field t=
o
> >>>> the DSDBKey. Should I go ahead and do that?
> >>> To the key or the cdd?
> >> =20
> >> The DSDB is heavily linked to the IS as a LOCK may shift into a
> >> redeemtion (and maybe additionally a minting) process. I do not see ho=
w
> >> a wallet should contact a DSDB and a distinct IS during a lock-->redee=
m
> >> +mint conversation.
> >>
> >> And DBDB requests which to not switch over into a redeemtion/exchange
> >> will be extreemly rare.=20
> >>
> >> So the DSDB itself may be at a different location within the issuer
> >> infrastructure, but that should not bother the wallets. The IS should
> >> proxy DSDB requests.
> >>
> >> Or am i missing something? What exact (attack) scenario whould a
> >> independant DSDB solve?


> >>>> 1b) Supporting the multiple currencies using the same DSDB, I
> >>>>     moved the signature to the additional signatures field.=20
> >>>>     That way each CDD signs the DSDBKey
> >>> a cdd signs a dsdb key? I thought an issuer would sign it? Does a
> >>> cdd have a signing key?
> >>>
> >>>> 1c) Does this mean that the DSDB itself should sign the
> >>>>     certificate?
> >> [omit 1b and 1c because 1a has to be clarified before]


> >>>> 2) The DSDBKey has not_before and not_after fields. Does this mean
> >>>> that all currencies that use this DSDB need to expire at that time?
> >>>> Answer for 2) No.=20
> >> true
> >
> >>>> the DSDBKey is only used for encrypting the serials
> >>>> (and maybe depending on (1a), the location)
> >>  ... and it is mayby used for singing answers, but that's still only f=
or
> >> trusted communication, so DSDB key could change without invalidatiing
> >> any minting keys.


> >>>> 3) When we LOCK_COINS_REQUEST and later REDEEM_COINS_REQUEST, the=20
> >>>> coins have to be exactly the same, right? That is, we have the exact
> >>>> same coins as the serials we locked, no less.
> >>> Would say so
> >> Good question. A wallet could redeem only a subset and let the locks f=
or
> >> the other coins expire (but why locking them then?). And a wallet coul=
d
> >> try to redeem coins without locking them before (which means that the
> >> wallet accepted them without DS check, which is dangerous).=20
>=20
> Isn't there the case of offline transactions, without ds check, usually
> between trusted parties? In this case I would not need to do a lock -
> however doing a lock beforehand also does not really hurt (besides not
> being necessary).

Yes, and there is at least one more case: when i want to
refresh/re-split coins i once created myself, i do not need a lock. So
it should not be mandatory to lock coins before redeemtion.

But we could still require that *if* a list of coins is locked then this
list can only get redeemed complete or not at all.=20


> >> So it not really nessecary to insist on the same set of serials, but i=
n
> >> the real world it makes no sense for wallets to behave otherwise.=20
> >>
> >> The question is: which way is simpler? Let's do that.
>=20
> I would say that we don't need to enforce the same list. So it should
> not be an error if I lock n coins, but only redeem n-1 coins.
>=20
> > I thought it over again. Letting things open in specs leeds to
> > incompatible inplementations. So i agree with Mathew: Although a paymen=
t
> > scheme would not require that, we should insist on the same list of
> > serials. At least unless someone finds a good argument not to do so.
>=20
> Reason a: another thing we need to check, enforce and handle.
> Reason b: a split transaction of some sort - I want to accept all coins,
>           and redeem some, and exchange some.

I do not really have a strong attitude on this topic, maybe you are
right that LOCK and REDEEM should be completely independent of each
other, and that it's up to the wallet which coins get locked before
redeemtion. Means also that our atoms are coins (and not lists of
coins), at least when it comes to redeemtion.

Mathew?  (hey, i feel a bit like a CNN reporter :-)=20


> >>>> 4) MINTING_KEYS_FETCH_DENOMINATION returns the currently mintable
> >>>> MintKey for that denomination, right (even if it expires in .5 secon=
ds
> >>>> seconds..)?
> >>> Where are you in the protocol?=20
> >=20
> > Where the wallet asks the IS about the current minting keys to blind
> > for:
> >=20
> >   <https://trac.opencoin.org/trac/opencoin/browser/trunk/standards/prot=
ocol.txt?rev=3D34#L79>=20
>=20
> Thanks, it was the additional s
>
> >> Hmmm ... alternatives? It could return future key_ids as well. Client
> >> will read date/time limits on keys an knows which one to use or if
> >> better to wait a few minutes to not run into a minting key expiration.
>=20
> I think it should deliver future keys as well, returning
>=20
>  MINTING_KEY_PASS(keycertificate,[keycertificate...])

Ack. What about the wallet asking=20

  MINTING_KEY_FETCH_DENOMINATION(denomination, [deadline])

expecting all yet published certs which validity has non-empty
intersection with the period [now:$deadline].

Btw: a wallet usually need more than one denomination. What about

  MINTING_KEY_FETCH_DENOMINATION(list(denomination1, denomination2, ...), [=
deadline])

> >> Issuer could publish a time delay like "minting key switch time =3D
> >> 60min": if minting keys will switch at 15:00 vom key_A to key_B, then
> >> from 14:00 on minting requests have to be blinded for key_B.


> >>>> 5) protocol.txt states that the transaction_id for the DSDB locking
> >>>> and the MintRequest is created using a two-party agreement. Is there
> >>>> any reason it shouldn't just be a randomly generated number of some
> >>>> length?
> >>> I would have the feeling that would suffice. Nils?
> >> I cannot recall any such reason (which does not mean there is none),
> >> too. Wallet should just ask /dev/random (unguessable by mallory).
>=20
> Ok, so random number is it.



> >>>> 6) If the IS/CDD is setup (see 9) to require MintRequests to be
> >>>>    sent to the IS prior to a RedeemCoinsRequest,
> >=20
> > I do not see a reason why an IS should require that? (What have i
> > forgotten?)
> >=20
> >>>>    should it be an error if we have not minted yet? Should the
> >>>>    protocol for that requirement change=20
> >>> I don't get the quiestion - if I read the protocol in the case of the
> >>> RedeemCoinsRequest (RDC), MintRequest is sent along with the RCR.
> >=20
> > But asynchronous in two requests (by now), see (9)
> >=20
> >>> In exactly what case should it be an error?
> >>>
> >>>> to give the MintedBlanks right away during the RedeemCoins Request?
> >>> Minting can take quite a while, so no, the coins should not be assume=
d
> >>> to be given immediately.
> >=20
> > Usually not, but some issuers may support just-in-time-minting ("JITM")
> > (e.g. if the tokens have no actual value).
> >=20
> > [see my answer to (9)]


> >>>> 7) Does the opposite condition, the one where MintRequests are not
> >>>> allowed until the RedeemCoinsRequest make sense? Should we implement
> >>>> it?
> >>> I thought the come together...
> >=20
> > Again, no (yet)
> >=20
> > [see my answer to (9)]


> >>>> Protocol declarations:
> > [Corrected from 7 to 8]
> >>>> 8) We need some sort of handshaking, be it just something like
> >>>>    "OpenCoin 1\n", "OpenCoin 1 Agree\n". The other allowed=20
> >>>>    transaction
> >>> Or you put it into the messages that you pass along. The whole thing
> >>> started with more or less http like request/response pairs. The whole
> >>> thing of having handshake etc. requires a stable session.
> >>> Maybe I am lost and the protocol has advanced too far anyhow in the
> >>> direction of keeping a stable connection. Then the proposal would be =
fine.
> >=20
> > Didn't we already agree that the transport layer below our protocol
> > shall give us sessions? I am not sure ...
>=20
> Ok, for sockets we have some form of session anyhow (assuming that the
> connection does not break in between). For HTTP we can use cookies.
> So I guess it would be fine.

And it's not really a disaster if the session dies a this point - just
establish a new one and send the handshake again.

BTW: Shall the handshake be mandatory? I vote 'yes': our protocol is
very verbose anyway and not optimized on bandwidth at all, so adding
this overhead will not hurt.=20


> > Anyway, i agree on having a handshake. That would be also a place to
> > communicate information which changes from time to time (issuer would
> > have to change CDD everytime), like "Prepaid only". "JITM supported",
> > "JITM currently unavailable", "asynchronous exchange not supported".
> >=20
> > As these additional information are not bound to special transactions,
> > this makes even sense if our protocol has no sessionsbut only
> > request/response pairs.
>=20
> OK, so I propose a
>=20
> 	HANDSHAKE(protocol version, subprotocol)
>=20
> with subprotocol being something like "sendMoneyProtocol", indicating
> what we would like to do.

Hmmm ... what shall "subprotocol" that be good for? The wallet's next
statement will make that clear anyway.=20

> The other side can response with either
>=20
> 	HANDSHAKE_ACCEPT(protocol version, subprotocol, [data...])
> 	HANSHAKE_REJECT(reason)
>
> Generally speaking right now we never seem to exchange key-value pairs
> in the messages, which I would actually would find quite usefull.
>=20
> E.g. the Issuer could then return something like
>=20
> jitm=3D1,prepaid_only=3D1,someotherstuff=3Dfoo
>=20
> with that we would not rely on the order of things. A bit like the
> headers in the http protocol.
>=20
> What do you think?

I almost agree. I wonder if we should combine the ESMTP way ...

  (client connects to server)
                                  220 trinity.takatukaland.de ESMTP TakaTuk=
aPost
  EHLO laptop.nt.eonis.de=20
                                  250-trinity.takatukaland.de
                                  250-PIPELINING
                                  250-SIZE 30000000
                                  250-ETRN
                                  250-STARTTLS
                                  250-AUTH PLAIN LOGIN
                                  250 8BITMIME

  (you see a nice trick here: a hyphen after the response code indicates
   "there are still more lines to come for this response")=20

... with the X.509 way: There are protocol extensions (like JITM), which
were not necessarily part of the original protocol, or which are not
supported by all participants. Some are 'critical', which means "if you
do not know this extension, then quit now" ("my way or the highway" ;)
For example

  HANDSHAKE_ACCEPT(protocol version, jitm PREPAIDONLY maxcoins=3D100)

uppercase signalling a critical extension. On the other side, there is
the CDD for long-term information. So i think: if JITM is supported by
an issuer in general, it should be mentioned in the CDD. Protocol
extensions should only be used for

* short-term variations of the CDD (like "jitm currently not
   available")

* properties which are not properties of the currency or issuer but of
   its issuer service itself (like ... encodings, compression?)

> > [Corrected from 8 to 9]
> >>>> 9) Right now the protocol allows for either forcing mint requests
> >>>> prior to redeem coins requests, or allows them before or after the
> >>>> RedeemCoinsRequest. This information needs to be given to the wallet
> >>>> somehow. One way is to have that part of the handshaking (see 8).
> >>> Still don't get the question.
> >=20
> > I pound the exchange part for quite some time now. This is my current
> > state of thoughts on that (may change next minute):
> >=20
> > * Some issuers may prefer to only accept a MINT_REQUEST if that is
> > already paid (whether paid with OpenCoins or RealMoney (RM) does not
> > matter), so there has to be either an CDD-option or a handshake option
> > "PrepaidOnly".
> >=20
> > * Some issuers may support just-in-time-minting/JITM, our protocol
> > should do that, too.
> >=20
> > * We should make MINT_REQUEST more similar to REDEEM_COINS_REQUEST,
> > splitting "request_id" into "transaction_id" (identifying this list of
> > blinds) and a "target" (identifying an external payment):
> >=20
> >   MINT_REQUEST( transaction_id, target, list( (blind1.key_id, blind1), =
... ) )
>=20
> Fine with me
>=20
> >=20
> > transaction_id=3D0 means mandatory JITM (which may get rejected). Issue=
r
> > may accept
>=20
> may accept with...
>=20
> >=20
> >   MINT_ACCEPT ( transaction_id, list( signature_of_blind1, ...) )  # JI=
TM
> >   MINT_ACCEPT ( transaction_id )                                   # de=
layed minting=20
> >=20
> > or reject. There are additional reject reasons:
> >=20
> >   "JITM not sopported"
> >   "JITM currently unavailable",
>=20
> Looks good to me
>=20
>=20
> > * Yes, you are right (and i think Joerg once voted for this, too):
>=20
> Ack
>=20
> > besides asynchronous REDEEM_COINS_REQUEST+MINT_REQUEST there should be
> > another way to refresh coins with a single request like
> >=20
> >   EXCHANGE_COINS_REQUEST(transaction_id, list(coin1, ...), list( (blind=
1.key_id, blind1), ... )
>=20
> I assume thats a very often used transaction. I like it

Me too. I originally preferred the REDEEM_COINS_REQUEST+MINT_REQUEST way
because it falls from the sky without requiring YetAnotherRequestType,
but i agree that we really want a synchronous exchange, too.=20


> > If transaction_id=3D0, the wallet insists on JITM. Possible answers:
> >=20
> >   EXCHANGE_COINS_ACCEPT( transaction_id, list(signature_of_blind1, ...)=
 )   # JITM
> >   EXCHANGE_COINS_ACCEPT( transaction_id)                               =
     # delayed minting
> >   EXCHANGE_COINS_REJECT( list( (blind1.key_id, "Reason1"), ... ) )
> >
> > Does that make sense to you? If you agree i change our Protocol.txt
> > accordingly. (I should learn how to branch svn).
>=20
> +1
>=20
> Also: change it in trunk. We still have the old revisions. As we are
> working together on the protocol anyhow, we should have one place to
> refer to.

ok


> >>>> Request for clarification:
> >>>> Can someone go through all the ways we can have a
> >>>> MintRequest/RedeemCoinsRequest/FetchMintedAccept? (See 6 & 7). Does =
it
> >>>> make sense to allow all of them? (So three options, I think)
> >=20
> > (A) "initial buy": Buying OpenCoins, paying with RealMoney or
> >    something else
> >=20
> >       MINT_REQUEST(transaction_id, target, list( (blind1.key_id, blind1=
), ... ) )
> >   =20
> >    May get rejected if
> >=20
> >     * transaction_id=3D0 but JITM is not supported/available;
> >     * issuer requires "Prepaid only" but $target is not paid yet
> >=20
> >=20
> > (B) "exchange/refresh": Buying OpenCoins with OpenCoins.
> > (B1) asynchronious (this is just A+C, so we get it for free):
> >=20
> >       REDEEM_COINS_REQUEST( transaction_id, EXCHANGE, ...)
> >       MINT_REQUEST(         transaction_id, EXCHANGE, ... )
> >=20
> >    This order should always be accepted (or??). If issuer is "Prepaid
> >    only" he rejects the order MINT_REQUEST, REDEEM_COINS_REQUEST.=20
> >=20
> > (B2) synchronous
> >=20
> >       EXCHANGE_COINS_REQUEST(transaction_id, list(coin1, ...), list( (b=
lind1.key_id, blind1), ... )
> >=20
> >=20
> > (C) "final redeemtion": Selling OpenCoins, getting something else.
> >=20
> >       REDEEM_COINS_REQUEST(transaction_id, target, ...)
> >=20
> >=20
> > There is some inconsitency here: with (B1), the $transaction_id cannot
> > be set to zero, so the wallet cannot insist on JITM here. We could
> > circumvent this it we signal mandatory JITM not via $transaction_id=3D0
> > but {whatever}.
>=20
> I think its ok to leave it as it is. The (small) inconsistency could be
> allowed.