Category Archives: Development

Ethereum Commonwealth development update (11 Jan, 2018)

1. Callisto network project.

Rationale:

  • The main goal of Callisto network is to research and provide a reference implementation of an experimental protocol changes that aim to establish a smart-contract based on-chain governance system, completely financially transparent built-in development funding mechanism and balance the interest in the network between the miners and coin holders (ordinary network users).
  • It is possible to improve the scalability of both ETC and Callisto networks by using one as a sidechain.
  • Create a field for crosschain services improvements. It is also possible to establish a core of any crosschain service at the Callisto network and use Callisto smart-contracts state on ETC chain and visa versa which allows to facilitate the bandwidth of ETC chain. (Currently, DexNS, Address-To-Address message system, Token swap channels and ECNS are crosschain services that are deployed on ETC chain simultaneously)

Here you can track the progress:

Summary:

Callisto is a separate blockchain that is based on Ethereum protocol with its own cryptocurrency (CLO). Callisto has a fixed cap monetary policy similar to ETC. Unlike ETH, ETC is posing itself as a value storage. It should be noted that the ETC does not have any incentives for coin holders. The whole emission is completely controlled by miners and their influence grows with the growth of the network. Callisto introduces a Cold staking protocol that rewards coin holders for being a network participants.

Cold staking is a smart-contract based process that allows CLO holders to earn interest in a total CLO emission when they hold CLO coins at their balances for long enough preiod of staking time (1 month by default).

Cold stakers are not required to run a node to participate in cold staking process. Cold stakers are not validating transactions and the whole system can remain fully POW which is important since ETC adheres to POW consensys. It is only necessary to call the “Staking contract” to become a cold staker.

Cold staking is a step towards the goal of turning the desired cryptocurrency into a value storage currency because this significantly increases a total demand to hold for stake holders. Further protocol improvements would be described at this open document. It may take years to propose any changes to ETC protocol and achieve a consensys on whether we need to implement it or not. As the result it was decided to launch a separate network to implement the protocol. If the reference implementation will succeed then we can implement the protocol changes on ETC as well.

Cold staking protocol could be an intermediate step of automated on-chain governance system implementation.

Callisto whitepaper will be released soon.

Callisto initial distribution

It was decided to distribute the initial stake of CLO between current ETC holders. We will make a snapshot of ETC blockchain at block 5500000 (approximately 5 March, 2018. This depends on ETC block time and ETC hashrate changes). Then we implement the initial balance of each ETC holder in the Callisto network genesis block, so each ETC owner will receive CLO coins automatically in a 1:1 ratio to the amount of ETC that he had at block 5500000.

2. Cold staking protocol.

Problem that is solved by this project:

  • There is no incentive for coin holders to continue to own coins which is important for “store of value” currencies.
  • Interest and influence in the network are not balanced. The balance is strongly biased towards the miners.
  • Lack of governance system. Cold staking protocol could serve as an intermediate step for governance system implementation.

Here you can track the progress:

Update summary:

Reference implementation of the cold staking protocol is developed and tested. The 1.0 version of the protocol has some issues that can hurt the network bandwidth in some circumstances. The 2.0 version of the protocol is intended to resolve bandwidth issues but it is still in development.

3. Callisto testnet.

Problem that is solved by this project:

  • Lack of a specialized testnet for Callisto and ETC chains. If Ethereum will introduce any breaking changes then there will be no viable testnet for ETC chain. Morden testnet is very old and require syncing and mining a test block to start testing contracts on it which is not suitable in most cases.

Here you can track the progress:

Update summary:

Callisto-TEST is ETC-compatible implementation of Callisto protocol that allows to run smart-contracts with the same version of EVM that ETC is currently relying on. Unfortunately, there is no blockchain explorers that support Callisto-TEST now. We are working on our own blockchain explorer that will support multiple networks but it is still in development.

Callisto-TEST is now supported at ClassicEtherWallet.This means that any developer can successfully deploy, run, test and debug contracts on Callisto-TEST network.

We have a manual faucet for Callisto at the moment. You should join the ETC discord and type your address at the special #callisto-faucet channel in tech topic. We will distribute test-CLO manually (analogue to how Ropsten testnet works).

Advantages of Callisto-TEST network:

  • Proof of Authority consensys. High DDOS resistance.
  • Zero install requirements to test your contracts at this testnet.
  • No need to sync your node to test contracts at this testnet.
  • Reduced block time for testing reasons which allows to execute contract calls and normal transactions faster.

4. DexNS revenue.

Here you can track the progress:

Update summary:

A final version of DexNS is launched. 56 names are currently registered at DexNS which brings 5,6 ETC to the revenue distribution address. The amount is too small to launch a distribution between DEX token holders now.

The amount of revenue that is generated by DexNS will be distributed between DEX token holders according to announcement#24: revenue distribution process of Ethereum Commonwealth as soon as the amount of revenue will be sufficient to cover gas fees for transfers to the smallest DEX holders.

5. Address to Address message system.

Problem that is solved by this project:

  • This contract solves the problem of impossibility to contact the address owner without knowing anything other than his address.
  • Ethereum lacks a central messaging system that will allow to contact an address owner directly. As the result there is no viable way to deliver a message to address owner without knowing his real identity.

Here you can track the progress:

Update summary:

A2A Message smart-contract is successfully deployed. The next step is UI implementation and integration with ClassicEtherWallet.

For more information read this: https://www.reddit.com/r/EthereumClassic/comments/7n2a83/addresstoaddress_message_system_based_on/

6. ClassicEtherWallet maintenance.

Rationale:

  • Maintain and improve the efficiency of the main web-wallet of Ethereum CLassic.

Here you can track the progress:

Update summary:

  • Callisto-TEST network integration.
  • Specialized GAS options for Callisto-TEST network.
  • Minor UI fixes and upgrades.
  • UBQ RPC endpoint fix.

Ethereum Commonwealth

Ethereum Commonwealth is a completely financially transparent development team that aims to solve a number of Ethereum Classic infrastructure problems and improve the whole Ethereum Classic ecosystem.

You can find a complete Ethereum Commonwealth roadmap here.

Ethereum Commonwealth official address: 0x52823e725a34d42e14a1b66fb67299c30c4d8edf

If you have something to say, feel free to reply to this post or contact via e-mail: dexaran@ethereumclassic.org

Ethereum Development Guide — Part 1

Developing an Ethereum Document Certification Application

Introduction

Document certification, also known as timestamping or proof of existence, is one of the most obvious use cases for blockchain technology beyond digital currencies. Document certification consists in saving a tamper-proof timestamped fingerprint of a document (or binary file) on the blockchain. This basically serves as proof that the document existed in a certain version at a certain time and can be used to prove integrity of the file. That is, you can prove that a document has not been modified since its certification. Use cases cover registering private contracts, protecting copyright, sealing log files and any other case where file integrity is important.

In this tutorial we will look at how to create an Ethereum contract that allows to store data on the blockchain and read it, by using document certification as an example. To do so, we will create a simple smart contract that saves an SHA-256 hash of a file on the blockchain, together with a timestamp. SHA-256 hashes uniquely identify sets of data by means of a cryptographic hash function. We will not go into detail on hash functions and cryptography here, but you should know that a SHA-256 hash is a 32-byte fingerprint derived from the input data. The reverse operation, i.e. calculating the data from the hash value, is not feasible, so data protection is a welcome side-effect.

Document certification is fairly easy to implement, which means it is ideal for explaining certain concepts and techniques without unnecessary complexity, whilst still being more useful than typical “Hello World” examples.

Prerequisites and Learning outcomes

To follow this tutorial you need some basic understanding of the command line, text editing and a basic understanding of how blockchains work. You should have Node.js installed on your system and know some Javascript. After following this tutorial you will know how to:

  • Write a simple smart contract for the Ethereum blockchain
  • Store and retrieve data on the blockchain
  • Understand the difference between a transaction and a call
  • Deploy and test a smart contract in a local test environment
  • Use basic functionality of a professional Ethereum development framework

Developing the smart contract

We will use the Solidity programming language to write our contract and the Truffle framework to ease development.

Install Truffle with the following command (the -g option may require root privileges on your system):

npm install -g truffle

Now, we are ready to initialize our smart contract development project. In a new directory type the following:

truffle init

This creates various directories and files. For now we will create a Solidity source file in the contracts directory. We can use truffle to create the file with some scaffolding code for us:

truffle create contract Notary

This creates a file called Notary.sol in the contracts directory. In the same directory there is also a Migrations.sol file. This is a contract used by truffle to aid blockchain deployment. You should leave this file untouched. Let’s edit Notary.sol to contain the following code:

pragma solidity ^0.4.4;
contract Notary {
struct Record {
uint mineTime;
uint blockNumber;
}
mapping (bytes32 => Record) private docHashes;
function Notary() public {
// constructor
}
function addDocHash (bytes32 hash) public {
Record memory newRecord = Record(now, block.number);
docHashes[hash] = newRecord;
}
function findDocHash (bytes32 hash) public constant returns(uint, uint) {
return (docHashes[hash].mineTime, docHashes[hash].blockNumber);
}
}

This is all the Solidity code we require for this application. First of all, we use a pragma expression to specify a minimum compiler version (0.4.4) for this code. The code should compile with anything below version 0.5.0.

Next we use declare the Notary contract. Inside the contract we declare a struct datatype, instances of which will be used to store records of the documents we wish to fingerprint. The struct has two entries of type uint, which is an unsigned 256-bit integer. The fields are a timestamp and the block number at which the transaction supplying the hash value of our files is mined.

In the next line we create the following state variable:

mapping (bytes32 => Record) private docHashes;

This will actually be stored on the blockchain and maps 32-byte values, our SHA-256 hashes, to an instance of our previously declared Record struct. A mapping is essentially a hash table, which you may know from other programming languages. The SHA-256 hash will actually be used as the key to find the corresponding record.

The next piece of code is the constructor of our contract. Constructors are called at contract deployment and serve for initialisation tasks. As our contract is very simple we do not need to do anything special here, so we just leave the constructor empty.

Next, we declare the function that is used to store records on the blockchain:

function addDocHash (bytes32 hash) public {
Record memory newRecord = Record(now, block.number);
docHashes[hash] = newRecord;
}

Note that the function takes a hash value as an argument. We could send the actual file content to the contract and calculate the hash value in the contract code, but this would be a poorer design decision for a number of reasons: First of all, contract execution has an associated cost in gas, which is translated to Ether via the gas price, and is charged to the caller of the transaction. The more work to be done, the costlier the transaction will be. Secondly, users should not have to send their files across the network. There is no reason for user data to leave the owner’s machine, as SHA-256 hashes can be calculated locally. Finally, independent of transaction fees, sending large files over the network is just much more inefficient than sending the SHA-256 hash. As can be seen above, the addDocHash function is declared public, so that it can be accessed externally. The memory keyword used in the local Record declaration means that it won’t be saved to storage. Storing it is eventually achieved by saving the data to the docHashes mapping, which is an in-storage state variable.

When the addDocHash function is called in a transaction, the same transaction is executed by all nodes trying to include the transaction in a new block. The winning miner node that eventually seals the block sets the correct block number and mine time. Note, that whilst the timestamp can be manipulated by the miner in theory, it still needs to be larger than the previous block’s and lower than the next block’s timestamp. Therefore, any discrepancies will be minimal.

Having provided a way to save a hash, we now need a way to verify wether a hash exists on the blockchain and retrieve the corresponding record:

function findDocHash (bytes32 hash) public constant returns(uint, uint) {
return (docHashes[hash].mineTime, docHashes[hash].blockNumber);
}

This function simply returns the corresponding mine time and block number for a given hash as a tuple (Solidity can have multiple return values). If a hash is not in the mapping the code will return (0,0). We could in fact add a test wether the hash exists and throw an exception, but as (0,0) is a pretty clear indicator for failure to find a hash, we can deal with this off-chain in the client code. A good rule of thumb is to only include code that benefits from the blockchain’s properties in your contract. The rest is better off in client side code.

One important fact to notice is the constant keyword in the findDocHash function declaration. This indicates that the function does not alter state and can therefore be executed in a call, rather than a transaction. Calls may read state of a local Ethereum node and do not have to be propagated through the network and mined. They therefore do not require any gas and are free to use.

To compile this code with truffle type:

truffle compile

This creates a JSON files in the build directory of our contracts. Feel free to look at Notary.json. We will discuss the content of the file further on this series of articles. For now, we let Truffle handle the file.

Testing the contract

To test our contract we will deploy it onto an in-memory Ethereum blockchain simulator. It would be unwise to directly deploy our contract onto the real network without prior testing. We will use the Ganache tool for testing. Installation of the tool is straightforward. Once executed, Ganache presents the following graphical user interface:

As you can see there are a number of accounts created automatically, each of of which hold plenty of test Ether. You can also see details on the chain’s blocks and transactions, which is useful for testing.

Now we will deploy our contract onto the test blockchain. To do so, we use truffle to first create a migration file for our Notary contract:

truffle create migration Notary

This will create a new Javascript file in the migrations directory with some scaffolding code. Edit this file to contain the following code:

var NotaryContract = artifacts.require("Notary");
module.exports = function(deployer) {
deployer.deploy(NotaryContract);
};

