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

[cryptoheadd]

I have been working hard in the last days.

Goal:

The goal was to create the world's first mini-blockchain proof-of-stake coin so we can use this as a basis for future development.
As no such thing has been done before, it was required to actually build it.

Note: This does not include any of the computational resources market engine yet: right now (in this early stage) it is just a mini-blockchain based proof-of-stake coin.



Implementation:

I have used Cryptonite's mini-blockchain implementation as the basis.
I have removed the "nonce" from the block header and instead added a "PoS generation signature" which works according to the basic scheme that we have discussed here earlier. Note, this scheme is still open for discussion and may change anytime.
The PoS verification scheme itself has been created from scratch and basically adjusts the "difficulty" after every block based upon the moving average (last 3 block generation times). I have furthermore created one genesis-block that distributes all coins in circulation (in my current demonstrator, it just distributes 2000 ELC to a single address of which the private key can be found in chainparams.cpp/.h. That is enough to play around with so far. All network communication routines have been altered to work with the new, changed block headers.
A dozen minor and major fixes and tweaks to Cryptonite's implementation has been applied as well.

GUI:

Standard Bitcoin GUI is used now, but this will change quickly. I just do not want to spend too much time on the cosmetics right now and do the really interesting stuff first. Of course, at some point we will have a nice GUI that will help to manage the entire computational resource market in a nice and understandable way. One that looks entirely different and novel compared to what we have now.

Missing Parts:

Before I can officially announce a test version there are still a few very important things that I have to do.
- The PoS hash right now it a int64_t value. Currently its just a fixed low value, so that PoS blocks can be generated ALWAYS. This is required because if just two test clients are online, it might happen that both are unlucky (their PoS hash is so high) so that they both cannot "mine the PoS block" for the next hours/weeks/months. (see point below).
- The "miner" (which you activate by setgenerate=true) is not finished. It just wins the block (see fixed PoS hash) trivially and nothing more. Here we will have to monitor all addresses in the wallet, and check for all of them when each of them will be possible to generate a block. Maybe we can display the information somewhere in the client, like "If nobody else finds a block by 11:53:33 GMT, you will find it". Due to the PoS scheme that I have used, everyone can predict the exact point of time that he will be able to mine the current block.

Question, enforce easy mining?:

Question to the community:
When we have only a few people in the network, it may accidently happen that the PoS hashes, which are pseudo-random but constant for each block and account, are so bad that it would take months for anyone to solve a PoS block. (This is a reason why for now I sticked to a low fixed PoS hash for testing only).
How should be solve this problem? Should we allow that anyone can solve a block after some grace period has passed and noone else has mined that block (maybe 5 minutes)? Or should we rather switch from the linear target value increase per time unit (Personal Target = Basetarget * Balance * Time since last block) to something exponential? I would need some input on that.

When can we test:

Once I am finished with the missing parts. I will write a detailed developers guide and instructions how to test the software.
You can check the status at https://github.com/OrdinaryDude/elastic-mini-blockchain and of course test yourself, but please understand that things change there fast and I cannot give any support for the unfinished version.
Please wait a few days for the entirely working test setup. i will try to finish it as soon as possible.

Can I see something?

Please do not get fooled by the visual proximity to other alt coins. This look and feel is just temporary.
The real magic happens under the hood and indeed is a lot of work.

Awesome!

Looking forward to the test version.

[1713869437]

1713869437

[1713869437]

1713869437

[xxxgoodgirls]

Awesome job EK.
Will the mini-blockchain mitigate possible attack vectors that affect the classic pow-pos schemes?

[Evil-Knievel]

Awesome job EK.
Will the mini-blockchain mitigate possible attack vectors that affect the classic pow-pos schemes?

Actually, it comes with even more attack vectors like for example the "secret chain" attack.
Cryptonite has a good summary of this attack in his white paper here, but he has already suggested solutions to that problem and I am very confident that we can easily adopt them.

I personally think that the community needs some kind of bug bounty program,
In the form of "5 BTC for everyone who manages to steal coins in the Elastic test net and provides us with a reproducible step by step instruction", or something like that, once the software is finished.
I think this could uncover attack vectors that we did not even see yet, and is surely more effective than paying someone for a code review.

[xxxgoodgirls]

Awesome job EK.
Will the mini-blockchain mitigate possible attack vectors that affect the classic pow-pos schemes?

Actually, it comes with even more attack vectors like for example the "secret chain" attack.
Cryptonite has a good summary of this attack in his white paper here, but he has already suggested solutions to that problem and I am very confident that we can easily adopt them.

I personally think that the community needs some kind of bug bounty program,
In the form of "5 BTC for everyone who manages to steal coins in the Elastic test net and provides us with a reproducible step by step instruction", or something like that, once the software is finished.
I think this could uncover attack vectors that we did not even see yet, and is surely more effective than paying someone for a code review.

I completely support the bounty, I'm not sure about the amount of BTC offered being a bit too much maybe?
However I would  institute both the bug bounty and an audit review (if it will require few BTCs to be spared).

[Evil-Knievel]

Krajan, maybe I can help quicker. This should be no problem at all as long as you keep your MultiBit backup or recovery phrase  
I am sure the community will make sure to create redeem-tools for the most major wallets including Electrum, Multibit HD, blockchain.info HD, etc.
As all these wallets are open source, it is no problem to come up with a quick tool that will take your "recovery seed" or "mnemonic" and scan which public key of all the possibly derived keys has some ELC in it.

It's more problematic with closed source solutions, which Multibit HD clearly isn't.

[nihilnegativum]

Question, enforce easy mining?:

Question to the community:
When we have only a few people in the network, it may accidently happen that the PoS hashes, which are pseudo-random but constant for each block and account, are so bad that it would take months for anyone to solve a PoS block. (This is a reason why for now I sticked to a low fixed PoS hash for testing only).
How should be solve this problem? Should we allow that anyone can solve a block after some grace period has passed and noone else has mined that block (maybe 5 minutes)? Or should we rather switch from the linear target value increase per time unit (Personal Target = Basetarget * Balance * Time since last block) to something exponential? I would need some input on that.

Could block retargeting facilitate any attacks, or is it just an distributive issue? I like randomness, provided there are no security issues. If anyone can get a stake it makes the network more robust and it lowers the capital required to stake.

[Dink]

The ability for anyone to stake would seem to keep with the idea of being decentralized.

[cryptoheadd]

Just invested 0.3 BTC more.

Hope you guys are legit. 

[Dazza]

Hope you guys are legit.  

If we're not, then we're working bloody hard for our money.

[Dazza]

The ability for anyone to stake would seem to keep with the idea of being decentralized.

There ought to be a network-wide minimum balance in order to stake fully, otherwise we could suffer from network congestion (and could be DoSable) if there are large numbers of tiny balances trying to stake.

My idea of collateral support would enable accounts to offer smaller proofs, because they would be voting for which chain to extend, without offering a block to extend it.  (Obviously somebody will have to produce a block to extend it.)  Smaller proofs means less network congestion, which ultimately could permit smaller accounts to stake.  However accounts offering collateral support only, could not earn transaction fees.

Here's an analogy that might help people understand my idea.  Imagine an electoral system in which ordinary voters were only allowed to vote for a party, rather than a specific candidate, based upon a small "show of wealth".  Candidates would need a larger show of wealth to even stand/run.  The winning candidate would be the one with the largest show of wealth, but each losing candidates might form a new party of his own, which could fight the next election.

In this analogy:

show of wealth = PoS
voting = staking (collateral only)
candidate = (proposed) new block.
standing/running = staking (full)
party = chain

It's by no means a perfect analogy

[Dazza]

7y6
Could block retargeting facilitate any attacks, or is it just an distributive issue? I like randomness, provided there are no security issues. If anyone can get a stake it makes the network more robust and it lowers the capital required to stake.

The PoS scheme I outlined above has a little randomness, but I'm going to revise it to eliminate that outright.  In general, randomness tends to result in hard-to-trigger and hard-to-replicate bugs which are not good things, especially in security systems, as they tend to persist undiscovered for a long time, and can be hard to debug.  Of course, some security systems depend upon the judicious use of randomness, for example, choosing random keys.

In the NXT PoS scheme, as with BitCoin's PoW, the randomness we're talking about is not just something that happens "under the hood".  It negatively affects user experience.  Blocks are generated at random intervals which can only be tuned to a desired average.  This means that the time to transaction confirmation will be random too.

I do not see how in a PoS scheme, retargeting would facilitate any attacks, except in the trivial sense that, by reducing the averagemaximum typical wall-clock time for a transaction to be regarded as confirmed, double-spend attacks against them could be similarly speeded up.  But "under the hood" the attack would be no faster relative to the "engine speed".  I'm not sure whether retargeting in a PoW scheme would facilitate attacks.

One other possible consequence of retargeting might be an increased likelihood of a blockchain fork, if the delay in block generation triggering the retargeting was just bad luck, and not due to insufficient staking.  But (shallow) forks are tolerable, and we actually want to generate them during testing, because we want to be sure they're handled correctly.  Generating forks is trivial for an attacker anyway.

[Dazza]

I completely support the bounty, I'm not sure about the amount of BTC offered being a bit too much maybe?
However I would  institute both the bug bounty and an audit review (if it will require few BTCs to be spared).

Might be better to say that the BB will be shared if multiple critical bugs are found.

[Dazza]

Actually, it comes with even more attack vectors like for example the "secret chain" attack.
Cryptonite has a good summary of this attack in his white paper here, but he has already suggested solutions to that problem and I am very confident that we can easily adopt them.

In fact it was the defenses described in that summary which convinced me that side-chain attacks generally, including the 51% attack, don't really amount to much more than a DoS if appropriate precautions are taken.

I think this could uncover attack vectors that we did not even see yet, and is surely more effective than paying someone for a code review.

I'm not so sure  There have been critical security bugs that have lain undiscovered for years in dusty, rarely-used-or-legacy corners of an application.  The ShellShock attack against BASH was an example.  Few people used the functionality that was targeted, so few people were looking for vulnerabilities.

I think a code review (undertaken by someone competent, of course) would be a good idea, combined with a bug bounty.

[Dazza]

I have been working hard in the last days.

Thank's for your hard work.

Question to the community:
When we have only a few people in the network, it may accidently happen that the PoS hashes, which are pseudo-random but constant for each block and account, are so bad that it would take months for anyone to solve a PoS block. (This is a reason why for now I sticked to a low fixed PoS hash for testing only).
How should be solve this problem? Should we allow that anyone can solve a block after some grace period has passed and noone else has mined that block (maybe 5 minutes)? Or should we rather switch from the linear target value increase per time unit (Personal Target = Basetarget * Balance * Time since last block) to something exponential? I would need some input on that.

If you eventually go with my scheme or something like it, then blocks should be generated regularly every minute (or other period we decide), provided that at least one full PoS is submitted.  That would make the time-to-confirm a transaction predictable, once a transaction has been included in a block.  This would be yet another feature which would make our coin attractive for general trading, relative other other coins with random block-generation timing.

[tan625747]

how  get

how start

[Dink]

The ability for anyone to stake would seem to keep with the idea of being decentralized.

There ought to be a network-wide minimum balance in order to stake fully, otherwise we could suffer from network congestion (and could be DoSable) if there are large numbers of tiny balances trying to stake.

I disagree, the idea of Elastic is to provide supercomputing power... all these tiny balances are the computers that make up this
 decentralized supercomputer.  You lessen there ability to stake just like everyone else, they fall to the way side and stop contributing, soon your decentralized supercomputer is a centralized sytem controled by a few large holding stakers.

network congetion? makes no sense. Any of these POS coins say keep your wallet open to stake.  If that is the case elastice system needs to be thought out a little more.   If some one wants to Dos the system they will...it wont  be because there are a bunch of tiny balances that leave it exposed.    If dosing was that big of a problem all POS coins would suffer.

[Evil-Knievel]

Thank's for your hard work.

If you eventually go with my scheme or something like it, then blocks should be generated regularly every minute (or other period we decide), provided that at least one full PoS is submitted.  That would make the time-to-confirm a transaction predictable, once a transaction has been included in a block.  This would be yet another feature which would make our coin attractive for general trading, relative other other coins with random block-generation timing.

Well I have to thank YOU for your hard work as well.

I will most likely finish the basic NXT scheme today, and I will then immediately start implementing your approach in a new branch.
I think I can make it work pretty quickly in a test setup when I can assume more or less synchronized clocks, but this will be a big issue I think. I know I keep talking about these clocks, but I see many scenarios where the network can split and create to parallelly existing side chains when clusters of nodes form, that do have similar clocks. So over time those which have a clock that is off +10 seconds will end up in a filter bubble, just as those with a clock -10 seconds will, none of the groups accepting blocks from the other groups and working on two entirely different sub-chains.

We need a sophisticated methodology to mitigate such timing issues, that, in the worst case, can be in the order of minutes.

[Matory]

Just invested 0.3 BTC more.

Hope you guys are legit. 

ELC ticker is used in another crypto project. Where your btc is invested?

[cryptoheadd]

Just invested 0.3 BTC more.

Hope you guys are legit. 

ELC ticker is used in another crypto project. Where your btc is invested?

In Elastic Project's Crowdsale.
I heard that EK will be changing the name soon.

[Dazza]

Well I have to thank YOU for your hard work as well.

Yeah, but I can do my hard work while out walking dogs.

I will most likely finish the basic NXT scheme today, and I will then immediately start implementing your approach in a new branch.

Which means we're now In a race.  I have to articulate my latest thinking before you write the code it's relevant to.

Re that DoS attack on the NxT scheme we were talking about.  I suggested that, once two or more blocks using the same PoS were detected, all such blocks should be regarded as invalid.  This is a minor DoS in so far as if any of these blocks have been built on, that work will have to be discarded.

A better approach might be to regard the competing blocks as valid, but to treat the stake value as zero.  Nobody honest would build on them knowingly, but it is still possible that one might be built on, if the competitor blocks are injected later.  In that case, treat it as a valid chain, albeit with a lower value that the honest builders thought at the time.  So yeah, still kind of a DoS against those honest builders, but the attacker will be DoSsing himself just as much.  The impact upon the network would be between negligible and nil.

I think I can make it work pretty quickly in a test setup when I can assume more or less synchronized clocks, but this will be a big issue I think. I know I keep talking about these clocks, but I see many scenarios where the network can split and create to parallelly existing side chains when clusters of nodes form, that do have similar clocks. So over time those which have a clock that is off +10 seconds will end up in a filter bubble, just as those with a clock -10 seconds will, none of the groups accepting blocks from the other groups and working on two entirely different sub-chains.

Did you read that link I posted earlier in the thread about timing attacks?

We need a sophisticated methodology to mitigate such timing issues, that, in the worst case, can be in the order of minutes.

My gut feeling is that this won't be too much of a problem in the end.