Topic: Relaunched Completely - page 4. (Read 11497 times)
P.S. I have already started investing some btc but most of my btc is tied up momentarily. I am serious about contributing too.
Great your improving the white paper. You should also use those bitcoins you get on the automated and industrialized software creation network running on bitcoins here codevalley.com. But if you do that save a dozen btc worth of your coin for me to buy and we will be billionaires 
and I would even learn skills and help develop as a volunteer!
Sincerely,
Daniel Hazelton Waters
and I would even learn skills and help develop as a volunteer! Sincerely,
Daniel Hazelton Waters
The concept does sound interesting, but at the moment the nature of the crowd-funding is putting me off. Could you tell me if you would be willing to reveal more about yourself personally, perhaps by linking to a public profile in order to assuage the fears of potential investors and show that Lionel Keys is in fact your real name. To be frank, the project reminds me very much of the work of a prolific scam dev who was very active here in the past. I'd feel a lot more comfortable investing knowing this is your true identity and so that you are not him. Thanks.
I can assure you that I am no "prolific scam dev".
We will put up a detailed list of the core development team along with their pictures and short CVs online pretty soon
If you do not like the idea of crowdfunding (which i totally understand and accept) please make use of the advantage that this "development and IPO proceed simultaneously" scheme has: you always have the chance to wait until the product is finished, and if you like it buy directly into the genesis block. See, you can totally avoid any risks because once the product is out and working, it cannot be a "scam" right?
Any progress with the profiles and CVs? I think this would benefit everyone involved. More assuring for potential investors and so more BTC to fund you and your team.
^ in case you missed it
You've avoided responding to this twice now. Do you intend to put those profiles of the core development team up as stated?
Hi guys, minimun amount to invest is 1 btc?
Hi, the minimum ist 0.01 BTC.
No problem at all. You can buy multiple times using the same address ... the crowdfunding software will accumulate that automatically.
You can always check your current balance using the balance check function on http://elastic.pro.
Hi guys, minimun amount to invest is 1 btc?
Hi, the minimum ist 0.01 BTC.
The concept does sound interesting, but at the moment the nature of the crowd-funding is putting me off. Could you tell me if you would be willing to reveal more about yourself personally, perhaps by linking to a public profile in order to assuage the fears of potential investors and show that Lionel Keys is in fact your real name. To be frank, the project reminds me very much of the work of a prolific scam dev who was very active here in the past. I'd feel a lot more comfortable investing knowing this is your true identity and so that you are not him. Thanks.
I can assure you that I am no "prolific scam dev".
We will put up a detailed list of the core development team along with their pictures and short CVs online pretty soon
If you do not like the idea of crowdfunding (which i totally understand and accept) please make use of the advantage that this "development and IPO proceed simultaneously" scheme has: you always have the chance to wait until the product is finished, and if you like it buy directly into the genesis block. See, you can totally avoid any risks because once the product is out and working, it cannot be a "scam" right?
Any progress with the profiles and CVs? I think this would benefit everyone involved. More assuring for potential investors and so more BTC to fund you and your team.
^ in case you missed it
Hi guys, minimun amount to invest is 1 btc?
The concept does sound interesting, but at the moment the nature of the crowd-funding is putting me off. Could you tell me if you would be willing to reveal more about yourself personally, perhaps by linking to a public profile in order to assuage the fears of potential investors and show that Lionel Keys is in fact your real name. To be frank, the project reminds me very much of the work of a prolific scam dev who was very active here in the past. I'd feel a lot more comfortable investing knowing this is your true identity and so that you are not him. Thanks.
I can assure you that I am no "prolific scam dev".
We will put up a detailed list of the core development team along with their pictures and short CVs online pretty soon
If you do not like the idea of crowdfunding (which i totally understand and accept) please make use of the advantage that this "development and IPO proceed simultaneously" scheme has: you always have the chance to wait until the product is finished, and if you like it buy directly into the genesis block. See, you can totally avoid any risks because once the product is out and working, it cannot be a "scam" right?
Any progress with the profiles and CVs? I think this would benefit everyone involved. More assuring for potential investors and so more BTC to fund you and your team.
Dazza please can you explain us why you are here if you don't like this project?
I do beg your pardon. I was unaware that these threads were only for uncritical fanboys.
Quote
Do you have so many free time in your life?
Not enough to get a 154 point activity score.
Mr. Dazza, please can you find another thread to FUD and SPAM?(this forum is full)
@Elasticcoin : The ANN thread must be moderated to avoid FUD and spam from professional spammer .
I made four comments and you're calling me a professional spammer? Now who's FUDding?
Getting such things done properly is one major aspect when developing a coin.
That would include the white paper itself, no?.
Quote
In this case, where the proof of work functions are provided externally, it is far from trivial.
But if it could be done easily, someone would have already done it before.
But if it could be done easily, someone would have already done it before.
You given us no reason to believe that you are capable of solving these "far from trivial" problems.
In fact you've done worse. You failed to solve some problems which are trivial and which have already been solved before.
For example, there's another reason your proposed function SHA256(Inputs,Outputs,PK) won't work: There's no dependency on the block. You need SHA256(Inputs,Outputs,PK,BLK) where BLK is the block or (better) the hash of the block. If the PK is encoded in the block, which it probably ought to be, then all you need is SHA256(Inputs,Outputs,BLK). This of course, is what bitcoin already does.
Quote
Thank you for pointing the discussion in that direction. We are well aware of the possible attack vectors and we already worked out how to conquer them.
I will make sure the white paper gets extended by a "possible attacks" chapter to eliminate concerns regarding exactly that.
To clarify: the security of the transaction ledger in Elastic Coin will be mathematically provable. We are not fixing several isolated attack vectors here, we make it rock solid.
Expect the new version of the whitepaper anytime soon.
I will make sure the white paper gets extended by a "possible attacks" chapter to eliminate concerns regarding exactly that.
To clarify: the security of the transaction ledger in Elastic Coin will be mathematically provable. We are not fixing several isolated attack vectors here, we make it rock solid.
Expect the new version of the whitepaper anytime soon.
Will your new section explain how you propose to defeat these attacks? I'm not asking for formal proofs at this stage, an outline will do. So far, all we've seen are promises to be delivered in the months to come, while you're collecting crowdsourced bitcoin now.
really cool idea with this kind of proof of work
Evil Knievel, you've just written two lengthy paragraphs explaining how the attack wasn't a problem "from the reward point of view". I never said it was. I'm well aware that there's no 25 coin per block bounty.
You wrote one line on the actual problem:
This is the problem. Focus on this.
Why are you "sure"? Why are you "very confident"? What grounds has Dev given us to have faith in his ability to deliver what he is promising?
And, just to be clear, it's not a problem if a miner solves some of his own blocks. It's a problem if a miner solves blocks (whether his own or someone else's) faster than the rest of the network put together. Solving his own blocks is just a means to that end.
The concerns I am raising go way beyond mere "design questions". Some of the promises in the white paper are mathematically impossible, for example: a Turing-complete language which does not allow arbitrarily long loops.
I have done none of those things. The only personal point I made was about Dev's competence, which is, of course supremely relevant, and I'm hardly the first in this thread to question it.
You wrote one line on the actual problem:
The only reason to solve own blocks might be (and in this point i agree with you) to tamper with the consensus itself.
This is the problem. Focus on this.
Quote
But also regarding the consensus: I am sure that this will be very well thought of ... I am very confident that it will do no harm to the system, if someone solves his own blocks.
Why are you "sure"? Why are you "very confident"? What grounds has Dev given us to have faith in his ability to deliver what he is promising?
And, just to be clear, it's not a problem if a miner solves some of his own blocks. It's a problem if a miner solves blocks (whether his own or someone else's) faster than the rest of the network put together. Solving his own blocks is just a means to that end.
Quote
I think these are other design questions such as "are the proof-of-work ledger and the transaction ledger one or two chains"? "When is a transaction expected to be confirmed"? "Do miners decide about the inclusion of transactions in their blocks or is there some other, more fancy, maybe deterministic confirmation methodology?". It has nothing to do with the fact, that some functions can be solved easier and some not.[
The concerns I am raising go way beyond mere "design questions". Some of the promises in the white paper are mathematically impossible, for example: a Turing-complete language which does not allow arbitrarily long loops.
Quote
I wish you could discuss on a more professional level instead of shouting "SPAM" peppered with a bit of "mimimi" and "I am the greatest". 
I have done none of those things. The only personal point I made was about Dev's competence, which is, of course supremely relevant, and I'm hardly the first in this thread to question it.
Getting such things done properly is one major aspect when developing a coin.
In this case, where the proof of work functions are provided externally, it is far from trivial.
But if it could be done easily, someone would have already done it before.
Thank you for pointing the discussion in that direction. We are well aware of the possible attack vectors and we already worked out how to conquer them.
I will make sure the white paper gets extended by a "possible attacks" chapter to eliminate concerns regarding exactly that.
To clarify: the security of the transaction ledger in Elastic Coin will be mathematically provable. We are not fixing several isolated attack vectors here, we make it rock solid.
Expect the new version of the whitepaper anytime soon.
In this case, where the proof of work functions are provided externally, it is far from trivial.
But if it could be done easily, someone would have already done it before.
Thank you for pointing the discussion in that direction. We are well aware of the possible attack vectors and we already worked out how to conquer them.
I will make sure the white paper gets extended by a "possible attacks" chapter to eliminate concerns regarding exactly that.
To clarify: the security of the transaction ledger in Elastic Coin will be mathematically provable. We are not fixing several isolated attack vectors here, we make it rock solid.
Expect the new version of the whitepaper anytime soon.
Thanks for the update
And mine is that you don't even know what PoW is for.
blah blah blah
Oh have it your own way. Invest in this coin if you want to; it's no skin off my nose. I'll leave my remarks up to be evaluated by people who do understand what PoW is for.
And my conclusion: Dazza did not read the white paper with the proper concentration.
And mine is that you don't even know what PoW is for.
Even if the outputs are not constant suppose there is a particular value or values of Outputs which are produced relatively often. Call this value (or these values) C (or C1, C2, C3,...) An attacker could compute SHA256(Inputs,C,PK) or SHA256(Inputs,C1,PK), SHA256(Inputs,C2,PK), SHA256(Inputs,C3,PK)... until he finds a hash < r and only then does he run to program to see if it does in fact produce the desired output for that imput.
And why is that bad? Its good when miners find such similarities/biases and get the work packages worked off quicker. Or do I miss something? Actually this scheme as you describe would also cause the miners to miss the "bounty payments" which are then credited back to the originator. Nobody would have the incentive to act this way.They would if it gave them a much better chance (or in practice the only chance) of winning the block. The scheme I outlined is not a clever way for a miner to do the work more quickly. It's a way for a miner to avoid doing the work at all.
OK, these attacks are trivial to defeat. Here's a harder one: The attacker submits a program implementing some algorithm to solve a particular problem. The attacker, however knows a faster algorithm, and computes the outputs that way.
And what does he win? If he mines using the "faster algorithm", he get's rewarded the coins he initially spent to get his work done?
Exactly, so this is essentially cost free for him.
Quote
What is the point of acting this way
He almost certainly wins the block. And the next. And the next. And the next. You've heard of the 51% attack? This is the 99% attack.
Do you have any previous work to back up your ability to take on this massive task?
I've read the white paper. My conclusion: Dev is not competent to design a cryptocurrancy. There are so many ways to attack this thing, some of which are trivial to fix, others are harder. For example, as the white paper notes, the results of user supplied programs as typically skewed, with some output values, or combination of output values, much more likely than others. He proposes to find SHA256(Inputs,Outputs,PK) < r for some adjustable r.
The limiting case is when the outputs are the same irrespective of inputs. In this case the computation is SHA256(Inputs,Constant,PK) and the attacker doesn't need to run the program at all. So much for your "proof of work"!
Even if the outputs are not constant suppose there is a particular value or values of Outputs which are produced relatively often. Call this value (or these values) C (or C1, C2, C3,...) An attacker could compute SHA256(Inputs,C,PK) or SHA256(Inputs,C1,PK), SHA256(Inputs,C2,PK), SHA256(Inputs,C3,PK)... until he finds a hash < r and only then does he run to program to see if it does in fact produce the desired output for that imput.
OK, these attacks are trivial to defeat. Here's a harder one: The attacker submits a program implementing some algorithm to solve a particular problem. The attacker, however knows a faster algorithm, and computes the outputs that way.
The limiting case is when the outputs are the same irrespective of inputs. In this case the computation is SHA256(Inputs,Constant,PK) and the attacker doesn't need to run the program at all. So much for your "proof of work"!
Even if the outputs are not constant suppose there is a particular value or values of Outputs which are produced relatively often. Call this value (or these values) C (or C1, C2, C3,...) An attacker could compute SHA256(Inputs,C,PK) or SHA256(Inputs,C1,PK), SHA256(Inputs,C2,PK), SHA256(Inputs,C3,PK)... until he finds a hash < r and only then does he run to program to see if it does in fact produce the desired output for that imput.
OK, these attacks are trivial to defeat. Here's a harder one: The attacker submits a program implementing some algorithm to solve a particular problem. The attacker, however knows a faster algorithm, and computes the outputs that way.
escrow - no more trust
What are you talking about, let me give you an example. SebastianJu run many escrows, including StepsCoin!
There were many ico's that did not even delivered a wallet, with Sebastian he made sure there is a working wallet and all coins distributed before btc released.
Surely that is enough security. Dev if you interested in using Sebastian please send me a pm and I will forward the detail to you.
escrow - no more trust
Jump to: