Development Update #36


We are exhausted. We just finished 4th cryptography audit. Some minor issues were found and fixed. All the issue involved impossible conditions, but are fixed anyways.

Cryptography Audit/Changes:



We are delayed on problems with ChaCha20. We are getting different results from two different reference implementations.

Coin Distribution Website:

Now that deterministic wallets work, we can start the distribution.

The distribution is open for a particular period. It is not a first come first serve distribution. This is a very small distribution and not intended to distribute huge number of coins.

We have an immense amount of work left and this does not mean the coin is anywhere close to being finished. We will do our best to ensure that - Sending coins work - Checking balance of address works - If we have to reset the blockchain, that address balances will be preserved in the new chain.

Project Management: Bounties

We are beginning to see the overall project architecture and begin breaking the long term goals of the project into a series of very small, specific libraries.

We are beginning to post several development bounties on Github. Each bounty is for implementation of a library that satisfies a particular specification. Each bounty will be worth between 10,000 and 30,000 SKY. Multiple implementations and improvements to existing implementations are encouraged.

Address Format:

The binary representation of Skycoin addresses are

struct {
   uchar8 Version;
   uchar8[20] PubkeyHash;
} Address;

PubkeyHash is computed from a compressed secp256k1 pubkey by SHA256(SHA256(RIPMD16(pubkey))). Skycoin only uses compressed public keys.

Version is 0. In Bitcoin, Version means “main network, test network”. In Skycoin, version is same across different blockchains and is reserved in case stealth addresses, group addreseses or addresses with different len must be added.

The base58 representation of a Skycoin address is the base58 representation of + + < 4 byte checksum >

The checksum is computed as the first 4 bytes of SHA256 of +

Note. The reason version comes after PubkeyHash is so that vanity addresses can have arbritary prefixes. This is very important. In Bitcoin the

For reference, private keys are:
struct {
   uchar8[32] Seckey //32 bytes
} Seckey;

A private key is a 256 bit integer (32 bytes). The base point is raised to the power of the Seckey in the curve to generate your public key.

A public key is a point on the curve (a pair of two 256 bit integers) and has a compressed binary representation as 33 bytes

struct {
   uchar8[33] Pubkey; //33 bytes
} Pubkey;

A Pubkey can be “multiplied” by a seckey, by raising the pubkey (a point on the curve) to the power of the seckey (an integer). This generates another pubkey. This is the basis of Elliptic Curve Diffie Hellman Key Exchange (ECDH). Skycoin will soon have a standardized encrypted message format using ECDH with ephemeral keys and ChaCha20. This functionality will be exposed as a library for application developers.


After doing a finite state machine diagram, we determined that the distributed time stamping system did not add any security over the node using its local clock. Therefore it is not needed for preventing 51% attacks. However the distributed time stamping system can be used to prove to third parties the publication time of a block.

The new system is much simpler. Consensus nodes will still affirm receipt of blocks by publishing the block’s hash in their personal block chains in the next block after receipt. Nodes will remember the time they first learn about a block using their local clock and that will be used for negotiating consensus during chain forks.


If are evaluating if there is an advantage to a stricter window and more accurate clocks.

Skycoin will use deltas from the trusted consensus nodes to set local system time and use NTP severs for verification. If the NTP servers and trusted consensus nodes go out of sync by more than a reasonable window, the client will go into warning mode and all transactions will be considered pending and unconfirmed until the issue is resolved (to protect exchanges against double spending attacks).

Valid block headers whose timestamps are too far in the future, will still propagate to allow time stamping by consensus nodes. We are still working through whether anything needs to be done about these.

Reducing Block Propagation Time:

In Skycoin, in the long term we are trying to keep the time between announcement of a block and receipt by all nodes to below 2 seconds across the global network. There are two reasons for this - Ensure timestamps with local clocks for block publication times are reasonably accurate - Enable real time transactions with confirmation times in seconds

Bitcoin is very robust and has a very low orphan rate, despite block propagation speeds because of the 10 minute block time. However, other coins with more frequent blocks have been subject to Sybil attacks. The altcoin is flooded with thousands of nodes, which forward blocks mined by one pool very quickly, while uploading blocks from other pool at the slowest rate possible. Combined with small time between blocks, this has led to several 51% attacks on smaller coins.

In Bitcoin, when a client gets a new block:

The fact that Bitcoin only downloads blocks from one peer at a time, means that a peer can delay propagation of a block by purposely uploading the block as slow as possible. This has not been an issue for Bitcon, but has been a significant problem for coins with faster blocks.

There are several bottlenecks for propagation:

In Skycoin, there are several things we can do to reduce these bottle necks

In Skycoin when a client gets a new block:

If you are connected to 10 peers and each block averages 10 KB and each peer sends a 1500 byte, part-file encoded block body immediately upon receipt of the body, without round trip delay then propagation delay is significantly reduced at the cost of some extra bandwidth usage. This is the fastest possible theoretical full block propagation, at the cost of extra bandwidth.

There are delicate DDoS edge cases that need to be designed around. If we prevent block propagation from blocks so far outside of the consensus set (forks of the chain more than N blocks in the past), then it eliminates certain DDoS attacks but leads to an edge case with netsplits, but also eliminates propagation of 51% attacks.

These are some of the long term technical measures we are looking at. We dont see a technical reason why global block propagation should take more than a few seconds.

Translation bounty: 20 SKY (1934 words)

Discuss this post on telegram

Skycoin Telegram