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

What would you call them, then?

And with your addition of the exponential 7-second target-doubling scheme, which i personally find genius, we at the same time mitigated both the block-takes-forever and the block-submission-burst-after-duration-threshold problems.  

EDIT: I think I should take some time this weekend to write all our latest thoughts down in the white paper.

But the really hard (and interesting) part is yet to come. Computational verifiability.

It's clever because it's simple, it works, and because I didn't think of it.  My solution would have been to keep rehashing using the timestamp as a nonce.[/quote]

3600 seconds is an hour, seems a bit long if we want a block every minutes.

Why not just have a slow exponential increase?  If the target doubles every 7 seconds, then even a target of 1 will exceed 2^256 in just under 30 minutes.

Or wait one minute with no change in the difficulty (to allow nodes with up to a minute's clock skew to submit blocks they win imediately) then start doubling every 7 seconds, guaranteeing a block in just over 30 minutes.  Nodes with greater skew than that will suffer a disadvantage, but I don't think that is much of a problem.

Hi Guys,

Could someone tell me when the crowdfunding phase will end? Also, would I be able to just donate using my multibit BTC wallet?

Many thanks.

Cheers

Does Lannister have access to this old address?

You are absolutely right. Sometimes I make assumptions too quick without even thinking.
Well I have checked the NXT source code and they indeed tried to fix the problem by setting a fixed threshold of 3600 seconds when, if passed, every one can generate a block.


I am not a fan of this approach. I always try to look on such things from the network's perspective. A fixed time frame causes bursts of thousands of blocks being flooded in the network simultaneously once that threshold is reached.

Maybe we could do a linear target increase until the last block was mined 3600 seconds ago or more.
After that we switch to an exponential increase which quickly lets someone find a block but avoids that burst of network traffic.

The address has been changed since Lannister took over the management of the project.
The original address was 3Qnj4QtdD4qtZcP82xyLq2paAEPDgfwezd

The addresses have changed.

hi,
the website indicates today that 78,87 BTC was donated.

When is the ICO ending?

EDIT: What's the Roadmap for the launch?

Surely it would reduce the advantage of people with more coins.

Assume that account A has ten times the balance of account B, and that both have approximately the same hash value.  Then with a linear increase in target value, account B would take ten times as long to be able to submit a block as account A.  With an exponential increase, account B would take log(10) more than account A, a constant difference.


With exponential growth, that would happen anyway pretty quickly, when the target exceeds 2^256.

Thanks ;-) Yes, releasing the block a short time before the due time is a very good idea. Thanks for that.
Still we have one issue left. Let us say, without loss of generality, the PoS hash is very bad for all active miners, i.e., a lot higher than the personal target value of each one of them. If everyone of these miners has a very low balance, e.g., 1 coin the personal target T would only rise by 1 unit per second. This may take a very long time.

Either we need an exponential increase in the target value, but that is bad because it means that people with more coins have significant advantages.

Not sure how to resolve this issue. We have to avoid such (even if they are unprovable) deadlock situations.
Would you think a hard deadline which, when passed, allows anyone to mine a block even with no balance in the account, could resolve that problem?

No they're not.  PoS is there to secure the blockchain, nothing else.  The distributed computing is a separate system which is not involved in blockchain security.  You don't need any stake to be part of the distributed computer, though your earnings from that might enable you to stake.  Similarly you don't need to work in order to be able to stake.


I don't think that would happen, because the big money will come from working, not staking.


Yes, but small balances, and even large balances don't get to stake every block.  They are entered into a lottery where their stake determines their chance of winning.  This is what prevents the network from being overwhelmed by a vast number of tiny PoSs

My scheme will allow every account with a balance that isn't tiny to stake every block, either collaterally, or given a little higher balance, fully.  Security comes from having as much honest stake participating each turn as possible, and I don't want to force small holdings into a lottery, in order to enable even smaller ones to participate.  It might give people the warm fuzzies if you tell them that they can stake their penny holdings, but it does nothing to enhance block security.


With respect, I don't think you have the technical expertise to be able to judge that.


No because of the lottery.  Only a tiny number of the sybils can win and get their PoSs accepted into the network.

That is clever.

Suggestion: have the miner release the block 20 seconds (or some other value determined empirically) before it is due.  Nodes receiving blocks will calculate their own "due by" time, based upon the stake-value and their own idea of network time, and hold onto the block until then.  If no valid higher-stake block is received in the meantime, the miner wins the block.

Having everyone releasing early eliminates the advantage to be gained by unilaterally doing so.

Short update:

I have the PoS mining ready by now. I need some more time to test everything and remove static parameters that I have (over)written in the code for debugging reasons.
Also I need to use all addresses with positive balance in the current wallet instead of (again just for testing) a hard coded pubkey. We are almost there.

Just so that you see something, here a little screenshot showing the "time to block estimation" in action.

This is what happens here:

1. The miner wants to create a block, so he generates a "Blocktemplate" based on the current transaction pool. In this process he also creates a Coinbase transaction paying the TX fees to himself.
2. He generates a "signatureHash" H which is a hash of the previous block's signature hash combined with his public key.
3. He calculates his own target vaue T which is personalized and bases upon the users stake value.
4. If Hif not, then he has to wait. The own target value T increases over time, linearily. The more stake value a user has, the faster this value rises.
Eventually, T will raise so much that H5. As we exactly know how fast T is rising for each user, we can exactly determine the time a user has to wait until he finds a block.


Right now, only visible in the console, soon presented nicely in the GUI client.

Great, I will have responded to all open questions and commented on your thoughts by then.
See you later.

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


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.


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


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

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