Bitcoin Forum

Relaunched Completely

Looks interesting. Reading

Setting aside the risks involved in a non-escrowed crowdsale...

150,000 transactions per second is a BIG checkmark.

More interesting to me is the notion that you can submit any kind of processing work you want to the Elastic Coin blockchain, for its "miners" to computationally solve. So rather than ONLY grinding the same make-work algo for bitcoinlike proof-of-work cryptocurrencies, miners can work on unique submitted tasks whose solved output has value beyond a blockchain reward.

The interesting part of this is its potential interplay with Ethereum for large projects.

Gonna Google you, Lionel. What other stuff have you coded and worked on?

Lol, so people will get 800ELC for 1 BTC? So 1ELC costs 0.00125BTC? And the supply could be around 5M? Even Decred is cheaper right now, considering supply and price :) Your coin looks interesting, but seems a little bit expensive :)

OK, thanks for your answer and good luck with your project :) Maybe i will buy some ELC later :)

Good to see over 6BTC of investment already.

So will the ELC PoW be set to a default, like Bitcoin mining, if nobody has currently submitted custom work for it to do?

Will the custom work be made public, or hidden, or optionally either? I foresee problems regarding co-opting a big computational network to do secret password brute-forcing. There's lots of potential for bad actors to use the network for evil, if the ELC network's computational power goes to the highest bidder.

Will it be ok if we send BTC from online wallets?

From the website:

Phone: (000) 555 1212
Mobile: (000) 555 0100
Fax: (000) 555 0101

123 Some Street
Some City
AA 12345

At least use a free escrow available on this forum ;D

There is no reason for not using escrow, good luck with your project ;D

Very interesting project.. But honestly I would suggest getting an escrow involved.

I think is a good project...  More info? AirDrop? Time to Start mining? Official ANN?  More and more SPEC? algo? Thanks to all and good Luck Dev  ;)

Correct me if I'm wrong, as I have been out of the crypto game for a while, but with a non-escrowed ICO, couldn't a dev:

Take whatever money sent in, buy his own coins in the ICO using that money, and end up with both the coins + money in the end? It was one of the reasons why everyone cried 'scam' ages ago when ICOs starting rolling around.

I have been thinking about a similar idea, but I failed to solve a certain mathematical issue. Now I'm wondering how you tackle that. Your paper doesn't seem to be so much technical and in github there doesn't seem to be a ledger. In bitcoin mining, a miner wants to find certain data such that sha(data) has a certain number of leading zeros. Now, suppose a miner finds such and tries to get that into the blockchain. Another miner may steal that and say "Hey, I found data and sha(data) has leading zeros". That doesn't work for bitcoin however, because the address that the mined coins are sent to is part of data. If the stealing miner now creates a data2 which is equal to data but with a different address, then sha(data2) generally does not have the leading zeros, so this won't work and the second miner can't steal.

This does not work for user-defined proof-of-work. My question is: How can a miner generate proof of work for a custom question, without another miner stealing that proof of work?

I have another concern. If I understand correctly, the miners execute Python code to solve computational questions. However especially for high-performance computing, this coin may be beat by a coin that does the same with C (which is quicker). What do you think about that?

Yep, except if the dev doesn't think all coins will be sold, or thinks at some point after the ICO the coin valuation will go much higher, then buying his own coins could make sense. I don't mean a dev would use all of his ICO to buy all of his or her own coin. But I expect many devs have taken a decent chunk for themselves... which then equates to the same situation as a large premine.

In that type of case, it's not necessarily better to sell ALL coins during the ICO. They just need to sell enough to bring in a nice chunk of BTC, while at the same time set aside a little nestegg of their own coin for selling at a later date.

There is another benefit for the dev buying his own coins too ... fake volume. "Hey, 50 BTC has already been invested, Yay, I want to invest too" ... now if an ICO is failing, a dev can buy his own coin to make it look like others are buying it, luring in new investors.

And this does apply to all ICOs, but the issue with non-escrow is that the dev doesn't even have to use his own money to manipulate things.

As for the first point, yep. I even said it can occur with regular ICOs. The only difference is that it's a lot easier to do with non-escrowed, as then it doesn't even require upfront money.

As for people being so foolish... greed trumps logic sometimes.  And regarding who owns the other coins, it can matter. You don't want one person or a small group owning a disproportionate amount of coins (at least ideally). Dev dumps, coin dies, money is lost. It's just riskier.

I'm not saying this ICO is a scam -- those who go around yelling scam everywhere is silly in my opinion. By their own definition of a scam, every single crypto in existence would qualify. I'm just saying that non-escrow is a red flag, and really, I see no reason not to use escrow. Yes, the dev says he needs money immediately to hire other devs and so on, but is anyone in that big a rush? So development gets delayed until the ICO is over? It just seems odd to me.

Yep, but again, it just strikes me a bit odd. There are some devs working on it currently (unpaid), I believe, right? Or maybe I misread something.

