Topic: This message was too old and has been purged - page 7. (Read 12685 times)
EK, do you have any thoughts on the subject of data persistence?
At some point I would like to hear what Evil Knievel was thinking about using something other than a blockhain so that it doesn't matter who is the fastest - something already being developed like Iota's DAG (I think that's what they call it) or something new?
Well I don't know. As I said I'm not really competent to evaluate it. I'm just a guy on the internet, after all, who doesn't know that much about anything. Most of what I know about crypto came from Wikipedia.
I think you're being overly modest. Regardless of where you got your cryptocurrency knowledge, you clearly have some fairly in-depth understanding of both it and computer science in general.
it is possible that this blog post is just straying into the other guy's territory and making mistakes because of that.
Or perhaps he's just straying into theoretical areas he doesn't understand, but which aren't really relevant to what he's working on, which could be perfectly fine and functional.
Quote
But in any case, I was mainly wondering if they had any ideas there which might inspire a better solution for ELC, but it seems that anything relevant is either not being shared or just isn't there.
Well I don't know. As I said I'm not really competent to evaluate it. I'm just a guy on the internet, after all, who doesn't know that much about anything. Most of what I know about crypto came from Wikipedia.
Of course this is no "security" as it is defined in theory, but unless an attacker contacts all miners and lets them run a modified version of the client software, I dont think that this attack would be practicable.
Not saying this is a very good idea, I was just brainstorming what may or may not be important to the design of ELC. So I put it up for discussion.
Not saying this is a very good idea, I was just brainstorming what may or may not be important to the design of ELC. So I put it up for discussion.
Well, the user's data, to the extent that it is used in a proof of work, must be publicly visible. We could maybe obscure who the user is, and what the data means, but that's about it.
I am greatly in favour of encrypting data while it is being passed around the network, but in the end, confidentiality is not going to be one of our selling points.
I thought there would be some kind of default hashing task in case the network idles.
Yes this would be the fall-back solution when there is absolutely no work at all.
This would only allow for collecting the tx fees. This is by the way also open for discussion, maybe someone comes up with something better.
Personally I think tx fees suck. Why should people have to bribe the miners to get their transactions processed?
I think we need a small tx fee, say 0.01% of every transaction, to combat transaction spam and for no other reason.
Edit: on second thoughts, scrap that. Make it a flat 0.0001ELC Let's go for transaction neutrality. If you're mining for the tx fees, everyone's is a good as anyone else's. Nobody's transaction should have to wait because other more lucrative transactions are jumping the queue.
This message was too old and has been purged
I thought there would be some kind of default hashing task in case the network idles.
This message was too old and has been purged
On a second thought, what makes this coin competitive versus BOINC? At BOINC there is a huge amount of computing power already available for free. So why would someone mess with crypto and pay for computing power in the first place? Also, if there are no regular PoW block rewards that means miners are not incentivized to process regular transactions, will network stall until someone pays enough for miners to start computing?
As for amount of coins, 5M sounds fine but I would also be OK with 1M or 100M. Just don't go retarded and opt for 100B or 100k coins.
As for amount of coins, 5M sounds fine but I would also be OK with 1M or 100M. Just don't go retarded and opt for 100B or 100k coins.
Well I'm not that knowledgeable. I just skipped over what I couldn't understand until I found something I could. It's still possible that someone in that project is doing cool. I mean, it's not as though our white paper, or for that matter, our website is particularly impressive.
Lol, that's true. I think there are two devs on that, the one who wrote that blog post I think does the 'agoras' part (the token and end services) and the other the 'tau chain' part that its built on top of, so it is possible that this blog post is just straying into the other guy's territory and making mistakes because of that.
But in any case, I was mainly wondering if they had any ideas there which might inspire a better solution for ELC, but it seems that anything relevant is either not being shared or just isn't there.
This message was too old and has been purged
I thought about some kind of Opt-In encryption at some fixed fee. People can decide if they want the extra encryption at the cost of a decreased mining speed or not. What do you think about it?
Until someone figures out a practical way to do this workers will have to be able to see the data they're working on. Are we planning to subject miners to security vetting?
If not, then this problem is unsolvable. At the very least, nobody here is going to solve it.
Thank you for that Dazza. My own non-technical opinion when I was considering buying into their crowdsale, based only on intuition and not any actual understanding, was also that it was a lot of 'technobabble' as you say, and that the they would not be able to do what they were saying they were going to do, but I was never sure and it seemed to contain some interesting ideas so its good to hear a more knowledgeable opinion about it.
Well I'm not that knowledgeable. I just skipped over what I couldn't understand until I found something I could. It's still possible that someone in that project is doing cool. I mean, it's not as though our white paper, or for that matter, our website is particularly impressive.
Quote from: Dazza
Second, "my scheme" for the PoW function which EK and I have been discussing, has an aspect which hasn't been discussed at all so far. It will vastly add to the storage requirement in the blockchain. Essentially the entire data-segment of the program that wins the block will need to be stored in order to be able to verify the block.
We have to use the "checkpoint" scheme as already known from Bitcoin.
Checkpoints have to be set on a regular basis, so that it will be not required to keep track of everything that took place before that. We need to come up with a smart way to do it "decentralized". At least if we go the traditional blockchain approach.
For different schemes however, different opportunities may arise.
Bitcoin is limited to 1MB per block and it already amounts to over 50GB in total. Our blocks could be hundreds or thousands of times larger, under "my scheme" as I've been thinking about it. And that's without handling any more transactions per second than Bitcoin.
But there's a solution. Just eliminate any and all variables not read in the PoW. This would have the additional advantage of eliminating the "nonce" used by the attacker to effect the "run once, hash many times" attack I described earlier.
Still too much data? Then disallow it. That segment can't win the block, no matter what the hash value. Try again. Ironically this is most likely to happen in loops which do incremental reads, such as, for example, computing SHA-256.
Have you guys looked into Tau chain https://bitcointalksearch.org/topic/tau-chain-and-agoras-official-thread-generalized-p2p-network-950309 ?
There are some similarities to ELC such as 'proof of code execution' although I'm not sure if that is used to secure the chain or just get payment. I tried to follow Tau chain / Agoras a while back but a lot of the AI-type stuff just seemed overly optimistic to me.
There are some similarities to ELC such as 'proof of code execution' although I'm not sure if that is used to secure the chain or just get payment. I tried to follow Tau chain / Agoras a while back but a lot of the AI-type stuff just seemed overly optimistic to me.
I had a look at this.
The overview is utterly incomprehensible to me. There are a lot of buzz words about things I know somewhere between little and nothing about. I am not competent to evaluate this, though the suspicion is raised that it is meaningless technobabble....
...At this point, you can stop reading. The author, who also appears to be the project leader, does not know what he's talking about.
Thank you for that Dazza. My own non-technical opinion when I was considering buying into their crowdsale, based only on intuition and not any actual understanding, was also that it was a lot of 'technobabble' as you say, and that the they would not be able to do what they were saying they were going to do, but I was never sure and it seemed to contain some interesting ideas so its good to hear a more knowledgeable opinion about it.
Have you guys looked into Tau chain https://bitcointalksearch.org/topic/tau-chain-and-agoras-official-thread-generalized-p2p-network-950309 ?
There are some similarities to ELC such as 'proof of code execution' although I'm not sure if that is used to secure the chain or just get payment. I tried to follow Tau chain / Agoras a while back but a lot of the AI-type stuff just seemed overly optimistic to me.
There are some similarities to ELC such as 'proof of code execution' although I'm not sure if that is used to secure the chain or just get payment. I tried to follow Tau chain / Agoras a while back but a lot of the AI-type stuff just seemed overly optimistic to me.
I had a look at this.
The overview is utterly incomprehensible to me. There are a lot of buzz words about things I know somewhere between little and nothing about. I am not competent to evaluate this, though the suspicion is raised that it is meaningless technobabble.
Then I clicked on one of the links, and found this: The first part of this post makes sense to me, and accords more-or-less with my understanding of how Bitcoin and Etherium work, not that I know much about the latter. (Or the former, for that matter.) Then we get to this bit:
Quote
But it turns out that life aren't so easy. The Halting problem over Turing machines became so famous not because its answer is “No”, but because its answer is both “Yes” and “No”! A contradiction. This situation is mildly called “undecidability”. And this can go arbitrarily far: any such contradiction can be elevated to any statement, supplying a proof that it is true, and also supplying a proof that it is false!
Nonsense. The situation is called "undecidability" because there is no way to decide whether an arbitrary TM halts or not. The answer is not both "yes" and "no". It is one or the other, but we can't tell which. You should also understand that undecidability is not just a statement about our ignorance. It is built into the mathematics.
Undecidability is not a problem for the programmer. It's his job to ensure that his program is decidable, and that it does what he wants it to do. Undecidability is (potentially) a problem for the people who run programs supplied by others. Etherium's solution to the halting problem - aborting the program when it runs out of "gas" - is the same as ours, and it is the correct solution. However the halting problem is not the only undecidable problem in computing and the issue will recur for us.
Quote
Because of such pathologies, we can never trust a proof over a Turing complete language. Completeness here happens to be precisely the completeness Godel spoke about, when he proved that any language that is expressive enough to describe arithmetic, must be either inconsistent or incomplete. Since Turing complete languages are also “Godel-complete”, they are provably inconsistent.
Utter balderdash. Turing-complete languages are languages which can compute anything a TM can. Godel-completeness means that any statement expressible in the language is also decidable in it. The very existence of undecidable problems shows that TMs are not Godel-complete.
At this point, you can stop reading. The author, who also appears to be the project leader, does not know what he's talking about.
This message was too old and has been purged
This message was too old and has been purged
Well, it depends on the definition of "compatible".
I am pretty sure that you can take a task from folding@home and have it solved by the Elastic Coin network (or its miners).
I am pretty sure that you can take a task from folding@home and have it solved by the Elastic Coin network (or its miners).
I think we are aiming at general-purpose computing. If it is a task that can be performed by a computer, then we can do that task for you. But there will be several caveats.
First, as I envisage things, you will need source code, since applications will need to be specially compiled with a compiler which we will provide. Initially only one programming language will be available. I'm sure others will join it over time.
Second, "my scheme" for the PoW function which EK and I have been discussing, has an aspect which hasn't been discussed at all so far. It will vastly add to the storage requirement in the blockchain. Essentially the entire data-segment of the program that wins the block will need to be stored in order to be able to verify the block. Consequently we may have to limit the size of that data-segment. Since I am now convinced that "my scheme" is unworkable and we will have to find a different solution, I don't think this will be an issue, though of course the individual nodes will have their own memory and storage restrictions.
Third your data will be made available at the very least to a large bunch of random people, and probably to the entire general public. So while it might be possible for us to process your company payroll, it would be neither legal, ethical, nor sensible for you to use it for that purpose.
Jump to: