Update of uCoin clients code (python versions)

Since the uCoin protocol changed deeply during these last months (thanks @cgeek ;-)), I wanted to start adapting the python version of the uCoin clients already existing but not working anymore. I think we get a strong basis regarding the WoT guidelines that should not change before a while. The goal of this topic is to deal with this task and bring back any issues I can encounter during the process. You could find both the projects I have intended to update below:

@cgeek, I already have a first question regarding the change from PGP to Scrypt, should I encrypt messages as we were doing with PGP ?

The API services named hdc, pks and ucg are no more available and have to be replaced by the ones available for now that are wot, blockchain, network and tx.

network is nothing more than ucg renamed.

There is no encryption anywhere, and I don’t remember we had once.

About Scrypt & keys in general, I guess you understand that we generate keys out of thin air (well, out of salt + password). I know this is really useful if we don’t want to store the key, but what if we would like? Do you plan a way of storing the key using encryption with a passphrase?

About API services: you are right.

Yes we had, but like a signature and thanks to the node PGP public key, each time the client got a message the message was verified using both clean and signed texts.

Regarding the salt + password usage I know it but I have not thought about any solutions saving these data yet, but you are right asking the question since the problem did not exist with PGP. I guess I will not store anything and ask to the user to pass them to the functions, same thing occurs for webclient but it should be a feature suggesting users to save or not these data.

Ok, you were talking about multipart/signed, weren’t you? If yes, indeed there is no more such feature. We do it at the application layer, where every message has a signature in it (see UCP, every message should be authentified).

Yes, I personnally would like to save my key somewhere, encrypted of course, with the ability to change the passphrase. Thanks @canercandan :smile:

Yes it’s exactly what I am saying. When you say application layer, you mean client right ? But how far is it different from the old protocol since I had also verified the message signature before.

For instance such a command line provide the following content:

$ curl http://ucoin.twiced.fr:9101/blockchain/current
  "version": 1,
  "nonce": 3,
  "number": 6,
  "timestamp": 1412153831,
  "membersCount": 7,
  "currency": "beta_brousouf",
  "issuer": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk",
  "signature": "5IW8Fg0Y9JAZ3Ac21ZlEHQ/fXEwj8/rwXqe/wblMMQYZk/ZLl4uXc0YcSHkf4iHXGXJsYfA4y4g/LNnp2dSzBg==",
  "hash": "08EF413C4906C4C3C014ECF486F7440D0B0B2163",
  "previousHash": "00CADDD560FB44183BF0FFFD6B1DC47E2171A2DC",
  "previousIssuer": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk",
  "dividend": null,
  "fees": null,
  "membersChanges": [],
  "identities": [
  "joiners": [
  "leavers": [],
  "excluded": [],
  "certifications": [
  "transactions": []

And I see that’s in the JSON dictionary

returned there is a signature as well, so does it mean I have to use it and thanks to the server key check that ?

Sorry if there is a misunderstanding on this point I forgot some points.

Indeed this feature still matters.

Ok I just remembered it was specific to the uCoin-web client auth mode usage where we wanted to ensure every messages were well coming from their owner. Question still remind is any auth mode still needed ? :wink:

No more :slight_smile:

Before, you had a 2 step authentication: 1 was the multipart/signed where we verified the message did come from the server (the HTTP response), but we also had another signature for the document. The HTTP signature was made on-the-fly, while the document signature was made by its author when he emitted the document.

Hope I am much more clear!

Yes thanks much more clear :wink:

A new release of ucoin-python-api has been released (v0.10.0). The new protocol is entirely supported (even though there are still lot of new features to add in this protocol).

The changes to apply to the web-client will follow.

Here is a few example of how to use it:

In [1]: import ucoin_python_api as upy
In [2]: ch = upy.ConnectionHandler('ucoin.twiced.fr', 9101)
In [3]: upy.blockchain.Block(ch, 3).get()
{'membersChanges': [],
 'number': 3,
 'nonce': 1,
 'hash': '09813779721C1C6246DC54D2923B1AEEEDD792EF',
 'previousHash': '09B4C743268C36C59FEA30D3E8D81A4440A80981',
 'certifications': ['HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk:C4LcanvvGPwuJZofxRun6maux2qBLh2MTyq7rHnm24hD:1411716383:SajvOOKQ4DGG5IJKq3VK/BUxfVP4mRtcuYFx2Q2a2GPXbTrXAuWExiMlnctCO4zx8wgqWIyiS7X6CHkFEooeCA==',
 'signature': 'H+ZR3b+Y39b/gq59rjedQV89x991+B46C76CfG6STEdjADRU/BKgZ+UFEW04oblzbxmAYNvBXZw5vLoJYnzeAA==',
 'previousIssuer': 'HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk',
 'timestamp': 1411709213,
 'fees': None,
 'currency': 'beta_brousouf',
 'joiners': ['C4LcanvvGPwuJZofxRun6maux2qBLh2MTyq7rHnm24hD:CU8WNYGhOArn7aBCTvFb/rW9O+BpRSZcAfyVvynp+cWy5pFY1Ds7TtR/+fnwN35ub3garv1q6bKBsWt2yWegBA==:1411681631'],
 'excluded': [],
 'version': 1,
 'transactions': [],
 'identities': ['C4LcanvvGPwuJZofxRun6maux2qBLh2MTyq7rHnm24hD:CfC4O5IfW/01TZD3zxTzZfDllPZrpV44iFq/1T6D1mcUJfK7IDildLkqkI6W6/Hu/b5gU9QcJdnDFZh6WlmSDQ==:1411681459:moshe'],
 'leavers': [],
 'dividend': None,
 'issuer': 'HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk',
 'membersCount': 4}

Entirely? :slight_smile:

Anyway, it is a good news you are updating your API! I know someone who might want to use it be the end of october :wink: (maybe)

Will be glade to see someone use it again :wink:

BTW, I hesitated a lot regarding the version number, since we changed everything on the protocol, does the major number be incremented or not, but I finally chose to not use this way since we are still in a brainstorming step. The major number will be incremented only when we declare protocol are mature enough to be used.

1 « J'aime »

Just realized I forgot to implement blockchain/current service will do it ASAP.

@cgeek do you foresee to implement an API service that returns the whole state of WoT ?

Dunno if it is wisheable, since each pubkey is ~32 bytes, meaning a 100k members WoT would require a 3.2 Mb response, which is rather big :confused: It is probably better for clients to sync with the blockchain for blocks <= 1 year old. This way, the whole WoT can be computed.

But the API is not fixed, we can add several methods. If you have any idea, with the data volume issue in mind, do not hesitate to propose some!

I have thought about using Merkle tree, do you think it could help fixing this issue ?

The whole point is to split up the data, indeed. Merkle tree could do the job.

We could for example have Merkle URL where each leaf represents a pack of 1.000 users. What do you think of it?

Ya it’s a great idea :wink:

Added issue: https://github.com/ucoin-io/ucoin/issues/30

Thanks @cgeek, I am looking forward to seeing this feature usable :wink: