I'm motivated only if I see that other people are interested in work I'm going and I interact with those people.

Alternatively I can get motivated by a challenging problem, but coding is too boring to trigger that kind of motivation.

That's a personality trait, I guess, other coders might have no problem coding for 8 hours straight. I can't, even for money, unless I'm really motivated.

If somebody doubts my qualification, here's a little crypto research I've done: https://bitcointalk.org/index.php?topic=55888.10 (Although I'm not a cryto professional, it's just a little research project which I found interesting.)

Nothing, actually. I'm just sort of lazy.

I'm posting this just to see community reaction, if people are interested I can do this, otherwise I won't.

I'm currently working (aside from my main job) on a speculative market, e.g. futures/options exchange, where people can bet on exchange rates, prices and stuff like that. Ideally, I want a blockchain-level escrow for this, to avoid bitcoinica-style fiasco.

I started working on it about a year ago, and at that time there were talks about escrow and distributed contracts. But, still, these things are PITA in Bitcoin mainline, so maybe I have to implement it myself?

I mean, if bbqcoin is possible...

1. OK, to make it clear, it is vaporware: I'm a really lazy person and I have lots of ideas. But, on the other hand, I'm a pro C++ coder, so I can do this, in theory.

2. People might say: "Why don't you work on improving existing currency like bitcoin or litecoin?". It's simple: when currency is actively used and valuable, its developers become conservative in features they allow. They do not want disruption for existing users, which is understandable. OTOH with some obscure alt chain you can experiment however you want.