The code tells Truffle to obtain a reference to the Notary contract and deploy it. However, before we can execute this code and proceed with the actual deployment, we have to configure Truffle to use our local test blockchain for deployment.

To do so we need to edit the file truffle.js which is the main configuration file, and add the following content:

module.exports = {
networks: {
development: {
host: "localhost",
port: 7545,
network_id: "*"
}
}
};

This code tells truffle to look for an Ethereum node’s RPC interface on port 7545 on localhost and deploy onto the network we find there, whatever the network id (Ethereum networks are identified by ids, with 1 being the oficial Ethereum main network). Ganache is listening on this port by default. We have also named this deployment configuration development, so that we can add further networks with different names later on.

Now we can deploy the contract by typing:

truffle migrate --network development

It is not actually necessary to explicitly specify the network, as truffle will deploy to the first network on the list. However, it is good practice to do so, in order to avoid mistakes later on. During development we might fix some bugs and redeploy. To do a re-deploy we have to add a reset option:

truffle migrate --network development --reset

Note, that we have automatically deployed the truffle supplied Migrations contract as well. This is used by Truffle for migration tasks and we will leave it alone. You should see the address each contract is assigned.

We now have version of our contract on our local blockchain simulator and can interact with it. There are various ways to test a contract and Truffle actually ships with a sophisticated test framework, but for now we connect to our blockchain using Truffle’s console mode, which provides a Javascript console with the Web3 library and some further Truffle extensions. The Web3 library provides a standard Javascript interface to allow applications to communicate with the blockchain. Type the following to enter console mode and receive a Javascript command prompt:

truffle console

Truffle makes life easy by injecting a Notary object with some important fields, such as the contracts Application Binary Interface (ABI) and it’s a address. These are two details you need to know of any contact you wish to interact with on the blockchain. We can use the injected object to create a reference to our deployed contract:

var notary = Notary.at(Notary.address);

We can now send a hash value of a file to the blockchain. As we have not implemented a client which calculates hash values yet, we can either send any integer number for testing purposes or use openssl or any other tool you have installed locally to generate a SHA-256 hash of a file. Alternatively you can just use the value I use in my example below. To send a hash value to the blockchain we can use the following code in the Truffle console:

notary.addDocHash("0x5abf61c361e5ef91582e70634dfbf2214fbdb6f29c949160b69f27ae947d919d");

Note that we are passing a string datatype as an argument. As long as we format the string correctly with a leading (0x) to indicate a hexadecimal value, the web3 library translates this correctly to our contract’s ABI.

On return, you should be presented with a receipt of your transaction, including a transaction id, some information on the block the transaction has been mined in and the gas used. Note, that in our testing environment the transaction is mined instantly. Using a real Ethereum network things would be considerably slower and testing would be cumbersome.

Let’s now use the findDocHash function to check wether our hash value exists on the blockchain:

notary.findDocHash("0x5abf61c361e5ef91582e70634dfbf2214fbdb6f29c949160b69f27ae947d919d");

The result is an array with two objects of type BigNumber. Web3 uses the BigNumber library, as Javascript is notoriously bad at dealing with large numbers. We could use the library to decode these values properly, but it is easy to see that the first element of the array corresponds to our first return value, the timestamp, and the second element to the block number.

You may try repeating the call with a hash value which we have not saved onto the blockchain to get two zero values as return values.

We have thus shown that our contract works correctly.

Next Steps

Once we have a working contract our next steps could be as follows:

  1. Develop a client application that calculates hash values for provided files and sends them to the blockchain and also allows checking if hashes exist.
  2. Test our client with our test environment.
  3. Deploy the contract on the Ethereum test network, a real blockchain that works with worthless test Ether to allow inexpensive real world testing.
  4. Test our client against the contract deployed on the test network
  5. Deploy our contract on the Ethereum main network.

We will look at these steps in part 2 of this tutorial series.

The source code for this tutorial can be found on GitHub:

stbeyer/docCertTutorial

If you find this tutorial useful, you may consider donating a modest amount:

Ethereum: 0xd9fa3fb148154ca0c70ecb89009df54ae9f9924b

Bitcoin: 1Jk13X9BTcQ2huMy1RS6Dx71oFtMMUmfXc

Litecoin: LcfTyh7xbLgi1gFStEG3xBNpGhmVAXg2Yj

Ethereum Development Guide — Part 1

Developing an Ethereum Document Certification Application

Introduction

Document certification, also known as timestamping or proof of existence, is one of the most obvious use cases for blockchain technology beyond digital currencies. Document certification consists in saving a tamper-proof timestamped fingerprint of a document (or binary file) on the blockchain. This basically serves as proof that the document existed in a certain version at a certain time and can be used to prove integrity of the file. That is, you can prove that a document has not been modified since its certification. Use cases cover registering private contracts, protecting copyright, sealing log files and any other case where file integrity is important.

In this tutorial we will look at how to create an Ethereum contract that allows to store data on the blockchain and read it, by using document certification as an example. To do so, we will create a simple smart contract that saves an SHA-256 hash of a file on the blockchain, together with a timestamp. SHA-256 hashes uniquely identify sets of data by means of a cryptographic hash function. We will not go into detail on hash functions and cryptography here, but you should know that a SHA-256 hash is a 32-byte fingerprint derived from the input data. The reverse operation, i.e. calculating the data from the hash value, is not feasible, so data protection is a welcome side-effect.

Document certification is fairly easy to implement, which means it is ideal for explaining certain concepts and techniques without unnecessary complexity, whilst still being more useful than typical “Hello World” examples.

Prerequisites and Learning outcomes

To follow this tutorial you need some basic understanding of the command line, text editing and a basic understanding of how blockchains work. You should have Node.js installed on your system and know some Javascript. After following this tutorial you will know how to:

  • Write a simple smart contract for the Ethereum blockchain
  • Store and retrieve data on the blockchain
  • Understand the difference between a transaction and a call
  • Deploy and test a smart contract in a local test environment
  • Use basic functionality of a professional Ethereum development framework

Developing the smart contract

We will use the Solidity programming language to write our contract and the Truffle framework to ease development.

Install Truffle with the following command (the -g option may require root privileges on your system):

npm install -g truffle

Now, we are ready to initialize our smart contract development project. In a new directory type the following:

truffle init

This creates various directories and files. For now we will create a Solidity source file in the contracts directory. We can use truffle to create the file with some scaffolding code for us:

truffle create contract Notary

This creates a file called Notary.sol in the contracts directory. In the same directory there is also a Migrations.sol file. This is a contract used by truffle to aid blockchain deployment. You should leave this file untouched. Let’s edit Notary.sol to contain the following code:

pragma solidity ^0.4.4;
contract Notary {
struct Record {
uint mineTime;
uint blockNumber;
}
mapping (bytes32 => Record) private docHashes;
function Notary() public {
// constructor
}
function addDocHash (bytes32 hash) public {
Record memory newRecord = Record(now, block.number);
docHashes[hash] = newRecord;
}
function findDocHash (bytes32 hash) public constant returns(uint, uint) {
return (docHashes[hash].mineTime, docHashes[hash].blockNumber);
}
}

This is all the Solidity code we require for this application. First of all, we use a pragma expression to specify a minimum compiler version (0.4.4) for this code. The code should compile with anything below version 0.5.0.

Next we use declare the Notary contract. Inside the contract we declare a struct datatype, instances of which will be used to store records of the documents we wish to fingerprint. The struct has two entries of type uint, which is an unsigned 256-bit integer. The fields are a timestamp and the block number at which the transaction supplying the hash value of our files is mined.

In the next line we create the following state variable:

mapping (bytes32 => Record) private docHashes;

This will actually be stored on the blockchain and maps 32-byte values, our SHA-256 hashes, to an instance of our previously declared Record struct. A mapping is essentially a hash table, which you may know from other programming languages. The SHA-256 hash will actually be used as the key to find the corresponding record.

The next piece of code is the constructor of our contract. Constructors are called at contract deployment and serve for initialisation tasks. As our contract is very simple we do not need to do anything special here, so we just leave the constructor empty.

Next, we declare the function that is used to store records on the blockchain:

function addDocHash (bytes32 hash) public {
Record memory newRecord = Record(now, block.number);
docHashes[hash] = newRecord;
}

Note that the function takes a hash value as an argument. We could send the actual file content to the contract and calculate the hash value in the contract code, but this would be a poorer design decision for a number of reasons: First of all, contract execution has an associated cost in gas, which is translated to Ether via the gas price, and is charged to the caller of the transaction. The more work to be done, the costlier the transaction will be. Secondly, users should not have to send their files across the network. There is no reason for user data to leave the owner’s machine, as SHA-256 hashes can be calculated locally. Finally, independent of transaction fees, sending large files over the network is just much more inefficient than sending the SHA-256 hash. As can be seen above, the addDocHash function is declared public, so that it can be accessed externally. The memory keyword used in the local Record declaration means that it won’t be saved to storage. Storing it is eventually achieved by saving the data to the docHashes mapping, which is an in-storage state variable.

When the addDocHash function is called in a transaction, the same transaction is executed by all nodes trying to include the transaction in a new block. The winning miner node that eventually seals the block sets the correct block number and mine time. Note, that whilst the timestamp can be manipulated by the miner in theory, it still needs to be larger than the previous block’s and lower than the next block’s timestamp. Therefore, any discrepancies will be minimal.

Having provided a way to save a hash, we now need a way to verify wether a hash exists on the blockchain and retrieve the corresponding record:

function findDocHash (bytes32 hash) public constant returns(uint, uint) {
return (docHashes[hash].mineTime, docHashes[hash].blockNumber);
}

This function simply returns the corresponding mine time and block number for a given hash as a tuple (Solidity can have multiple return values). If a hash is not in the mapping the code will return (0,0). We could in fact add a test wether the hash exists and throw an exception, but as (0,0) is a pretty clear indicator for failure to find a hash, we can deal with this off-chain in the client code. A good rule of thumb is to only include code that benefits from the blockchain’s properties in your contract. The rest is better off in client side code.

One important fact to notice is the constant keyword in the findDocHash function declaration. This indicates that the function does not alter state and can therefore be executed in a call, rather than a transaction. Calls may read state of a local Ethereum node and do not have to be propagated through the network and mined. They therefore do not require any gas and are free to use.

To compile this code with truffle type:

truffle compile

This creates a JSON files in the build directory of our contracts. Feel free to look at Notary.json. We will discuss the content of the file further on this series of articles. For now, we let Truffle handle the file.

Testing the contract

To test our contract we will deploy it onto an in-memory Ethereum blockchain simulator. It would be unwise to directly deploy our contract onto the real network without prior testing. We will use the Ganache tool for testing. Installation of the tool is straightforward. Once executed, Ganache presents the following graphical user interface:

As you can see there are a number of accounts created automatically, each of of which hold plenty of test Ether. You can also see details on the chain’s blocks and transactions, which is useful for testing.

Now we will deploy our contract onto the test blockchain. To do so, we use truffle to first create a migration file for our Notary contract:

truffle create migration Notary

This will create a new Javascript file in the migrations directory with some scaffolding code. Edit this file to contain the following code:

var NotaryContract = artifacts.require("Notary");
module.exports = function(deployer) {
deployer.deploy(NotaryContract);
};

The code tells Truffle to obtain a reference to the Notary contract and deploy it. However, before we can execute this code and proceed with the actual deployment, we have to configure Truffle to use our local test blockchain for deployment.

To do so we need to edit the file truffle.js which is the main configuration file, and add the following content:

module.exports = {
networks: {
development: {
host: "localhost",
port: 7545,
network_id: "*"
}
}
};

This code tells truffle to look for an Ethereum node’s RPC interface on port 7545 on localhost and deploy onto the network we find there, whatever the network id (Ethereum networks are identified by ids, with 1 being the oficial Ethereum main network). Ganache is listening on this port by default. We have also named this deployment configuration development, so that we can add further networks with different names later on.

Now we can deploy the contract by typing:

truffle migrate --network development

It is not actually necessary to explicitly specify the network, as truffle will deploy to the first network on the list. However, it is good practice to do so, in order to avoid mistakes later on. During development we might fix some bugs and redeploy. To do a re-deploy we have to add a reset option:

truffle migrate --network development --reset

Note, that we have automatically deployed the truffle supplied Migrations contract as well. This is used by Truffle for migration tasks and we will leave it alone. You should see the address each contract is assigned.

We now have version of our contract on our local blockchain simulator and can interact with it. There are various ways to test a contract and Truffle actually ships with a sophisticated test framework, but for now we connect to our blockchain using Truffle’s console mode, which provides a Javascript console with the Web3 library and some further Truffle extensions. The Web3 library provides a standard Javascript interface to allow applications to communicate with the blockchain. Type the following to enter console mode and receive a Javascript command prompt:

truffle console

Truffle makes life easy by injecting a Notary object with some important fields, such as the contracts Application Binary Interface (ABI) and it’s a address. These are two details you need to know of any contact you wish to interact with on the blockchain. We can use the injected object to create a reference to our deployed contract:

var notary = Notary.at(Notary.address);

We can now send a hash value of a file to the blockchain. As we have not implemented a client which calculates hash values yet, we can either send any integer number for testing purposes or use openssl or any other tool you have installed locally to generate a SHA-256 hash of a file. Alternatively you can just use the value I use in my example below. To send a hash value to the blockchain we can use the following code in the Truffle console:

notary.addDocHash("0x5abf61c361e5ef91582e70634dfbf2214fbdb6f29c949160b69f27ae947d919d");

Note that we are passing a string datatype as an argument. As long as we format the string correctly with a leading (0x) to indicate a hexadecimal value, the web3 library translates this correctly to our contract’s ABI.

On return, you should be presented with a receipt of your transaction, including a transaction id, some information on the block the transaction has been mined in and the gas used. Note, that in our testing environment the transaction is mined instantly. Using a real Ethereum network things would be considerably slower and testing would be cumbersome.

Let’s now use the findDocHash function to check wether our hash value exists on the blockchain:

notary.findDocHash("0x5abf61c361e5ef91582e70634dfbf2214fbdb6f29c949160b69f27ae947d919d");

The result is an array with two objects of type BigNumber. Web3 uses the BigNumber library, as Javascript is notoriously bad at dealing with large numbers. We could use the library to decode these values properly, but it is easy to see that the first element of the array corresponds to our first return value, the timestamp, and the second element to the block number.

You may try repeating the call with a hash value which we have not saved onto the blockchain to get two zero values as return values.

We have thus shown that our contract works correctly.

Next Steps

Once we have a working contract our next steps could be as follows:

  1. Develop a client application that calculates hash values for provided files and sends them to the blockchain and also allows checking if hashes exist.
  2. Test our client with our test environment.
  3. Deploy the contract on the Ethereum test network, a real blockchain that works with worthless test Ether to allow inexpensive real world testing.
  4. Test our client against the contract deployed on the test network
  5. Deploy our contract on the Ethereum main network.

We will look at these steps in part 2 of this tutorial series.

The source code for this tutorial can be found on GitHub:

stbeyer/docCertTutorial

If you find this tutorial useful, you may consider donating a modest amount:

Ethereum: 0xd9fa3fb148154ca0c70ecb89009df54ae9f9924b

Bitcoin: 1Jk13X9BTcQ2huMy1RS6Dx71oFtMMUmfXc

Litecoin: LcfTyh7xbLgi1gFStEG3xBNpGhmVAXg2Yj

SpankChain Development Update 004 — November 25, 2017

Good day happy Spankers! Now that the auction has successfully completed the SpankChain team wanted to take a moment to update our community on milestones, token details, and next steps!

Key milestones Achieved:

  • Successfully built and launched a custom, blind, same price, State Channel Auction
  • Successful Spork testing method developed & implemented
  • Off Chain Processing method developed and implemented
  • Successful distribution to Metamask wallets of token holders

Validating Our Finite Stake Machine

We needed to process off-chain bids in order to successfully conclude our auction and transfer the ETH staked (deposited) during the auction. Anticipating this event, we abided by best practices implementing unit tests and held many simulated auctions to provide a level of confidence that the contract code would function as expected. But how do you ensure you know all scenarios? The realm of possibilities, while finite, can be quite large. So we decided to spork the main net.

Similar to a fork and a spoon, a spork is a divergence of a chain that allows developers to know what would happen to a set of transactions if they were to be processed. Inspired by this article, we thought that this technique could not only be applied to past events but could also help “predict” future events. Using this technique turned out to be invaluable. Inevitably there were some edge cases that we did not anticipate that were exposed from our spork.

Hustl and Hodl

After successfully concluding the auction and fixing edge cases, community members discovered that we had made a unit conversion mistake. No funds were lost and were were able to deploy a fix. We were “moving fast” and focused on making sure that our hybrid system worked correctly that we overlooked a simple unit conversion bug. This retrospective of the infamous NASA unit conversion mistake sends chills down our spine, turning any condescending thoughts to sympathy and understanding.

But there was an underlying issue in the culture of NASA’s space exploration at the time, Cook said.

“‘Better, faster, cheaper’ was the mantra at the time,” Cook said. “Certainly that project was trying to do a whole lot for a limited amount of money.”

Luckily for us, no funds were lost, nonetheless — no excuses, lesson learned! We apologize for any inconvenience or confusion this may have caused. Since we are dealing with a blockchain we can’t “move fast and break things” so we are setting processes in place that allow us to continue to “hustl and hodl”. We believe this requires investing in development tools without sacrificing product delivery expectations. This is truly exciting because there is full confidence in the team that we will be able to meet these goals. Most importantly, this would not have been possible without those who believed in us. From the entire SpankChain team, thank you!

Token Information:

Connect with SpankChain

To learn more about SpankChain please visit our website, follow us on Twitter, and join our growing Discord community.

Bloom Development Update

Bloom is in a very exciting phase right now! There is a lot of community interest in the roadmap we have laid out, we are working with lenders on our platform, our Slack is growing like crazy, and our token sale is just around the corner.

We have been working hard on all fronts and we are ahead of schedule with development. Our sale contracts will be deployed to the main net next week. We’re deploying the first phase of the protocol next month. Bloom users will be able to signup and participate in the protocol voting system as soon as they own some BLT. User profiles and voting are at the heart of our protocol. These features set the stage for the beta releases of our identity and risk platforms which will be live at the beginning of 2018.

Polishing our Token Sale

We are in the process of getting our second formal audit. We have been using some of the most trusted community resources, including:

We are aiming for high test coverage on our contracts and we’re using tools like solhint to help double check for common mistakes. We have a basic vesting system built in for founders and advisors based off of OpenZeppelin’s VestedToken. Once we are done with our second audit we will open source all of the code so that contributors have full transparency before buying BLT.

Keeping our Communities Safe

We have seen incredible community growth on Slack and Telegram communities. Between the two, we have over 6,500 community members! After our token sale we want to migrate off of Slack, but in the meantime we can’t risk splintering our community. We have setup a number of tools which we want to share afterwards that helps detect spammers and scammers before they message users.

Our custom setup builds upon what other crypto Slack communities have setup with antiScamBot_slack. Since anti-fraud is inherently a cat and mouse game, we can’t dive too much into the techniques we’re using. Simply put, our combined system of signup monitoring, fingerprinting, and early detection has seen an 85% reduction in malicious activity on our Slack. We’re seeing fewer people get through the filters and when they do we catch them fast! Of course, our community has also been vigilant which has helped with quick early detection.

Easy-to-use Decentralized Invites

As we mention in our whitepaper, we want to concentrate where we initially launch the Bloom network so that early users have a great experience. The early system requires users to collateralize a fractional amount of BLT in order to invite new users. If the user invites someone who exit scams, they can’t reclaim their BLT. The idea is to make it harder for someone to invite a lot of malicious users in the early days of the network.

Our prototype for the backend of our user system is done and should be ready for an audit soon. The front-end we are building out to interface with these contracts makes it seamless to use this system. To facilitate adoption, awell-built dApp should feel just like a well-built app! The end user should only brush up against the more technical aspects of Ethereum (addresses, signing, ENS) as a last resort.


Accepting a Bloom Invite

Voting for Bloom Token Holders

Decentralization is a core value for Bloom so we want to launch with an easy-to-use voting system. This goes hand-in-hand with the account system mentioned above. BLT holders will be able to vote on decisions that are relevant to Bloom’s development. Voting is counted proportionally to the amount of BLT a user holds. This contract is also prototyped and should be ready for an audit about a week after the invite system. Our goal is to have voting and invites lives by the end of December.


Voting with a Bloom account

Want More Information?



Bloom Development Update was originally published in Bloom on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bloom Development Update

Bloom is in a very exciting phase right now! There is a lot of community interest in the roadmap we have laid out, we are working with lenders on our platform, our Slack is growing like crazy, and our token sale is just around the corner.

We have been working hard on all fronts and we are ahead of schedule with development. Our sale contracts will be deployed to the main net next week. We’re deploying the first phase of the protocol next month. Bloom users will be able to signup and participate in the protocol voting system as soon as they own some BLT. User profiles and voting are at the heart of our protocol. These features set the stage for the beta releases of our identity and risk platforms which will be live at the beginning of 2018.

Polishing our Token Sale

We are in the process of getting our second formal audit. We have been using some of the most trusted community resources, including:

We are aiming for high test coverage on our contracts and we’re using tools like solhint to help double check for common mistakes. We have a basic vesting system built in for founders and advisors based off of OpenZeppelin’s VestedToken. Once we are done with our second audit we will open source all of the code so that contributors have full transparency before buying BLT.

Keeping our Communities Safe

We have seen incredible community growth on Slack and Telegram communities. Between the two, we have over 6,500 community members! After our token sale we want to migrate off of Slack, but in the meantime we can’t risk splintering our community. We have setup a number of tools which we want to share afterwards that helps detect spammers and scammers before they message users.

Our custom setup builds upon what other crypto Slack communities have setup with antiScamBot_slack. Since anti-fraud is inherently a cat and mouse game, we can’t dive too much into the techniques we’re using. Simply put, our combined system of signup monitoring, fingerprinting, and early detection has seen an 85% reduction in malicious activity on our Slack. We’re seeing fewer people get through the filters and when they do we catch them fast! Of course, our community has also been vigilant which has helped with quick early detection.

Easy-to-use Decentralized Invites

As we mention in our whitepaper, we want to concentrate where we initially launch the Bloom network so that early users have a great experience. The early system requires users to collateralize a fractional amount of BLT in order to invite new users. If the user invites someone who exit scams, they can’t reclaim their BLT. The idea is to make it harder for someone to invite a lot of malicious users in the early days of the network.

Our prototype for the backend of our user system is done and should be ready for an audit soon. The front-end we are building out to interface with these contracts makes it seamless to use this system. To facilitate adoption, awell-built dApp should feel just like a well-built app! The end user should only brush up against the more technical aspects of Ethereum (addresses, signing, ENS) as a last resort.


Accepting a Bloom Invite

Voting for Bloom Token Holders

Decentralization is a core value for Bloom so we want to launch with an easy-to-use voting system. This goes hand-in-hand with the account system mentioned above. BLT holders will be able to vote on decisions that are relevant to Bloom’s development. Voting is counted proportionally to the amount of BLT a user holds. This contract is also prototyped and should be ready for an audit about a week after the invite system. Our goal is to have voting and invites lives by the end of December.


Voting with a Bloom account

Want More Information?



Bloom Development Update was originally published in Bloom on Medium, where people are continuing the conversation by highlighting and responding to this story.

Particl Dev Update: Particl Marketplace

October 30th, 2017 | Leveling UP

In Friday’s update I gave a detailed update on the work most of the team has been focusing on the past 4 weeks; preparing Particl GUI for Cold Staking (CS).

While October was a flurry of activities surrounding GUI prep for Nov. 10th, a small contingent of the team also continue working on crucial backend functionality for the upcoming Particl Market.

I have so much information to share about Particl products that I had to split the update into 2 PARTs. Now, let’s get into how the Market is moving along!

Status Report

What are we busy with

  • Current Bootstrap to Material migration: Development clean-up for merge
  • Marketplace GUI Designs: Categories: UX/UI Design — GUI Design: Seller Side — GUI Design: Buyer Side
  • Establish Marketplace Codebase
  • Messaging (Daemon / Core): Paid messages / Listing fee

What is wrapped up

  • Marketplace Database Design
  • Current Bootstrap to Material migration: Create Mobile menu in Material

What is coming next

  • Marketplace Categories: Initial Categories (Building and Import) — Additional Categories
  • Functions (Backend)
  • GUI Design: Market management GUI
  • GUI Integration (API Service + Consuming): Market Management — Share URI / Open URI to view marketplace item — Add item — Add Item Image — Full list — View Items (Search View) — View item — View “My Item/s” — View Escrowed item — Checkout View — Negotiation page integration
  • P2P Marketplace Governance: Consensus on removal of products (Voting)

Marketplace Database Design

Work on the underlying database for the Market has been completed. This task focused on identifying all the functions the market might see in a Buy/Sell/Escrow scenario.

DApp Shell

Juha (ludx), our developer on the Particl Marketplace database design, has been working on the DApp Shell and busy establishing codebase and structure for the Marketplace backend.

The Marketplace database has been modeled based on Kewde’s work on the Open Market Protocol (OMP). All the market database related functionalities are finished and work now continues on the Marketplace functionalities and RPC API for Marketplace GUI.

Entity Model (database):

work in progress

Bootstrap to Material Migration

Closely tied to the Particl GUI — Electron Wallet App — is the migration from Bootstrap to Material Design. All modals, components, transitions, etc have been migrated successfully and are being cleaned up for development merge.

The smooth transitions and slick, responsive design of these updates for the Particl GUI is teased ahead of official mainnet builds below.

Messaging (Daemon / Core)

Even as a team member on Particl, it is hard to grasp the amount of work and dedication the development team takes when creating a truly private marketplace until you see a task like our End-to-End Encrypted (E2EE) Messaging.

Unified smsg return codes. · particl/particl-core@a9d4828

Our Lead Core Developer, Tecnovert (TV), has been tackling this task which is one of our longest in the creation of our Private Market MVP. Scheduled on our dynamic calendar as a stand-alone item and lasting 12 weeks by itself (research, coding, testing), the focus here is on Paid Messages and Listing Fees.

If you’ve been following the project at all you’ll recognize Tecnovert by his stellar work in bringing Confidential Transactions (CT) and Ring Signature Confidential Transactions (RingCT) to Particl Core. He also has kept our protocol up-to-date with Bitcoin Core development and the latest security updates in Bitcoin 0.15.0.1, making Particl one of the first projects on the lastest codebase.

