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

why the ICO amount showed in main page doesn't match the balance of the address??? Scam?

I just make a donation from blockchain.info wallet.
Why my public key does not match btc_tx from genesis block please
Thanks,

I want to do some distributed machine learning. Would be absolutely amazing if this could also allow for CUDA or OpenCL optimizations within the Python running.

I would actually pay for my calculations to run. But still waiting to see how far you guys go with this.

That question had already been answered on the very same page you asked it.

To ensure that an attacker cannot predict whether another account (i.e., not under the control of the attacker) will be able to stake or not, what is hashed should be the account's digital signature of something.  The "something" needs to be something that the account owner can't manipulate, (so that he can't PoW it), it shouldn't be different if he chooses a different branch (so he can't N@S), and it should be no older than N blocks (so he can't try a bunch of accounts and see which one will be able to stake before he has to fund the account.)  I propose that the "something" be the PoS hash N blocks ago.  This is not entirely N@S proof because forks can last longer, but this will be unusual, I think.


I'm now thinking that the dependency on M in this algorithm is likely to cause more problems than it solves, because M is not a network-wide parameter.  Different nodes will have different views on what M is, and so will have different views about which candidates are eligible to win in Step 2.  This is a recipe for forks.

So replace the above with:

Step 1.  Calculate each candidate's normalised ASV (nASV) by dividing its ASV by the largest ASV of any of the last N block winners.  This will not affect the candidates' rankings in any way.

Step 2.  Iterate through the candidates in decreasing order of nASV.  For each candidate, if the account last won more than max(N,N/nASV), or if it has never won, it wins; exit.  Otherwise multiply the nASV 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 N blocks.  If there is a tie, then use the figure calculated in step 2 as a tiebreaker.

Is it ok to send from coinbase account?

Hey Elastic team,

About a day or something after i deposit 1,27 Btc exactly the same amount got withdrawn from your wallet.

Im just here to ask if my ico deposit still is oke ? and this funds was just for development withdrawn.

Do you guys have a Slack?

Hi guys, I will be offline for the next 5 days as I will have no access to an internet connection from where I go now. I will be working offline and present you my work and my thoughts as soon as I come back.

Thank you ! I never blamed anyone on my post.

Great discussion going on in ELC.
Waiting to see a working product before putting some BTC in.

Its a good project. I have invested my 1.5btc Needs patience. Good luck devs.

Yes.


I did say that, but then changed my mind.  Forgot to unsay it; beg pardon.

The current iteration of this scheme allows accounts to win more than once per N blocks, but only as a last resort.  A valid block from any account which has not won in the last N will always beat one from one that has, but this is now done further into the algorithm, not here.


My original thinking was as follows:

All PoS contain a hash of the previous PoS+B, specifically of the branch they regard to be the current winner.   Out of all the valid PoS+B submitted extending this branch, the one with the bighest ASV will win, but its BSV will then equal the sum of the ASVs of every PoS hashing to the same previous PoS+B.  You should interpret every PoS as a vote to extend a particular chain, though only PoS+B come with a block to extend it.

A side-chain may also receive PoS-B and PoS+B from various accounts which indicates that other nodes think that the side-chain is in fact the main chain.  If a side-chain attracts more stake value than what a node believes to be the main chain, then that's an indicator that the node's belief is incorrect.

The PoS part of a PoS+B would do double duty, both supporting the block nomination, and voting for the chain it tries to extend. Hence if both a PoS+B and a PoS-B were received from the same account, delete the PoS-B.

My current thinking revises this as follows

It would be simpler if the PoS+B were simply to nominate the block, while the PoS-B (which would come later in the revised 4-stage schedule) votes for which chain to extend.  Consequently, both a PoS+B and a PoS-B from the same account should be expected and accepted.  An honest PoS miner ought to vote against his own winning block, if he saw a block on a close-running side chain supported by a much higher ASV.  However there's no way to enforce this.


Yes, sums of sums of ASV's, in principle all the way back to the genesis block.  In practice you only need to go back as far as the oldest live forkpoint.  My current thinking is that only the most recent PoS-B, (in any branch) should count.  Hence if an account switches its support to a different branch, it's previous support is cancelled.


Yes, but according to my current thinking, the PoS+B only nominates a block, it does not vote for the chain it extends.  The account should send a PoS-B to do that.


My current thinking is that there are two periods which might be called the "nomination period" when PoS+B are launched and the "voting period" when PoS-B are launched.  I also think a node should always launch exactly one PoS+B, the best it can for the branch in considers to be the winner unless it receives a better PoS+B from somewhere else before it launches its own.  I've abandoned the idea of a lower limit of x%.

Thinking about "Nothing @ Stake", I cannot see a way, if a node controls more than one account, to prevent or detect it launching multiple PoS+B, each from a different account, each to a different branch.  There would be no point in launching multiple PoS+B to the same branch, because it will know ahead of time which one would win.

I am assuming that there is nothing tying an account to the node that controls it.


Current thinking is just the one best PoS+B (There can be only one winner), but as many PoS-B (each for a different account) as the node can validly launch.  Collateral is persistent, until that account launches another PoS-B, at which the previous collateral for that account is cancelled.


Or even if it doesn't, if we allow zero-ASV account to PoS+B if there is nothing better.


Again, this works only if we abandon the >x% criterion and allow any account to PoS+B


Current thinking is that any new side-chain
But yes, at some point a judgment has to be made that a side-chain is no more; it has ceased to be; It's expired and gone to meet its maker.

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.

Yes.

Quote

An account that was created or which has won a block fewer than N blocks ago has an ASV of zero.

Created fewer than N blocks ago, yes, because its balance before creation logically must have been zero.

Last won a block fewer than N blocks ago, no.  So long as it maintained a +ve balance throughout the last N blocks, it will have a +ve ASV.

Quote

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.

See above.  We will be counting only an account's most recent PoS-B, so it is the earlier one(s) which will be ignored.

Quote

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.

Current thinking is that PoS+B never contributes collateral support whether or not there is a PoS-B from the same account.  All a PoS+B does is nominate the block.

Strictly speaking collateral support is given to mothers, but of course it is all the winning daughter who are supported when mother is supported, i.e. the sister of the collateral supporter.  I hope this makes sense.

Quote

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.

Yes.

Quote

Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.

Don't understand the sentence.

Quote

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

Deterministic, but not necessarily predictable because an attacker (or anyone else) does not know which other accounts will stake at any time.

That said, my ultra-ultra-latest thinking is that, just to inject more randomness into the system, perhaps we should have a hash target, but one that is the same for all accounts, and independent of the SV.  However we will have to be careful to ensure that an attacker can neither predict whether an account he doesn't control will pass its target on a particular turn, nor manipulate the accounts he does control to ensure that they will.

Quote

who from a subset of N "online" users will win which block.

The subset is not limited to N.

Quote

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?

That was my original idea.  The sole purpose of dropping to zero was to prevent accounts from staking more than once in any N consecutive blocks.  This is now achieved in a different way.

Quote

If so, this could leave an attacker the possibility to create N high-stake account and winning blocks with them "round robin".

Yes, he can do that.  They would have to be all higher than any other staking account, which would be quite hard to achieve.

(Snip recapitulation of obsolete scheme.)

Quote

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?)

