Topic: Relaunched Completely (Read 11514 times)

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.

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?

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.

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.

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

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, this is evidence that it is secure.

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.

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.

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

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

Where is Lionel?

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.

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.

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.

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.

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.

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?

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.

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.

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.