Bitcoin Forum
August 21, 2018, 06:50:34 AM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
   Home   Help Search Donate Login Register  
Pages: [1]
Author Topic: ConceptCoin (Will be renamed)  (Read 501 times)
Offline Offline

Activity: 3
Merit: 0

View Profile
May 28, 2014, 01:01:11 PM

ConceptCoin is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas.

The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.

We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.

Join the team @  Grin Kiss Smiley

Contact me to speak about donations/funding.

Protocol V0.1 Draft


To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.

There will be some small changes as follows:

    The magic value is F3 B2 BA D1
    The relay field is removed from the version message
    filterload, filteradd, filterclear, merkleblock, and alert messages are not supported

There will be three major changes which will be explained in greater depth:

    Scripting will be simplified
    Blocks will have a different structure to support proof of stake mining
    Beacon blocks are introduced

Scripting simplifications

The only valid scripts are those of the following form:

scriptSig: <sig> <pubKey>


Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.

Block header:

Version uint32_t: as in Bitcoin = 1

Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30

Block creator pubKey char[33]: the block creator's public key in compressed form given as <sign> <x> where <sign> is 0x02 if y is even and 0x03 if y is odd. (see section below)

Previous block hash char[32]: the hash of the previous valid block

Merkle tree hash char[32]: As in Bitcoin

Block hash char[32]: The SHA256 hash of the previous fields

Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.

Block body:

Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)

Transactions starting with the coinbase transaction (same as Bitcoin)

Creating a block

Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.

All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:

pubKeyHash   Unspent output
12           30
17           4
32           5
21           12
19           9
24           16

pubKeyHash   Cumulative   Value of selector required
12           30           0-29
17           34           30-33
19           43           34-42
21           55           43-54
24           71           55-70
32           76           71-75

If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected

Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.

Beacon block

Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1

Timestamp uint32_t: must match the NIST beacon timestamp

NIST version var_str: must match the NIST beacon version string

NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)

NIST seed value char[64]: must match the NIST beacon seed value

NIST status uint32_t: must match the NIST beacon status code

NIST signature char[256]: must match the NIST beacon signature

NIST output value char[64]: must match the NIST beacon output value

A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.

More details will be provided on how to verify that beacon blocks are genuine.

Transaction fees

By default transaction fees are 0.

Block rewards

Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1

The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.

Edited to update beacon block data types.
Pages: [1]
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!