NEM - 100% new code. Easy APIs. Integration with Bank and over 5000 Business



  • Nem Release Nano Wallet v 1.4.13

    Changelog

    • Allow sub-namespaces and mosaic names to start with a number
    • Fix secondary accounts: In occasional cases, secondary accounts private keys can start with '00' but BIP32 was omitting it, giving a 62 characters private key. Those secondary accounts will fail to send anything out even if password is valid (but recoverable).
    • Update languages

    Sha256sum

    Cross-platform: 7121e96fe105c76b8475bb55b7206a0377c4a864129f1c4da780e4120b9ed58e Linux64: ad847eb23c28c0015f14352d790ee5f9bddab3dfd0afd18be9bce71c66b6dafa Osx64: 5ad6572a60e3f9ee473767d784387fd3cb2881ed7ae29650702e7cce7b00a1f4 Win64: 55a4eb5582cb7fd5c09faad73f8aecada6b79591e5b42aa39484e9c941d2d753

    Download:https://github.com/NemProject/...



  • Status of the NEM Library Project

    We would like to make an announcement on the project that was proposed by Aleix and Guillem on the NEM Library earlier on, seeking funding from the community fund to the tune of 1 million XEM.

    The response from the community has been a resounding yes, for the project to go ahead. The core team has done some deliberation on it and they are of the opinion that both Aleix and Guillem’s contribution and work are valuable for the greater NEM, and that they should be considered for permanent employment by the foundation instead.

    We have decided that the community should only fund them for the work they have done to date (i.e., 600K XEM) and have them paid by the foundation from there on as employees.

    Both Aleix and Guillem have gracefully accepted our alternative offer. To that end, they are now employed under NEM.io Foundation as part of our plan to expand and recruit more programmers.

    Catapult is more or less completed for its beta release, but the project is huge. As you can imagine, it took us 15 months to release NEM version 1. But the Catapult is already taking 20 months now. Further, the design of the Catapult is based on knowledge already known to the NEM developers during its first iteration. Obviously, a lot more design work has been put in place to make the Catapult a better project.

    Both Aleix and Guillem were drawn into the project immediately to help expedite and hasten its completion. Their involvement was to work on the APIs so that they can be documented, tested, and expanded.

    Aleix and Guillem have reviewed on the catapult features, ideas and concepts. They have been working on the NIS2-API (i.e., Catapult API) and have been testing them. Lots of hours have been spent on finding ways to automate the generation of SDKs for different programming languages. We must report that they seemed to have found a good architecture for this automated generation of SDKs.

    These include:

    Creating API generator routes and models. Implementing integration tests for all endpoints to validate correct behaviour of APIs. Coming out with a solution to test different serialization libraries to build transactions. Verifying these serializations by creating end to end testing for all transactions implemented in the Catapult.

    More work is still required. These will include:

    Generating a shippable nem-javascript-sdk adding websocket support and other features. Generating SDKs in other languages. Exploring options for a complementary GraphQL API End to end blackbox testing

    Jaguar0625, our lead programmer has been very pleased with their progress thus far. With additional help, it is hoped that the Catapult can be completed earlier.



  • NEM (XEM) Release v0.6.93

    Merge branch 'testnet2'

    Download:



  • NEM Hot/Cold Wallet: The First Ever NEM Cold Offline Wallet You Can Use To Send And Receive Funds

    The NEM team would like to thank Anthony (Telegram user @antownee) for creating this app and blog.

    NEM Hot/Cold Wallet

    Index

    Part 1: Introduction Part 2: Build the first ever Hot/Cold Wallet Part 3: Tuturial on using the Hot/Cold Wallet

    Part 1: Introduction

    In this blog, we introduce a new and revolutionary idea in cryptocurrencies and blockchain technology. We will set up a cold wallet, i.e., a wallet that has never touched the internet, that is also a hot wallet, i.e., a wallet that can easily send and receive assets. This means a user has the security of an offline cold storage but that they can actually send and receive XEM. This is thanks to NEM's powerful APIs and tiered architecture designed from the ground up with 100% new code.

    The advent of cryptocurrencies has seen an increase of interest and investments into this new space and with this comes the need to focus on security. Fortunately, in an ideal situation, blockchain technology is built with this in mind, provided you are in control of your private keys.

    NEM is consistently ranked in the top 10 via market capitalization and provides an easy and intuitive way to interact with its blockchain to further help developers and users alike bolster their security. To achieve this, we shall essentially implement "air-gapping" a wallet; meaning this wallet will never touch the internet nor directly connect to another device that is connected the internet (e.g., hardware wallets), yet still be able to send and receive cryptocurrency.

    So what can you do to ensure more safety? Well, if you have two computers, you can always keep your private keys separated from the internet, protecting them completely against cyber attacks. All you have to do is, create your transaction online, sign it offline to protect your keys, and broadcast it online again. This is what is known as “air gap” protection or "cold storage."

    "Air-gapping"

    The idea behind air-gapping is to have two separate devices. One that can access the internet and the other that will NEVER connect to the internet. The emphasis on the NEVER is quite clear as this is the device that will hold your private keys; in this case, we will use an Android phone that is no longer being regularly used. What we are essentially doing is splitting the transaction creation and signing from the broadcasting of it. The creation and signing will be done on the offline device while the broadcasting will be done on the online device. This has in theory been possible before in the past by technically savvy devs, but for the first time, we are now offering an experimental app that almost anybody can use and without having to buy additional hardware. It should be noted that this is an experimental Proof-of-Concept app and should be treated as so and used with caution. The NEM team is not responsible for the loss of any funds that occur as a result of using this app.

    Part 2:

    Development process

    Create-sign app (Cold)

    Both apps were built using an Ionic framework to enable cross-platform compliance. As well, the nem-SDK was used extensively for this app which is available on npm via npm install nem-SDK

    For the creation-signing app, I had to achieve the following:

    • Scan mobile account QR
    • Decode QR and wallet to retrieve private key
    • Use obtained private key to create and sign transaction
    • Generate QR

    I won't go into detail about the entire process but here's the GitHub link to the full code.

    However, I'd like to talk about the bit that proved challenging as it wasn't properly documented: Decoding QR and decrypting wallet.

    Decrypting the QR code was fairly straight forward and it yielded a similar json object:

    // Foo
    let walletinfo = {  
    "V" 1, 
    "type" 3, 
    "date": { 
    "name": "test-WLT" 
    "priv_key":"23a57b49fbac363aa2a9d8d5421930b14c3c55fa96a4c675611766207fdf67a61ded08686f72d874db7cb057354dcae7115cf69c1fe33c57af4a891f346a7e07", 
    "salt":"580e102a1b834b2ded7dcb26f683af4097e57a6803b01cbc343216a4d52dd7e0"
        }
    }
    

    The following function was used to decrypt the wallet with the above object

    // Decrypting wallet
    decryptWalllet(walletinfo, password) {  
            return new Promise((resolve, reject) => {
                let salt = CryptoJS.enc.Hex.parse(walletinfo.salt);
                let encrypted = walletinfo.priv_key;
                let key = CryptoJS.PBKDF2(password, salt, {
                        keySize: 256 / 32,
                        iterations: 2000
                }).toString();
                let iv = encrypted.substring(0, 32);
                let encryptedPrvKey = encrypted.substring(32, 128);
                let obj = {
                    ciphertext: CryptoJS.enc.Hex.parse(encryptedPrvKey),
                    iv: convert.hex2ua(iv),
                    key: convert.hex2ua(key.toString())
                }
                resolve(CryptoHelpers.decrypt(obj));
            })
        }
    

    The result of this function is the wallet's private key with which it will create and sign the transaction.

    // Sign Transaction
    signTransaction() {
            // Set the private key in common object
            this.common.privateKey = this.nemPrivatekey;
            // Check private key for errors
            if (this.common.privateKey.length !== 64 && this.common.privateKey.length !== 66)
                return {
                    error: true,
                    message: 'Invalid private key, length must be 64 or 66 characters !'
                };
            if (!nem.utils.helpers.isHexadecimal(this.common.privateKey))
                return {
                    error: true,
                    message: 'Private key must be hexadecimal only !'
                }
            // Set the cleaned amount into transfer transaction object
            this.transferTransaction.amount = nem.utils.helpers.cleanTextAmount(this.nemAmount);
            // Recipient address must be clean (no hypens: "-")
            this.transferTransaction.recipient = nem.model.address.clean(this.nemAddress);
            // Set message
            this.transferTransaction.message = this.nemMessage;
            // Prepare the updated transfer transaction object
            var transactionEntity = nem.model.transactions.prepare("transferTransaction")(this.common, this.transferTransaction, nem.model.network.data.mainnet.id);
            // Create a key pair object from private key
            var kp = nem.crypto.keyPair.create(this.common.privateKey);
            // Serialize the transaction
            var serialized = nem.utils.serialization.serializeTransaction(transactionEntity);
            // Sign the serialized transaction with keypair object
            var signature = kp.sign(serialized);
            // Build the object to send
            var result = {
                'data': nem.utils.convert.ua2hex(serialized),
                'signature': signature.toString()
            };
            // Show the object to send in view
            return {
                error: false,
                message: JSON.stringify(result)
            }
        }
    

    Thereafter, a QR code will be generated which will then be scanned by the broadcast app.

    Here’s the code in its entirety for your perusal.

    Broadcast app

    The broadcast bit was fairly straightforward. All it had to do was scan the generated QR code by the cold wallet and broadcast it into the blockchain by making a POST request to the given endpoint.

    Note: This end-point was selected from a list of available NEM mainnet nodes that are accessible here.

    this.nodeUrl = "http://62.75.251.134:7890/transaction/announce";
    //Broadcast transaction
    broadcastTx(signedTransaction: any): Promise<any> {  
            this.signedTx = signedTransaction;
            let headers = new Headers({ 'Content-Type': 'application/json' });
            let options = new RequestOptions({ headers: headers });
            return this.http.post(this.nodeUrl, this.signedTx, options)
                .toPromise()
                .then(this.extractData)
                .catch(this.handleErrorPromise);
        }
    

    Here is the entire code repo up on GitHub.

    Part 3: Tuturial on using the Hot/Cold Wallet

    Overview

    An extra layer of security while moving your funds is added by the use of paper wallets. In achieving so, you will have achieved an almost completely cold wallet environment. As previously explained, you will need two smartphones where one will never connect to the internet while the other does. Alternatively, a wallet could also be created via an offline iOS/Android/NanoWallet app and backed up before moving the wallet to the transaction signer app.

    We suggest using an unrooted Android phone with freshly installed OS on it. Then to install the transaction signer app, and then turn the phone into airplane mode for the life of the device. Note: connecting the app to the internet after turning on airplane node negates the security provided by having an offline signer application.

    Install the apps as follows:

    • Transaction Broadcast app: Install it on the phone that will connect to the internet.
    • Transaction Sign app: This will be installed on a smartphone that will not connect to the internet

    Advance preparation

    In this step, we will create a paper wallet, preferably on a PC that is not connected to the internet. This further bolsters our cold environment approach to moving our funds to and from our wallets. Download the paper wallet generator app and follow the below information:

    Description
    • The QR code on the left has account address information of NEM that can be openly shared with anyone. Funds will be credited by remitting to this address.
    • The QR code in the upper right has information on the private key encrypted with the password. Both the NanoWallet and smartphone apps have the same structure as QR which contains the private key.
    • The lower right QR code is the private key itself. A general QR code reader can read the secret key string itself.

    How to withdraw funds from Cold wallet

    NEM Hot/Cold wallet

    Launch this app on your old smartphone or on the phone that will not connect to the internet. This is the app that signs your transaction offline.

    Description
    • SCAN WALLET QR: We are able to obtain your private key by scanning the QR code in the upper right corner of the paper wallet.
    • MANUAL ENTRY: Enter the destination address/remittance amount/message/private key manually. However, it is also possible to scan a prepared invoice QR code. Invoices can easily be made in the NanoWallet or Android/iOS NEM apps available at nem.io.

    SCAN WALLET QR

    Enter the password in the popup to decrypt and obtain the private key.

    After inputting it, the QR reader will start up, scan the QR code and eventually fill in the private key field of the provided wallet.

    On this screen, the private key is automatically filled on successful decryption. If you have a prepared invoice QR, you can hit 'SCAN INVOICE' which as before, with prompt the camera to scan your invoice QR code. Therefater, your 'NEM address,' 'Amount' and 'Message' fields will be automatically filled.

    Upon filling of all required fields, the 'SIGN TRANSACTION' button is then enabled.

    Once the 'SIGN TRANSACTION' button is pressed, a new page appears containing the eventual QR code that should be broadcast to the network.

    This QR code will be scanned by the 'Transaction Broadcast' app.

    Transaction Broadcast app

    Launch this app that you have installed on your regularly used smartphone. e.g., the one that is connected to the internet.

    Description

    SCAN QR CODE

    Press the SCAN QR CODE button and scan the generated QR code on the 'NEM Hot/Cold' wallet app on your other phone.

    Upon a successful scan, the 'BROADCAST' button is enabled, and the transaction can be broadcast on to the NEM network.

    A successful broadcast will give a similar message as shown below. Complete with a transaction hash and a 'Success' or a 'Failure' message.

    In case of insufficient funds etc., an error message will also be displayed.

    And that's it. You have now received and sent from an offline wallet, the NEM Hot/Cold Wallet.

    Source:https://blog.nem.io/hot-cold-w...



  • The Healthcare Blockchain and NEM


    The NEM team would like to thank Telegram user @Aenima86 for contributing this blog

    This blog post will discuss the potential of using the NEM public or private blockchain for data management within the healthcare sector. This could lead to several important advantages.

    • Patient-centered access management
    • Improved data security
    • Improved sharing of patient data
    • Increased data availability
    • New opportunities for medical research
    • Inclusion of wearable sensor data
    • Inclusion of Patient Reported Outcome Measures (PROM)

    The use case

    Hannah is a chronic diabetes patient; she needs to regularly visit the hospital and her general practitioner (GP) for monitoring of her disease status. This includes several blood samples and a yearly eye exam. Besides routine checks, she also daily injects herself with insulin with subsequent measurements of her blood glucose. Furthermore, she also uses a Fitbit to track physical activity and sleeping patterns. Hannah generates a lot of data, and it is difficult to keep track of all her data and which persons have access to her data.

    A well-designed healthcare blockchain solves many of her problems. All of her devices are linked to the blockchain, uploading measurements into the chain. She can overview all her data from one application. Both the data generated by herself and the data generated by the hospital are now at her fingertips. Moreover, she can view and control which persons have access to which part of her data. Maybe she would like to share sleeping patterns with a diabetes clinician at the hospital. On the other hand, she might not like to share the results from her other specialists (mental health/transmitted diseases/drug treatment), as this may not be relevant for the treatment of her diabetes.

    Background

    Blockchain technology has the potential to disrupt and improve the way we utilize and share patient data. Cross-institutional sharing of patient healthcare data is complex and as a consequence data is not always available for a healthcare provider treating a patient.

    Furthermore, the patient is often left without control of their personal healthcare data and not involved in which persons have access to which part of their information. Ideally, the patient would have control over their data and thereby also potential empowering the patient to be further involved in the treatment. Many patients do already measure a broad range of disease indicator data such as vital signs, medication compliance, exercise, sleep quality, physical functioning, diet, mood and life quality. However, these data are not always utilized by the healthcare provider because of technical difficulties in sharing these data sufficiently.

    How can we use the NEM platform

    Blockchain technology has potential to solve many of these challenges in healthcare data management, especially the NEM public or private blockchain platform is suitable for patient-centered governance of health data. The concept consists of using multi-signature contracts for access-control of data management and encryption of data to allow privacy and control of one's healthcare data.

    Furthermore, the blockchain is an ideal platform agnostic database for many different service providers and consumers to share content. NEM works via JSONrest API meaning that each company with its own proprietary system can easily connect to the NEM protocol to share data while remaining fully firewalled and secure. In this case, NEM provides a secure and encrypted medium for cross-platform exchange.

    The patient will have full access to his data and control over which persons/institutions her data will be shared. The patient can set access permissions and designate who can read and write healthcare data to his account. This access-control management could be utilized using an off-chain application. The application would allow the patient to see which persons/institutions have access to data and allow the patient to assign new permits and revoke already issued permits and/or make limited time sessions for reviewing data.

    This concept would provide transparency and allows the patient to make central decisions about what healthcare data is collected and how the data is shared between relevant persons/institutions.

    In one model for providing blockchain based healthcare records, when a healthcare entity is approved access to the patient's’ health data, it queries the blockchain for the data and uses the account bound key mixed with a SALT to decrypt data. Second layer intermediary software can act as a further form of encryption with the data encrypted with a SALT that is time bound. The healthcare entity could utilize a customized application to view and analyze the data. Querying the blockchain is API-based, and this would allow any programming application to interface with the blockchain. This means that a hospital using an EHR system could easily integrate their system with the NEM blockchain.

    In another model, the architecture is built around cryptography, mosaics (NEM assets) and the multi-signature contracting available on the NEM protocol. The multi-signature contract enables several entities to admin the activity of an account, control assets from one account, such as mosaics, or create additional contracts. NEM’s multi-signature makes a contract that assigns rights and powers of a certain account to other accounts; this contract can be edited. You can create the multi-signature contract in such way that any number of the signatories need to sign a transaction. This is called m-of-n multisig, where m can be any number equal to or less than n. In the architecture of the healthcare blockchain, we would use a 2-of-n multisig contract.

    In such a case, the patient would control two keys in the contract and each healthcare entity included in the contract associated with the patient's account would hold one key. This means that the patient will remain in control of the account because he has the required number of keys to edit the contract. Healthcare entities still have the ability to view the account information (such as encrypted messages) and initiate transactions. The patient would still need to co-sign transactions initiated by other entities, but that could be set up to be done automatically or within certain rules in the off-chain application layer.

    New data would be stored on the blockchain in the following manner: the patient or a healthcare entity with at least one key associated with the patient’s multi-signature account would initiate a transaction, sending a data-mosaic with included data as a message. The message would be encrypted, and the decryption key would be sent back to the multi-signature account in another transaction. When the data-mosaic transaction is co-signed manual or automatic the transaction is sent to an account related to that specific data type. This ensures that only persons/institutions with access to the patient's multi-signature account can read the patient's data using the decryption key(s). In practice the patient would control several multi-signature accounts – each account would be allocated to a specific type of data. This architecture would allow differentiating access to different type of data between healthcare providers.

    In yet another model, data can be encrypted with Shamir's Secret Sharing model. In this method, each data input can be sent with multiple passwords. There can be an individual password just for that line of data and message, or passwords that are included for multiple messages and therefore unlock multiple blocks of messages. This latter example could be used to associate a set of messages with a doctor, hospital, or medical record category. So, for instance, a patient that wanted a specific doctor to see said information can include the doctor's secret key in each message. Or in the case that one patient had multiple doctors in many regions over long time spans, they could have one password that unlocks all the messages for those specifically related health issues.

    In some cases, a patient is not capable of releasing their records due to their medical condition. In the case the patient is incapacitated, the necessary access permit in cases of emergency where the patient is unable to approve new persons for reading and viewing rights can be solved by using a trusted party. A trusted party could hold an additional key-pair, and the emergency procedure can be regulated by local legislation.

    Data with large volumes such as medical images are not suitable for storage on the blockchain. This can be resolved by adding a data lake storing encrypted data with references in the blockchain holding the decryption keys. Data lakes are highly scalable and can store a wide variety of data such as images and time series.

    Another viable option already being applied to some blockchain projects is to apply the above-mentioned methods with IPFS where each file is stored in encrypted format on distributed servers hosted by healthcare providers and can not be accessed without both the link and the password to decrypt the data. These can be encrypted or secured with the methods in the sections above for privacy and security.

    Remarks

    The potential for improving healthcare data management is enormous. The healthcare sector is known for being conservative in structural changes. Hopefully, this blog and similar ideas could lead the way and demonstrate that already working and proven technology, such as NEM, could be used for implementation of ‘The healthcare blockchain.'

    Working Applications on NEM

    One such company in India specializing in AI, Big Data, Blockchain, and IOT, RapidQube Digital Solutions, has already been a working prototype built on the NEM Blockchain implementing an advanced medical health records application.

    Their app utilizes the NEM protocol to allow patients to share selective medical records with their medical care providers in time locked sessions on an as-needed basis. This gives patients full rights to their data and makes them more active participants in their treatment process.


    Credits

    Icons made by DinosoftLabs & Freepik from www.flaticon.com, Creative Commons BY 3.0

    .



  • ioNEM - Transferable, On-Chain IoT Ownership with NEM


    The NEM team would like to thank Nikhil Jha (Telegram @ReverseCold) for contributing this project.

    The Internet of Things (IoT) is a massive developing category with a lot of potential applications. Unfortunately, many IoT implementations today rely on a centralized server to stay operational. Alongside the IoT movement, we have the blockchain movement, which provides distributed, secure computer systems to use. Let's combine the two categories into one using our very own NEM blockchain!

    What We Can Do

    1. Facilitate the ownership of one or a group of IoT devices of any kind on-chain.
    2. Control, manage, and secure the daily use of IoT devices off chain (fee free and secure).
    3. Allow IoT devices to communicate with others through the chain if necessary.

    The third point is not discussed in this blog post, but here are a few scenarios where it could be useful.

    An IoT device breaks and needs a replacement part. The IoT device sends a message to the user's phone with an order for the replacement part as well as labor costs to fix it. The user approves of the order, and the IoT device is fixed.

    An IoT solar panel produces extra energy that the owner does not need. Other IoT devices want cheaper energy than the normal on-grid provider, so then they make an off-grid bid for that electricity and the IoT solar panel sells it to the highest bidder. This can be done either with approval from the user or without in the case it is automated with an off-chain smart contract.

    The Basics

    There are a few NEM concepts that are central to this project. In this section, I will give a quick overview of a few of them.

    With Apostille, you can notarize a file on the blockchain. The notarization process creates a new account which is "colored" with that file.

    In NEM, accounts can own other accounts, so one can make it such that they own the account that was colored with the file. The account colored with the file is now useless without the private key of the owning account. Additionally, the ownership of other accounts can be transferred by the owning account. These multisigged accounts essentially act as colored accounts that are updatable, can hold memos, and are transferable.

    Overview

    What if we created a file that represents a group of IoT devices? For example, we could create a file for a house. It would be a plain text file containing the address, description, permissions for that certificate, a random string, and any other relevant information all in plain English. It doesn't matter what the file is at all, since the actual action occurs on the blockchain.

    Once the file is notarized by Apostille, we have a private key account that can be owned by other accounts. Going into NanoWallet and converting it into a multisignature account with a single owner does exactly this.

    At this point, the owned account and its private key can be given to the IoT device. This enables an application to make a signed and encrypted request to the IoT device (for example, switch fan to speed 3).

    It is here that we run into a problem. In order for an IoT device to determine what account owns it, the device needs to make a request to an NIS. Unfortunately, it is possible for a 3rd party NIS to relay back malicious or incorrect information. The simple solution here is to run a node on every IoT device. Unfortunately, that can not happen due to space and processing constraints.

    This issue can be resolved by storing a list of 30-40 supernodes and picking a few at random to check from and verify the answer.

    Now that the IoT device has the public key for the account that owns it, the device is able to verify the signature, complete whatever action was sent to it, and send a signed/dated response to the sending application.

    Implementation

    Whew, that was a lot of information. Let's look at how we would actually implement this in an IoT device. Due to the current fragmented nature of IoT, there is no one platform to build on that would support this method. As such, here's everything you need to implement this system in your own devices. The author of this article has a homemade IoT system secured by NEM on a Raspberry Pi, which will be shown in the video at the beginning of this post.

    Key Generation

    First of all, an owned account must be created. This can be done by an end user through NanoWallet on any major desktop platform. Alternatively, a business could create a plain text file containing the company name and serial number of the device along with a random string and give it to the user to put into Apostille. The IoT device can then ask the user for the Apostille zip on setup and retrieve the relevant keys from there.

    An even easier solution for the end user is if the IoT device itself creates an account and securely transmits the private key of the account that owns it. The user can then remove the temporary account from ownership and replace it with their own account.

    The private key, even though it is temporary, should not be sent over the internet unless absolutely necessary (more on this in the next paragraph). The key can instead be displayed through any display the device has or locally using any other available method.

    If the private key were to be sent insecurely over wifi, an attacker could take the key and bind it to their own account. This would disable the IoT device, as the user can no longer bind the given address to their own. This means that while an attacker can not actually take over an IoT device without the user's knowledge, it is still best practice to show the key locally. In a future update to NEM, codenamed Catapult, upgrades to NEM's multisig and multiple txs in one called "aggregate transactions" will offer elegant solutions to this problem.

    Commands

    Commands can be sent to the device in whatever format is desired as long as they meet the following criteria:

    1. Timestamped with a reasonable amount of accuracy and precision.
    2. Signed with the key of the owning account.
    3. Encrypted with the public key of the device.

    It is also recommended to pad the commands with some random data to potentially reduce any unforeseen attack vectors with a specific vendor crypto implementation.

    The demo later in this video simply encrypts messages in the following format (before signing and encryption).

    UNIX_EPOCH/DEVICE_ID/{on | off}/RANDOM_BYTES  
    

    Sample Implementation

    Let's take a look at a sample implementation! If you would like to try this yourself, you will either need to have devices that are controllable by making web requests, or you can modify the code yourself to be anything you would like. This can be done with IFTTT if you would just like to see a demo, but note that using IFTTT doesn't give you the same security guarantees as a local, finalized version.

    IoT Controller / Hub Code

    For demo purposes, this can be run on any computer. In a final application, it would be run on an IoT hub. Alternatively, in a future where every device is its own hub, similar code could be run on each device.

    Controlling Application Code

    For demo purposes, this code needs to be run on a computer. Again, in any final vendor implementation, this would probably be a mobile application

    Additionally, no effort is made to do device discovery. The "IoT Hub" network address must be input manually. This is already implemented in nearly all IoT devices, and reimplementing it is complex as well as outside the scope of this demo.

    How to Use

    Apostille a picture of your house or an "IoT" device.

    Clone the hub and app from git. Edit app.js in your favorite text editor and replace the variables at the top with relevant variables.

    Do npm install to get dependencies.

    First, start the server with node hub.js and then run the client with node app.js.

    For more details (or an updated version of the instructions), please visit the Gitlab page: https://gitlab.com/nikhiljha/ionem

    sa



  • Nem Release Nano Wallet 2.0.2 - Testnet

    his is a TESTNET release, do not modify to use on Mainnet!

    Changelog

    • Fix password input showing if using trezor
    • Shows encryption fee message in fee input

    Sha256sum

    Cross-platform: 96575e67d574efc27095edaeb64c2d1e66ee9a356839a515b9eb32da1add401b Linux64: ab76ad7909affaf3ef7d0f91d5a070e271e07eb74c3248b1fef5279d1ad39f5b Osx64: 098b6c8b9ad2bf03c9f7afcac04fc4558a33d1405b0448b82a8cfcc73d5e1373 Win64: e8411a1f04a1b4a032130e11ce59d1c93bb9687635313b58a13a4dd4aea56dc5

    /!\ Linux64, Win64 and osx64 builds are experimental

    • Win64 build has problems with trezor #333

    Download:

    https://github.com/NemProject/...



  • TREZOR Creates Hardware Wallets for the NEM Blockchain

    NEM launches first NanoWallet with TREZOR login


    SINGAPORE/PRAGUE — December 21, 2017 — The NEM.io Foundation (www.nem.io), creators of the peer-to-peer NEM blockchain platform, and TREZOR today announced the launch of new firmware and integration into the NEM blockchain. NEM will also launch the first Nanowallet that allows unified login with TREZOR credentials. NEM joins other coins on TREZOR including Bitcoin, Ethereum, and Zcash.

    “Many cryptocurrency investors, traders, and users demand the security that TREZOR provides,” said Marek Palatinus, CEO of SatoshiLabs. “We’re happy to be collaborating with NEM to offer community more options when it comes to wallet security.”

    Along with providing support for XEM, TREZOR will also be able to provide support for assets built on the NEM blockchain. NEM’s architecture has been designed with 100 percent new code, and one benefit of this is all tokens are “native” tokens, which means anytime XEM is upgraded or support added by a third party, support for all assets created on NEM are also added. At this time, other assets being supported with this release are two assets for DIMCOIN, two assets integrated with the PacNEM game, and one asset for the Breeze project.

    “The NEM community represents some of the most savvy cryptocurrency investors out there, and we’re constantly working towards providing the best user experience,” said Lon Wong, President of the NEM.io Foundation. “We’re confident our integration with TREZOR will provide enhanced security in which the NEM ecosystem can continue to grow.”

    XEM is the world’s ninth largest cryptocurrency according to CoinMarketCap, with a market capitalization of US $8.1 billion. NEM’s technology is currently employed by a variety of financial institutions and industries. When considering demand and trade volume, NEM also boasts being one of the most popular altcoins in Japan.

    TREZOR is the first Bitcoin hardware wallet, offering unmatched security for cryptocurrencies and password management, providing ease of use for anyone from security experts to the general user. TREZOR’s design breakthrough allows the hardware wallet to isolate all private keys, with which transactions are signed. No confidential data is ever leaked to the computer, so even if the computer was ridden with viruses, a person’s NEM assets will still be safe.

    The TREZOR firmware update 1.6.0 or later can be downloaded from https://wallet.trezor.io/https://nem.io/downloads/.

    About Satoshilabs / TREZOR SatoshiLabs is the innovator behind some pioneering projects in the Bitcoin universe, from TREZOR, CoinMap.org to Slush Pool, the world’s first bitcoin mining pool. TREZOR is the first Bitcoin hardware wallet ever invented in the world. It offers an unmatched security for cryptocurrencies, Password Management, can be used as Second Factor, while maintaining an absolute ease-of-use, whether you are a security expert or a general user. For further information, please contact us at [email protected]

    A complete tutorial on how to use TREZOR with the NanoWallet can be found here.

    About NEM.io Foundation Ltd NEM.io Foundation Ltd. is a non-profit organization based in Singapore, set up to promote NEM’s blockchain technology globally. It is currently one of the most well-funded and successful blockchain technology projects in the cryptocurrency industry. NEM’s technology is currently being utilized in a variety of financial institutions and industries. For more information, please visit: www.nem.io Press contact NEM.io: [email protected] / +1-415-595-2030

    All other product and company names herein may be trademarks by their registered owners.



  • Nem (XEM) Core Release Wallet v0.6.95

    Merge branch 'testnet2'

    Download:https://github.com/NemProject/...



  • Snap Interactive Appoints Blockchain Pioneer and President of NEM Foundation to Blockchain Advisory Board

    Globally Recognized Blockchain Pioneer, Lon Wong, to Advise Snap Interactive on Blockchain Strategy and Execution

    NEW YORK, NY, January 3, 2018 — Snap Interactive, Inc. ("SNAP," the "Company," "we," "our" or "us") (OTCQB: STVI), a leading provider of live video social networking applications building on blockchain and other innovative technologies, today announced that it has appointed globally recognized blockchain pioneer and innovator, Lon Wong, to its Blockchain Advisory Board. Mr. Wong will be advising SNAP on its strategic development of blockchain initiatives as the Company extends its efforts to capture the growth and value creation potential of this emergent technology. Mr. Wong is currently the President of the international NEM.io Foundation Ltd. (“NEM Foundation”), which actively educates, develops and promotes the use of the NEM blockchain technology platform on an international scale. Significant developer adoption has fueled NEM’s XEM coin to obtain a market capitalization ranking in the top 10 of all crypto-currencies.

    "It is an honor to be invited to join SNAP's Blockchain Advisory Board. SNAP's move into the blockchain space brings many opportunities to apply the technology effectively to new secure live video solutions and I look forward to working together," commented Mr. Wong. Alex Harrington, CEO of SNAP, commented, “Lon is one of the world’s leading technologists and pioneers in blockchain, and it will be a great privilege to work closely with him on our development initiatives. Lon’s deep technical expertise and extensive industry experience as an early innovator of blockchain technologies will both be amazing assets to draw upon as we further the development of Backchannel, our secure video messaging application, and expand other blockchain initiatives.”

    About Snap Interactive, Inc. Snap Interactive, Inc. is a leading provider of live video social networking applications building on innovative technologies such as blockchain. SNAP's product portfolio includes Paltalk and Camfrog, which together host one of the world's largest collections of video-based communities, and Backchannel, a secure video messaging app built on blockchain, due to launch in 2018. The Company also offers FirstMet, a prominent interactive dating brand serving users 35 and older. The Company has a long history of technology innovation and holds 26 patents related to video conferencing and online gaming.

    About NEM.io Foundation Ltd. The NEM.io Foundation is incorporated in Singapore as a company limited by guarantee. The sole purpose of the NEM Foundation is to introduce, educate, and promote the use of the NEM blockchain technology platform on an international scale to all industries and institutions. The NEM Foundation is endorsed by an international network, compiled of a wealth of experience in IT, entrepreneurship, business processes, trading, property and asset development, international management and academia. The business’ ethos is to provide NEM’s blockchain technology platform to enhance enterprise whilst being run by the people, for the people. NEM’s team provides this through an array of support and education, from training events and service providers to technical support for the ecosystem. NEM Blockchain technology has the potential to change the way every industry manages its information and data. The NEM Foundation details the opportunities in every industry to effectively store transaction, customer, and supplier data in a transparent immutable ledger.

    For more information on SNAP, please visit http://www.snap-interactive.com.

    To be added to our news distribution list, please visit http://www.snap-interactive.com/investor-relations/investor-alerts.

    Snap Interactive Investor Relations Contact: Mike Cole VP, MZ Group 949.259.4988 [email protected]

    Forward-Looking Statements

    This press release contains "forward-looking statements." Such statements may be preceded by the words "intends," "may," "will," "plans," "expects," "anticipates," "projects," "predicts," "estimates," "aims," "believes," "hopes," "potential," or similar words. Forward-looking statements are not guarantees of future performance, are based on certain assumptions and are subject to various known and unknown risks and uncertainties, many of which are beyond the Company's control, and cannot be predicted or quantified and consequently, actual results may differ materially from those expressed or implied by such forward-looking statements. Such risks and uncertainties include, without limitation, risks and uncertainties associated with general economic, industry and market sector conditions; the ability to effectively develop and incorporate blockchain technology into the Company's applications; the ability to effectively integrate the operations of the Company and AVM; user acceptance of our updated applications; the Company's ability to institute corporate governance standards or achieve compliance with national securities exchange listing requirements; the Company's future growth and the ability to obtain additional financing to implement the Company's growth strategy; the ability to increase or recognize revenue, decrease expenses and increase the number of active subscribers, new subscription transactions or monthly active users; the ability to enter into new advertising agreements; the Company's ability to generate positive cash flow from operations; the ability to diversify new user acquisition channels or improve the conversion of users to paid subscribers; the ability to anticipate and respond to changing user and industry trends and preferences; the intense competition in the online dating marketplace; the ability to release new applications or derive revenue from new applications; and circumstances that could disrupt the functioning of the Company's applications. More detailed information about the Company and the risk factors that may affect the realization of forward-looking statements is set forth in the Company's filings with the Securities and Exchange Commission ("SEC"), including the Company's most recent Annual Report on Form 10-K and Quarterly Reports on Form 10-Q. Investors and security holders are urged to read these documents free of charge on the SEC's web site at http://www.sec.gov.

    All forward-looking statements speak only as of the date on which they are made. The Company undertakes no obligation to update any forward-looking statement or statements to reflect events or circumstances after the date on which such statement was made, except to the extent required by applicable securities laws.


Log in to reply
 

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.