[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[Dazza]

I think if we use two signatures:

- the full signature for the integrity of the block
- and the PoS signature which is only there to check if the user was allowed to forge the block

By "forge" you mean "create", not "falsify".

So the PoS only directly validates the winner's public key.  The winner's signature validates the data block, and nobody else can steal the proof of work and claim it validates a different block because they will not be able to sign that block. Am I right?

What is to stop the block winner from signing two different data blocks?

[Matory]

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

[aleksand]

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

Lol, really. You can check at http://coinmarketcap.com/currencies/elacoin/
How soon ico will end? It will take really too long to wait untill all 100% of coins will be DISTRIBUTED.

[Dazza]

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.

[poornamelessme]

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.

If renaming, not so sure about that one. Coin of the Elastic Project doesn't exactly roll off one's tongue... and CEP doesn't automatically lead one to think of 'Elastic'.

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.

[scam confirmed]

ELA_hu akbar!

[xxxgoodgirls]

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.

If renaming, not so sure about that one. Coin of the Elastic Project doesn't exactly roll off one's tongue... and CEP doesn't automatically lead one to think of 'Elastic'.

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.

ELP is taken, I'd pick ELA.

[Dazza]

What is to stop the block winner from signing two different data blocks?

The problem here is that if any part of data block is fed into the PoS hash, then that part can be used as a nonce to turn your PoS into PoW.  If any part of the data block is not fed into the hash, then that part can be modified to create a competing data block, and the winning stakeholder could sign both.  To avoid both problems, you need simultaneously to feed in all of the data block, and none of it.

Under my scheme as outlined about, you feed in all of it.  Sure the stakeholder could manipulate the block to create a different hash value, but this makes no difference, because the hash value is not significant.  If he tried to distribute two (or more) different blocks both signed by the same key, then each would have the same stake value and he would just be competing against himself.  Eventually one (or none) of those blocks will become the main chain, while the others would die.

[Dazza]

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.

Not ELT.  This is a coin, not a token.  I would favour ELN.

[Evil-Knievel]

The problem here is that if any part of data block is fed into the PoS hash, then that part can be used as a nonce to turn your PoS into PoW.  If any part of the data block is not fed into the hash, then that part can be modified to create a competing data block, and the winning stakeholder could sign both.  To avoid both problems, you need simultaneously to feed in all of the data block, and none of it.

He could indeed sign two different blocks with the same PoS signature. These two different blocks would however be only linkable to one certain previous block (note, the previous block's hash indeed is fed into the PoS hash). This way you can create many many "sub-chains" of length 1 of which of course only one will eventually survive. I see only the danger of an easy 0-confirmation attack, but maybe I just miss something basic here.

Let me first read your suggestion from above, after I have gotten myself a hot cup of coffee.

[Dazza]

PEN - Project Elastic Network.

The demo could be TELA - Toy Elastic.

So we would have PEN and TELA.

[Dazza]

He could indeed sign two different blocks with the same PoS signature. These two different blocks would however be only linkable to one certain previous block (note, the previous block's hash indeed is fed into the PoS hash). This way you can create many many "sub-chains" of length 1 of which of course only one will eventually survive. I see only the danger of an easy 0-confirmation attack, but maybe I just miss something basic here.

He could use multiple versions of the previous block as a nonce to win the next one.

This is actually the nightmare scenario.  Using the current data block is at least a strategy that all the (purportedly) PoS miners could use.  But only a winner of the previous block could use the win as leverage to win the next, and the next, and the next...

[Evil-Knievel]

He could use multiple versions of the previous block as a nonce to win the next one.

Could we solve this issue by not feeding the previous block's hash into the current block's PoS hash
but the previous block's PoS hash (containing the last block's miner's signature as well as some other variable that varies deterministically from block to block such as the block height) itself? This should be invariant to any sort of changes to the previous block.


EDIT: So basically:

Current Block's PoS hash is the hash of the concatenation of
(Last Blocks Height, Last Blocks PoS Signature, Current Blocks Height, My PoS Signature)
and if this meets the target value we're done?

[Dazza]

Could we solve this issue by not feeding the previous block's hash into the current block's PoS hash
but the previous block's PoS hash itself? This should be invariant to any sort of changes to the previous block.

Then we're back to the problem we have before.  The chain of successive PoWs each validate the previous, but there is nothing uniquely tying them to the data blocks.

You could try to forbid an account from winning consecutive blocks, but then Sybil.

[Evil-Knievel]

The next 40 seconds I call the refectory period.  No blocks timestamped during this period will ever be accepted by any node.  (Also no node will judge any block the winner, if it receives that block before its timestamp, though it might accept if it is otherwise acceptable, just in case the rest of the network decides to choose it anyway, which they might, if they receive it later.  A node could accept multiple competing blocks)

The next 20 seconds is the bidding period.  During this period, any account holder may generate and sign a block, (or start distributing a block generated earlier, though there will be no advantage in doing this).  Other nodes will accept it if its stake value is greater than any other block already received.  They may also accept it if it is lower, but it is still high enough that the node believes that it might win the contest anyway.  Nodes may also choose to reject (i.e. delete from memory) previously accepted blocks which it judges to no longer have a chance to win the contest.  However, nodes will only ever attempt to distribute the highest scoring block they know about.

At the end of the bidding period, each node chooses the winner.  Most likely every node will have chosen the same block, the one which globally has the highest stake value, and the next refectory period can begin like the last, only this time, that account will have a stake value of zero.  Sometimes the highest value block may not have reached every node, and on rare occasions, for example if the highest stake-value block was released close to the end of bidding, another block might be judged the winner on the majority of nodes, Call this block the global winner.

After another refectory period, the next round of bidding begins.  Each node submitting a block will chain it from what it thinks the winner of the last round was, but each accepting node will accept high scoring blocks from the other last round contestants.  The next block winner (as judged by each node) will be the highest scoring block across all the competing chains.

I absolutely love your approach. There are however two problematic parts about it, that I see and that would have to be settled out.

a) The fact that every node is allowed to submit a block during the bidding periodcould cause immense congestion in terms of network traffic.
Most likely, the moment the bidding period begins, there is no "highest value block yet". This regularly would cause all nodes to simultaneously broadcast their block as they think it is the highest so far.

b) We do not have synchronized clocks. In fact, clocks may drift away in the magnitude of minutes and we cannot assume that every node uses the same NTP server to sync its time. I see hard to solve synchronization issues here.

[Dazza]

The next 20 seconds is the bidding period.  During this period, any account holder may generate and sign a block, (or start distributing a block generated earlier, though there will be no advantage in doing this).  Other nodes will accept it if its stake value is greater than any other block already received.  They may also accept it if it is lower, but it is still high enough that the node believes that it might win the global contest anyway. (It can never win the local contest because it doesn't have the greatest stake value known to the node.)  Nodes may also choose to reject (i.e. delete from memory) previously accepted blocks which it judges to no longer have a chance to win the contest.  However, nodes will only ever attempt to distribute the highest scoring block they know about.

Edited for clarity.

[worthyou]

Is there any advantage for early investors on ico? If not what is the point of buying now instead of buying last minute?

[schnötzel]

Is there any advantage for early investors on ico? If not what is the point of buying now instead of buying last minute?

All you need is here:

http://www.elastic.pro/crowdsale

[Dazza]

a) The fact that every node is allowed to submit a block during the bidding periodcould cause immense congestion in terms of network traffic.
Most likely, the moment the bidding period begins, there is no "highest value block yet". This regularly would cause all nodes to simultaneously broadcast their block as they think it is the highest so far.=

Perhaps we could program the following heuristic:

1.  If I have a stake value greater than or equal to the previous winner, broadcast as soon as the bidding period starts.

2.  Otherwise if my stake value is x% of the previous winner, wait until there is only x% of the bidding time left.  Broadcast only if I have not yet received a better block.  Edited to add: apply the same heuristic to any higher value blocks I receive, in other words, If I receive a block before I think it ought to have been sent, wait until then before passing it on.

b) We do not have synchronized clocks. In fact, clocks may drift away in the magnitude of minutes and we cannot assume that every node uses the same NTP server to sync its time. I see hard to solve synchronization issues here.

I'm not an expert on NTP, but aren't most servers within a few seconds of real time?  So most nodes should be OK.  Those nodes using the wildly out-of-synch time are screwed anyway and could perhaps notice that "everyone else is using the same time, but different from me, so I'll correct myself".

We could perhaps tolerate a timestamp which is a few seconds into the future.

[Evil-Knievel]

Sorry to switch between approaches,
but I still have a hard time to understand why this should be problematic.
Seems I am not seeing something that seems to be obvious.

Imagine we have Block x with:
a) H, the full hash which is the of the entire block's content
b) The signature of a miner, that signs the previous block's PoS hash S
b) S, the PoS hash which is unique for the particular block and the signer (not depending on data, but indeed on signature)

Now we mine a Block (x+1):
a) H, again the full hash
b) The signature signing the PoS hash the full hash (?) of Block x (note, last block, not the current one)
c) Again this block has an own PoS hash which is unique for block and signer (not depending on data, but indeed on signature)


I am yet to understand how exactly we could PoW the PoS block here, assuming that we force a deterministic signature scheme and disallow any signer-injected randomness in the signature.