Task Notes

RingCT Transaction → OP_RETURN msg <hash>

  • Hash of messages stored in OP_RETURN with no value outputs (TX FEE only), and change
  • Change goes to self, fee goes to network
  • Bigger Payment = Longer Duration
  • Formula
  • payment / size = days

Additional Items

Categories

Product categories and sub-categories have been identified and organized thanks to one of our advisors, Joe Fisher. Joe’s focus is on E-Commerce Strategy. He has a profound and long history background as a Private label online seller and Product Developer.

Joe spoke with Tai Zen and David Fong of Cryptocurrency Market in New York earlier in this month about Particl Market. Check out these 2 episodes to hear more:

Part. 1: https://youtu.be/sAhZK6AnPLw

Part. 2: https://youtu.be/mlAL3x2HHFY

Particl Core

What are we busy with

  • API to filter transactions

Release 0.15.0.3

We have released a minor update to Particl Core that can be downloaded here:

particl/particl-core

Release Notes:

  • New rpc command filtertransactions.
  • Fixed startup crash on windows versions.

📝 Subscribe to our blog for the latest updates from Particl.

Thank You

Particl Team



Particl Dev Update: Particl Marketplace was originally published in Particl News on Medium, where people are continuing the conversation by highlighting and responding to this story.

Light Clients on Ethermint

This post is about how you can build very good light clients using Ethermint.

It’s very hard to build light clients on Ethereum because a light client at least must have the ability to see every block header. This means that a light client must be able to receive new data of the network state every 12 seconds, be able to verify that data, go back to sleep, then run the same process again 12 seconds later. The problem is, if you have a light client running on your phone, this process becomes very expensive in terms of bandwidth and battery.

What we have built in Tendermint is a highly efficient light client protocol, which only requires a light client to keep track of the validator set. Since validator sets change less frequently than the state of a network changes, with Ethermint, your phone running a light client need only to verify 1 transaction every 30 days.

Tendermint’s light client protocol by proxy of Ethermint fully supports Ethereum functionality in the palm of your hands. Powerfully, Ethermint light clients will allow you to execute smart contracts from your mobile phone, all without zapping your battery. This use case is huge. And we are inviting you to try it.

Further Discussions

  • Ethermint on Twitter: @ethermint
  • Watercooler for developers on Matrix Chat Channel: #cosmos



Light Clients on Ethermint was originally published in Cosmos Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

WHAT BLOCKCHAIN MEANS FOR START-UPS

Blockchain technology has become a widely discussed buzzword, because of its potential for disruption, transparency and a secured way of doing business. The technology didn’t disrupt the world as initially stated by Satoshi Nakamoto, but it does not disregard its capacity to be more important than the internet. The blockchain is a new way that businesses create, and enforce transactions without a central authority, and a few industries are using it in money exchange, property security, advertising, and product management. Many large corporations which include JP Morgan and Deloitte are already part of the disruption, and states like Estonia have already adopted the technology. This article details how start-ups can be affected by blockchain and what to be expected when the technology becomes the core of operations for new business platforms.

Why Blockchain?

The Blockchain mechanism enables systems to moderate all transactions by verifying existent and newly initiated activities through a distributed network consensus. This technology is poised to bring significant transformations to the start-ups space, secure encryption, transparency, and elimination of premium charges by intermediaries. With start-up transactions amounting up to 10,000 daily in supply chain activities — industry experts believe that blockchain would facilitate cuts in the supply chain, Ad fraud, the recruitment processes among other areas. So, here is a look at what blockchain means for start-ups.

  1. ICO CROWDFUNDING

IPO is gradually becoming unconventional, because of its susceptibility to manipulations from wealthy individuals and government control. When financiers or major shareholders cash out of start-ups, such brands begin to struggle for stability. Crowdfunding, however, is a safer method to finance new establishments, and developing brands — the approach gets financing faster and low-cost funding. Crowdfunding allows members of the public, without restriction to the class hierarchy to get an opportunity in start-ups, with a secured hope of future profits. Over $34 billion has been issued in ICO crowdfunding — this shows the confidence the public has in blockchain systems, as the big guys would not authoritatively force out the small financiers. ICO’s lack of regulation is why more individuals are contributing tokens, and the market value of Bitcoin and other cryptocurrencies guarantees high proportion profits.

2. PRODUCT DEVELOPMENT

Product is shifting from a thing to a person, as consumers are demanding communications and user responsiveness. Brands are also concerned about idea theft, piracy, and intellectual property protection. The question is how will a start-up test its products with a little market lead? Blockchain allows new brands to create a secured platform where both the product and its digital twin remain in the supply chain while interacting with only members of the community. Furthermore, the system protects the product’s block, and constraints alteration or Property breach from spies. For example, an invoice check by Trade Finance Market allows transparency in invoice check reducing fraud. The possibility of this is because payment defaulters couldn’t access the product development process

3. ADVERTISEMENT

Start-ups amounted for about 10% of the $60 billion Ad loss in 2016, which is close to 85% of their total advertising budget. Being new businesses, with meagre Ad budget, start-ups are finding it difficult to break into the face of consumers, and publishers are also not considering their content.

Konga.com is a Nigerian e-commerce start-up, despite being indigenous, it still struggles in conversion among Nigerian consumers’, who purchase more from the foreign brands which include Amazon and Ali-Express. This, however, arises from effectiveness, right placement and conversion of Ads as these other brands are bigger in terms of revenue and budget — but how does blockchain help a start-up like Konga.

The blockchain technology is eliminating frauds, and content diversion in Ad by at least 70%, which means new brands can have more traffic, conversion, and sales. Blockchain innovations like iBuildApp Network will drive more content on a mobile platform, through consumer behaviour and automated SEO programmes. Ad sellers and buyers would also have control over content, saving cost and Ad display time.

4. RECRUITMENT

Jobseekers want the best job, and employers want great talents, with great characters at midscale pay. How will a start-up attract the best talents, when even the established brands find difficulties when it comes to recruitment? Jobeum and chronobank are examples of blockchain-based recruitment technologies that allow brands to screen for the best talents. In a secured digital system, employers and candidates can validate both parties’ information in real-time, eliminating all the wastes associated with recruitment. Start-ups will not have worries about an expensive interview pathway, as blockchain assures 75% conversion from candidates to an employee due to interactions with the smart recruitment community.

5. THE SUPPLY CHAIN

Most start-ups have challenges when it comes to quick and efficient delivery. E-commerce brands mix-up location, and delivery of consumer goods — which has reduced their trust among consumers, who now return to the brick and mortar stores. When one of the supply chain components fails, the brand at the front end takes all the backlash says, Phil Gomes. By using blockchain, start-ups would provide traceable, transparent auditing to all good consumer stakeholders at every logistics point. There will also be validations from consumers before products leave warehouse to eliminate logistics traffic and distrust. If a start-up gets its supply chain efficient and in real-time, such brand is not far from success.

Bottom Line

The blockchain is a decentralized system eliminating intermediaries and central authorities — it is, therefore, an interesting subject for start-ups as the larger corporations are already adopting the technology. Low-cost, speed and transparency are features of blockchain that will ensure a revolution in the way visionary start-ups will operate. The technology might run unnoticed, but it promises positivity for start-ups both now and in the future.



WHAT BLOCKCHAIN MEANS FOR START-UPS was originally published in Ethereum dApp Builder on Medium, where people are continuing the conversation by highlighting and responding to this story.

WHAT BLOCKCHAIN MEANS FOR START-UPS

Blockchain technology has become a widely discussed buzzword, because of its potential for disruption, transparency and a secured way of doing business. The technology didn’t disrupt the world as initially stated by Satoshi Nakamoto, but it does not disregard its capacity to be more important than the internet. The blockchain is a new way that businesses create, and enforce transactions without a central authority, and a few industries are using it in money exchange, property security, advertising, and product management. Many large corporations which include JP Morgan and Deloitte are already part of the disruption, and states like Estonia have already adopted the technology. This article details how start-ups can be affected by blockchain and what to be expected when the technology becomes the core of operations for new business platforms.

Why Blockchain?

The Blockchain mechanism enables systems to moderate all transactions by verifying existent and newly initiated activities through a distributed network consensus. This technology is poised to bring significant transformations to the start-ups space, secure encryption, transparency, and elimination of premium charges by intermediaries. With start-up transactions amounting up to 10,000 daily in supply chain activities — industry experts believe that blockchain would facilitate cuts in the supply chain, Ad fraud, the recruitment processes among other areas. So, here is a look at what blockchain means for start-ups.

  1. ICO CROWDFUNDING

IPO is gradually becoming unconventional, because of its susceptibility to manipulations from wealthy individuals and government control. When financiers or major shareholders cash out of start-ups, such brands begin to struggle for stability. Crowdfunding, however, is a safer method to finance new establishments, and developing brands — the approach gets financing faster and low-cost funding. Crowdfunding allows members of the public, without restriction to the class hierarchy to get an opportunity in start-ups, with a secured hope of future profits. Over $34 billion has been issued in ICO crowdfunding — this shows the confidence the public has in blockchain systems, as the big guys would not authoritatively force out the small financiers. ICO’s lack of regulation is why more individuals are contributing tokens, and the market value of Bitcoin and other cryptocurrencies guarantees high proportion profits.

2. PRODUCT DEVELOPMENT

Product is shifting from a thing to a person, as consumers are demanding communications and user responsiveness. Brands are also concerned about idea theft, piracy, and intellectual property protection. The question is how will a start-up test its products with a little market lead? Blockchain allows new brands to create a secured platform where both the product and its digital twin remain in the supply chain while interacting with only members of the community. Furthermore, the system protects the product’s block, and constraints alteration or Property breach from spies. For example, an invoice check by Trade Finance Market allows transparency in invoice check reducing fraud. The possibility of this is because payment defaulters couldn’t access the product development process

3. ADVERTISEMENT

Start-ups amounted for about 10% of the $60 billion Ad loss in 2016, which is close to 85% of their total advertising budget. Being new businesses, with meagre Ad budget, start-ups are finding it difficult to break into the face of consumers, and publishers are also not considering their content.

Konga.com is a Nigerian e-commerce start-up, despite being indigenous, it still struggles in conversion among Nigerian consumers’, who purchase more from the foreign brands which include Amazon and Ali-Express. This, however, arises from effectiveness, right placement and conversion of Ads as these other brands are bigger in terms of revenue and budget — but how does blockchain help a start-up like Konga.

The blockchain technology is eliminating frauds, and content diversion in Ad by at least 70%, which means new brands can have more traffic, conversion, and sales. Blockchain innovations like iBuildApp Network will drive more content on a mobile platform, through consumer behaviour and automated SEO programmes. Ad sellers and buyers would also have control over content, saving cost and Ad display time.

4. RECRUITMENT

Jobseekers want the best job, and employers want great talents, with great characters at midscale pay. How will a start-up attract the best talents, when even the established brands find difficulties when it comes to recruitment? Jobeum and chronobank are examples of blockchain-based recruitment technologies that allow brands to screen for the best talents. In a secured digital system, employers and candidates can validate both parties’ information in real-time, eliminating all the wastes associated with recruitment. Start-ups will not have worries about an expensive interview pathway, as blockchain assures 75% conversion from candidates to an employee due to interactions with the smart recruitment community.

5. THE SUPPLY CHAIN

Most start-ups have challenges when it comes to quick and efficient delivery. E-commerce brands mix-up location, and delivery of consumer goods — which has reduced their trust among consumers, who now return to the brick and mortar stores. When one of the supply chain components fails, the brand at the front end takes all the backlash says, Phil Gomes. By using blockchain, start-ups would provide traceable, transparent auditing to all good consumer stakeholders at every logistics point. There will also be validations from consumers before products leave warehouse to eliminate logistics traffic and distrust. If a start-up gets its supply chain efficient and in real-time, such brand is not far from success.

Bottom Line

The blockchain is a decentralized system eliminating intermediaries and central authorities — it is, therefore, an interesting subject for start-ups as the larger corporations are already adopting the technology. Low-cost, speed and transparency are features of blockchain that will ensure a revolution in the way visionary start-ups will operate. The technology might run unnoticed, but it promises positivity for start-ups both now and in the future.



WHAT BLOCKCHAIN MEANS FOR START-UPS was originally published in Ethereum dApp Builder on Medium, where people are continuing the conversation by highlighting and responding to this story.

Status Development update for the 18th to 20th of October

Active Epics

Wallet Redesign & Implementation

Some thorough testing is being conducted by our team to ensure wallet is fully functional and bug free for the upcoming release.

Network Switching

Both Rinkeby and Ropsten network faucets are being secured and mining pools setup to allow testing of Status upon these two networks.

Decentralized Push Notifications

The team is making progress in allowing offline push notifications, without compromising decentralization. Issues are being created for each push notification scenario for our Clojure-Team, and our Go-Team continues R&D on push-notification implementation.

Discover

Further progress is being achieved in ensuring Discover is bug free and pixel perfect. Alongside these tweaks and style changes, the team is working hard on testing Discover.

Project Management:

Our team working on project management oversees the big picture and aids in the planning, initiation of work and the coordination between teams.