M >=N.  M is actually the distance back to the last confirmed block.  This will be N unless there is a long-lasting fork whose fork-point is further back.

Quote

Quote

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.



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.

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?

Not in two lines, but in one short paragraph:  If all the attacker's accounts have the same minimum balance, i.e., the same raw ASV (and all no lower than the honest account with the largest raw ASV) then, after the normalisation in step 1, all the attacker's accounts will have a normalised ASV (nASV) of 1.  On the other hand, if one of his accounts has a higher ASV than the others, the highest account will normalise to 1 and the lower accounts will normalise to < 1  These account will not be able to win every N blocks.  Instead, they will win every N/nASV > N blocks (assuming that M is not higher than this.)

Quote

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 he only needs N accounts all with a raw ASV higher than any other staking account, to win every block forever.  He won't need to shuffle his money around.  The question that needs to be asked is, what can an attacker achieve if he succeeds in his attempt to do this?  As far as I can see, other than winning all transaction fees, the only thing he can do is shut out transactions of his choice.  To attempt to double-spend would require a side-chain attack, and the rule that (1) no transaction is considered confirmed if it is not in a block preceding the earliest fork point, and (2) no forking block is accepted if it is later than a confirmed block, prevents all possible double-spending attacks.

In other words, the worst that an attacker can do is DoS.

I have two ideas to defeat this.  First is the ultra-ultra-latest idea of randomness.  No matter how low we set the probability of an account not being allowed to stake that turn, and no matter how many high-value accounts he has, eventually all his accounts will be blocked in the same turn, and his monopoly (or even his monopole ) will be broken, if only temporarily.

My second (brand new) idea is to introduce a new metric that nodes can use to decide which branch is the current winner - not difficulty, nor stake-value, but unsociability.  A branch's unsociability is the total number (or perhaps the total value) of all transactions the node knows about that are not yet included in the branch, excluding very recent ones, and perhaps giving a higher weight to older ones.  Anyone not including all the transactions he knows about into his blocks will soon find his branches losing to more sociable side-chains.

And if the attacker with N high-value accounts locks out all others, and is completely sociable, in what way is he attacking?

Very briefly, as I'm busy with real life, the attacker gains nothing doing this because he could pull off the same attack with the same N accounts over and over.  He doesn't need to create new ones.

I do have a new idea to defend against this.  Hope to be back late this evening, but gotta go now.

Edited to Add:  M is always >= N, it can never be < N.

Last night, when I couldn't sleep, I was thinking about the N-account attack, specifically this version here (let's call it N+2 account attack):


EDIT: Removed possible solution, as it clearly was none.

Sorry this happened to you.  However the instructions on the website have always been clear on this point.  It's not anyone else's fault if you didn't read them or couldn't comply with them.

You get more ELC for your BTC if you donate now versus waiting.

You should never use an exchange to directly withdraw to the donation address if you want to receive some ELC.
A coinbase account should be fine, but the easiest way is indeed to send everything to a private account first.

If you use your coinbase wallet you would need this information:

- 3 extended public keys (xpubkeys)
- User seed
- Shared encrypted seed
- Your vault password

good idea, might as well make all the addresses and amounts that have been raised so far public. I too sent my money during the initial first week

are you joking?  The 22000 blocks time left, it is abou 150 days!!!