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

[Evil-Knievel]

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.

This is a very sophisticated approach, and I would love to see something entirely new in a coin.

If 1+2 are just heuristics and not enforced by the protocol, this could be problematic when people are allowed to deviate from that. We would have to make sure to close all possible DoS vectors, like submitting many many blocks with an incrementing stake number (you could prepare a million sybils all having a different but incrementing number of dust in their balance) and replay them in the correct order over and over again. When transaction costs are negligible, this attack could be pulled of quite easily.

The time issues are tough i think, specially if we go fully decentralized, without the need of a centralized synchronization server.
EDIT: Also the definition of a deviating clock is hard to formalize, as a base line for comparison is missing here. That is, who has the correct clock which we measure the others against?

I will have to reread everything carefully, I don't want to say anything wrong. All I can say now is that I find your approach very interesting. I'll get a cup of tea and go through it one more time.

[1714198724]

1714198724

[1714198724]

1714198724

[1714198724]

1714198724

[1714198724]

1714198724

[1714198724]

1714198724

[Dazza]

Regarding point 1: We would have to make sure to close all possible DoS vectors, like submitting many many blocks with an incrementing stake number (you could prepare a million sybils all having a different but incrementing number of dust in their balance) and replay them in the correct order over and over again. When transaction costs are negligible, this attack could be pulled of quite easily.

According to the the Cryptonite Wiki the mini-blockchain is tolerant of large numbers of transactions, but suffers in the face of a large number of accounts, so we should charge a higher transaction fee if a new account is being created.  This would financially penalise your million sybils, while still allowing micropayments into and out of existing accounts.  This is consistent with my "make it as good a coin for general trading as possible" philosophy, because micropayments can be generally useful, while tiny-balance accounts aren't much use at all.

How are these million sybils going to distribute their shitty PoS bids?  Are they going to connect to ten million peers?  If so, are they going to distibute their bids late, when the other higher bids are already in, or early, when their peers won't promulgate them further.  Or is the intent just to DoS the peers, without penetrating further into the network.  If that's a concern then isn't PoW similarly vulnerable?  What's to stop a million sybils submitting a million blocks supported by bogus PoW?  The PoW's won't verify, but they'll still have to be checked.

If the PoW coins can survive, I think we'll be OK.

[Dazza]

This is a very sophisticated approach, and I would love to see something entirely new in a coin.

Here's how you break it:

An honest PoS miner will never try to extend a chain he doesn't think is the winner, but a dishonest one will always be able to.  As long as there is at least one account submitting a PoS for the sidechain, it will survive.  So the attacker continues to build his sidechain using fairly large stakes, large enough to keep the other nodes interested, so they keep monitoring, but not large enough to take over as the main chain, until he's ready.  Then he deploys the high stake value account he's been keeping up his sleeve all this time, and takes over the chain.

I think I am a living counterexample to Schneier's Law.  I have failed to design a security system I cannot break.

Any thoughts on how we can fix this?

Edited to add:  I will continue my assault on your scheme shortly.  I'm going to bed just now.

[Evil-Knievel]

Dazza, just fixed this

 

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.

I will think a minute about your last comment and be back to you in a few minutes.

[Dazza]

I will think a minute about your last comment and be back to you in a few minutes.

OK, I'll stay up for a few more minutes, but I am near mental exhaustion and will need to sleep soon.

[Evil-Knievel]

This is a very sophisticated approach, and I would love to see something entirely new in a coin.

Here's how you break it:

An honest PoS miner will never try to extend a chain he doesn't think is the winner, but a dishonest one will always be able to.  As long as there is at least one account submitting a PoS for the sidechain, it will survive.  So the attacker continues to build his sidechain using fairly large stakes, large enough to keep the other nodes interested, so they keep monitoring, but not large enough to take over as the main chain, until he's ready.  Then he deploys the high stake value account he's been keeping up his sleeve all this time, and takes over the chain.

I think I am a living counterexample to Schneier's Law.  I have failed to design a security system I cannot break.

Any thoughts on how we can fix this?

Maybe we have to think about

a) our definition of "longest chain"? This does not have to be necessarily defined by its height/index
b) using not the balance itself, but sort of a "weighted balance". We could give more weight to coins which haven't been spent in a while. Submitting a block "spends" those coins to oneself reducing the weight significantly. Weight could be also influenced by what happens in other sub-chains.

Just as a first shot.

[Evil-Knievel]

I will think a minute about your last comment and be back to you in a few minutes.

OK, I'll stay up for a few more minutes, but I am near mental exhaustion and will need to sleep soon.

Same for me  I wish you a very good night. Sometimes, you get the best ideas under the shower. Maybe we see the obvious by tomorrow morning.

[Dazza]

EUREKA!

The stake value of a block is not the same as the stake value of the winning account.  It is the sum of the stake value of the account and the stake value of the previous block.  This doesn't alter the task the honest PoS miners are doing.  Out of all those extending the primary chain, the one with the largest stake value will (probably) win.  But anyone building a side chain will have to add more stake value to it than the winner of the main chain, in order to overtake.

Back to bed now.

[Matory]

Hey, oodles of holders, what coin are you provided?
ELC which has approved three years ago or Novacoin - how I see in source https://github.com/elastic-project/elasticd ? 

[Evil-Knievel]

Hey, oodles of holders, what coin are you provided?
ELC which has approved three years ago or Novacoin - how I see in source https://github.com/elastic-project/elasticd ? 

None of both.

[Matory]

Hey, oodles of holders, what coin are you provided?
ELC which has approved three years ago or Novacoin - how I see in source https://github.com/elastic-project/elasticd ? 

None of both.

Then what are you doing here 

[Evil-Knievel]

Then what are you doing here  

We didn't know that there already is an ELC (Elacoin) so we will have to rethink the name acronym, but this has been discussed in this thread already.
This is "Elastic Project".
What we are doing right now, just to quickly summarize, is to build a revolutionary new coin. The idea is based on a proof of stake mini-blockchain which has not been created before. But the project will be a lot more than that, you can read a bit through the threads or through the whitepaper (even if parts of it still must be fixed) to learn more about it.

[Dazza]

Re clock skew and timing attacks: this pertains to BitCoin, but may also be relevant to us.

[Mrboot]

Whats proof of stake mini blocks ? like a fast chain or am i thinking wrong?

[Dexter12]

Interesting project - watching!

[Dazza]

Whats proof of stake mini blocks ? like a fast chain or am i thinking wrong?

Proof of Stake (PoS) is an alternative to Proof of Work (PoW) as a means to achieve network consensus and blockchain security.  Here are two links which will tell you probably more than you ever want to know about it.

https://en.bitcoin.it/wiki/Proof_of_Stake
https://en.wikipedia.org/wiki/Proof-of-stake

The mini-blockchain is a different kind of blockchain from the one used by Bitcoin, which requires less storage.

http://cryptonite.info/wiki/index.php?title=Mini-blockchain

If all this is just a load of technobabble to you, then don't worry.  All you need to know is that once you download a wallet and get some Elastic Coin, your wallet will automatically participate in PoS when appropriate, and so help with network security, as long as you keep your wallet running on your computer.

Please also be aware that the discussions here between Evil-Knieval and myself are highly technical.  Nobody else is expected to understand them fully, and nobody or almost nobody else does.  They are public, so that those people who can understand some of it have the opportunity to do so, even if they don't understand fully.

Even if you understand nothing at all you can still help with the development.  Soon we will release a test wallet which uses fake coins. We'll give some of those to anyone who asks. Simply by downloading and running this wallet on your computer, and receiving some fake coin into it, you will be helping us test the PoS system.

[Dazza]

EUREKA!