Vic:

  • Preparing context for copy writer. General app testing sessions with members of the team, with a particular focus on Wallet and Discover features.

Clojure-Team:

Our Clojure team is the core of our development team, they handle the functionalities of our application and house our largest team of developers.

Roman:

  • Reviewed some existing code and issues
  • Working on messaging documentation
  • #2194 — Fixed issue where received request message is shown in chat without text and extra /send command is added to the list of commands

Julien:

  • #2211 — Started and finished migration to a unique toolbar implementation
  • #2229 — Pushed out a new etherscan API key
  • #2233 — Started fixing bug present when displaying QR code
  • Moved [components] to [ui.components]

Oskar:

  • Reproduced and investigated regression when upgrading Status app from 0.9.11->dev for commands parsing in Js jail
  • Wrote talking notes on push notifications for DevCon3
  • #2185 — Investigating and working on fix for issue where /send and /location messages are shown as plain text and request is shown without text
  • Bug fixing / UI triage for Discover must haves #2221 and nice to haves #2222

Goran:

  • #2222 — Discover pixel perfect ‘nice to haves’
  • Wrote Discover messaging documentation

Andrey:

  • #741 — Fixed issue where there is no option to recover immediately after a fresh install
  • #2142 — Fixed issue where unexpected error should be handled and feedback shown after signing a transaction
  • #2212 — Fixed issue where Webview with DApp is reloaded following sent transaction

Eric:

  • Fixed small bug and issued pull request #2214 for a warning when syncing was not shown
  • Tickets triage
  • Brainstorming session for improvements to developer experience / on boarding
  • #2217 — Working towards updating of react native
  • #2236 — Finished a working version with update to realm 2.0.0

Jan:

  • #2125 — Investigated and fixed regression caused by command-scopes pull request
  • #2220 — Working on fix for issue where once fee value has been typed in, the slider function doesn’t work as intended

Alex:

  • Investigated regression issues
  • #2167 — Fixed issue where web3 suggestions are missing in console chat
  • #2201 — Investigated command scopes spec fix
  • Issued two pull requests #2216 & #2238

Go-Team:

Our Go-language team handles the forked Go-Ethereum implementation in Status — This is the “backend” of Status that allows you to connect directly to the Ethereum Blockchain.

Ivan T:

  • Discussed, reviewed and then deployed Ropsten nodes
  • Set up a mining pool for Ropsten for the new faucet
  • Fixed and secured Rinkeby and Ropsten faucets
  • Proposed some changes to GitHub labelling
  • Reviewed pull requests
  • Reviewed high priority issues and lowered priority wherever possible
  • #425 — Proposed a pull request template
  • #426 — Fixed e2e tests by making them run against our private chain

Adam:

  • #401 — Improved pull request with jail refactoring following discussions and investigation
  • #413 — Looking into updating Ropsten CHT
  • #414 — Fixed Rinkeby synchronization issue
  • Reviewed existing code

Ivan D:

  • Investigating bugs
  • #401 — Working on refactoring of jail part two

Ewetumo:

  • #325 — Working on making it possible to analyse which messages were lost / resent in the test environment
  • Rewrote #325 to #420 because of scope creep

Frank:

  • #323 — Investigating signals from ‘status-go’ to ‘status-react’
  • #410 — Finalised the ‘no suitable peers available’ error, this included two minor errors that were not yet discovered, tested and optimised

Eugene:

  • #412 — Working on ensuring NodeManager thread safety

Boris:

  • #417 — Issued pull request relevant to lint warnings

Desktop team:

Our desktop team works towards building the Status client on desktop

Narek:

  • Finished Picker changes to not use old components
  • Begun work on <WebView> component implementation

QA-Team:

Our QA team handles the testing of the application, works with users reporting bugs, and they are crucial to getting feedback and report bugs to our development team with details.

Nastya:

  • Working on Discover testing

Anna:

  • Testing pull requests and develop build
  • Test session call with other members of the team

Join Our Community

Status is an open source project, and if you’d like to get involved with development — the single best way would be to build Status for yourself, explore our open issues. We prefer to hire core contributors based on Pull Requests, so this is a great way to get involved with the Status community.

If you feel you can help us grow our community in other ways, we’d love to hear your ideas. You can also Tweet at us, like our Facebook or subscribe to the Status Subreddit.

Continous development on production

Not able to decide on what project to focus on next, I’ve ignored common sense, and jumped in and just start coding. Forget all the smart ideas about finding the best idea, I’m now focused on getting a few plays live.

And to make it even more fun, I’m pushing everything straight to production. Most of the projects below are undesigned, unstructured, vague propositions or completely broken. But while I progress, these should evolve to fully grown products.

I’m working live on:

State.of.dev
Launched earlier this year, with actually pretty decent reactions, the next version involves public input and consensus on the data, and a way to visualize historical context.

State of Coin
With my experience in SEO, I’m working on State of Coin to launch a crypto coin related project. Eventually the product would involve a way for investors to make predictions that lead to buy/sell advice.

Commend.work
A way to capture professional recommendations. Much like LinkedIn recommendations but focused on continuous feedback.

Entrepreneurial.com
A product idea framework. Allows you to manage your ideas, capture them in a smart template, and help you with actionable advice to move them forward.

Hyperspace Your New Coin Monitor

The blockchain community needs a lot of information at all times, 24 hours a day, 7 days a week. However, unfortunately we are not machines, yet, and for this reason we have to use solutions that do this work for us.

Actually, one of the main issues that demand high speed of knowledge is the launch of new cryptomoedas or as it is better known, an ICO (Initial Coin Offering).

We have some basic steps and different profiles of people who participate in this event. Some are interested investors who end up becoming “holders”. Others prefer immediate trade by taking advantage of large variations and becoming “traders”.

The fact is that in the end everyone has the same goal, the profit. And one of the key moments to reach if you reach that end, is the time when a new currency is listed on some Exchange.

At that moment some problems arise. How do you know when this availability happens? Tracking all communication channels with the project team manually? Searching the community? Monitoring the market?

Calm down, Hyperspace will come to solve your problems!

Using Hyperspace will no longer need to open account in several Exchanges hoping that someday, if you are lucky, your currency will be listed in any of them.

Hyperspace will be a free solution (we will do everything to keep it that way) that will monitor and monitor the release of new cryptomoedas in the market.

The project was divided into two modules (1) Interface and (2) Batch Process, is in the final stages of integration and testing and will soon be made available to the entire community.

Help Us Evolve

We want to build a solution that helps the community and for that reason all help is welcome. We want to hear your opinion. Help us to evolve!

Hyperspace Your New Coin Monitor

The blockchain community needs a lot of information at all times, 24 hours a day, 7 days a week. However, unfortunately we are not machines, yet, and for this reason we have to use solutions that do this work for us.

Actually, one of the main issues that demand high speed of knowledge is the launch of new cryptomoedas or as it is better known, an ICO (Initial Coin Offering).

We have some basic steps and different profiles of people who participate in this event. Some are interested investors who end up becoming “holders”. Others prefer immediate trade by taking advantage of large variations and becoming “traders”.

The fact is that in the end everyone has the same goal, the profit. And one of the key moments to reach if you reach that end, is the time when a new currency is listed on some Exchange.

At that moment some problems arise. How do you know when this availability happens? Tracking all communication channels with the project team manually? Searching the community? Monitoring the market?

Calm down, Hyperspace will come to solve your problems!

Using Hyperspace will no longer need to open account in several Exchanges hoping that someday, if you are lucky, your currency will be listed in any of them.

Hyperspace will be a free solution (we will do everything to keep it that way) that will monitor and monitor the release of new cryptomoedas in the market.

The project was divided into two modules (1) Interface and (2) Batch Process, is in the final stages of integration and testing and will soon be made available to the entire community.

Help Us Evolve

We want to build a solution that helps the community and for that reason all help is welcome. We want to hear your opinion. Help us to evolve!

Meet the Enigma Dev Team — and Join Us

An introduction to the Enigma developers, and how you can get involved

Hi to all from Enigma! As we all continue to work on the Catalyst product and reconcile our token sale, we wanted to take a moment to properly introduce the main developers behind Enigma. A later post will focus on the other members of our core team that are working hard to scale our project, platform, partners, and community.

Thanks again for following Enigma. If you’re interested in joining our team and helping us build the future of crypto trading and data, please read additional info at the end of this post.

Guy Zyskind


Guy Zyskind

Guy is the CEO and co-founder of Enigma. He is a long time tinkerer, most comfortable sitting at the intersection of entrepreneurship and research. Prior to Enigma, Guy was a graduate student at MIT researching and teaching blockchain technology. Guy has authored several academic papers around cryptocurrencies, including the Enigma white paper (downloaded over 100K times) and “Decentralizing Privacy: Using Blockchain to Protect Personal Data”, which is one of the most cited papers in the space. Previously, Guy led the development of several start-up companies. Most notably, he was the Chief Technology Officer at Athena Wisdom (now Endor), an MIT Media Lab spin-off company involving Big Data Analytics and Network Science. Guy holds a M.S. from MIT and a B.S. in Electrical Engineering and Computer Science from Tel-Aviv University.

Victor Grau Serrat


Victor Grau Serrat

Victor speaks many languages, both natural languages and programming languages. As a senior developer at Enigma, he predominantly codes in Python, which is the language of choice for Catalyst, an algorithmic trading platform and Enigma’s first product. Having learnt version control software in the early days of Subversion, now he heavily relies on Github to manage the development of open-sourced Catalyst and other Enigma repositories. With a Master’s in Electrical and Computer Engineering from the University of Maryland, Victor brings more than fifteen years experience in software development that includes developing electronic medical records with JavaServer Pages, firmware engineering of WiFi drivers in embedded systems using C for high latency networks, and interactive online ads programmed in Flash and ActionScript. For 7+ years, Victor was the co-director of MIT D-Lab, a research and academic program at the intersection of technology innovation, social entrepreneurship and global poverty. Under his leadership, the D-Lab’s academic offerings quadrupled and its staff and operational budget grew tenfold. Victor also previously created his own algorithmic trading platform that traded live with a leading exchange, and he’s finally found his tribe in joining the Enigma team to develop Catalyst.

Frederic Fortier


Frederic Fortier

Frederic is a senior software developer specializing in finance. Prior to joining Enigma, he designed and implemented several enterprise applications for some of North America’s largest financial institutions. He primarily develops software in Python, but also has deep expertise with Java and JavaScript. Passionate about the financial markets, he has been trading equities and options since the dawn of online brokerage. His idea of fun is to read research papers on quantitative trading, trying to put them into practice. Over the years, he has live-traded several profitable strategies. His platform of choice is Zipline, which he knows inside and out. He joined Enigma partly to scratch his own itch, which is to build a high-grade quantitative trading platform for cryptocurrencies. He holds double degrees in Computer Science and Finance, as well as a Master of Science in E-Commerce from the Université de Sherbrooke.

Would you like to join our developers in building Catalyst and the Enigma data marketplace protocol? We are actively hiring for the following roles:

Data Engineer

A finder of needles in a virtual haystack, you will comb your way through the web, markets and social networks, crawling and curating intelligence around the cryptocurrency ecosystem. Solid knowledge of Python and data-driven frameworks such as Pandas is required. Experience in scaling big data systems, handling high-throughput queries in a real-time manner, is a big plus.

Data Scientist

Your thirst for knowledge is insatiable. You see patterns everywhere you look, and enjoy turning raw datasets into useful insights. Proficiency in Python and ML libraries (e.g., TensorFlow) is required, as well as previous quant experience and understanding of financial markets.

Fullstack Developer

A jack of all trades, you’re a dev ninja that can speak both front-end and back-end. Experience in React, NodeJS and MongoDB is required. A good inclination towards good UI/UX is a significant advantage, as well as any design skills.

If you’re interested in any of these roles, send us an email at jobs@enigma.co. Include your resume and a bit of information about yourself and why you’re excited about Enigma. We are working hard to bring our visions for Enigma and Catalyst to life — help us build the future of crypto trading and data!

With excitement,

The Enigma Team

Our community Telegram — https://t.me/enigmacatalyst

Our community Discord —https://discordapp.com/invite/SJK32GY

Our Twitter — https://www.twitter.com/enigmampc



Meet the Enigma Dev Team — and Join Us was originally published in Catalyst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Meet the Enigma Dev Team — and Join Us

An introduction to the Enigma developers, and how you can get involved

Hi to all from Enigma! As we all continue to work on the Catalyst product and reconcile our token sale, we wanted to take a moment to properly introduce the main developers behind Enigma. A later post will focus on the other members of our core team that are working hard to scale our project, platform, partners, and community.

Thanks again for following Enigma. If you’re interested in joining our team and helping us build the future of crypto trading and data, please read additional info at the end of this post.

Guy Zyskind


Guy Zyskind

Guy is the CEO and co-founder of Enigma. He is a long time tinkerer, most comfortable sitting at the intersection of entrepreneurship and research. Prior to Enigma, Guy was a graduate student at MIT researching and teaching blockchain technology. Guy has authored several academic papers around cryptocurrencies, including the Enigma white paper (downloaded over 100K times) and “Decentralizing Privacy: Using Blockchain to Protect Personal Data”, which is one of the most cited papers in the space. Previously, Guy led the development of several start-up companies. Most notably, he was the Chief Technology Officer at Athena Wisdom (now Endor), an MIT Media Lab spin-off company involving Big Data Analytics and Network Science. Guy holds a M.S. from MIT and a B.S. in Electrical Engineering and Computer Science from Tel-Aviv University.

