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

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

Hi *,

I will start replying to this email, because its newer, also deleting
stuff, because its getting a bit lengthy....

> In general: lets try not to make thing more complex than they already
> are before we have a running system. When we have a working play

This is _absolutely_ my opinion. I am very afraid of falling into an
abstraction/complexity trap. I would be much happier to have a running,
somewhat simple solution, than a half ready complex solution.

>> Does it make sense to support two different currencies in the same
>> wallet transaction?
>=20
> Wallet to wallet: yes

Disagree. I would say lets go one currency all the way - one currency in
the issuer, one currency in the transaction. Leave the whole multiple
whatever to later versions of the protocol.

Also: how often have you done multiple currency transactions in real life=
?


> I have a slight bias towards atom=3Dcoin, but i do not really care.

I guess that means that I am atom=3Dlist of coins.

> Again, i stongly vote for hiding the DSDB behind IS. At least for now.
> Otherwise we make the protocol more complex than nessecary. Make IS
> resistant by cloning/distributing it.

+1

> But i agree that LOCK requests (which go through the IS to the DSDB) ma=
y
> have to use a different public key than the other requests to the IS. S=
o
> having a DSDB key in addition to the IS key is still a good idea.

+0

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

Ok we could, but what would be the benefit? I don't see it...

> transaction. So maybe we should _always_ work with non-zero TIDs. If we=

> want to signal things like "JITM required" we should not do that via
> TID=3D0 (was that me who supposed exactly that?)

ok, so we have a jit flag.


>> IIRC, the reason I was doing it between the Locking and the Redeeming
>> was for simplicity. I cannot come up for any other reasons at this
>> time.
>>
>> *shrug* I'm happy to remove any requirement like that.
>=20
> Me2

+1


> ack
ok

> Do we ever ask for keys instead of certificates? Shouldn't we replace
> "KEY" with "CERT"?

good point

>   FETCH_CERT( MINTING [, DEADLINE=3D$deadline] [, DENOM=3Dlist(denomina=
tions)] )
>   FETCH_CERT( IS      [, DEADLINE=3D$deadline] )
>   FETCH_CERT( CDD )

Fine with me.

>>> uppercase signalling a critical extension. On the other side, there i=
s

No. I don't like the whole idea of casing being significant.
> So we agree that *some* information will be in the handshake, in
> addition to or updating the CDD information. Let's postpone the questio=
n
> *which* information belongs where, that's again "up to the issuer".

I would be rather happy to decide how we run our issuer, and then
abstract from there.

> Instead, lets discuss the syntax for passing name/value info in the
> handshake.=20

Well, right now I am quite happy with the json approach. So we would
pass an optional dict/array with key value pairs.


> What about *one* generic request/response type doing all that? Somethin=
g
> like:
>=20
>   TRANSACTION( transaction_id, options, target, list of blinds,=20
>                list of coins)

OK, if its not named transaction. Maybe SEND_COINS?


>   * coin exchange: empty. Value of blinds and value of coins have to be=

>     the same.

rather 'coin_exchange'

>   * underpaid: a payment identifier. List of coins either empty (pure=20
>     minting request) or value of coins less that value of blinds

? not quite getting it. I would say that you always try to get all
blinds minted. I also would not do mixed payment in one go. So either
pay by target (empty list of coins, list of blanks, target =3D
'account:123 / whatever') or do a coin exchange.

>   * overpaid: an account identifier. List of blinds either empty (pure =

>     redemption) or value of blinds less that value of coins.

Again: either coin exchange, or list of coins, empty list of coins,
target =3D 'account:123'

I don't like this whole mixed thing, because you can have multiple
problems at the same time: invalid coin, invalid account, invalid blank,
whatever. And the whole problem reporting and answering gets more
complicated. And harder to debug.


> types or only pure exchange/mintingrequest/redemption. For now we shoul=
d
> require that either both lists have the same value or that one list has=

> to be empty.

+ quite a lot.

> FETCH_MINTED_REQUEST as if resuming a stalled TRANSACTION:

Na, lets leave that. I like the request to have some form of coherent
format.

> Yep. Most of them have to be unguessable by mallory. So making 128 bit
> random bits mandatory is fine.

Ok. Who is putting this all into the protocol, btw?

Cheers,

  Joerg