The stake value of a block is not the same as the stake value of the winning account.  It is the sum of the stake value of the account and the stake value of the previous block.  This doesn't alter the task the honest PoS miners are doing.  Out of all those extending the primary chain, the one with the largest stake value will (probably) win.  But anyone building a side chain will have to add more stake value to it than the winner of the main chain, in order to overtake.

Back to bed now.

I've just discovered that this is, in fact, just the PoS version of what BitCoin already does with PoW

[Evil-Knievel]

I've just discovered that this is, in fact, just the PoS version of what BitCoin already does with PoW

And I am working day and night to keep my promise to give the community a mini-blockchain with a basic PoS scheme (as for example used in NXT) to play with by tomorrow today (GMT). It is not that easy, but I think I can meet my deadline.

And yes, Bitcoin does not measure its "longest chain" by the length, but by the work that has been cumulatively contributed (not sure if its the cumulative difficulty of all blocks in the chain?). I am, for now, going with the PoS scheme as described a few posts before just to have something the community, or we, can play with. Changing the PoS scheme is of course open for discussion   Getting back to work, even though i am already working 14 hours today. I hope I will have more time tomorrow to think and brainstorm about your PoS scheme. I like the idea, but I think we would have to think about skewed clocks a bit more ... we cannot assume clocks to be off only by a few seconds.

[Dazza]

a) our definition of "longest chain"? This does not have to be necessarily defined by its height/index

See my "Eureka" post.  In fact "longest chain" was never the criterion since all live chains will be the same length/height.  It was the highest SV of the last block that I was counting.

b) using not the balance itself, but sort of a "weighted balance". We could give more weight to coins which haven't been spent in a while.

Already in my plan via the "time integral".

In fact, this is a weakness, as it allows an attacker with a modest amount of coin to leave them unspent for a long time, allowing them to accumulate stake-value (SV) until he judges that he has enough to mount an attack.  The problem for us is, even if he fails, the SV he "spends" isn't really spent, because it was "spent" on a side chain that is ultimately discarded.  So he can have another go, and another, and another, until he succeeds.  

Submitting a block "spends" those coins to oneself reducing the weight significantly.

Merely submitting a block doesn't spend the SV.  You actually have to win the block.  Otherwise an attacker building a side-chain would have less opposition, since both losing and winning honest blocks will spend their SV.  Edited to add: A further downside would be that this would actively discourage honest accounts from submitting bids unless they were sure they had a good chance of winning, again reducing the opposition.

Weight could be also influenced by what happens in other sub-chains.

That is also a possibility.  Another idea I had was to divide the time since the account creation or last block win into three equal-length epochs.  The SV would be the lesser of the time integral of the coin balance in each of the epochs.  This would make it harder for an attacker to fine-tune the SVs of his various accounts as he approaches the time to launch his attack, and has a better idea of what the opposition is likely to be, because while he might be able to reduce an account's SV by moving coin out, he would not be able to increase another account's SV by moving coin in, because the balance will have been lower during the earlier epochs.  The downside of this plan is that it discriminates against accounts whose balances vary a lot, while we can be sure that an attacker will keep his account balances static.

In the end, my feeling is that the attack I have described can be at best mitigated by these stratagems, and that this scheme is still to vulnerable.  Fortunately I have another idea.  See next post.

[Dazza]

And I am working day and night to keep my promise to give the community a mini-blockchain with a basic PoS scheme (as for example used in NXT) to play with by tomorrow today (GMT). It is not that easy, but I think I can meet my deadline.

I'm certainly not working night and day.   

I'm conscious of the fact that I also have an outstanding promise, namely to detail the attack on the section 2.4 PoW system, and suggest other ways to assure both buyers and miners that they will get their rewards.  However, I think at the moment, my time is better spend brainstorming what you're working on now, than thinking about what you won't be working on for a while.

Getting a coin up-and-running is the easy bit.  It's the right decision to do it first.