Victor Grau Serrat


Victor Grau Serrat

Victor speaks many languages, both natural languages and programming languages. As a senior developer at Enigma, he predominantly codes in Python, which is the language of choice for Catalyst, an algorithmic trading platform and Enigma’s first product. Having learnt version control software in the early days of Subversion, now he heavily relies on Github to manage the development of open-sourced Catalyst and other Enigma repositories. With a Master’s in Electrical and Computer Engineering from the University of Maryland, Victor brings more than fifteen years experience in software development that includes developing electronic medical records with JavaServer Pages, firmware engineering of WiFi drivers in embedded systems using C for high latency networks, and interactive online ads programmed in Flash and ActionScript. For 7+ years, Victor was the co-director of MIT D-Lab, a research and academic program at the intersection of technology innovation, social entrepreneurship and global poverty. Under his leadership, the D-Lab’s academic offerings quadrupled and its staff and operational budget grew tenfold. Victor also previously created his own algorithmic trading platform that traded live with a leading exchange, and he’s finally found his tribe in joining the Enigma team to develop Catalyst.

Frederic Fortier


Frederic Fortier

Frederic is a senior software developer specializing in finance. Prior to joining Enigma, he designed and implemented several enterprise applications for some of North America’s largest financial institutions. He primarily develops software in Python, but also has deep expertise with Java and JavaScript. Passionate about the financial markets, he has been trading equities and options since the dawn of online brokerage. His idea of fun is to read research papers on quantitative trading, trying to put them into practice. Over the years, he has live-traded several profitable strategies. His platform of choice is Zipline, which he knows inside and out. He joined Enigma partly to scratch his own itch, which is to build a high-grade quantitative trading platform for cryptocurrencies. He holds double degrees in Computer Science and Finance, as well as a Master of Science in E-Commerce from the Université de Sherbrooke.

Would you like to join our developers in building Catalyst and the Enigma data marketplace protocol? We are actively hiring for the following roles:

Data Engineer

A finder of needles in a virtual haystack, you will comb your way through the web, markets and social networks, crawling and curating intelligence around the cryptocurrency ecosystem. Solid knowledge of Python and data-driven frameworks such as Pandas is required. Experience in scaling big data systems, handling high-throughput queries in a real-time manner, is a big plus.

Data Scientist

Your thirst for knowledge is insatiable. You see patterns everywhere you look, and enjoy turning raw datasets into useful insights. Proficiency in Python and ML libraries (e.g., TensorFlow) is required, as well as previous quant experience and understanding of financial markets.

Fullstack Developer

A jack of all trades, you’re a dev ninja that can speak both front-end and back-end. Experience in React, NodeJS and MongoDB is required. A good inclination towards good UI/UX is a significant advantage, as well as any design skills.

If you’re interested in any of these roles, send us an email at jobs@enigma.co. Include your resume and a bit of information about yourself and why you’re excited about Enigma. We are working hard to bring our visions for Enigma and Catalyst to life — help us build the future of crypto trading and data!

With excitement,

The Enigma Team

Our community Telegram — https://t.me/enigmacatalyst

Our community Discord —https://discordapp.com/invite/SJK32GY

Our Twitter — https://www.twitter.com/enigmampc



Meet the Enigma Dev Team — and Join Us was originally published in Catalyst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ethereum Development

All that you need to know about the decentralized platform for applications that run exactly as programmed without any anomaly.

Ethereum is swiftly emerging as a revolutionary technology that has the power to disrupt almost all industries. Organisations are recognizing its power and potential to make processes more secure and efficient and are opting for Ethereum development.

Ethereum development facilitates the development of decentralized applications of the next generation. Ethereum development has grown exponentially in terms of scale and interest and promises to overhaul open-source development.

Ethereum development involves creation of a shared platform which is flexible yet secure. Ethereum development facilitates creation of a blockchain protocol using its own native programming language. The application is written on the top. This arrangement is supported by most existing applications and creates development momentum for creation of groundbreaking future applications as well.

What is Ethereum Dapp?

Dapp is decentralized application that serve particular purpose to users. They are built up on a code that runs on a network of blockchain, no single user or entity controls them.

What is DAO?

DAO stands for Decentralized Autonomous Organizations, they are fully autonomous with no single ledger and are run by a programming code on Ethereum blockchain smart contracts.

Benefits of Ethereum Decentralized Platforms?

No Down time : Apps made on Ethereum blockchain can never be switched off or can go down.

Consensus based security : Principle of security is consensus based thereby making censorship possible. Ethereum development also immutable as no changes can be made to the data.

Elimination of central point of failure : Apps developed on Ethereum are protected cryptographically against fraudulent activities.

Can Ethereum development add value to your business?

Ethereum has many benefits such as :

  1. Inhibition of wasteful code and keeping cost of Ethereum development low.
  2. Lower operational costs due to increased efficiency.
  3. Elimination of Third party intermediaries.
  4. Rules of smart contracts are automatically enforced.
  5. No need of legal mediation for enforcement of smart contracts.
  6. Powered by nodes
  7. Nodes are immune to interference and crashing.
  8. Paves way for efficient outsourcing by setting milestones for payment.

Current Uses of Ethereum

  1. Preventing identity theft : Consumer information is secured through cryptographic protocols.
  2. Improving transparency in crowdfunding : Implementation of Ethereum enable refund easily if project goals aren’t met.
  3. Reduction of operational fees : Significant reduction in exorbitant online payment fees, high currency exchanges and complicated remittance processes.

Future of Ethereum Development

It is estimated that within this decade most entrepreneurs will run their business processes on private blockchains. Ethereum is a transformational platform and for Ethereum development many unimagined possibilities await!

“In essence, the fundamental benefits of investing into Ethereum is the cryptographic nature, it’s anonymity, it’s universality, it’s divisibility, and most specifically, its coding language which specifically targets it for automated transactions and contracts.”

Jeff Reed, Investing in Ethereum: The Essential Guide to Profiting from Cryptocurrencies

Originally published at Techracers



Ethereum Development was originally published in TechRacers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Development Update 4

The primary focus of last week’s development was migrating the code base to take advantage of features standardized in ECMAScript 6 and implementing simple test interfaces for AFIX.

Next week, we will be continuing work on AFIX and beginning our port of existing infrastructure to browse indexed content as a plugin to the blockchain interface.

Advanced File Index (AFIX)

The simple explanation of how AFIX works is an IPFS hash which points to a set of metadata is stored on the blockchain.

From the hash, we can then resolve the metadata as seen below:

{
"layer": "ipfs",
"data": "QmbFwV3C73eqM5x2AvRjPYXifoBe73JkBQYWhn5jBsYR4t",
"metadata": {
"prefer": "ipfs.novusphere.io:8080",
"format": "mp3",
"name": "Ahrix - Nova",
"description": "Ahrix - Nova: No Copyright Sounds"
}
}

The metadata is then analyzed to determine how to process it. Using the example above we can see its data storage layer is IPFS and further see that it’s format is mp3.

A simple example of handling this data and presenting it back to the user can be seen here:
https://wallet.novusphere.io/#/afix/tx/bd2e99584c454e627966bf8d96d2109c773e4e89c7a32b7a721d54a0b9017c84

While IPFS is at the crux of AFIX, the data storage layer used is quite flexible. For example, this metadata is for a Web Torrent.

This can then be presented back to the user as seen here (code):
https://wallet.novusphere.io/#/afix/tx/0b05b2d3edda40bf501ac570a09d60733f1bd639d7dd36a5b2d91320bee61d57

In the future, nodes will maintain an index of metadata the same way they do the unspent transaction output set. This index provides a means of performing complex advanced queries which the results of can then be presented back to the user in an easy to navigate fashion.

With the flexibility of plugins and AFIX we hope to see use cases such as video streaming, blogging and more implemented in the near future!

ECMAScript 6 (ES6)

The decision to use ES6 features has greatly reduced the technical debt in terms of the code base. This has allowed for code to become more modular as well as readable due to the use of new language features in ES6 such as async/await. There are some down sides to using ES6 such as the lack of backwards comparability with older browsers without using a compiler such as Babel, however the trade off in terms of making things easier for future developers is worth it.

Resources

We have published a full feasibility study of the Ties.Network

We have published a full feasibility study of the Ties.Network and Ties.DB projects, which includes:

– Market analysis overview and business needs.
– Dynamics of the market development and prospects for business social networking for the crypto community.
– Revenue generating streams. Economic justification of all cash flows.
– Costs and EBITDA.
– DPP, NPV, and project IRR for the next five years.
– Prospects for the growth of the TIE token rate, as well as the overall market capitalization of all TIE tokens for best and worst case scenarios.
– A detailed description of the principles behind issuing TIE tokens including a comprehensive analysis of the market, the token cost, as well as other details necessary for making an investment decision during Ties.Network Token Generation Event.
– A detailed project roadmap, with a clear and step-by-step explanation of how the project will develop and function, as well as the overview of marketing and other activities we are engaged in for project launch success.

More details are available at https://cdn.ties.network/BusinessOverview.pdf
Please follow the link under the “Business Overview” button on the Ties.Network website.

Website:
http://ties.network

BitcoinTalk:
https://bitcointalk.org/index.php?topic=2092900.new

Follow us:
http://blog.ties.network
http://twitter.com/tiesnetwork
http://reddit.com/r/tiesnetwork

Communication:
http://t.me/tiesnetwork
http://slack.ties.network

Questions:
info@ties.network



We have published a full feasibility study of the Ties.Network was originally published in TIESNETWORK on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have published a full feasibility study of the Ties.Network

We have published a full feasibility study of the Ties.Network and Ties.DB projects, which includes:

– Market analysis overview and business needs.
– Dynamics of the market development and prospects for business social networking for the crypto community.
– Revenue generating streams. Economic justification of all cash flows.
– Costs and EBITDA.
– DPP, NPV, and project IRR for the next five years.
– Prospects for the growth of the TIE token rate, as well as the overall market capitalization of all TIE tokens for best and worst case scenarios.
– A detailed description of the principles behind issuing TIE tokens including a comprehensive analysis of the market, the token cost, as well as other details necessary for making an investment decision during Ties.Network Token Generation Event.
– A detailed project roadmap, with a clear and step-by-step explanation of how the project will develop and function, as well as the overview of marketing and other activities we are engaged in for project launch success.

More details are available at https://cdn.ties.network/BusinessOverview.pdf
Please follow the link under the “Business Overview” button on the Ties.Network website.

Website:
http://ties.network

BitcoinTalk:
https://bitcointalk.org/index.php?topic=2092900.new

Follow us:
http://blog.ties.network
http://twitter.com/tiesnetwork
http://reddit.com/r/tiesnetwork

Communication:
http://t.me/tiesnetwork
http://slack.ties.network

Questions:
info@ties.network



We have published a full feasibility study of the Ties.Network was originally published in TIESNETWORK on Medium, where people are continuing the conversation by highlighting and responding to this story.

Network Partitioning

Bitcoin Core recently merged in a pull request from Matt Corallo which disconnects certain nodes. This has caused some interesting takes by several prominent people. In this post, I’m going to describe what this pull request does.

The Bitcoin Network

Before I start explaining this pull request, we first need a little background on how Bitcoin’s network actually operates.

Bitcoin’s network operates in a peer-to-peer fashion. That is, every computer running Bitcoin software connects to other computers that are running Bitcoin software. There’s no central place that all these computers connect to. Instead, they connect to each other.

New transactions and blocks are transmitted on this network and each computer sends this information to other computers as they see them. The network is designed this way so that no single computer, or even a group of computers, can shut down the network. Indeed, this is one of the Bitcoin network’s strengths.

Connecting To Other Computers

When a new computer joins the network, it has to figure out which other computers to connect to. This is generally done by finding at least one other computer that’s on the network, asking that computer what other computers it’s connected to and connecting to those and asking those computers what other computers they’re connected to and connecting to those and so on.

The process of connecting to another computer is what’s called a handshake. During a handshake, the computers send information about the software that they’re running. This is what the code change is about.

Services

During a handshake, computers announce two things; first, the network identifier (“network magic” in tech speak) and second, the services that they have.

The network identifier is normally used to make sure the computer is connected to another computer on the same network. Each cryptocurrency generally has a unique network identifier. This is how Litecoin software makes sure it’s connecting to other computers running Litecoin software and not Monero.

Unfortunately with Bitcoin ABC and Segwit2x, they use the same network identifier (most likely because both hope to replace Bitcoin).

Both differentiate themselves from Bitcoin Core by announcing their software as a service that they have. Bitcoin ABC started using bit 5 to announce that computer is running Bitcoin Cash. Segwit2x’s software, btc1, is using bit 7 to announce that the computer is running Segwit2x.

The Pull Request changes Bitcoin Core 0.15 so that any computer announcing service at bits 5 or 7 (6 or 8 according to the PR since Matt’s counting is 1-based) are disconnected automatically. That is, computers running Bitcoin ABC or btc1 are disconnected from computers running Bitcoin Core 0.15.

The effect of this is that computers running Bitcoin Core are in one group and computers running Bitcoin ABC/btc1 are in another. This is what we call network partitioning. That is, there are essentially two networks instead of one.

