Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 343. (Read 450549 times)

All you need is here:

http://www.elastic.pro/crowdsale

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

Edited for clarity.

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.

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.

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?

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...

PEN - Project Elastic Network.

The demo could be TELA - Toy Elastic.

So we would have PEN and TELA.

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.

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

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.

ELP is taken, I'd pick ELA.

ELA_hu akbar!

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.

CEP?  The Coin of the Elastic Project.

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.

ELC ticker was since at 2013 and live now — https://bitcointalksearch.org/topic/ann-elc-elacoinelastic-scrypt-n-miningtwo-exchangesnew-wallet-766417
Please change the coin name!

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?

I'm in the possibly advantageous position of knowing that PoS is a respectable way to secure a blockchain, but not actually knowing how anyone does it.  Therefore I'm starting with a blank mental slate, but approaching it from a mindset that says "how can I make this work?" rather than "can this be made to work?"

My idea is that, instead of having the PoS miners compete to find a hash that meets a particular target, said target being easier for large stakeholders than for smaller ones, why not just award the block to the PoS miner with the largest stake value?  Of course, the "stake value" cannot just be the account balance, otherwise the same account would win block after block after block, until spent or until another account achieved a higher value.  Moreover the winning miner could prevent that from happening simply by refusing to include in his blocks any transaction that would put a competing account over the value of his own.

I propose that "stake value" of an account be the time integral of the account balance since the last time that account won a PoS block, or the from the time of its creation, if it never has.  In addition to keeping track of an account's balance, therefore, we would also have to keep track of it's stake value.  We would not have to recalculate it every block, instead we could just record the block number when it was last recalculated, and recalculate every time the balance changes.

In order to generate one block per minute, quite regularly, I propose the following process.

At time x minutes and 00 seconds, each node will have (tentatively) chosen the previous block winner.  Let's assume for the sake of arguement that every node has chosen the same block.  This would be the situation after the first genesis block.

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 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.

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.

Because most submitted blocks will extend the chain of the previous global winner, it is likely that the next global winner will extend that chain.  Over time, the side chains will be extended by fewer and fewer blocks until no node considers them to be a winner, at which point they die.

Because this system doesn't care what the hash value is, there is no way to turn it into PoW.  It is pure PoS.  Thoughts?  Comments?  Criticisms?

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

it should be fine. I am sorry if I did not make it clear enough that we use both hashes signatures simultaneously.
I hope my feeling is not misleading me, but I am pretty sure that we can avoid any PoW on the PoS function this way and still having the maximum security and integrity of the blockchain.