On average per capita, sure, but it evens out the distribution of money, which does lead to a more vibrant economy with more opportunities for innovation.

maaku, is this parallel to developing a blockchain for trading computation, or is this your main project, now?

I had an idea for doing this a few months ago.  I've come up with a few improvements and hope to start working on an implementation soon.

You'll need to understand some more of the technical details of bitcoin's operation before you can think clearly about this.  The seminal bitcoin paper (google for "satoshi nakamoto paper") is a good start.  Many of the things you propose would be hard to implement in a bitcoin-style framework.

As for your question about how to create one, someone will have to implement it in software, someone will have to market it, someone will have to develop user-friendly tools for manipulating and tracking it.  You've got your work cut out for you.

 

Thanks for the suggestion.  In the case of  gmaxwell's function, when the network checks the result it's still going to run a huge number of SHA256 calculations that the attacker doesn't need to compute, so as far as the network is concerned any contribution from the hacker is going to look bona fide.  Of course  for gmaxwell's function the optimization is so easy there are probably compilers which would find it, but it's also easy to make much more cryptic (even cryptographically unidentifiable) optimizations.

It is possible to force the attacker to do the calculation as advertised by incorporating oblivious hashing into the hash function, but that  would slow things down even more than devoting every second block to a default hash function.

If you want the proof of work to involve a fixed algorithm, it seems doable.  It is not my central focus, but I describe a way of doing this in the white paper that link of Stephen Gornick's is discussing, and another participant on this forum has stated that he's building a business around a framework for such blockchains.  Based on my current understanding, the main problem is ensuring simultaneous consistency and efficiency of calculations across platforms. 

Yes, such a scheme unavoidably requires trust in the mintettes.  Laurie makes this clear in his paper.

I'm looking for a centralized authentication system with flexible federation/syndication, because I think it should be possible to arrange things so that the authenticators could only cheat effectively by colluding on a large scale, and such an arrangement would increase the system's trustworthiness and robustness.  I don't have a clear picture of it, yet, but it may not need a secondary blockchain like you're assuming.

 Thanks, I'd appreciate that.

Yes, I should change MCMC in the abstract to straight Monte Carlo.

 
This gets into questions of marketability which I find really hard to think clearly about, but you're not the only person to express concern about the inefficiency compared to bare metal.  It probably needs to be addressed.

For the defense against the "optimization attack" the only speed tradeoff I can think of is centralization.  Full SolidCoin-style trusted-node verification every second block would work, at least for this aspect.  That was actually my first approach, but I was looking for a tradeoff which preserved decentralization.   Perhaps there is a way to federate the trusted nodes along the lines Ben Laurie proposed with his mintettes.  Centralization would simplify many aspects of the design, though.

For the floating-point consistency, it might be possible to make a software-f.p. "fuzzing library" which randomizes the least-significant bits from each f.p. operation across multiple runs, to check numerical stability.  Then algorithm submitters would be responsible for using the fuzzer to ensure that their numerical calculations are stable to, say, 20 significant bits, and the f.p. values used in the hash could be rounded accordingly.  All results reported to the network would still be checked using software f.p., but the bulk of the computation could be bare-metal.  To prevent a "pessimization attack" via posing an numerically unstable algorithm which causes most bare-metal results to fail the software-f.p. check, the default miner could compare results generated by the fuzzer library every hundred iterations or so, and get a prize for reporting an example of numerical instability to the network.  Such reports would trigger miners to fail over to the default hashing algorithm for that block.  But requiring this of submitters would be a significant useability setback. (Edit:  On the other hand, this will probably make William Kahan happy.)

I didn't mention this in the paper, but the plan there is to allocate a sizeable chunk of memory at the start of the run, and tell malloc to assign all memory from that chunk.  (Needed to think about this anyway because an earlier iteration used only the seccomp sandbox, and that would not allow mmap.)

Looking forward to it!