Bitcoin Cash/Bitcoin ABC

We know that because of wipeout and replay protection built into Bitcoin Cash, that blocks and transactions from Bitcoin Cash are not valid on Bitcoin and vice-versa.

Thus, it makes sense to disconnect these computers since validating blocks and transactions that we know to be invalid would be a waste of the computer’s time. Furthermore, it’s in the best interest of both Bitcoin and Bitcoin Cash to not mix. Bitcoin’s network doesn’t care about what’s happening on Bitcoin Cash’s network and vice-versa.

For this reason, disconnecting computers that are running Bitcoin ABC (Bitcoin Cash’s client) and partitioning the network makes all the sense in the world.

Note that even without this change, when a Bitcoin Cash computer is connected to a Bitcoin computer, receiving an invalid block or transaction causes them to disconnect each other, so preemptively disconnecting is just being more efficient.

Segwit2x/btc1

Segwit2x’s situation is a bit trickier. In some cases, partitioning the network can be good, and in others, not partitioning the network is good.

We know there’s a plan for a hard fork to 2x the blocksize limit in November. This may mean two coins, Bitcoin Core coin and Segwit2x coin.

Supposing we only have one coin, partitioning the network would be marginally bad. I say marginally since there still would most likely be a single ledger, but the blocks and transactions wouldn’t propagate as fast. This also increases slightly the possibility of a block reorganization.

Supposing there are two coins, partitioning the network would be very good. Because Segwit2x has wipeout protection, blocks from btc1 will not be valid on Bitcoin and vice-versa. This means that the computers would be disconnecting each other once they see the blocks.

We want to partition sooner if we’re anticipating a partition since doing so suddenly when a fork happens may isolate the computer without anyone to connect to. As a computer, you won’t have to suddenly disconnect from other computers and be left isolated from the network you want to be on. This is a win-win for both network partitions since you want computers that are running the correct software on the network.

Given this situation, the Core developers felt that the marginal loss of the former scenario was not enough to outweigh the major gain of the latter scenario and merged this pull request.

Conclusion

So what does this mean? Bitcoin Core 0.15 will make the network a little safer. A little bit, because unless other implementations follow suit and every computer upgrade, a network that really should be partitioned will still be connected.

Should Segwit2x cause a network split, Bitcoin Core will help partition the network in a useful way.

Build a Cryptocurrency Comparison Site using Ruby on Rails and TDD

Img prepared by: Shkodran Arifi

I recently had the pleasure to publish my first article at Scotch.io, which is a very popular platform. It is one of the longest articles that I have written so far. It is a written tutorial on how to build a cryptocurrency site in which you can see the changes of values of BitCoin, Ethereum and NasDaq overtime. The project accompanying this article is developed with Ruby on Rails using Test-Driven Development (TDD).

This project is very simple and it’s mostly intended to be as a tutorial. It does not do anything fancy, nor does it resemble anything that has to do with rocket science. This application communicates with external web services and gets the latest values of these currencies over time and then displays these values using graphs. The latest values of currencies are daily received and displayed.

I have tried to write this article documenting each step of the process of development, hoping that readers who are not familiar with TDD or Ruby on Rails can also benefit and learn from.

It is developed using some of the best practices of software development, such as test driven development and do not repeat yourself principle.

I used suspenders gem to create the project, which is the way that the famous software development company, thoughtbot, uses for all its Ruby on Rails projects.

I also used HighCharts and ChartKick to help display the charts for a pleasant way of representation of the variations of the values of these currencies over time.

You can access the source code on GitHub. You can read the full article here.

Happy mining and coding!

July 2017: GitHub Development Winners

The 4th month of the GitHub Development Bounty (1st of July 2017–31st of July 2017) is now complete.

We could not be more excited about how quickly our development community is growing and the amount of community contributions we keep seeing each and every month. Our development community continues to push amazing pull requests and we are truly proud of all of the hard work you do for ARK. We are truly grateful from the bottom of our hearts to see such enormous support and willingness to help build the ARK ecosystem. We couldn’t do this without you!

Without further ado, here are the winners for the month of July 2017:

1st of July 2017–31st of July 2017:

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
1st place: 3,000 ARK
Github User:
fileninja
— — — — — — — — — — — — — — — — — — — — — — — — — — — —

Some of the notable commits:

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
2nd place: 2,000 ARK
Github User:
kristjank
— — — — — — — — — — — — — — — — — — — — — — — — — — — —

Some of the notable commits:

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
3rd place: 1,500 ARK
Github User:
Moustikitos
 — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Some of the notable commits:

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
4th place : 1,000 ARK
Github User:
eugeneli
 — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Some of the notable commits:

Code and documentation overhaul (Added support for devnet, Removed Api calls that weren’t working or deprecated, Wrapped ark-js for secure creation and sending of transactions in ARK- API)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
5th–9th place (in no particular order): 500 ARK /each
— — — — — — — — — — — — — — — — — — — — — — — — — — — —

— — — — — — — — — — — — — — — — — — — — — — — — — — — — 
9th place+: 100 ARK /each
 — — — — — — — — — — — — — — — — — — — — — — — — — — — —

For August 2017 payouts will be:

1st of August 2017–31st of August 2017 :

  • 1st place: 3,000 ARK
  • 2nd place: 2,000 ARK
  • 3rd place: 1,000 ARK
  • 4th–8th place: 500 ARK /each
  • EXTRA IN AUGUST 9th place+: 100 ARK / each those not eligible for any of the 1–8th places will still get 100 ARK (+ all 5 PR rewards)!

Missed what this is all about?

Read the full instructions here: 200,000 ARK Bounty for Developers in the 1st Year.

Are there any other development bounties going on?

Sure, we also have: 10 for 10,000 = 100,000 ARK program

There is also community run ACF (ARK Community Fund) — read more here:

https://blog.ark.io/ark-community-fund-acf-has-commenced-84e67ec9a1fa

And remember to join our Slack!



July 2017: GitHub Development Winners was originally published in Ark.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your First Truffle Dapp — An attempt at a beginners guide to the Truffle Framework

In this series, we’ll walk through creating our first truffle Dapp for the Ethereum blockchain. This will be my attempt at a beginners guide to Truffle.

There’s a lot to love about the truffle framework:

· Truffle is a development environment, testing framework and asset pipline for Ethereum. Its main goal is to make life as an Ethereum developer easier. It is one of the most widely used IDE’s in the Ethereum community.

· Automated contract testing with Mocha and Chai

· A configurable build pipeline that supports both web apps and console apps.

· Console to easily work with your compiled contracts

· Support for JavaScript, Coffeescript, sass, ES6 and JSX built-in.

Don’t get me wrong, truffle has some great documentation and you can’t beat documentation straight from the source. But when I first started working with truffle, there was a gap, because a majority of the material was aimed at experienced Ethereum Dapp developers.

There was nothing written for absolute beginners.

As a means of trying to help fill this gap, and further my own understanding for the framework, I decided to write something. They say the best way to learn is to help teach someone. So the plan is simple: Write a series of articles I wish I had existed when I first started using truffle.

The core ambition of this series is to try and be a bridge. It won’t contain every last detail there is to know about the truffle framework, but it will contain everything that you need to know to make your first Truffle Dapp, while also helping you become a confident, independent problem solver. Hopefully by the time the series wraps up, you can say “I know how to make this thing work”. Do you feel the confidence?

You’ve probably heard all this before though. Every writer thinks their work is going to be the perfect reference material and will make the biggest difference. Let’s at least give it a chance, so allow me to suggest:

1. Make a nice cup or tea or coffee

2. Find a nice quite place

3. Work your ways through the series

The series are short, but I’ll do my best to keep them flowing regularly so that you’re not waiting long between each release.

Let’s begin. As a side note, if you prefer watching videos instead of reading, let me know and I’ll see if I have some time to put together a video series that covers the same topics…based on user demand.

Prerequisites

I’ve read a lot of technical tutorial series and I’ve notices that authors tend to use the words “for beginners” a little too easily. So, with that being said I want to clearly explain want you won’t need to take advantage of this series.

1. You won’t need prior experience with the truffle framework. I won’t dwell on what truffle is, but I will show you how to install it and how to start writing code as quickly and simply as possible.

2. You won’t need to have made a DAPP before. There are some theoretical aspects of Ethereum Dapp development that we won’t cover, but if your primarily an Ethereum developer using solidity, that will work fine. You shouldn’t have any trouble grasping the details of Dapp development with the truffle framework.

3. You won’t need to consult multiple other sources along the journey. You’re free to consult other articles and tutorials, of course, but this series will be designed to be an all-encompassing introduction to the basics and will try to only reference the official truffle document library alone.

You will, however, need a little background knowledge:

1. You will need a basic understanding of Solidity. This means being familiar with state variables, functions, modifiers, events, and mappings. You don’t need to be a solidity ninja, just be comfortable with the fundamentals.

2. You will need a basic understanding of the Ethereum blockchain. This means being familiar with transactions, promises and calls.

To acquire either of these skills, I’d suggest reading the official solidity documentation and the Ethereum getting started tutorials

· Solidity Development Documentation

· Ethereum Project Website

What you’ll need for this journey

Well, you don’t need much to develop with truffle. This might seem like a minor detail, but you wouldn’t believe the amount of people that switch frameworks because getting up and going was a frustrating multi-day exercise, before they even get a change to write some code.

With truffle though, there’s only a few things you’ll need:

1. You’ll need a computer with a major operating system. This could be Mac OSX, Windows, Linux. All major operating systems are equally supported

2. You’ll need a text editor. This one is your choice, I’m a fan of sublime text 3 — a cross-platform editor with plenty of plugins and productivity features. But like I said, completely up to you, so stick with whatever you prefer.

3. You’ll need a relatively modern web browser. Google chrome is my browser of choice, and since we’ll be using it throughout the series, it might be worth installing a copy if you haven’t already.

And finally, you’ll also need Truffle, and we’ll install that in the next series.

Final words

I’ll try and end each series with a summary of what we’ve covered in that series, so for instance in this first series release, we’ve learnt:

· Truffle is a framework that makes it easier for beginners to start building DAPP’s for the Ethereum blockchain.

· You won’t need a lot of background knowledge to get starting with truffle, but the more you know about solidity and smart contracts, the better.

· There’s not that much setup to get you started with truffle, so there should be a very small gap between learning and actually writing code.

Along the series, I’ll also share a number of exercise, you don’t have to complete the exercises — but it might be helpful to circle back after you’ve worked your way through the core of the series, definitely worth trying at some point. Keep an eye out as we’ll get things started in the next series.

If you also want to follow my journey on creating an Ethereum based token for the Tap Project, you can follow us on Twitter: @Tap_Coin or swing by and have a chat with us on Telegram: https://t.co/eIP47QmZ1E

Sumokoin: Development Path

Two months ago, we launched Sumokoin like “just-another-cryptocurrency” to this crowded field and the rest story most of us have already known.

Like a baby in a new wild world, he met many people, a few were just scammers trying to catch a portion of anything they could. Luckily, many others were good guys who helped him through attacks and pitfalls. So, first of all, we would like thank all of you for great support.

Back to the end of 2016, there were two men, like millions of men working in an industrialized country with very strict culture, who would live the rest of their lives in routine, doing forever the same day job. But on a very late night of September 2016, they decided to do something different and that was the beginning of Sumokoin. They were both naive in cryptocurrency only knowing that they can publish their fork via a forum called “The Bitcoin Talk” and when the announcement came out, Sumoshi had just “newbie” account, as he had never written a single post. He’d never known that a “newbie” account would result in no images shown at his post.

He still remembers the moment he found that the announcement post would look very bad being text only, all images being replaced with ugly links, and the whole post looking like a casual work from an unknown team. Yes, that was not a happy moment. But we were actually a completely unknown team, bearing no trust from anyone and with not much hope of building a community so only through some tough challenges we could prove ourselves. These challenges came soon after….

Old Code, New Problem

Sumokoin, as a fork of Monero which itself was a fork of Cryptonote base code, inherits an algorithm for difficulty adjustment which, I may say, is very optimistic regarding the good intentions of the wild crypto world. People soon found out that they could easily mine SUMO using a high hashrate without being caught up by a proportional rise in difficulty for long periods of time. The algorithm would just ignore the first 30 blocks, for a reason, and would only adjust to a proper difficulty level after hundreds of blocks mined. That would be OK for an established coin, with great total hashpower, where an increase of the total network difficulty, even by a small fraction, needs a lot of mining power. However for a small coin, using an existing, well known, hash algo, it’s very easy to rent big amounts of hashpower (even x10 folds) to pour in and still enjoy low difficulty for hours. When the difficulty caught up with the total network hashpower, these people would just leave abandoning the network at high difficulty, essentially stealing good coins from other miners and damaging the network.

Eventually that became a serious problem, leading to a network stall for days, so team was set to find a new algorithm with better responsiveness to even the slightness of hashrate changes. We were very reluctant to do so because that would require a hardfork to implement while we had agreed to avoid frequent hardforks that would force users, exchanges and anyone running a node to upgrade while creating uncertainty to the community.