With so many shady things that happen here, it just feels risky to see an ICO without escrow nowadays.

I'd think they'd take in a lot more money if using escrow, even if he's perfectly on the level, just to assuage some fears people may have. I realize people can wait and get their coins after seeing the finished product ... but it also means the dev could have done the 'Re-use invested money to buy up coins for himself' game if he wanted to. If he holds, no problem down the line... just so many devs dump and run here, so it adds a bit of risk.

So my question is, if a dev could take in more btc by using escrow, even if it delays development somewhat over a couple of months, why wouldn't he do so?

Interesting project, i'll try my luck at this coin.

Yeah, if a dev has enough BTC onhand, he can do the same thing. But of course it's easier if the dev doesn't have to use his own money. The risk is with shady, poor devs who want a quick buck. Not saying that is the case here, just speaking in generalities.

As for dumping, well, any dumping isn't so good obviously. The risk is with devs who cut and run (and as we all know, that has happened here many, many times). The main difference is if a lot of investors dump, the dev may still be around to develop and promote the coin, usually keeping the price semi-stable and over time the coin may recover. If a dev dumps, all is lost.

And as for the perfect way to do an ICO... beats me. I don't think there is a perfect way. I have no problem when devs profit (as why not, they are doing work)... it's just when the risks add up, I become wary.

The way to run a decent scam -- goes into evil dev mode -- would be to use non-escrow, take in some btc, use some of that btc to buy your own coin, bring ICO volume up, hype coin, bring in more btc, collect generous portion of that... keep using free help (or code yourself), say you are hiring devs ... promise wonderful things .... once price/volume is up, sell your freebie coins and cut and run. It cost nothing at all to even do this, a dev could have zero btc to start and manage it.

It's a lot easier to come up with ways to scam than foolproof ways to run an ICO.

My point was, if not using escrow, the shady poor devs are the ones to worry about. If using escrow, then you can worry about the shady rich ones. It's just easier if a dev wanted to scam to not use escrow.

And yes, using an escrow doesn't necessarily mean all is well. Dev can still run away (although at least they have restricted funds until dev delivers coin + wallet). And then they run away...

I find it a lot safer in the crypto scene if you look at things from a somewhat jaded perspective. A dev nowadays runs an ICO without escrow and it's a red flag to me. It could be unwarranted, just my 'risk meter' going off.

My question is, if you can sell all of 5,000,000 you can get 6,250BTC or more but at the end if you just get 10BTC (assumed), do you still run or cancel your project?

Why is 150,000 tps necessary?

Visa tops out at 56,000 and never uses it, Paypal is in the hundreds per second.

What's with the weird domain name registration for elastic.pro ?

Thanks for your reply. I believe that investors need escrow!

But if investors wait until the product is finished, they pay double for the coin, correct?

Is it possible to rent the ElastiCoin network to do advanced 3D-rendering tasks?

Okay, thanks. That is the main part that concerns me. Although I do agree those who enter earliest deserve the higher reward (most escrowed ICOs just do a little bonus at that stage), I expect others can see how this potentially could be a red flag when a coin doesn't use escrow. Although I won't harp on ICO details as the dev asked us not to (although since this is an ICO thread, I personally see no issues with discussing ICO terms) -- it is an incentive for a dev to do the 'buy his own coins using donated btc' game before the coin hits viable product stage.

Nobody cares about how much ELC one gets as long  as it is not clear how much ELC will be on the market. The only number that counts is your percentual share of the total. So, to use your words, ELC pre-sale is still gambling.

If I expect 5 million coins, I'd see it will be initially valued with at least 2.5m$ (even more if some buys are made after btc block 400k). That's absolutely insane for a new unknown coin.
To make money as initial investor the intial mc must be far below. As I don't know how it will end, I have to gamble about the final numbers.

Hope you get the idea...

This depends on 2 factors: technical innovation and brand awareness. The first one doesn't  weight much for the initial value as we have seen over and over again. The brand awareness, however, makes up nearly everything for the initial valuation.
Since Elastic Coin hasn't got much/any public awareness, I'd see an initial market cap of max 250k$ as a fair entry point.

Disclaimer: this is only my personal general view about investments in new coins. Hope you feel not offended about the high difference.

:D Just right in the moment before I posted this number you got it yourself :)

I guess it's a wise decision and will attract more potential investors.


Whish you all the best!

@ElasticCoin

Do you need german translation  (payment in ElasticCoins) ?

best regards

I think the concerns that poornamelessme has brought up are of the utmost importance. With access to the BTC before the IPO is over you are able not only to buy a portion of the IPO funds for free (as with an escrowed IPO), but can use the same funds to do this several times, for instance under the pretense of "hiring devs". You say that not everyone around here is a bad person, but the fact remains that about 98% of IPOs conducted here have been outright scams. In an ideal world the concerns raised would be sticked in big bold writing at the top of every IPO thread.

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.

