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

[Joerg B. <li...@ba...>]

Hi Nils,

thanks a lot for your email


Nils Toedtmann wrote:
> Hi Mathew and Joerg!
>=20
> 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
>=20
> Moved it over to opencoin-devel, seems more appropriate to me.

Fine

>=20
> Read my awnser to questions 9 first, that's the interesting part ;-)
>=20
>=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?
>=20
>=20
>>>> - The code only supports one type of currency during a
>>>>   transaction between wallets
>>> Fine for now
>> ack
>=20
>=20
>>>> - 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.
>=20
>=20
>>>> 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?
>=20
>=20
>>>> 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]
>=20
>=20
>>>> 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.
>=20
>=20
>>>> 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

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

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

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.

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

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.


>=20
>=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

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


I think it should deliver future keys as well, returning

 MINTING_KEY_PASS(keycertificate,[keycertificate...])

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

Ok, so random number is it.

>=20
>=20
>> #### damned, time running out. stopping now
>=20
> Woke up again.
>=20
yeah

>=20
>>>> 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)]
>=20
>>>> 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)]
>=20
>=20
>>>> 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 ...

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.

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

OK, so I propose a

	HANDSHAKE(protocol version, subprotocol)

with subprotocol being something like "sendMoneyProtocol", indicating
what we would like to do.

The other side can response with either

	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.

E.g. the Issuer could then return something like

jitm=3D1,prepaid_only=3D1,someotherstuff=3Dfoo

with that we would not rely on the order of things. A bit like the
headers in the http protocol.

What do you think?

>=20
>=20
> [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), =
=2E.. ) )

Fine with me

>=20
> transaction_id=3D0 means mandatory JITM (which may get rejected). Issue=
r
> may accept

may accept with...

>=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",

Looks good to me


> * Yes, you are right (and i think Joerg once voted for this, too):

Ack

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

I assume thats a very often used transaction. I like it

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

+1

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.

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

I think its ok to leave it as it is. The (small) inconsistency could be
allowed.