Quote from: TPTB_need_war on January 13, 2016, 07:30:56 PM

IoT is an entirely new concept for me, and I am just now reading the GadgetCoin white paper. I have not had time to study the W3C working group or any other resources on this topic. Note I did make a supportive comment early on in this thread, commending the attempt to create user level apps utilizing crypto-currency.

Thank you very much for your supportive comment back at the time and your post now.

Quote from: TPTB_need_war on January 13, 2016, 07:30:56 PM

Why have IoT private databases? Use encryption instead, which is more secure. Network intrusion is impossible to 100% prevent, even if you use a sneakernet, e.g. the Stuxnet attack.[/li][/list]

It is encrypted even on the private device node. We thought it is necessary to keep the transaction information not only in the public blockchain, but on the node level too. We were trying to solve privacy and provide anonymity at the time, but soon we realized anonymity is not possible without trusted nodes. The idea was, don't give full power to the trusted nodes in managing the data and don't rely 100% on the honesty of trusted nodes, don't assume the trusted node will always return the correct data. The individual nodes keep the transaction data locally to prove the balance and transaction history. Most likely it is an unnecessary complication.

Quote from: TPTB_need_war on January 13, 2016, 07:30:56 PM

Low-power, resource constraints favor Winternitz signatures over ECDSA for authentication in terms of the CPU cost although the bandwidth cost rises exponentially compared to ECDSA as bit-security increases. For encryption, a Diffie-Hellman exchange will be required to establish a shared encryption key, but this will not be a real-time requirement.

Currently the system uses FIPS compliant ECDSA and EC Diffie-Hellman for key exchange. We will look into the Winternitz signatures.

Quote from: TPTB_need_war on January 13, 2016, 07:30:56 PM

Afaics, smart contracts incur the multiplicity of verification cost. The only solution I thought of is zk-snarks, but then the proving cost is very high, which isn't applicable to low, resource IoT/WoT. Seems contracts for IoT will need to be hard-coded efficient scripts, unless another technical solution can be devised.

You assumed correctly, all current contracts are hard coded. We don't have a turing-complete scripting language for smart contracts in the system. We thought it's not feasible to implement such module on low constraint IoT devices. The idea was that smart contracts could be very useful in device provisioning and device management, but it seems businesses and end users don't see a lot value in smart contract. The smart contract concept on IoT devices needs to be revisited.

Thank you!