^^ this
and i got scared when they said "prime number" thing, made me think is this the next cube? i smell a spot somewhere haha.
anyways watching, won't be investing in a newbie account with no escrow but hey good luck! i may get in once hit exchange!

I'm not against crowdfunding per se, but crowdfunding without escrow with an (for the moment at least) unknown dev who's possibly using a pseudonym gives me pretty serious pause for thought. So if you could put up those CVs and pics I'd personally be very grateful. If you could do it before the IPO reward drops that would be good too, as it doesn't seem fair that there should be greater rewards for the people reckless enough to invest in this at the very start when that information isn't publicly available.

1: Why no escrow
2: Spend my money and have to wait almost 1/2 yr is "frightening"

Actually no.

The issue is that early investors get up to twice the value of the coin than later investors. So by waiting until the product is out and working they are already at a major disadvantage. Then add in the fact that if you were scamming people (not by not releasing the coin, but buying in on your own coin using donated btc instead of hiring devs), you would have done so early most likely.

So if going into evil dev mode, you take early donations, and since there is no escrow you buy-in on your own coin using that btc, and by the time the product is released you have both the original btc plus the elc worth double (ish) the initial rate.

Yep, although if going that route, it'd make more sense to use proper escrow.

As for early investors gaining greater rewards, I am fine with it. Usually it's not like double the rate, however, and it does add an extra red flag when not using escrow.

Initially, is it possible to put those funds to a trusted escrow in order to build more trust?

I may be in the minority here, but if the dev is willing to not touch the funds until a certain date, I see no logical reason not to use a trusted escrow instead.

The idea is to use a trusted escrow... not some dubious form of escrow. I trust exchange escrows more than most devs (and that is saying something after the Cryptsy debacle). But yeah, if escrow runs away, coin is totaled. And if dev runs away, coin is totaled. Guess it depends who you trust more, a form of trusted escrow or a dev with a newbie account.

Waiting is the safest way to go without some form of escrow. The issue then is that investors are paying around double the rate for the coin compared to earlier investors. I do agree that early investors should get greater rewards, but double is a bit much, at least compared to most other ICOs. So it's safe in regard to scam potential (well, safer, anyway), but not exactly the best way to invest in an ICO. One almost might as well just wait until the coin hits the exchange at that point.

I recall ICO coins on Polo that did the two tiered ICO thing (early investors got coin for half the cost of 2nd tier level)... and then when the coin was active for trading, pretty much everyone who bought early dumped  for around double the profit.  And I don't mean 2x the profit of 2nd tier guys, I mean 2x what they invested... they eventually sold below 2nd tier ICO levels and still made a nice profit. That is the issue with double the rate for early investors, they can sell when the coin hits the exchange way below testnet ICO levels, driving the price down. And why waiting, although safest, may not make sense investment-wise.

Anyway, I will drop the issue and just keep an eye out on the coin. Apologies if it seemed like I was harping on things; only reason I did so was because I was considering investing in the coin.

Either I misunderstood your reply (or you misunderstood my question) when I asked earlier about how the ICO pricing works. I assumed by the time the product was ready the coin would be double-ish the cost. If not, then yeah, it could work out.

As for dumping coins, right now, nope, nobody has really invested, so it doesn't matter. A lot of time left and it's probably safe to assume there will be a lot more than 11 btc invested before the reward lowers.

And I don't see evil, just seeing things through jaded, crypto eyes. Again, will drop it, and just watch how things go.

Thanks we are ElasticMiner :)

following!  ;D

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.

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.

Do you have any previous work to back up your ability to take on this massive task?

And mine is that you don't even know what PoW is for.


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.


Exactly, so this is essentially cost free for him.


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.

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.

Thanks for the update

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.

really cool idea with this kind of proof of work

That would include the white paper itself, no?.


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.


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.

I made four comments and you're calling me a professional spammer?  Now who's FUDding?

I do beg your pardon.  I was unaware that these threads were only for uncritical fanboys.


Not enough to get a 154 point activity score.

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.

Hi guys, minimun amount to invest is 1 btc?

^ in case you missed it

ok thanks, but if i want buy like 0.01 every day there no problem to do it?

ok thanks, i´m IN good luck to everyone.  ;)

You've avoided responding to this twice now. Do you intend to put those profiles of the core development team up as stated?

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

P.S. I have already started investing some btc but most of my btc is tied up momentarily. I am serious about contributing too.

gtfo

new ACCOUNT made just to show "how invested you are, and how talented you are"
but have no profile on the most popular btc forum in the world?

i smell a shill...

btw-- things like this de-credit you greatly, i am now NOT investing,
 thank god i was waiting for less days left on ipo anyways

Also curious about this. As someone who obviously has had his doubts (and will not bring them up again), at least I'd like to see profiles/info on the people behind the coin. So far, all I have seen are just a lot of red flags.

