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

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

Hi Mathew and Joerg!

I am reuniting my replies to Joerg and Mathew to keep everything in one
thread. Had to add some ">" to keep consise quoting, hope that does not
confuse. If possible, do not delete parts of the mail in your replies
(even if you do not answer to them) unless they are cleared out.=20

Moved it over to opencoin-devel, seems more appropriate to me.

Read my awnser to questions 9 first, that's the interesting part ;-)


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
> >=20
> > Why would it do that? I thought the coins get added to a list in
> > the dsdb?
>=20
> 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.
>=20
> BTW: The DSDB should forget, not unlock, right?


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


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

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).
> > >=20
> > > 1a) For this to be viable, we need to add a service location field to
> > > 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 how
> a wallet should contact a DSDB and a distinct IS during a lock-->redeem
> +mint conversation.
>=20
> And DBDB requests which to not switch over into a redeemtion/exchange
> will be extreemly rare.=20
>=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.
>=20
> 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?
>=20
> [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
>=20
> true
>=20
> > > the DSDBKey is only used for encrypting the serials
> > > (and maybe depending on (1a), the location)
>=20
>  ... and it is mayby used for singing answers, but that's still only for
> 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.
> >=20
> > Would say so
>=20
> Good question. A wallet could redeem only a subset and let the locks for
> the other coins expire (but why locking them then?). And a wallet could
> try to redeem coins without locking them before (which means that the
> wallet accepted them without DS check, which is dangerous).=20
>=20
> So it not really nessecary to insist on the same set of serials, but in
> the real world it makes no sense for wallets to behave otherwise.=20
>=20
> The question is: which way is simpler? Let's do that.

I thought it over again. Letting things open in specs leeds to
incompatible inplementations. So i agree with Mathew: Although a payment
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.


> > > 4) MINTING_KEYS_FETCH_DENOMINATION returns the currently mintable
> > > MintKey for that denomination, right (even if it expires in .5 second=
s
> > > seconds..)?
> >
> > Where are you in the protocol?=20

Where the wallet asks the IS about the current minting keys to blind
for:

  <https://trac.opencoin.org/trac/opencoin/browser/trunk/standards/protocol=
.txt?rev=3D34#L79>=20

> 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
> 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?
> >=20
> > I would have the feeling that would suffice. Nils?
>=20
> I cannot recall any such reason (which does not mean there is none),
> too. Wallet should just ask /dev/random (unguessable by mallory).


> #### damned, time running out. stopping now

Woke up again.


> > > 6) If the IS/CDD is setup (see 9) to require MintRequests to be
> > >    sent to the IS prior to a RedeemCoinsRequest,

I do not see a reason why an IS should require that? (What have i
forgotten?)

> > >    should it be an error if we have not minted yet? Should the
> > >    protocol for that requirement change=20
> >=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.

But asynchronous in two requests (by now), see (9)

> > 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 assumed
> > to be given immediately.

Usually not, but some issuers may support just-in-time-minting ("JITM")
(e.g. if the tokens have no actual value).

[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?
> >=20
> > I thought the come together...

Again, no (yet)

[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
> >=20
> > 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 fi=
ne.

Didn't we already agree that the transport layer below our protocol
shall give us sessions? I am not sure ...

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".

As these additional information are not bound to special transactions,
this makes even sense if our protocol has no sessionsbut only
request/response pairs.


[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).
> >=20
> > Still don't get the question.

I pound the exchange part for quite some time now. This is my current
state of thoughts on that (may change next minute):

* 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".

* Some issuers may support just-in-time-minting/JITM, our protocol
should do that, too.

* 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):

  MINT_REQUEST( transaction_id, target, list( (blind1.key_id, blind1), ... =
) )

transaction_id=3D0 means mandatory JITM (which may get rejected). Issuer
may accept

  MINT_ACCEPT ( transaction_id, list( signature_of_blind1, ...) )  # JITM
  MINT_ACCEPT ( transaction_id )                                   # delaye=
d minting=20

or reject. There are additional reject reasons:

  "JITM not sopported"
  "JITM currently unavailable",


* Yes, you are right (and i think Joerg once voted for this, too):
besides asynchronous REDEEM_COINS_REQUEST+MINT_REQUEST there should be
another way to refresh coins with a single request like

  EXCHANGE_COINS_REQUEST(transaction_id, list(coin1, ...), list( (blind1.ke=
y_id, blind1), ... )

If transaction_id=3D0, the wallet insists on JITM. Possible answers:

  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).



> > > Request for clarification:
> > > Can someone go through all the ways we can have a
> > > MintRequest/RedeemCoinsRequest/FetchMintedAccept? (See 6 & 7). Does i=
t
> > > make sense to allow all of them? (So three options, I think)

(A) "initial buy": Buying OpenCoins, paying with RealMoney or
   something else

      MINT_REQUEST(transaction_id, target, list( (blind1.key_id, blind1), .=
.. ) )
  =20
   May get rejected if

    * transaction_id=3D0 but JITM is not supported/available;
    * issuer requires "Prepaid only" but $target is not paid yet


(B) "exchange/refresh": Buying OpenCoins with OpenCoins.
(B1) asynchronious (this is just A+C, so we get it for free):

      REDEEM_COINS_REQUEST( transaction_id, EXCHANGE, ...)
      MINT_REQUEST(         transaction_id, EXCHANGE, ... )

   This order should always be accepted (or??). If issuer is "Prepaid
   only" he rejects the order MINT_REQUEST, REDEEM_COINS_REQUEST.=20

(B2) synchronous

      EXCHANGE_COINS_REQUEST(transaction_id, list(coin1, ...), list( (blind=
1.key_id, blind1), ... )


(C) "final redeemtion": Selling OpenCoins, getting something else.

      REDEEM_COINS_REQUEST(transaction_id, target, ...)


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}.


Greetz, /nils.