This is actually the purpose of alt chains, according to Gavin himself (https://bitcointalk.org/index.php?topic=55506.0)

3. So, here's a list of features I'm interested in:

3.1. Geared towards CPU mining, via scrypt tuning (more memory), plus maybe my own crypto ideas. (I need to discuss them with pros first, though.) This would change initial coin distribution patterns (i.e. owners of large GPU farms won't get majority of coins, sorry), and might help against 51% attacks simply because influential people in bitcoin community are likely to have more GPU hashing power than they have CPU hashing power. (Although they can rent CPUs from EC2, for example.)
3.2. First class support for escrows, distributed contracts and stuff like that. With usable interface. They are sort of supported in bitcoin, but half of features are disabled, and half doesn't have proper UI. I actually work it working since I'm working on services which need this stuff.
3.3. Optional centralized timestamping to make instantaneous transactions possible. EDIT: probably irrelevant since similar goal can be accomplished with escrow I know it might be unpopular, but I'm going to make it a configuration option in client: you can configure it to either trust both timestamping server or only blockchain. It might also help against 51% attack, although I'm not sure about it. (Note that it's possible to implement it in bitcoin as a client feature, but it won't be as effective just because it's not default.)
3.4. Merged mining of stuff like ripple, distributed exchanges. (Technically this has almost nothing to do currency, but if I'll be making mining software I'll just include it there as a bonus feature.)
3.5. Potentially support for 'daughter chains', i.e. transfer of coins between many chains. I think it might help against blockchain bloat.
3.6. Constant mining rate, i.e. always 50 coins per block, forever. It would make monetary base stable, believe me or not. Rationale is that some coins are inevitably lost at a rate proportional to current quantity (on average), thus it's should be possible to get to equilibrium where number of coins lost = number of coins mined. As a side effect:

3.6.1. Since there are no changes in amount of bounties it makes things predictable and reduces volatility. (I.e. when mining goes from 50 to 25 you have change in supply and markets are going to react, even if it was known beforehand.)
3.6.2. Might subsidize transaction fees, i.e. miners don't have to charge a lot.
3.6.3. No deflationary problems like 'grandfather's wallet'.

4. I understand that many community members won't like some of these features, but the goal here is to try new things, not to get some people rich. If you don't like it, then forget about it. If nobody likes it, I have other things to do.

5. If there is an interest in bbqcoin community I can take it over. As I understand, original developer abandoned it... So this can save some time doing renaming and making initial block. However, it might be somewhat hard to switch hash algorithm 'on fly'. Also, there is already an awesome, vibrant community

Otherwise, I'm accepting donations (in form of pledges).

Thanks!

Um, can you show your evidence?

So far it looks like some 13 year old guy made a blockchain to learn more about this stuff and have fun, and you assholes ruined it.

How is it a scam? I don't see how a sane person would seriously invest into something called "bbqcoin", even more so when it was said that it is just for fun.

So unless this bbqcoin was a malware which steal wallets or something, you guys are overreacting.

These things are called CRYPTOcurrencies for a reason. They are NOT based on trust and are SUPPOSED to be attacked.

If you don't like this fact then I don't understand what are you doing on cryptocurrency forum.

I don't think so, with certain hash function designs advantage of ASIC/FPGA wouldn't be high enough to justify its price.

As I understand Litecoin's scrypt is still resistant against ASIC/FPGA because adding that much memory to the chip ruins the advantage.

So maybe we can wait till ASICs dominate bitcoin mining so all GPU guys will jump to litecoin mining and BEX will suck

As I understand, scrypt isn't GPU-resistant because GPUs are not sufficiently different from CPU in sense that they do have some cache memory.

It makes sense in game where economy is large part of the game. If currency is blockchain-based then its coinage is limited, and thus players can rely on it. (Hint: it might be a financial game.)

Also it makes sense if same currency is shared among many games.

Litecoin was geared towards that market, but now as GPU mining is available CPU mining is pretty much pointless.

So it turns out that scrypt is barely better than SHA-256 in terms of CPU/GPU performance ratio. Maybe tuning parameters can make it better, but it seems that the whole idea isn't working. From litecoin wiki:


But looking at mining hardware comparison page, difference seems to be lower than 2x.

OK, so aren't there hashes which offer higher competitive advantage to CPUs?

I'm really not an expert in this matter, but from what I know GPUs really do not like conditional jumps: with those jumps there won't be enough work for all ALUs within one stream processor. So are there hash algos which do that?

First thing which comes in mind is to make operations which are performed dependent on input itself. It might be structured in a way similar to scrypt, but with an additional step where bits of expanded input define what operations to perform on that expanded intermediate result.

Each such operation should be non-parallelizeable so that only one ALU of a stream processor can work at a time.

As a bonus it might give a relative advantage to hashing implemented in languages like JavaScript: they are already suboptimal so hit from conditional jumps is much lower.

I think there really is a case for CPU mining since it gives ordinary people a chance to mine coins for themselves. This makes sense for in-game currencies: some people really do not want to spend real money to get game money. And I guess ideally it should work well with browser-based mining so that people won't have to install anything to get money.

How is that possible?


Well, HDD comes to my mind. You're paid for storing stuff on your disk. Ownership of disk space is confirmed when you are able to retrieve content from its hash.

I don't quite get how to make a cryptocurrency out of it, at least not a bitcoin-like one, but at least there is a way where one can prove that his has a limited and valuable resource to another.

Maybe it makes sense to make it ripple-like (LETS) where peers will grant credit lines to each other proportional to amounts of data they store for each other.

As I mentioned, it isn't incompatible with (merged) mining. Mining still can be used for initial coin distribution. It just isn't an ultimate authority.

I.e. when central block chain disagrees disagrees with miner's block chain we just stop processing transaction and wait for a manual resolution. (Unlike bitcoin which automatically picks longest block chain.)


Sure, mining is a significant part of appeal. Or 'was', since CPU mining just makes no sense now and even GPU-based mining isn't that profitable.


'Decentralized' is just a buzzword which can mean many things. Ranging from democratic control to robustness to 'barrier to entry'.

If you remember those threads which discuss blockchain size scaling, people were arguing that at some point (many transactions per second) only large mining operations will ever touch blockchain directly since it would be of humongous size. So getting into bitcoin business at a tier1 player would cost a lot of money to get hardware, but even then, what if largest current operators will collude to ignore blocks you mine? Is it still decentralized?

On the other hand, in scheme I proposed above democratic control is much more straightforward as it comes directly from users, not from mining operations. 'Barrier to entry' is just different -- now bitcoin obviously wins, but in case of miner collusion it would take a lot of $$$ to override it, but in case with centralized timestamping you 'just' need to convince majority of users to switch to your server. Arguably, it might be easier. Centralized timestamping absolutely loses in terms of robustness, though, but that's another story.

If you remember, fate of P2SH was decided mostly among a small number of people (Gavin, Tycho, Luke-Jr and slush), so collusion isn't too far fetched to consider.


Yeah, that's the Sybil attack I was talking about. This is why timestamping server should be selected manually and consciously rather than via an automated algorithm, without proof-of-work there is no other way, I think.

If you worry about initial coin distribution, traditional mining can be used for that.

If you worry about choice of timestamping server after a failure, consider this scenario: you want to buy some item from an AwesomePantsStore which accepts weirdcoins. You have no other choice than to accept same timestamping server as used by that AwesomePantsStore, otherwise merchant wouldn't recognize your transaction as valid. There is absolutely no risk for you: if AwesomePantsStore picks a wrong timestamping server, it just risks to lose money due to double spending. So risk always lies on a merchant, buyer can always choose timestamping server suggested by an entity he sends coins to.

I wonder whether there are any developments on cryptocurrencies which are not based on blockchain proof-of-work.

I can think of one such scheme with a centralized timestamping server(s). It still can be run democratically just like bitcoin if users can select what timestamping server they trust. Double-spending is possible in case timestamping server goes rogue, but client software should detect this and revoke trust from that server. Then user can select another timestamping server he would trust.

Note that double spending is technically possible with bitcoin too, it's just rather unlikely unless attacker has superior hashing power. Taking into account that most bitcoin mining is now pooled, threat model isn't that much different: bitcoin users vote with their hashing power for mining pool they trust. If top mining pools collude they can implement 51+% attack, but then users will probably switch to different pool.

With trust-based centralized timestamping it's just more straightforward. Not that even though that it doesn't use proof-of-work, it isn't really that much vulnerable to Sybil attack (i.e. flooding network with attacker-controlled peers) because user's decisions won't be influenced by peers he doesn't interact with.

I.e. I would need to agree on timestamping server I trust with merchant I'm buying goods from, but it's rather unlikely that attacker would spawn lots of legit-looking merchants.

Further security can be improved with multiple timestamping servers and integration with proof-of-work-based timestamping (i.e. bitcoin merged mining). Although this would require more complex conflict resolution protocols.

But there is a shortcut: if forking happens, clients just stop functioning and we wait till software developers will find a solution and send an updated version of client. So essentially this can be quite vulnerable to DDoS but resilient to malicious double-spends.

This stuff seems to be rather trivial, so I wonder, have anybody already implemented this? If not, maybe we should? I mean a merged-mining based variant to make it more appealing.

(If it's not obvious, the goal is to make transactions instantaneous. Also, largely removes needs for blockchain downloads without completely sacrificing security.)

Oh, thanks... Well, that's how I got to that futures exchange project: it was supposed to be some quick project for a warm up. So I've got some half-assed version working, but I didn't have energy to develop it into a serious exchange. In a hindsight maybe it could work if I just propped it up a bit then, but now competition already got serious.

Who

I'm a programmer,  I can implement server-side parts of web sites (among other things). I have many ideas for bitcoin-related projects which I would love to do, and I can probably do all the coding myself.

But I really lack design skills, particularly I hate working on client-side web stuff (but I can do that if absolutely necessary). Also I hate working on projects alone, and also I'm somewhat afraid of responsibility and indecisive.

I'm looking for a person who can do design/copywriting AND/OR can take care of business issues. For example, provide funding, do PR stuff, advertisement, solve legal issues and so on.

(However, if you can neither can provide designs nor can attract funding I don't see how this can go anywhere.)

I'm not really looking for fellow programmers, particularly because I prefer to use rather esoteric programming language (Common Lisp) and would rather do everything myself. But if you really want to work with me I would consider that, I'm a friendly person .

To make it clear about funding, I could technically fund everything myself, but I just do not want to risk both my time and my money at the same time.

What

You probably want some proof that I'm not an idiot punk, so here's a project I worked on about a year ago: https://bitcointalk.org/index.php?topic=14059.msg258073

In about a week I developed a prototype of futures exchange, which was actually usable: you can see two users talking about using it. I really wanted to develop it further, but, unfortunately, I just cannot work on it alone.

I'm still interested in developing that project, but I have other ideas.

Particularly, the most exciting one is some wild mix of witcoin, hot-or-not sites and, um, youtipit. More detailed description is available on request.

(So two areas I'm interesting in is speculative/prediction markets and micropayments/donations.)

It's very unlikely that I would work on your idea, though, it might happen only if it's something I wanted to do myself, or you can pay lots of money.

(I'm currently working in a non-bitcoin-related web startup and not interested in job offerings unless they are some small/fun/well-paid things.)

So if you're interested in any way please PM me and we can discuss it further.

Thanks!

I see plenty of shopping cart interfaces, but no hosted, i.e. SaaS solutions for web shops and supplementary stuff. (I.e. for people who do not want to maintain their own servers.)

I know some guys in a company which provides such hosted solution. It's a small company and you probably don't know it, but they have existing customers who use their webshop and accounting software and are happy with it.

So... I talked with them about bitcoins, they say they might consider adding it as a payment option, but they are skeptic about market size. Are people interested in such hosted solution or they are happy with installing and using some open source thingie?

So... What's best way to gauge interest in such project? Poll on this forum, something else?

Concrete numbers: one SHA-256, 32 boolean variables in nonce position, no BDD optimization, just DAG nodest:

 * 99940  operations to compute last 1 bit of output
 * 101349 operations to compute last 16 bits of output
 * 102510 operations to compute last 32 bits of output
 * 104780 operations for 64 bits

(includes OR'ing them).

So computing more bits costs more, but not very much.

Now let's compare it with a traditional SHA-256 implementation, this page:https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU#Why_are_AMD_GPUs_faster_than_Nvidia_GPUs.3F gives an idea: "~3250 to execute the SHA-256 compression function" (on Nvidia GTX 590).

From https://en.bitcoin.it/wiki/Mining_hardware_comparison we get that 1024 ALUs working at 1215MHz make 193 Mhash/sec. 1024*1215/193 = 6446. Mining requires 2 SHA-256 has operations, so let's half that: 6446/2=3223. Quite similar to number on wiki page, so I guess that's it.

To compute hash for 32 different combinations NVIDIA GPU requires 3223*32 = 103136 cycles.

This is same number as required by boolean function implemention, so they should be roughly equal in performance, and perhaps boolean function would be even faster with additional optimizations (although second SHA-256 might not optimize as well as the first one).

So on the optimization potential, at least 2000 DAG nodes can be reduced to sufficiently simple (< 1000 leafs) BDDs. This number is going to get higher after I remove 5 variables to compute 32 combos in parallel.

Then there are 'hybrid' BDDs which combines dynamic nodes with static ones, it is going to penetrate DAG even further.

And then I haven't yet tried boolean function optimization and statistical early rejection.

So some speedup for NVIDIA GPUs and CPU mining isn't ruled out. AMD hardware is much harder to beat. But I haven't yet looked at what advanced instructions it supports, things like BFI_INT might replace several graph nodes.

Sure, I've just illustrated that SHA-256 round's diffusion isn't as good as people think about it. (BTW, even though these optimizations are applicable, I'm not sure that existing miners exploit all of them. Early miners like cpuminer do not seem to take advantage of them at all.)

And if it is not so good, there are optimization possibilities on bit level too (which aren't accessible on word level).


I think you've missed the main part of my reply -- I'm not calculating just one bit of output, I can calculate all bits of output using this method. So your criticism isn't applicable.

Let's say H is content of H register on 64th round, and H[0] is first bit of it, H[1] is second and so on.

We need to find input such that


That would be true for approximately one in 4 billion inputs. If that's not enough, we can include bits of G into a target function. Or we can compute fewer bits of H if that helps. Or we can express values of H[0] in terms of other expressions and do early rejection on that level.


I don't know yet. So far, I've got pretty good results with BDD, better than I expected.


Calculating another single bit would take only 0.1% because it depends on exactly same inputs as the first bit. Or see above -- it is possible to formulate whole mining problem in a form of boolean expression.


It was actually sufficiently clear the first time too, but for some reason you're missing that it is possible to reuse computations to calculate all bits of output.

In that case 2% speedup would be 2% speedup, plain and clear.

Right now I see BDDizing fringe nodes as only viable optimization, so I guess we need to wait until I'll BDDize all what is BDDizable before jumping to conclusions.

But thanks for looking into this, so far you're the one who paid most attention.

For people curious about possibility of optimization of 'fringe' nodes, here are some BDD (binary decision diagram) complexity results: http://paste.lisp.org/display/126772

These are results for all subtrees of height 13 in computation DAG after constant propagation and other simple optimizations. Vars is effective number of meaningful variables in BDD after optimization, leafs means number of distinct outcomes.

E.g. a fully random boolean expression of 32 vars would have 32 vars and something like 2^32 leafs.

Here maximum we have is 32 vars, 19676 leafs, while most are very simple, some even constants (zero variables).

Of course, it doesn't mean that SHA-256 is broken as registers after all 64 rounds have height of ~3500. At high heights it becomes close to random boolean function, with billions of distinct results. But low heights can be pre-computed and optimized out. I don't know how much yet.

Let's say 10-20% speedup in an ideal case.


I believe optimization can be done fairly quickly, thus its cost would be negligible. Especially if you use GPU for main computation and CPU for code generation. I would only be concerned with OpenCL/CUDA compiler not being fast enough, but that's just a technical difficulty.

I was thinking about this approach initially, but that doesn't make sense as that one bit shares a lot of computations with bits nearby (it is fairly obvious, I just wanted to verify that actual results match intuitive ones and there is no unexpected speedup). Now I'm aiming at computing as many bits as necessary. E.g. 32 or 64 of them. It is true that computing one bit costs about as much as computing 32 of them due to re-use of common dependencies. Computing 64 bits would require somewhat more due to a round structure of SHA-256 (see below).


That's right.


But half of result bits are pretty far from MSB. They will be mixed eventually, but only after a few rounds.


Many people say that, and initially I had a same impression. But try inspecting SHA2 compression function closer: one round does very little. It modifies only two registers (and shifts the rest), eating only 32 bits of input block at once.

Thus when you do SHA-256 for bitcoin mining, you don't need to compute first three rounds (of 64) at all. That's already a ~5% speedup. Then fourth round boils to a single addition. Then fifth is pretty simple too, as input bits are constant, so you just need to compute S0 (which boils down to two XORs per bit if you ignore ROTR) and do an addition with constant. And so on. So it only requires all operations by round 8 or so.

Likewise, we are only interest in H on 64th round. Which is just G at round 63. Which is F at round 62. Which is E at round 61. Which is D + S1 + Ch + W[60] + K[60] at round 60.

So you can chop off last four rounds. Only 57 rounds out of 64 are required, so ~11% of computations go away. Furthermore, a lot of leftover rounds can be simplified out. Furthermore, a lot of block expansion parts can be simplified. Furthermore, some bits in first few meaningful rounds have very few dependencies and can be simplified.


It is true that I cannot chop away, like, 99% of computation, but some modest speedup might be possible.

Yep, right. So it is 768 bits in general case. But it doesn't make any difference in this context.