Thanks, gmaxwell.  This is  exactly the kind of feedback I was hoping for.

 You're right could  only be used to find approximate modes in the parameter space.  Actual inference would have to be a subsequent MCMC involving sampling around these nodes.  I mention this footnote 3 on page 5, but obviously I need to clarify it.

At least with the current proposal, NooShares can only be used to purchase batch processing which will run several hours from now.

 The idea is that there are a lot of fallow computational resources out there.  Even if you only get access to 1/8th of their potential computing power, it's a huge win over doing nothing with them.  But certainly a market for computational resources of the same size but with more efficient computation would have a huge advantage, so these inefficiencies are a weakness...

You're right, I should be more explicit in section 2.2.3 that massive speedups in computation would actually be easy to engineer.

 Could you explain the economic advantages of this attack in more detail, please?  It is certainly economically deleterious for the blockchain as a whole, but it also seems deleterious for the attacker, in that with the current price/reward structure, they lose at least 5 NooShares per block (probably 10.)  

You could keep the last 5NS from them by requiring the report to occur in a block secured by the standard proof of work.  (I designed the pricing/reward structure specifically with this attack in mind, and should probably be explicit about that in section 2.4.)

 I don't think the economics are that clear, because this is a potential use for currently fallow resources.  It's not clear to me that the only participants would be people with distributed computing needs.  For instance, I have all the computrons I need at work, but I also have a machine at home running litecoin which I would be happy to turn over to this.  Obviously I'm biased, though.

No, your feedback has been incredibly useful.  Even if the  attack you describe is unsustainable, I hadn't previously thought of requiring the best-result reports to occur in the standard blocks, so it's been useful to discuss.  And if the NooShare idea is dead in the water, I want to know now, not after pouring hundreds of hours into implementing it, so I am grateful to learn of any possible flaws in it.  I'm also concerned about the potential useability/marketability of the system (see http://news.ycombinator.com/item?id=3609991), so I am glad to hear that you would be excited about using it.

It's fixed-price, first come, first served (modulo the random scheduling.)  I never thought of varying the price based on demand.  Interesting idea! 

Edit: The way I have been imagining it, "effective price" will be shaped by the exchange rate of nooshare vs other currencies.  I think this affords all the benefits you could get from varying the price within nooshare itself.

Thanks for your interest.  Just to make sure we're on the same page, T_A is like a bitcoin transaction with an input of at least 65 units (bitcoins/nooshares) and no explicit outputs.  Essentially, the nooshares used to purchase the computation are destroyed temporarily, but some are later redistributed.  So I'm interpreting your question as "what if no computation has been scheduled for some block?"  Please let me know if I've misunderstood or my answer isn't clear.  The answer is that I haven't decided yet.  The default computation ("curly A" in the paper's notation) would work.  Some publically interesting computation like a protein folding problem or searching for Fermat primes might also make sense. 

Thanks to the moderators for moving this out of the newbie jail!

The big question to me is why hide?

Well, we're at your predicted floor today.  It will be interesting to see how it goes.

It's actually worse than that.  A decent trading bot is going to require fairly clever numerical and statistical analysis.  Another way to look at it: if I could make a such a bot, why would I share it with you for two cards when I could make money with it directly myself?

  I'm fascinated by it.  It's definitely a new thing under the sun.  There are some libertarian ideas which appeal to me, and bitcoin aligns with them nicely.

Copying from the other post I made: 

Hi, everyone.  In my spare time, I've been thinking about ways to incorporate arbitrary computation into the proof of work for a bitcoin-like blockchain-based cryptocurrency.  You can read about the design I've come up with here (click on the "Download" link in the top right-hand corner to view the PDF locally.)  

I've given serious thought to this problem, but I am by no means an expert on any aspect of it, and I welcome all critical feedback on all aspects of my proposal.  In this thread I am mostly hoping for conversation about the flaws in the protocol I've described.  (E.g., I welcome conversation about security flaws or potentially perverse incentives created by the economic model I've proposed, I'm less interested in conversation about how the proof of work in bitcoin is already useful, or about David Graeber's ideas.)