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

Watching closely!

any bounty for translating? thanks

Why could not something like this be coded into a wallet.  The total number of ELC is fixed so someone submitting a vote through a wallet would automatically be sending his percentage vote via his publickey.  If he has multiple wallets they would be eligible as well.  I would disallow amounts held by exchanges, and other shady dealings.

I have some doubts here. I'm thinking if Elastic Project (Decentralized Supercomputer as you said) has some relation with Gridcoin, once Gridcoin Project directs the computational power to solve scientific problems, integrated with BOINC (Berkley Open Infrastructure for Network Computing).

What are the Elastic Project improvements, in that case?

ok. thx!

Then, the ELC giveaway stops immediately. All other donations that were received would be returned.

This is a very good idea! A few years ago, I heard some talk at a conference about "decentralized democracy"    Basically, a "proposal" is put online and the voters find a decision (not a full consensus though) by some fancy metric. I would highly appreciate something like that. The hard part will be, as I think, to also "spend" the money in a decentralized way.

The workflow would need to be something like this:
- Someone has a great idea, finds someone to do that idea for 5 BTC and creates a transaction paying those 5 BTC.
- Now people must decide whether they support that or deny that. Usually, we would require the users to sign the transaction if they support it. But of course we want to make it depending upon the amount of ELC they hold, so high rollers have more to say. This again is highly problematic and I would love to see someone solve it using pure bitcoin scripts. How can you make one signature weigh more than others).
- Anyway, at this step somehow the transaction is signed and pushed to the network.

If step 2 cannot be made automatic, then we again have some third party involved.    

I think, if someone was able to solve such issues with pure bitcoin, he would deserve one hell of a bounty.

i see a "percentage of coins distrubuted"  on the website. what happens if 100% is met before block 425920?

Giving the complete decentralized taste of the project, wouldn't be better if the funds will be spent following a sort of consensus through ELC holders (something like the decentralized budget system in dash - being the ELC stash the collateral)?
I have nothing against Lannister, he looked to me as a cool and honest guy, but I believe there is still some risks due a single entity.
I mean, as far as I understood how elastic is going to work, funds will be blocked forever if Lannister disappears.
It's a random thought, tho, not a criticism.

computrons, calculators? I don't really know.

I will rephrase your method quickly with my own words just to make sure I got everything right. Questions are inline.

First, we have:

- ASV = Account Stake Value: It is equal to the lowest balance that the account has had during the last N blocks.
An account that was recently created or which has won a block fewer than N blocks ago has an ASV of zero.

- BSV = Block Stake Value: The BSV of the block extending a chain equals to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain (in the future or in the past? Is it just the cumulative ASV up to "now"?). No account's ASV is counted more than once in the past N blocks.

- CSV = Chain Stake Value: The CSV is the sum of the last N blocks' BSVs. (did I get it correctly that we have sums of sums of ASV's? Counting older ASV's more often then newer?)

Then, we have two different "proof of stakes":

- PoS+B = PoS with associated block (i.e., including and confirming transactions)
- PoS-B = PoS without associated block

Now starts the so called so-called voting period:

- Nodes broadcast a PoS+B block for each of their accounts A where ASV(A)>x% * OLD_WINNER_ASV, that is, the ASV of account A is x% of the ASV of the winner of the last block or higher.
- Additionally, each Node broadcasts an PoS-B (here, without a block, i.e., without confirming any transactions) for each of their accounts A where ASV(A)>threshold. The threshold is fixed and no hash target has to be met.

Then this happens



So essentially, at least from what I understand, we no longer rely on any hash. As the hash was the only random factor in the scheme we now have a deterministic order who from a subset of N "online" users will win which block.

Also, I an not yet fully sure how the ASV will be "reaccumulated" after it was dropped to 0 upon creation of a new block. Will the ASV recover fully after N blocks have passed?
If so, this could leave an attacker the possibility to create N high-stake account and winning blocks with them "round robin".

Edit ... just saw, you already thought of that


Sorry if I get that wrong, bit don't we have the same problem here? Its just not that you need N accounts, but M accounts (which is less actually, as M<=N?)



Apart from that: my respect, this is a very nice and well thought approach. I think I will have to reread it like 3 or 4 more times to fully understand it    I will try to wrap it up in pseudo code once I have understood everything so we get a basic idea how we could code that.


EDIT: Just saw that you have found even more attacks with those N accounts and that you are already addressing them  


Maybe its just because its sunday midnight, but I don't see the point why increasing his amounts would break his monopole. Could you please explain that in 2 lines?
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block a new account (belonging to the attacker) with a sufficiently high ACV wins.

I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins of which N*C cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), and 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.

I think we can avoid this problem by defining the "longest chain" as the chain with the greatest cumulative difficulty and not by its height. It is highly unlikely (like 1 in 2^64 with our uint64_t difficulty) that two chains evolve from one block which have the same cumulative difficulty. This results from the fact that we submit blocks only at a point in time when the target is equal to the hash which has a collosion probability of 1/2^64.

If such forks occur (and yes, i think they will occur frequently), it is therefore quite easy to let the chain with the higher cumulative difficulty survive and let the other one die.




I will comment on your method soon. I am rereading it once more.

Wouldn't voting for your favoured block mean that the system would be in a continous state of soft forking, a kind of *khm* elastic system?

Oh, ok. So it is just a matter of when all the funding has been donated?

I think the deadline is bitcoin block 425920 which we all try to meet

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Is there a timeframe as to when the project will go live?

Not sure I understand the question.  If you are asking what people think of the project, read the threads.  If you are asking what the word "consensus" means in a technical sense, it would be, very roughly "the data distributed throughout the network which is known to and agreed by every or almost every node".

Not sure if that helps.

What is the consensus of the elastic network?

Some further thoughts.


Nodes could use this normalised value to decide the timing of their block launches.  A node will not launch its block(s) if it sees a block which (a) extends the main chain (as viewed by that node) and would beat that node's own block(s), or (b) extends a side-chain and would cause the node to switch to that side-chain even if (one of) its own block(s) were to win the (current) main chain.

In fact I'm now thinking that there could be two refectory periods.  The sequence of events might be, for example:

00-30 seconds:  launch blocks
30-40 seconds:  refectory
40-50 seconds:  launch collateral PoS
50-60 seconds:  refectory

You need less time to launch the collateral PoS (is "collateral" the best word for this?  How about "subsidiary", "auxilliary", or "secondary"?), because there is no need to delay them, you are voting for your favoured chain, not your favoured block.  (But why not favoured block?  Favoured chain was just my original idea), and you don't need to see the other votes before deciding.  You do need to see the other blocks because if you see a side-chain get a strong block, you may want to switch to it, even if that means voting collaterally against your own block.

The refectory periods are there to allow the data to percolate through the network and for nodes to make their decisions.


There is still a strange, though not necessarily undesirable property about this system.  Sometimes more stake can hurt an attacker.  For example, suppose the same honest accounts are staking throughout.  An attacker with N accounts each with equal balances greater than the highest-value honest stake would win every block forever (or until a non-staking account with a higher balance decided to start staking)  If these N accounts were the N highest, the attacker could permanently shut out transactions of his choice, including any transaction that might enable another account to compete.

But it would be really obvious that he was doing this.  So let's suppose that the attacker had some more funds, and randomly increased the balances of some of his accounts, then he would no longer prevent accounts he doesn't control from winning the occasional block.

I have a way to mitigate the "N equal accounts" attack, but I want to go to bed now, so I'll post it when I next have time.

Amen! you can not underestimate the power of hard work.
My own projects would never have succeeded unless I put in the work up front.