I am no shill. Had to look that up even though I guessed what it meant. But I have decided to wait until some of these concerns are dealt with. If this is a pump and dump or outright scam I am in the dark about it. I have some talents and if a few things about this project was altered properly I would jump in with them.

For instance with 150,000 transactions a second you could tout the potential use of them for future autonomous networks like D.A.C.'s This project could also easily contribute to APPS using Safe and Ether with it simultaneously. If you polished up your crowdsale presentation and gave more transparency I would be astonished if it did not sell out within a cycle of cpu.

Call this function S.E.E. Safe Elastic Ether apps

Hmm? I actually stated I was considering investing in the coin earlier, but there were issues not resolved to my liking (so I wouldn't be an early investor, but never ruled out investing later on). You can check my post history in general... I'm not a guy who just goes around spamming coins for the sake of spamming (either hype or fud/spam).

Asking for more info on the people behind the coin would hardly be called spam. If anyone gets all defensive over questions people ask in an ICO thread, I question the sincerity of both the devs and anyone supporting said coin. Nothing wrong with asking for more info about who is actually running the ICO. The fact that this info wasn't available Day One, is a red flag in my opinion ... it could just be an organizational issue... actually hope that is all it was.

It's an honour to have you here with us!

Thanks for that. It does seem like you know what you are doing there. The way you had been posting (more than Lionel even), led me to believe something like this, or that you invested most of the current ICO amount (guess it's a bit of both).

Lionel still plans to post his CV as well as the other team members though, right? I understand it can be tricky, as nobody here wants to post too much info about themselves ... but if going the ICO route, some info is needed. Usually when I invest in a coin (and expect many others do this too), it's not even necessarily about the coin ... it's about the devs.

I just made another little contribution to the crowdfund. I am not certain if this project will get much more support but I have plenty of btc (also in early)if it starts moving faster. I have a little extra time to invest for free too if I see anything I can do. I do not have the repertoire as some others but I can develop skills. I think the lack of transparency is temporary oversight. But I will not go too deep in until it is worked on.
Sincerely,
Daniel Ray Waters Hazelton Ortiz (yes my legal name for real)

ICOs are fun ;)

I agree with poornamelessme. The main reason why I'm not investing so far is not because the code is not fully developed but because Lionel has not given his CV.

Looks interesting, I hope you get the updated whitepaper out before the reward reduces too much because if you can show that the 51% attack concerns are unfounded then I'll definitely want in on this.

Looks interesting.

I assume you're talking about the attack I outlined above.

I suggest we call it the "faster algorithm" attack or somesuch.  The effect of the attack is the same as the 51% attack in that it could allow the attacker to take control of the consensus and effect double-spends, and other assorted nastiness.  But the computational resources required by the attacker are very modest indeed, much less than 51%.

I just invested 1btc

https://blockchain.info/tx-index/df71cd7e97c66a899db7f7c66965856323c4b9fdf801eea2fa9b629a2dd47770

project has promise...he who dares wins :)

How do you decide which computation request gets priority? In the order they are submitted?

Awesome, hope it doesn't completely take over your weekend, lol.


If I have to refer to it again that's what I'll call it then. Glad you're sticking around, I'll be interested to read how it works in more detail myself but I'd be more convinced that there's no problem if I know there is someone who seems to know what they are talking about trying to poke holes in it.

I'll watch this :)

leave a mark here.   




don't let me down. i will be back.

I have a dumb question about the crowdsale: the description says there will be an import tool to swipe your ELC from your wallet.dat; if I send coins from an address which doesn't have a wallet.dat but which I have the keys for, I presume I will be able to fairly easily import from just the private key?

Thanks, that's what I thought but I just wanted to check to make sure I wasn't going to be making life unnecessarily difficult for myself

Just a suggestion:  Why not let each miner decide for himself, out of the submitted user programs, which one he works on?

Honest, financially-motivated miners will work on whichever seems to them to be the most lucrative.  Honest, altruistic miners might choose to work on projects they deem to be more socially valuable, or which they just find more interesting.  Attackers will find a way to work on their own programs if that's what their attack needs, no matter how you arrange the work to be chosen, so your defenses against such attacks must not rely upon attackers never running their own programs.

I have a question of my own.  Is there a limit to the execution time for a program run?  For example, suppose the desired time between blocks is ten minutes.  Does the program need to finish within that time, in order to make its output available to be hashed?

When is the IPO going to end?

I believe I have a solution to the faster algorithm attack.

Specifically believe I have a modification of your PoW function such that the faster algorithm attack can achieve at best a linear speedup for the attacker.  I believe I can provide a security proof of this fact.  Moreover in any practical implementation it should be possible to determine and indeed control the multiplier.

Finally my construction works even if you don't cripple the language.  Arbitrary loops are allowed, as are programs which never halt.  You just abort them if they run too long; the PoW still works.