The new algorithm, while first appearing an easy job, turned out a rather tough one. During development, especially with the great help provided by Scott (zawy12), we gradually learned a lot about what affects the validity of the algorithm like time-warp attack, Poisson distribution etc. So after over a week of (rushed) development, finally, the new difficulty adjustment algorithm could be out to deal with the real world problem. Attackers, who rent high hashrate to mine, now have very small advantage in term of difficulty adjustment delay. Luckily, the hardfork went on without a single issue and those who struggled through the bad times the network was stalled now feel very happy with the new algorithm that brings back fairness to all miners. Many thanks to the community for its patience during dev time.

GUI Wallet

From the beginning, a demand for a GUI wallet was raised in community and the team immediately recognized that not everyone would be pleased to use command-line wallet which should be really for geeks only. We also found that many coins have no GUI wallets at all and even Monero only had its first desktop wallet version after nearly 3 years. Is it so hard to create a GUI wallet?

The answer is YES. It would be very hard if you have no experiences in development cross-platform desktop application. Fortunately, we have Bill who had already developed some cross-platform GUIs in Python to take the job. The target for first version of GUI wallet was simple, intuitive and do-it-job. It should be a good looking wallet, no needs to be over-engineered, it would be a wallet for everyone.

Bill had the first prototype of the app very soon and team discussed on every single feature should be in GUI to keep it tidy and less clustered. A few more features he wanted to include then were set aside for next version so that the first beta could release on time. We really did not expect much from the first version, yet reaction from community were very encouraging. Here are a few quotes from forum thread:

“Wallet is really amazing and revolutionary…”

(danrachita)

or

“The wallet is really very good, simple, very functional, easy to use!”

(rowenta01)

The wallet, however, still have some issues in different OS and that’s unavoidable for the first beta product. We will surely have more improved versions in future releases.


Sumokoin GUI Wallet

Development Path

Team had a constructive discussion last weekend on development path. We now have 4 developers (and it seems a big team for an under-1M-cap coin, I’ve just known that 😉). Of course, devs are working on free time only and all already have rather busy company jobs. So, we try not to give a tight schedule and some delays may be expected to ensure good outcome quality. Here are dev tasks in the next 3 months:

** Core:

++Sub-address: Feature to create a disposable, temporary address for receiving funds without being tracked or linked to main wallet address.

  • Main dev: Haruto Tanno
  • Target release: late Aug, 2017

++Multi-signature wallet: Feature to create multi-signature wallet for team, corporate uses or for better security.

  • Main dev: Sumoshi Tanaka
  • Target release: late Aug, 2017

** GUI wallet: Next BETA release. Various improvements on UI/UX. Better logging and compatible with OSes. Support multi addresses and sub-address.

  • Main dev: Bill Aue
  • Target release: Sep, 2017

** Lite wallet: Online wallet for instant use.

  • Dev: Vu Quang
  • Target release: Late Sep, 2017 or Oct, 2017

** Sumokoin Easy Miner: A side project by Bill to make a cross-platform GUI for CPU miners with easy to start

  • Dev: Bill Aue
  • Target release: Aug 2017

For all above tasks, core development will mainly merge from upstream codes (by Monero) with modifications and improvements. Lite wallet will be the whole new job for team while GUI wallet and Easy Miner will, hopefully, create a good reputation for Sumokoin.

Conclusions

So, we are here, 2 months and half from the announcement. It’s just a baby step, yet very important one, for Sumokoin. We are, as a team, feeling much stronger, much optimistic for future development of the coin. I hope we can keep the pace and more great ideas/features will be implemented in next 6 months.

We would like to give special thanks to active and helpful community members, @sumogr, @fiexer aka Maarten Henskens and many others who has been along with us from early days and doing their best to support Sumokoin.



Sumokoin: Development Path was originally published in The Sumokoin Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockpool Testnet Now Live!

Hello Blockpool Testnet Volunteers,

I would like to start off by thanking each and every one of you for participating in this public testing session and for being patient while the developers fixed issues that we came across during devnet.

With that being said, it is my pleasure to announce that the Blockpool Testnet is now live!

You can get to the BPL node, BPL Desktop and other Blockpool repositories by going to https://github.com/blockpool-io

Make sure to use the testnet branch!

If you have not signed up for the BPL Testnet, you can do so here: https://docs.google.com/forms/d/e/1FAIpQLSf0NC0diWtbhneT61jScUmEjmQvBw9cFj2hX1-nacGoh0tyHg/viewform

Only those who signed up for the Testnet will receive a portion of the Testnet Bounty.

Once you have the node and wallet running please DM me your BPL address or email it to me at bcook@blockpool.io and I will send over the tBPL to get you started.

Thank you again for your patience and help during this period!

Sincerely,
Brandon Cook
CIO
Blockpool



Blockpool Testnet Now Live! was originally published in BLOCKPOOL on Medium, where people are continuing the conversation by highlighting and responding to this story.

The heart BIT of our platform

Our public API will be the glue that connects our BIT to the blockchain and legacy systems. It does not matter if those systems come with a public API or a bespoke software hook developed in house or by a third party. You know what our API needs and can supply — now you can use blockchain.

This sounds too good to be true

Much of the blockchain development you will have seen or read about is coded for very specific purposes. Such is the way with new technologies; you solve a problem, which creates a new problem. Eventually you have either a difficult to untangle mess of code or something that is locked down and not adaptable.

At Blockpool we are taking a different approach. With our extensive experience of creating blockchain solutions, we are now able to develop a different solution from the ground up. As we progress, we will build it out based on market demands and how the technology expands.

Well it is a little more complicated than that…

Not for the end-user of our Blockchain, but for us! The key for us will to be grow the solution so that we can keep it as easy as possible to add new functionality to it later. For our initial development phase, we are delivering an interconnection API:

  1. Connect legacy systems to the blockchain with a defined interface for receiving data from and adding data to a chain.
  2. Use it as a method of connecting two different IT systems that cannot communicate directly with each other.

Some of this will be built as an ad hoc project-based operation depending on specific customer needs, however the majority will be universally included in our API.

To the future

The potential of our API to streamline blockchain usage is such that we are proposing to release part of it on a free basis to expand the ecosystem of applications that can connect. There will also be private forks and adaptations of the API to meet customer needs, but the core API will always be developed in a unified manner. Along with the modular elements of our BIT we will be able to develop features such as:

  1. Additional paid-tier services based on the Blockpool mainchain.
  2. Advanced features available behind a paywall.
  3. Different storage and access levels for the mainchain at different pricing tiers.
  4. Filters to prevent certain data items being added to a blockchain (e.g. Full-sized files) to maintain speed and efficiency.

Whilst others talk about these services, we have built the Blockpool platform from the ground up to keep bloat out of the system.

This is just a brief overview and the possibilities of our BIT API are endless. We will have more to say about this in the future and we will release our full BIT Whitepaper later this year.



The heart BIT of our platform was originally published in BLOCKPOOL on Medium, where people are continuing the conversation by highlighting and responding to this story.

My Ethereum Development Setup

We all have our way of developing applications, some more esoteric then others. I use a combination of Tmux, atom-beta, and Ngrok to manage my development process.

My Computer:

I have been developing on a Mac since 2004 when I received my own Macbook Pro. The thing was damn large and heavy. Installing packaging was still a chore, especially if it was not on Macports. Good ol’ Homebrew made life easy on the Mac. I personally have a 3 year old computer, and it’s chugging along. I hope my next upgrade will have 32 Gb or event 64 Gb of RAM and a 120HZ OLED screen.

My Terminal:

For the longest time I used the default terminal program. I would make customizations, but I left the terminal alone for the longest time. At some point I tried fish and zsh, which provided cool commands. I ultimately moved to iTerm with Oh-My-Zsh with Tmux.

iTerm provides a few more dials and customizations that the normal terminal does not allow. Similarly, Oh-My-Zsh has a great community of plugins for themes and commands. Lastly, I LOVE Tmux. It’s the best way to organize all my sessions, windows and panes.


Tmux Window Example

As you can see, a single window can have multiple panes. Notice on the bottom (1:dfarrell@host: 2:dfarrell@host), those are named windows with numbers next to them. That means switching between windows is a key command away, which is damn sweet!

Plus you can switch between session with another key command! The dropdown on the left pane is a list of sessions. Notice below I have several sessions private chains, repos, and projects I am working on.


Tmux With Sessions

That means I don’t have to reset myself for any subset of tasks. I don’t have to fumble through many terminal windows looking for the one I want. The best part is I have a plugin (tmux-resurrect) that allows me to keep my sessions post restart! That means I never have to remake my windows or cd into projects. I do it once, save, and I’m done FOREVER!

Working with Node:

We use a lot of JavaScript, which requires Node. Being able to switch to the newest version of Node easily is very nice. The best tool is NVM (Node Version Manager), hands down! If a project requires an older version, then I simply nvm into that version and we are done. Let’s say I want to update my Node module to use the native promise library instead of bluebird. That’s easy, I would simply do the following:

  1. cd <repo>
  2. npm install && npm test
  3. nvm use 8.0.0
  4. rm -rf node_modules
  5. npm install
  6. **make changes**
  7. npm test

Once I’m satisfied with my changes, I commit and create the pull request. If I need to then work on a project that is still stuck in Node 4.0 land, I simply:

  1. nvm use 4.8.3
  2. cd <new older repo>
  3. npm start
  4. **do work**

I cannot speak more highly of the command!

Private chains:

We are using blockchain, and specifically Ethereum to develop our app. Remember when I said Tmux allows me to create and manage terminal sessions. Well I have one session called private chain that groups all my different private chains together.


Session: hs-private-chain

I have a folder of all the local chains I am managing. You can see a stray genesis1.json file and a passwords.txt. Those I use with a geth command to run and a specific network of my choosing.

geth 
--datadir ...
--networkid ...
--mine
--minerthreads ...
--rpc
--unlock ...
--passwords ...
--rpcport ...
console

I would fill out the flags as desired for the specific network I need to work on. Notice, in the image below, the tabs on the bottom allow for easy switching with a key command. Life is easy!

I also have a session called testrpc, that I use for speedier transactions.


Session: hs-testrpc

I make a distinction between the global and local because I monkey-patched testrpc to fix a command issue and redux issue.

Browsers:

I generally have 4 browsers open at any one time. I have a specific set of things I use in one browser that does not exist in others.

  1. Chrome Canary: Main development & research
  2. Chrome: Research and info
  3. Firefox Nightly: Social and other logged into various services! YAY container tabs!
  4. Opera: Random things, mostly used for browsing internets

My use has evolved over time. Safari used to be in the mix for random web browsing as well, but now it’s rarely used. I use to use other browsers like OmniWeb, Shiira, and Camino.

Text Editor/IDE:

I forget what text editors I used before Sublime Text. It was a staple for the longest time. Over the last year I have moved over to atom-beta. Here are a few packages I use that I think are lovely:

  1. atom-beautify
  2. atom-ethereum-interface
  3. highlight-selected
  4. language-ethereum
  5. linter-solidity
  6. project-manager
  7. standard-formatter

There are also a slew of other language specific packages that let me deal with docker, nginx, or whatever other thing I had to do.

Development with private chains:

Our application requires the use of web, native, and APIs. If I want to have all systems talking to the same private chain locally, I use Ngrok. Ngrok allows me create a tunnel from a dynamic URL like http://999999999.ngrok.io that points to my local computers localhost:9000. I give all services the http://999999999.ngrok.io URL and it will be redirected to my computer. I configure the URL in my web app, native app, and API through an environment variable and I’m set!

Workflow Web:

Our first release is for the web, and is built with react, redux, truffle, and webpack 2. I forked a different repo, added truffle, upgraded to webpack 2, and moved over to Material UI. For development, I need one terminal to run webpack, another for commands, and another to run a private chain.


Web Session

On the left pane I have webpack running with npm run dev and on the right I am free to do other commands like git commit. Then I also have another session that is either testrpc or private-chains where I start and stop different networks to do development. With Tmux this is easy because I would simply go into the correct session and make my change.

One nice feature of this is I updated truffle-solidity-loader to work with Truffle 3. That means inside my projects I can import in a solidity file and have it be transformed into the correct JSON file. My web code will look like the following:

import MetaCoinArtifact from '../../contracts/Metacoin.sol
import contract from 'truffle-contract'
const MetaCoin = contract(TicketManagerArtifact)
//... more code

And every time I update the solidity code, webpack 2 will rebuild MetaCoin.sol and rebuild my app. This is a major life-saver because otherwise I would have to run a command like truffle compile && truffle migrate development –reset every time I made a change in solidity, which would be a major drag on development.

Working With React-Native:

We are also working a native application to allow users to explore events and scan tickets. This repository is in another directory! So if I want to develop the react app AND web app, I have to get a little fancy. Basically, I have webpack 2 run a script to copy and paste the contract JSON files into its directory. ୧༼✿ ͡◕ д ◕͡ ༽୨

One big caveat with react-native is testing on the phone. Using Ngrok, I can configure in a URL that talks to my computer. This makes my development easy because I have full control over the system at all times.

Conclusion:

I use Tmux to handle session by grouping them and making them easily accessible. I use a combination of webpack 2 and truffle-solidity-loader to speed up my app building. Lastly, I use Ngrok to connect all applications to a single URL that is connected to my active private chain of choice. Hope you found something new and cool to speed up your development.



My Ethereum Development Setup was originally published in HelloSugoi on Medium, where people are continuing the conversation by highlighting and responding to this story.