Quote from: tinybike on December 16, 2013, 02:24:14 AM

Suggestion: since you're incorporating mining but not using it to confirm transactions, why not just use BOINC? (http://boinc.berkeley.edu/ -- grid computing for scientific problems, cancer, AIDS, protein folding, etc.) Benefits:

1. Ripple's already doing this, with their World Community Grid "giveaway", and it seems like as good a proof of work scheme as anything else.

2. It's doing something that is obviously good and useful with your computing power. Might help you raise interest in Splash -- BOINC is useful in a much more concrete way than, say, finding long prime number chains.

3. It's easy for people to set up BOINC. It has a user-friendly interface. It runs on everything -- heck, I have it cranking away on my phone, because why not? Contrast this with, say, cgminer or cudaminer, which are a nightmare to set up the first time you do it.

That's an interesting thing to think about. I've been wrestling with the proof of work choice for a while now. (I didn't think specifically of BOINC or similar grid projects, but I thought of things like memory-hard functions over the whole ledger history - things that would be helpful if ever proof of work did move to ledger [validation] level after all.)

In the end, I'm planning at the moment to just stick with one of the two best-known "intrinsically pointless" hash functions, namely SHA256 or Scrypt. I know this will disappoint you, and I'd better say at least a few words to justify my choice. The main criterion is that verification must be utterly simple and unambiguous. Everyone who's in any doubt that a ledger history might be suspect in some way, must be able to establish beyond doubt that the hashes are valid solutions to a problem of the required difficulty.

As I understand things, the various scientific/medical grid@home projects - BOINC, SETI, folding... - all publish problems, ask people to work on them, and then say "scientists will get back to you (and at least congratulate you, put you on the fast track to fame, maybe offer a money reward in some of the projects... whatever) when they're happy you've found a worthy solution to a worthy problem". And there's the rub. How can a validating node, listening in on someone else's reported proof-of-work triumph, know the triumph really means anything? What if it's not a BOINC-approved protein that was being folded, but a similar-looking one that a protein expert could have told you was much easier to fold? The software would need web-interrogating interfaces to "BOINC HQ" or whatever, to check that BOINC at some earlier time "blessed" the problem just solved as a hard one. You see why I'm worried that this is all just too much for a software system to cope with.

For now, then, I'm planning to go down the well-worn "pointless work" route. - Probably Scrypt in preference to SHA256, since many people will only aspire to mine a one-shot, small, "bootstrapping" amount of XSP - just enough to set up a few orders and trust lines and the like, with a view to then acquiring and holding and spending other [IOU-type] assets. Such people will have no intention of thinking of themselves as miners in any long-term sense; they certainly won't want to buy an ASIC. They'll just want to leave an "ordinary" CPU/GPU running overnight or over a weekend, and wake up to discover they've successfully created a few tens of cents' worth of XSP, which is enough to let them start interacting with gateways, etc etc. (If serious miners were meanwhile using ASICs, then they'd out-compete the casual folk, who'd wake up to discover they'd mined nothing, rather than a reserve-and-a-few-account-lines quantity of XSP.)

I'd be delighted to be proved wrong on this choice. If there's a decentralized way of knowing a just-solved scientific problem was hard for the solver - i.e. a way not involving "chatting to BOINC HQ" or the like - then by all means let's go for it, in Splash or elsewhere! But for now, Scrypt is my likely choice. (I'll naturally try to write modular code, isolating the choice of proof-of-work task from the rest of the code, so that any breakthroughs in "decentralizing meaningful science" can be seamlessly switched to as and when they happen.)

Oh, and one final thing which might cheer you up: in your last paragraph you mentioned mining software being a difficult beast to master. Well, the good news is that moving proof-of-work from ledger (block) level to transaction level makes mining code vastly simpler. The reason is, rather pleasingly, it doesn't need to keep up with the ledger chain, or even be online! In the casual scenario above, where someone's trying to open a brand new Splash account (address) with a modest XSP balance, they just need to pass their currently-unfunded Splash address to their mining software, along with their rough target XSP amount to try and mine, and two public facts they can collect from any reputable "ledger explorer" site: the current (or reasonably recent) network difficulty figure, and the current (or, again, reasonably recent) ledger hash. The mining software can then chug away without even needing a net connection; and a day or two later, when it strikes lucky with its proof of work, it can proudly output its transaction for broadcasting on to the network. (Perhaps as a QR code - the transaction will be small.)

(The quid pro quo for this implausible-sounding miracle, of the mining software being able to be offline, is that when the transaction is broadcast and absorbed into a ledger it may not create precisely the stated target quantity of XSP. In practice the variation is unlikely to be more than a few percent. So if it's absolutely vital to you that you start your Splash adventures with 70XSP, it would in practice be enough to say to your mining software "I want to aim for 80". And then you might end up with 70 or 75... or 85 or 90.)

In the corresponding "professional" scenario, where a serious miner wants to keep topping up the same Splash address with ever more freshly-mined XSP, the software would need to be told a third and final public fact: how many times that address has had successful mining done on it already. (This is to avoid a certain kind of network spam, known as work re-use.) Even that small additional fact doesn't really need to be "told" in so many words, so long as you're only running one instance of your mining software, and it has read/write access to persistent memory of some sort (disk space, a browser cookie,...). (Because then it can jolly well count the number of mining events itself! That is, add 1 to its persistent-memory counter on each finding of a work solution, ready for its future self to be solving the right future work problem.)

Sorry if this all seems a bit cryptic - eventually I'll be describing, in full technical detail, my transaction-level mining protocol, but I'm not ready for that just yet - but I hope I've whetted your appetite for now, and teased you with the possibility of Splash mining software being simple enough that it can be installed with the same ease and panache as BOINC! I hope that's at least some consolation!