There is a price to pay for this: It's computationally expensive.

I withdraw the above.

It's funny.  I've been thinking about this stuff in general terms for the past couple of days.  I've had this specific construction in mind for the past day or so.  Then within a few minutes of publicly committing myself, I see a flaw in my reasoning.

Damn this stuff is hard.  I will think about it some more.

looking forward to reading the white paper, keep on trucking fellas. Will you launch a second ICO later on?

Lol, I often get a similar thing when I'm writing, I turn it over in my head for ages and its not till I write it down that I realize my mistake.

I've even been thinking about this myself, which is stupid since I'm not a programmer but its still interesting to think about - looking forward to seeing how they solve it. My only solution was to force a certain percentage of the blocks to be solved from a specified sub-set of problems, like PoW from another coin, so that any attack cannot win enough blocks to control the consensus.

+1


I've received no contact and I don't know why questions like this shouldn't be discussed publicly. The premise of Elastic Coin seemed interesting but I had misgivings about the non-escrowed ICO. Based on the suspicious behaviour of another forum member in this thread I actually have more now. Again, if you want to get the maximum amount of funding for this you will need to reveal some information about yourself publicly Lionel.

It looks like a really cool project but I don't really know what all the computation power will be used for, why would a regular person want to use this?

Also it turns into an effectively any algo possible to cheaper than now mine any crypto coin any person so desires on a singular level

I have few questions:
- elastic.pro points to 0 BTC funded yet, is that correct?
- Is there any available information beside the name about the main dev?
- can you estimate how much time have we got left until BTC block 400000 will be mined?

Thank you for the responses.

22.39 BTC funded now
37 buyers

I admit I am a little confused here.

Lionel started the ICO, said he had some devs working on the project... then a short while later someone in the forums (you), who invested, all of a sudden becomes the main dev on the project? What was Lionel planning to do if he didn't find someone to help out here?

You do seem to be qualified (at least tech/experience-wise, not sure about coding-wise), but it just seems like a weird ICO setup. There are definitely things that could have been done early on to maximize investment in the project -- I won't go into the escrow issue again, but how about some background info on the other team members, including Lionel?

I took part in several Poloniex ICOs (and a couple were really profitable), a couple of small-scale non-exchange ones (and even 1-2 without escrow), and you probably notice my signature is another ICO coin.

I'm fine with ICOs and have taken part in probably half a dozen or so of them. That's why I have asked questions here and pointed out some odd things ... usually the best run ICOs aren't managed like things have been here. If the fellow running the ICO states he will post his CV, for instance, it's sort of nice if he actually does ... and provides info on who is doing the coding, his other devs, past experience and so on. It's also a valid question to ask what Lionel planned to do if you didn't come aboard, or how he planned things out. And it'd be nice for a change if he answered questions about his own coin.

I completely agree with this. If Lionel makes himself known like how most developers make themselves known in a successful IPO, he will get a lot more funding.

Funding is not the main concern here. 23 bitcoins could finish this project using a p2p automated sofware creation service eventually I really believe. There is codevalley coming soon for instance. With Evil-Knievel redoing the white paper among other things it may begin to look a lot more appealing to potential investors. I see the current rate of funding as improving to the point of selling out before it ends.
I decided to invest a few more btc just in case it increases my computational wealth. I don't need to own a whole percentage though I may change my mind.

You don't need to know in advance how long it will run.

The buyer commits a number of ELC, and specifies how much he will pay the winning miner for each block solved while running his program, and what bounties he will pay for what results.  This is written into the blockchain.  Once committed, the network won't let him spend those coins in any other way, until the offer terminates or is withdrawn (Edit: by which I mean the buyer withdraws the offer.  There should be a short time before the withdrawal becomes effective, in order to allow the miners to notice the withdrawal and stop work).  It is then up to each miner to decide for himself if he accepts the deal or not.  There's no need for him to notify the buyer of his acceptance (Edit: or anyone else, until he actually solves a block). He just starts running the program.  The network confirms each block in the usual way and pays the winning miner out of the committed funds.  Similarly the network confirms the bounties, and pays the solving miners.  When the funds are exhausted, or when the offer terminates or is withdrawn, then the miners will abandon work on that program and run another.  Any ELC left over are returned to the buyer.


It runs indefinitely until the funds are exhausted, at which point the miners say "thank you and goodbye".  There is no attack here.


It's not required with my scheme.  A user-supplied program could run for hours or days, while generating proof of work blocks every ten minutes on average (or whatever other period is specified)..


