Topic: Relaunched Completely - page 2. (Read 11514 times)

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.

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.

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

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.

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

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.

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.

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

22.39 BTC funded now
37 buyers

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.

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

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?

+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.

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.

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

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.

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.

When is the IPO going to end?

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?