Me and my friend started this concept a while ago but with school and all abandoned it for a while. We decided to revisit and wanted to get some general feedback/thoughts. This community seems friendly so here it is...
My idea behind ConceptCoin is to generate a real implementation which tests out some new cryptocurrency ideas.
The important thing is to create a real world implementation which can be deployed easily without months of development work
I suggest that ConceptCoin version 0.1 should be based on a striped down version of Bitcoin core. We should simply implement a single new feature: Randomness beacon based proof of stake.
Why randomness beacon based proof of stake?Proof of stake in its current implementation is not secure, it relies on centralised checkpointing to prevent people from creating very long forks which overtake the main fork with little effort.
Randomness beacons can be used to make sure that the block creation process can't be easily forked. The beacon lets everyone know who is allowed to create the block, not information in the blockchain (which can be manipulated)
Randomness beacons can synchronise the block creation process. This means blocks are created every minute. A transaction will almost always get a confirmation in less than a minute.
Long range forks can still be created with a large portion of the coins but a synchronous block system can prevent this by allowing multiple parties to create each block. The exact details of how this is done need to be developed and any vulnerabilities highlighted.
Randomness beacons are centralised though?Yes they are, but ideally the platform can use a number of randomness beacons to make sure that the failure of one beacon has no effect. It may also be possible to create decentralised random beacons based on astronomical observations, random noise in the stock markets or even other blockchains.
Draft Protocol: v0.1
IntroductionTo 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
https://en.bitcoin.it/wiki/Protocol_specification 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 simplificationsThe only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
BlocksBlocks 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 blockBlock 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 blockVersion 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 feesBy default transaction fees are 0.
Block rewardsBlock 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.
Any feedback would be nice!
Topic: Concept (Read 1137 times)