With these limitations, you are foreclosing on one particular application which is ideal for the kind of distributed network which we are talking about.  Iinteger factorisation using the Elliptic Curve Method (ECM), uses the mathematics behind elliptic curve cryptography, but to a different purpose.  ECM is currently the fastest known algorithm for finding factors larger than about 20 decimal digits, and smaller than about one-third of the number of digits of the number to be factored.  (For factors larger than one-third of the length, sieving algorithms are better.  Don't even think of trying to use ECM to factor an RSA modulus.)

With ECM, the payload would be the target integer, a depth parameter B1, and possibly a few other switches and parameters.  The algorithm takes a random parameter s which defines the specific elliptic curve.  This would be the random input supplied by the miners.

For each s, the algorithm has a small chance of finding a factor.  The usual process given a target whose factor lengths are unknown is to start with a modest B1, run a few curves.  If no factor is found, increase B1 and run more curves, and so on.  Here (http://www.loria.fr/~zimmerma/records/ecm/params.html) is a list of recommended B1 levels, and the corresponding recommended number of curves to run.

Currently I am trying to factor a 187 digit number.  By my own efforts, I have reached the B1=110,000,000 level, and each curve is taking about eight minutes to run using GMP-ECM (http://ecm.gforge.inria.fr/).  A python implementation would surely be slower, and of course there will certainly be some computational overhead associated with the Elastic Coin infrastructure.

Just as I reach the point where I think a cluster would be useful, are you seriously telling me that the cluster you're building can't hack it?

Every 10 milliseconds would be better.  Bitcoin generates a new block every ten minutes on average, but individual miners produce millions of hashes per second.


It's a tradeoff.  The greater the hashrate, the greater the computational overhead, and the less useful work that gets done.  On the other hand, the longer between hashes the longer the confirmation overhead, so again there is a computational overhead.

There will be a sweet-spot, which will probably have to be found by experimentation, and which may depend upon different miner's hardware.  It will have to be a tunable (and if necessary, a retunable) parameter.


That won't work because it's not machine independent.  You're on the right track though.

Is there any consideration for protection against quantum computation? If not I suggest there should be it may not be too long from now.

Lionel's original white paper had another vulnerability which I haven't discussed in this thread because it was only theoretical - the computational resources needed to exploit it would have been enormous.  A quantum computer might possibly have bust it wide open.  The vulnerability is easier to fix than it is to explain.

The rule of thumb I use is that QC effectively halves the sizes of the crypto primitives you're using, so SHA-256 will be as strong as a 128-bit hash is now, which should be good for a long time, if not forever.  RIPEMD-160, used to turn ECDSA public keys into bitcoin addresses, looks very vulnerable.  I don't honestly know whether the ECDSA keys are big enough to resist QC.  I do know that only last year the NSA recommended moving away from elliptic curve cryptosystems which include ECDSA, or at least not migrating to them, in anticipation of QC.  Make of that what you will, this is the NSA, after all.

IMO it is a good design decision to make the keys compatible with bitcoin.  There will be plenty of time for us, and for bitcoin to move to something better later.  Moreover, there is not yet a consensus among crypto experts as to what "something better" might be.

Edited to add:  I notice EK has posted a contrary opinion.  I cannot vouch for his expertise in this field.  I can only vouch for my own lack thereof.

DL is not believed to be NP-complete to my knowledge.  It is no harder than integer factorisation, for which a sub-exponential non-quantum algorithm exists.  However some NP problems (and therefore all NP-complete problems) are believed to require exponential time.

It's been a long time since I studied this, and I can't recall if NP-complete problems were proven to require exponential time (assuming P/=NP), rather than being merely assumed to do so.  If proved, then it follows that DL is provably not NP-complete.  However if it was merely a belief, then beliefs can change.

Or perhaps I'm remembering it wrong, and all that was ever said was that the only known algorithms for known NP-complete problems were exponential.  It really is a long time ago that I took that class.

It's closer to 30 years for me.

NFS is conjectured to be subexponential based upon a heuristic argument.  There is no proof, or if there is, it was discovered within the last couple of years, or I would certainly have heard about it, given the company I kept about that time.

The only thing I can say for certain is that DL is provably no harder than factorisation, because RSA is DL and, as everybody here surely knows, factorisation breaks RSA.

None of this is particularly relevant to matters at hand.  Nor is our different understanding of the effect of QC.

By "confirmation", I meant verification.


Under my scheme, they would have to do a 10ms calculation.

I'm being intentionally cagey about exactly how my scheme works for two reasons.  Firstly, if you're going to use my ideas, or even if you don't, but they stimulate ideas of your own which you do use, and if the result is a hugely successful altcoin, which I think is a possibility, and if you, Lionel, or other people end up rich (or richer, in your case) because of it, then I would like to end up rich too. And right now I'm not seeing a clear path for myself to those riches. Your offer to remit to me a few BTC was kind, but it was conditioned upon you being paid yourself, which isn't certain. I could put those BTC into the public offer, or maybe scrape together the cash to buy a few BTC of my own, but I won't invest until there's a clear plan that I can believe in.  Even then, I'd consider it a gamble, and it would be one that it would hurt to lose in a way that it wouldn't hurt someone with another 860 of them.

But even if I invested, my coins would be no better than anyone else's.  In fact they'd be worse than those who came in early on a wing and a prayer. I want to be rewarded for my ideas, not (just) my money.

But that's not my only, or even my main reason for being cagey.  I also have issues with Lionel and the whole way he's managed/ing this thing.  Before I open up fully about mine, I would like to see a clear explanation of exactly what his original idea was, and I don't want him, or you for that matter, to take my ideas and claim that this was what he intended all along.

As things stand at the moment, I don't believe he ever had a viable plan.  I don't believe his system could have worked at all.  Even if it could have, I don't believe it was secure.  I don't believe his claims that he had security proofs, or if he did, that those proofs established the real-world security of his system.  I'm not calling him a liar.  I think it's quite possible that he believed in what he was doing, but if so, then I think he was mistaken.

There is a vulnerability, which I think is unavoidable under my scheme, which is that a malicious miner could open up the program in a debugger mid-execution, and change a few variables.  So long as he doesn't do this within the 10ms interval for which he claims a block win, and as long as he doesn't claim a bounty, then his mischief will go undetected.  This doesn't compromise block security; he will still have proven that he's worked, just not in the way the buyer wanted.  The only person harmed is the buyer who doesn't get what he's paid for.  The miner has no financial incentive to do this, so as long as it's documented and buyers know that this is a risk they're taking, then I think it's OK.

If each miner decides whether to take a particular piece of work does that mean you could have miners who only take a certain kind of work?

Forgive me if I'm being ignorant, but one thing that concerned me was the idea of people doing both bitcoin PoW and other assorted work on the same machine - wouldn't that mean doing bitcoin PoW on a regular CPU/GPU, which is obviously a lot less efficient that the ASICs it would be competing against? In this scheme, for example, could you have a form of merged mining where a bitcoin miner with an ASIC took only bitcoin PoW? If there were transactions providing fees then perhaps it would even pay for the miner to submit work so there is always bitcoin PoW for him to do, so he can earn ELC transaction fees on top of the regular mining. Also then perhaps a CPU could take different work to a GPU, meaning everyone could take the jobs best suited to his mining rig?

Awesome! In addition to making sure that the cluster is efficient for solving any problem, I think this could also increase the number of people who are able to participate in mining which will probably help with adoption and getting people involved with development and stuff.

Is Lionel even following this thread, on his own coin?

I see a lot of technical discussions, which is fine and all, but none of it from the original developer of the coin.

Basically to an outsider, it looks like some guy wrote a flawed whitepaper, with no devs aboard, asked for money without escrow, and now a couple of guys in this forum (you and Knievel) have ideas on how to fix the whitepaper. Only problem is, they aren't the ones doing the ICO.

Still waiting for Lionel's CV, info on his other devs + coders, and so on. That assumes any other devs even exist, and Lionel is really Lionel.

Assuming that by "10ms" we actually mean some yet-to-be-decided deterministic metric, which proxies for that or some other interval of time.  Your idea now is to use SHA-256(StartState,EndState) over the 10ms interval as your proof of work function.  Correct?


Nope, just the old one.


Agreed, but we can't do that.  Nor do we need to, from a block security point of view.  Think of the 10ms segment as an entire user supplied program.  StartState is random input.  EndState is the corresponding output.

And it suffers from the same flaw.  An attacker might know a faster algorithm to compute EndState from StartState.

You're on the right tracks, though.  Try again.  Here's a hint, or perhaps a puzzle.  Order matters.  SHA-256(This,That) might work, while SHA-256(That, This) is trivially exploitable.

I don't know if I qualify as an outsider any more, but that's exactly what it looks like to me too.  Added to that is the tight timescale that I doubt is achievable.

I think Lionel should hand the whole project over to EK, website and funds and all.  I think he's by far the most credible person involved.  Also EK should offer to refund everyone who wants their money back, and to those who stay in, make it clear that nothing is decided, that everything is open to brainstorming.

I've actually found the way the ICO was set up quite exciting and inspiring. It seems like Lionel set out the bare bones of a great idea that may or may not be possible, and set the sliding price scale so that if you think its possible - place your bets now. If you, like EK and Dazza, have the means to make it possible, then you can make your bet come good. If you're on the fence, then you can wait and see how the ideas unfold, but you'll get a lot less for your money.

Amazingly it seems to have drawn people perfectly placed to solve the problems, if they are indeed solvable.

Where is Lionel?

Good to hear. I'm definitely going to buy into this, but I think I'll wait till block 399990 to decide how much  ;)

@EK are you actually in contact with Lionel? I am unsure about investing in this coin or not.
He is still the guy who will handle the ICO funds and it looks like he's not giving his contribute anymore to the discussion you and dazza brought in.

I would skip the "rushing" part and just come up with something rock- solid, it seems the whitepaper was rushed and now look at all the discussion that needs to take place .  Thank you Dazza and Ek.

Yeah, no point in rushing and I don't think anybody expects you to come in and then get everything planned out in a few days. In any case, it would ruin the whole nature of the ICO if we know that's its going to work before the reward starts to go down. I like the idea of it being a bit of a gamble with out-sized potential returns, and then gradually becoming a safer bet (hopefully) but with lower returns over the course of the long ICO sale.

Please don't large me up, even in your own mind, as some kind of crypto guru.  I'm not.  I'm not a crypto virtuoso.  I'm not a crypto expert, (unless your definition of "expert" is "an ex is a has-been and a spurt is a drip under pressure".)  I'm just some guy on the internet who's a little smarter than the average bear, and who's done a little reading on the subject.  What I know about it might fill a book.  What I don't know would fill a library.

And please don't let anyone assume that if we come up with something that we can't see how to attack (https://www.schneier.com/blog/archives/2011/04/schneiers_law.html), this is evidence that it is secure.

Are you suggesting that there should be two ledgers so that the person solving his own blocks only gets his own payment, not control of consensus or transaction fees?

If so then doesn't this mean that you need some other pow or pos or something to secure the payment ledger? I that case you might as well just build a distributed cloud computing system and take bitcoin as payment, but you get rid of the big benefit - one set of work, meaning one set of costs, producing two valuable results (securing the network and whatever the purpose of the work has for whoever submitted it).

Pernicious, isn't it.


I keep vacillating on that one.  If the workers aren't securing the blockchain, for example, if we move to a pure proof-of-stake system, we still need a way to prove to the buyer (or at least provide him with some assurance) that the workers are working


I still think I've solved it.  I could be wrong about that.

About five minutes ago, I wrote.


I haven't solved it, at least not in the strong form I thought I had.  Damn faster algorithm attack.

I still think I've solved it in the weaker from that I've alluded to earlier.  Specifically I believe, but cannot prove that an attacker can achieve at best a linear speedup.  The problem is, how much he can speed it up is proportional to the efficiency of the proof of work system.  If the system is split 50-50 between useful work and overhead, then the attacker can double the speed, by dispensing with running the program, and just suffering the overhead.  If it's split 67-33, he can tripple the speed.

I can force him to suffer the overhead.  I can't force him to run the program.  Damn, damn, damn, damn, damn, damn.

I think I might be confusing myself here, but I was just reading over the whitepaper and the description of partial blocks. Each partial block which meets the requirements for the 'hooks' which the author puts in place gets a reward, even though they do not actually mine the block. If these hooks were a requirement for submitting work rather than an option, and if there is a minimum requirement for the number of payouts, would that not mean that our attacker with a faster algorithm would still only recoup part of what they paid to submit their slower algorithm to the network? For example, if his faster algorithm is twice as fast, then you only need three payouts and there is already a probable cost to the attack.

It looks like you guys are still making progress on making the faster algorithm attack impossible, but if that doesn't work out then perhaps it could be made prohibitively expensive by tweaking these variables? Or at least the computational overhead necessary to secure the network may be reduced by factoring in the financial overhead associated with the attack?

This is close enough to my scheme that I may as well just spell it out.

Declare a buffer of length L.  L is a network wide (and possibly varying) parameter and is the deterministic proxy for time.  "After 10ms" means deterministically "when the buffer is full".

As each executable statement is executed, write to the buffer the statement number followed by the list of variable assignments effected by that statement.  So for example, if in the C language, statement 100 was



(I don't know if you can do that in python), and if before the statement was executed c=3 and d=4, then you would write to the buffer


And write all of this, even if b was already equal to 7, so was not changed (but could have been).  c can not have changed so doesn't need to be written.

I would argue that to write that buffer is by definition to run the program.  What does "running a program" even mean, if not to determine the sequence of changes to state defined by its statements?  If "work" means "runs the program" than I cannot think of a definition of the phrase "proof of work" that is not satisfied by writing that buffer.  Yet still an adversary could craft a program that writes the buffer in a way that he can predict using a faster algorithm.

But lets not worry about that now.  Instead, let me continue with my idea.  I claim that the buffer will be written at a more or less constant rate.  In general, statements which change more variables will also take proportionately longer to execute.  If necessary we could add padding for statements that take much longer than average to execute.

Next note that SHA-256 is a serial algorithm.  We don't even need to allocate storage for the buffer; we just pipe it straight in.  Finally, note that it is a linear-time algorithm.  Any new algorithm computing the same function can be at best a constant times faster, otherwise finding collisions becomes trivial.  This is the basis for my claim that even the most powerful faster algorithm imaginable - an oracle that fills the buffer instantly - can achieve at best a linear speed-up.

Finally let's take a look at how your idea fits into this:


This is equivalent to encrypting the buffer using the seed as a key.  I have also had this idea.  It adds overhead that the adversary cannot avoid, but no more security because the attacker knows the key.  It's like DRM when the attacker is in the box.