I know something great will come from the efforts towards projects like this.
I don't know that anything great will come of this. I hope it will. Nobody should invest in this thinking it is a sure winner. There is no such thing.
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 337. (Read 450549 times)
I don't know that anything great will come of this. I hope it will. Nobody should invest in this thinking it is a sure winner. There is no such thing.
I do that sometimes I know something great will come from the efforts towards projects like this. Carry On and dont panic
Both I was speaking about elastic price if bitcoin was $600 and elastic commanded a bit cent. but not too long from now speaking in terms of dollars will be irrelevant for anyone into computational currency and bitcoin. Just imagine this and other projects unlocking the resources to produce Actual Intelligence to contribute to further development of itself and every other thing. Even though we are not using memristors yet and quantum computing is not household yet. There is tons of this current architecture computing laying around now enough to produce interesting abilities.
This is all rather vague and technobabblish to me. I prefer to stick to what I understand and can see how to make work.
Both I was speaking about elastic price if bitcoin was $600 and elastic commanded a bit cent. but not too long from now speaking in terms of dollars will be irrelevant for anyone into computational currency and bitcoin. Just imagine this and other projects unlocking the resources to produce Actual Intelligence to contribute to further development of itself and every other thing. Even though we are not using memristors yet and quantum computing is not household yet. There is tons of this current architecture computing laying around now enough to produce interesting abilities.
Well with the halving of bitcoin probably $6+ and sometime in 2017 meteoric rise of btc from there followed by some setback is likely. I honestly wouldn't even blink at $10000 btc price being topped by 2018 and a pullback to half that. But you never can tell...
Your talking about bitcoin price now ?
I assume he is.
I don't know what will happen to BitCoin next year or the year after. I think it is foolish to try to predict. I do know that the only thing that can really support a coin in the long run is a trade economy. Everything else is hot air and tulip mania.
And that is why I've been consistent about wanting our coin to be the best, most useful coin it can possibly be for general trade. Because my dream with this coin, is to knock BitCoin off its perch first, with Visa to follow. The distributed computing market is a way cool idea, and I really believe in it. But if my dream is to come true it will be only the kickstarter for something much, much bigger.
The chances of this are slim in the extreme. I will be happy with 4$/ELC.
Hi Guys, I know you are busy with coding, however I woud really like to know if it is save for me to donate to the crowdfunding using my MultiBit wallet.
Many thanks
Many thanks
Hey Dazza you look well known with cryptocurrency, do you have any other projects and made this account specialy for this project ?
I'm not sure if you're saying you think I'm well-known in the field of cryptocurrency, or you think I know a lot about the subject.
I'm not well-known. I have never been involved with any other open-source project of any kind. My only other online-identities pertain to social commentary and a social group activity. I've never commented on crypto matters here or anywhere else under a different name.
Almost everything I know about cryptography has come from Wikipedia, and Bruce Schneier's blog. Other than that, I've read a few whitepapers, a few academic papers, and some of the online-documentation of BitCoin, and some AltCoins.
I've consistently said from the start that I'm just a guy on the internet. That's me being honest, not modest. That really is all I am.
Well with the halving of bitcoin probably $6+ and sometime in 2017 meteoric rise of btc from there followed by some setback is likely. I honestly wouldn't even blink at $10000 btc price being topped by 2018 and a pullback to half that. But you never can tell...
Your talking about bitcoin price now ?
Well with the halving of bitcoin probably $6+ and sometime in 2017 meteoric rise of btc from there followed by some setback is likely. I honestly wouldn't even blink at $10000 btc price being topped by 2018 and a pullback to half that. But you never can tell...
I am back excited that maybe by my birthday on july 26 my share of elastic will be available to market though I will wait until they are a bit cent each to really sell much 
That's about $4/ELC (or whatever we call it). I would be satisfied with that. I hope it will go higher.
Hey Dazza you look well known with cryptocurrency, do you have any other projects and made this account specialy for this project ?
I am back excited that maybe by my birthday on july 26 my share of elastic will be available to market though I will wait until they are a bit cent each to really sell much
That's about $4/ELC (or whatever we call it). I would be satisfied with that. I hope it will go higher.
I have a different way to prevent the same N accounts winning over and over again. For any given chain, order the PoS+B trying to extend it by ASV. Then the one with the Highest ASV wins straight away so long as it hasn't already won in the last M blocks. Else if it won n blocks ago with n<=M, multiply its ASV by n/N, and move on to the next. If the PoS+B with the next highest ASV hasn't won in the last M or 2N blocks (whichever is greater), then it wins straight away. Else if it won n
If no block wins straight away choose a block which has won the least number of times during the last M blocks. Usually this number will be zero. If there are several blocks tying on this metric, use the modified ASV as the tie-breaker.
With this scheme, larger stakes will win the block more often, but, so long as there is an alternative, never more than once since transaction confirmation or the oldest live fork point. Smaller stakes get to win occasionally.
If no block wins straight away choose a block which has won the least number of times during the last M blocks. Usually this number will be zero. If there are several blocks tying on this metric, use the modified ASV as the tie-breaker.
With this scheme, larger stakes will win the block more often, but, so long as there is an alternative, never more than once since transaction confirmation or the oldest live fork point. Smaller stakes get to win occasionally.
I see a problem, or at least an undesirable characteristic of the above.
For simplicity's sake, assume that M=N. Suppose the three accounts with the largest ASV are A, B, and C, with ASV(A) > ASV(B) > ASV(C). suppose further that A won a block less than N blocks ago, B won a block between N and 2N blocks ago, and C has not won a block, or did so more than 3N blocks ago. If B and C both launch, but A does not, then B will have the highest ASV of any launched block, and because it last won more than N blocks ago, it will win this time. If all three launch, then neither A nor B will win straight away, but then C will.
It's a bit strange that A could stop B from winning without winning itself.
Here's a modification of the above scheme which does not as far as I can tell, have this property. Let M and N be defined as in the previous post, with M not necessarily equal to N.
Step 1. Normalise each candidate's ASV by dividing by the largest ASV of any of the last N block winners. This will not affect their rankings in any way. From now on, when I refer to a candidate's ASV, it is the normalised value I'm talking about.
Step 2. Iterate through the candidates in decreasing order of ASV. For each candidate, if the account last won more than max(M,N/ASV), or if it has never won, it wins; exit. Otherwise multiply the ASV by the number of blocks to the last win. Use this figure in the tiebreaker described in step 3.
Step 3. If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last M blocks. If there is a tie, then use the figure calculated in step 2 as a tiebreaker.
I am back excited that maybe by my birthday on july 26 my share of elastic will be available to market though I will wait until they are a bit cent each to really sell much
EDIT: What's the Roadmap for the launch?
I doubt we have a clear roadmap for the distributed computation market. We're still at the brainstorming stage.
What we're currently developing is the coin which will ultimately support the market. This is the easy part of the project, and should be functional, even releasable, as a coin within a few weeks. However I will be recommending against releasing it so soon. There have been any number of coins which have crashed and burned on release, and I don't want this to happen to ours. I have some ideas about how to defend against that scenario, but they require us to have the market in place.
Please bear with us. I would prefer to have it succeed, than have it soon.
Looking forward to the launch.
Me too, but it will be a long and rocky road until we get there. Full of interesting challenges and nights of coding.
When is the ICO ending?
You are right, this information is missing on the website (you can only see it from the chart).
I will shoot Lannister a PM to fix that as soon as possible.
To answer your question: after block 425920 has passed (or, if 5 million coins have been given away before that time),
no new Elastic Coins will be given out to new donators. Instead, all coins of these 5 million that are left over will be distributed proportionally to those who already have Elastic Coins.
Greaat. Thank you!
Looking forward to the launch.
When is the ICO ending?
You are right, this information is missing on the website (you can only see it from the chart).
I will shoot Lannister a PM to fix that as soon as possible.
To answer your question: after block 425920 has passed (or, if 5 million coins have been given away before that time),
no new Elastic Coins will be given out to new donators. Instead, all coins of these 5 million that are left over will be distributed proportionally to those who already have Elastic Coins.
When is the ICO ending?
EDIT: What's the Roadmap for the launch?
EDIT: What's the Roadmap for the launch?
Anyone?
Before I post my revisions, let's touch base on the NXT scheme. My understanding is that, regardless of stake, the first valid PoS block received by a node which meets the target is the winner. It's just that the target is harder, and in general will be met later for small stakes than large ones. If a node receives a valid block, before it has launched its own, then it won't launch. I would imagine that in such a scheme, relatively few blocks launch, but if two are launched near simultaneously (or which become valid near simultaniously) in distant parts of the network, then the likelihood of a fork with both branches being built on is high. How do you propose to eliminate side-chains?
With my scheme, a lot more PoS blocks will be launched, and even more PoS without a block, so the level of network chatter will be higher, but the voting will ensure that side-chains will very quickly become moribund, and will die when the recent stake value of the main chain gets high enough.
The timing can be solved by having nodes not care about the hours or minutes, only the seconds, and by having nodes periodically poll their peers for the latters' view of Elastic Network Time (ENT) and taking the average (appropriately defined. If one peer is 01 and another is 57 then their average is 59). Over time the nodes should converge.
I suggest a change in terminology. Call this the voting period rather than the bidding period. I think this more clearly reflects what is going on.
If a PoS+B is ineligable to extend the chain due to that account already having won too recently, then it will not win, but could still participate collaterally.
Or ASV > some threshold.
I would abandon this hash value test. for reasons given in my earlier reply to Dink. Also the last sentence would no longer apply though the stake threshold for a PoS-B would be less than for a PoS+B.
Sidechains should be allowed to develop a few blocks, to test the network's view on them, before killing them off.
This is slick, but again I think the whole hash target thing in these scheme would result in tiny accounts getting to stake, while larger accounts can't.
For clarity, leave N fixed, and let M be the number of blocks back to the earliest live fork point, or M=N if larger.
I have a different way to prevent the same N accounts winning over and over again. For any given chain, order the PoS+B trying to extend it by ASV. Then the one with the Highest ASV wins straight away so long as it hasn't already won in the last M blocks. Else if it won n blocks ago with n<=M, multiply its ASV by n/N, and move on to the next. If the PoS+B with the next highest ASV hasn't won in the last M or 2N blocks (whichever is greater), then it wins straight away. Else if it won n
If no block wins straight away choose a block which has won the least number of times during the last M blocks. Usually this number will be zero. If there are several blocks tying on this metric, use the modified ASV as the tie-breaker.
With this scheme, larger stakes will win the block more often, but, so long as there is an alternative, never more than once since transaction confirmation or the oldest live fork point. Smaller stakes get to win occasionally.
With my scheme, a lot more PoS blocks will be launched, and even more PoS without a block, so the level of network chatter will be higher, but the voting will ensure that side-chains will very quickly become moribund, and will die when the recent stake value of the main chain gets high enough.
When reading the following be careful to distinguish between the Stake Value (SV) of an account (ASV), the SV of a block (BSV), and the SV of a chain (CSV). These will all have different definitions. There will be two kinds of PoS, those that come with an associated block (PoS+B) and those that don't (PoS-B). I'm also not going to consider timing issues as my goal here is just to get the idea across.
The timing can be solved by having nodes not care about the hours or minutes, only the seconds, and by having nodes periodically poll their peers for the latters' view of Elastic Network Time (ENT) and taking the average (appropriately defined. If one peer is 01 and another is 57 then their average is 59). Over time the nodes should converge.
Quote
Assume that we want to regard as confirmed any block once it is N blocks deep into the blockchain.
My new idea is similar to my old one, in that for each block, there is a refectory period followed by a bidding period.
My new idea is similar to my old one, in that for each block, there is a refectory period followed by a bidding period.
I suggest a change in terminology. Call this the voting period rather than the bidding period. I think this more clearly reflects what is going on.
Quote
As before, each node discards any invalid PoS (i.e., those that violate the protocol, or those that do not extend a live chain) on sight, along with its block if it has one, and for each live chain, if it receives more than one valid PoS+B extending that chain, it regards the block with the highest ASV as the (local) winner.
If a PoS+B is ineligable to extend the chain due to that account already having won too recently, then it will not win, but could still participate collaterally.
Quote
It also keeps track of every other (valid) PoS - with or without block - it receives. (It could discard the blocks of losing PoS+B, so long as it has a way to recover them from other nodes, if necessary.) Nodes should discard or reject a PoS-B whenever it has decided to retain at least the PoS of a PoS+B from the same account.
At the start of the bidding period, a node should launch a PoS+B, for any account it controls with ASV greater than x% of the ASV of the account it regards as having won the last block. Because ASVs are likely to obey Zipf's law, x could probably be set quite low without causing flooding. Other nodes may have a different view of the winner of the last block, so a PoS+B might legitimately be launched, but rejected by other nodes who do not think its ASV is high enough. (Nevertheless, a node should retain an otherwise valid PoS+B from an account it judges to have insufficient ASV for as long as it is the highest ASV PoS+B it has seen. As soon as it sees another with a higher value, it can discard the lower one.)
In addition, the node should try to create a PoS-B for every account it controls with ASV > 0,
At the start of the bidding period, a node should launch a PoS+B, for any account it controls with ASV greater than x% of the ASV of the account it regards as having won the last block. Because ASVs are likely to obey Zipf's law, x could probably be set quite low without causing flooding. Other nodes may have a different view of the winner of the last block, so a PoS+B might legitimately be launched, but rejected by other nodes who do not think its ASV is high enough. (Nevertheless, a node should retain an otherwise valid PoS+B from an account it judges to have insufficient ASV for as long as it is the highest ASV PoS+B it has seen. As soon as it sees another with a higher value, it can discard the lower one.)
In addition, the node should try to create a PoS-B for every account it controls with ASV > 0,
Or ASV > some threshold.
Quote
including accounts for which it has launched PoS+B. (The duplication is necessary because, as stated above legitimately submitted PoS+B may be rejected by other nodes due to insufficient ASV.) Unlike PoS+B, PoS-B will have to pass a hash value test which depends upon the account's ASV as with NXT. If successful, these are also launched at the start of bidding. Valid PoS-B are never rejected on grounds of insufficient ASV.
I would abandon this hash value test. for reasons given in my earlier reply to Dink. Also the last sentence would no longer apply though the stake threshold for a PoS-B would be less than for a PoS+B.
Quote
Finally, as a last resort, if a node has neither launched a block nor received a (valid) one (including otherwise valid blocks from accounts with insufficient SV) then it should launch a PoS+B for its highest SV account according to the delay schedule described in my previous suggestion.
All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node.
The end result of all of this, is that so long as a node controls at least one account with ASV > 0, there will be at least one chain extended by a PoS+B. Any chain not so extended dies. Also a chain dies if it's CSV is less than y% of the CSV of the winning chain.
All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node.
The end result of all of this, is that so long as a node controls at least one account with ASV > 0, there will be at least one chain extended by a PoS+B. Any chain not so extended dies. Also a chain dies if it's CSV is less than y% of the CSV of the winning chain.
Sidechains should be allowed to develop a few blocks, to test the network's view on them, before killing them off.
Quote
Apart from the addition of PoS-B, The new scheme differs from the previous in that an account's ASV is no longer the time integral of its balance. Instead it is equal to the lowest balance that the account has had during the last N blocks. An account that was created or which has won a block fewer than N blocks ago has an ASV of zero.
The block extending a chain has a BSV equal to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain. Call these other contributors of ASV to the BSV "collateral support". No account's ASV is counted more than once in the past N blocks, so if any of the PoS, including the winning PoS+B has already contributed collaterally to the BSV of an earlier block in the chain, then it is not counted again. Nor, if a block is added to a collateral supporter, does the new block add to the collateral support. In other words, collateral support is given to sisters, not aunts. The CSV is the sum of the last N blocks' BSVs.
The idea behind collateral support is that the main chain will benefit from honest PoS more than any side-chain, including a side-chain being built by an attacker. (If the attacker's chain benefits more, then it is the main chain by definition.) Moreover an attacker can gain nothing by diverting his resources into his own collateral sybils, since this will just take away ASV from his winning blocks. This is a zero-sum game for him. PoS-B allows every account-holder with any ASV at all a chance to contribute collaterally to blockchain security, though they can never win a block unless their ASV is enough to allow them to launch a PoS+B. Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.
To summarise: PoS+B need to meet an ASV threshold, but not a hash threshold. BoS-B need to meet a hash threshold, but no ASV threshold. Note that the attack I describe above is defeated. A PoS miner cannot PoW his PoS+B because there is no hash target to meet. Neither can he PoW his PoS-B because there is no block to diddle.
The block extending a chain has a BSV equal to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain. Call these other contributors of ASV to the BSV "collateral support". No account's ASV is counted more than once in the past N blocks, so if any of the PoS, including the winning PoS+B has already contributed collaterally to the BSV of an earlier block in the chain, then it is not counted again. Nor, if a block is added to a collateral supporter, does the new block add to the collateral support. In other words, collateral support is given to sisters, not aunts. The CSV is the sum of the last N blocks' BSVs.
The idea behind collateral support is that the main chain will benefit from honest PoS more than any side-chain, including a side-chain being built by an attacker. (If the attacker's chain benefits more, then it is the main chain by definition.) Moreover an attacker can gain nothing by diverting his resources into his own collateral sybils, since this will just take away ASV from his winning blocks. This is a zero-sum game for him. PoS-B allows every account-holder with any ASV at all a chance to contribute collaterally to blockchain security, though they can never win a block unless their ASV is enough to allow them to launch a PoS+B. Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.
To summarise: PoS+B need to meet an ASV threshold, but not a hash threshold. BoS-B need to meet a hash threshold, but no ASV threshold. Note that the attack I describe above is defeated. A PoS miner cannot PoW his PoS+B because there is no hash target to meet. Neither can he PoW his PoS-B because there is no block to diddle.
This is slick, but again I think the whole hash target thing in these scheme would result in tiny accounts getting to stake, while larger accounts can't.
Quote
If a fork persists longer than N blocks, then we increase N by 1 per block so that it always covers at least as far back as the fork point.
For clarity, leave N fixed, and let M be the number of blocks back to the earliest live fork point, or M=N if larger.
Quote
To maintain the fork, an attacker will have to bring ever more resources to bear. Or increase his chain's CSV past that of the main chain, at which point it takes over as the main chain. To do this, he will need to own N account each with a higher balance than anyone else. If we ever see the same N accounts winning over and over, we could increase N even if we don't see a fork.
I have a different way to prevent the same N accounts winning over and over again. For any given chain, order the PoS+B trying to extend it by ASV. Then the one with the Highest ASV wins straight away so long as it hasn't already won in the last M blocks. Else if it won n blocks ago with n<=M, multiply its ASV by n/N, and move on to the next. If the PoS+B with the next highest ASV hasn't won in the last M or 2N blocks (whichever is greater), then it wins straight away. Else if it won n
If no block wins straight away choose a block which has won the least number of times during the last M blocks. Usually this number will be zero. If there are several blocks tying on this metric, use the modified ASV as the tie-breaker.
With this scheme, larger stakes will win the block more often, but, so long as there is an alternative, never more than once since transaction confirmation or the oldest live fork point. Smaller stakes get to win occasionally.
And with your addition of the exponential 7-second target-doubling scheme, which i personally find genius...
That's enough backslapping. Back to work.
Quote
But the really hard (and interesting) part is yet to come. Computational verifiability.
Yep.
Jump to: