defending ahead the p2p nature of bitcoin - blending hashcash & scrypt

[adam3us]

I presume most share the view that "me too" forks of bitcoin that
tweak parameters are a bad thing and should be ignored.  However I
think litecoin is the exception, because even though I am the inventor
of hashcash (the bitcoin mining function - yes I contributed to the
40MW and growing environmental crime;) - even with that personal
interest/attachment I think the scrypto mining function used by litecoin
has advantages and should be partially merged, and I'll tell you how
why I think this, and how I think it would best be done.

The reason is litecoin is ASIC unfriendly, so that moore's law chasing
generic CPUs and GPUs will track closer to what is achievable with
custom ASICs because of the intentional memory footprint.  Ok everyone
know how litecoin works, my point is meta, coming next: when the ASIC
wall hits (if butterfly ever ships) its probably going to put the GPU
miners out of business.

I think that is a bad thing for a few reasons: GPU mining is fun, it
adds the visceral gold-like aspect for users, and its inclusive, and
p2p friendly.  ASIC mining is exclusive, not in principle - nice ASIC
PCI cards and USB boxes could be built in $100, $200, $500, $1000
increments etc - but in practice because anyone with skills to make
cards has an obvious incentive to mine them themselves rather than
sell them.

(I just placed my own butterfly order + a two 5GH baby ones for my
teenage sons, one of who is enjoying GPU mining

Now the concern is longer term.  Imagine its 3-5 years down the road.
Rows of data center racks lined with blades chock full of 14nm
hashcash mining cores.  A danger I see is that manufacturers have an
interest to hoard as long as bitcoin price supports a high profit with
next gen hardware compared to what is available to others.  So the big
boys (and I mean financial houses, venture capitalists, kind of level)
will be best placed to be able to buy their way into the line at TMSC,
front millions in design, pre-order fees, circuit board design.  The
risk is p2p miners arent going to be able to get access to equipment
that can financially compete with this equipment.  Butterfly seems like
a small player - maybe they'll ship.  But what can be done with the
above scale could eclipse their power and efficiency, probably in the
same way ASIC outclasses GPUs and I can see market reasons why
you or I wont be able to buy them.

Now some people might think so what - all's fair in a moore's law arms
race - thats part of the design.  And to some extent thats right.
Bitcoin could do fine like that, but it wont be a p2p currency any
more, not really.  That's because if all the peers are big stock market
listed companies, with corporate lawyers, very statically and easily
identifiable, they will do whatever governments tell them to do.  And
governments will tell them to convert the network into swift 2.0
including government feeds for analysis (yes bitcoin is public anyway,
but not to your legally required truename etc), and legal requests to
block this and that payment entity change the protocol by fiat etc. to
roll back transactions because of some fraud or dispute unrelated to
bitcoin, to freeze and confiscate bitcoins - we'll be back to square one.

At that point also they'd just as soon stop mining and write contracts
to each other and save the hashcash GWs.  Big companies are largely
scared enough of misbehaving or having their banking or wire transfer
revoked that they're not going to hack a block chain fork or such
tricks.


Now I think one reason you might want to listen to me, some random
crypto-hacker, is I think I've been here before.  I predicted
something similar about CAs a decade or more ago.  I said one should
not trust CAs (I can probably find the post), one should not build
ecosystems that rely on them implicitly - governments will simply get
them to issue fake certs and intercept or manipulate user traffic.
Roll forward 10 years and it eventually slips out that we have CAs on
the down-low selling rogue CA certs, and some pretty questionable
governments operate some CAs.  Mozilla is debating removing another
CA right now for some malfeasance.  (And Iranians and Syrians etc
critical of their government etc are being identified, rounded up tortured
and murdered with using the info).  Well and western companies with
government blessing or turning a blind eye are making and selling
them the equipment to do it with, and doing backroom deals with
the same dictators in the name of strategic influence


Anyway hopefully you see my point - you do want bitcoin to remain p2p
or there is a risk if too large entities evolve, of that destroying
the p2p nature, and essentially removing the need for or value of
distributed time-stamping using hashcash.

Secondly the p2p miners and users "own" and are the network.  We
should protect their interests.  Keep them interested in bitcoin via
the fun of mining.  Maybe you could do that via easy access to
competitive ASIC and above hardware built with kickstarter or open
source hardware or small companies like butterfly.  But I'm not
confident.  Or if I had influence I'd encourage implementing a backup
plan ready to roll out.


I suspect the network difficulty might even drop facing a wall of
ASICs over the next year or so if GPU mining goes the way of CPU
mining.  I say that because even though the ASICs might get 100x more
MH, they may drive out 1000 GPUs each, and then the ASICs get to
profit even more (they own a bigger than anticipated slice if
difficulty falls).  Doesnt affect bitcoin price necessarily, but
different people will be getting the mining rewards.


So if you buy any of the above here's how I think it should be done
technically.  Clearly you dont want sudden changes, or it affects
confidence in the definition of bitcoins.  Maybe there are counter
arguments or other approaches.  I understand people are atttached to
the satoshi quo - as it should be sudden changes are bad.  You guys
are now in a EU troika like position you have to be careful what you
do because it can have consequences in the confidence in the BTC.  
Maybe soon even what you say!  So I do respect the no sudden or
unconsidered moves concept.

Well my idea is this aim to get to 50:50 hashcash scrypt (or perhaps
even 66:33 so the hashcash which is potentially more vulnerable to
centralization cant control in the 50% sense of forks
if the corporates decide to fork the chain following a government edict)
hashcash and scrypt are accepted as both equally valid whoever
finds the collision of the required difficulty wins the 10min block.

Phase in, maybe be ready to phase in, but dont even do it until
trouble looms.  Start with 2% scrypt and grow every 2 weeks (same cylce
as difficulty adjustment).  But this is the trick: give hashcash and scrypt
independently calculated difficulties, the market will figure out the
fair value between them.  The custom ASIC filled rackmount corporte
guys at the high end may focus on the ASICs they hve 50% to play with.
Maybe they can help make things fast and reliable with nice servers
and bandwidth.  And everyone else can compete on a level field with
scrypt.  Now the corporate guys can get into scrypt also, but the harware
they buy is the same basic class as you or I can buy - Intel CPUs,
GPUs etc with the same power efficiency.

(A more detailed comment one may want to allow the scrypt size
parameter to be network dynamic like difficulty because if a CPU
starts to be common (or is developed custom for mining) with L3
cache larger than the avarage systems minimum assumable main
memory you have a big problem as memory bound computational puzzles like
Moderately Hard Memory Bound functions 2003 (of which scrypt
is an improved derivative)
http://research.microsoft.com/pubs/54395/memory-longer-acm.pdf
are sensitive to too much ultra fast ram.  On the plus side the argument
is in general that variation in ram speed is less than variation in core
speed between mid and top range.)

You could consider it a BTC/LTC alloy so I guess I am arguing for a
gold-silver alloy coin.  (Or the BTC shiny coin logo always seem to
be 2 tone anyway already?)  A negative version of that could be call
of currency dilution, however I argue its not because it doesnt create
any new coins, just levels the playing field to lower hardware while
no one gets any particular advantage.

(Midly disgruntled after just having escaped the ignominy of being in
the newbie trap:).  But dont be gentle - bring on he nay saying - Ive
been through USENET flame wars of the early 90s - bring it on.

(My ignominy post towards my 5 to get out of newbie trap!
https://bitcointalk.org/index.php?topic=15672.msg1873483#msg1873483 )

Adam

ps Its kind of ironic - I got emails from Satoshi in 2008/2009 about
hashcash & inviting comments on his paper, and to try the alpha
software; the irony that I invented the hashcash function all the
CPU/GPU and ASIC miners are burning 40MW on and yet I dont own (nor
ever have) a single bitcoin.  What a foolish person Surely I
should've tried it out mining at the beginning like Hal Finney did.
Well I'm going to fix that via mtgox & an asic miner but there's no
way I'm going to get to Satoshi's $100m genesis hoard level as a late
late player

[1714943890]

1714943890

[1714943890]

1714943890

[gollum]

if all the peers are big stock market
listed companies, with corporate lawyers, very statically and easily
identifiable, they will do whatever governments tell them to do.  And
governments will tell them to convert the network into swift 2.0

That would kill the whole idea of bitcoin if a few corporations would own all mining. Do you think scrypt is a long term solution or only a temporary defence in the never ending battle against moores law & specialized hardware?

[amincd]

ASIC mining is exclusive, not in principle - nice ASIC
PCI cards and USB boxes could be built in $100, $200, $500, $1000
increments etc - but in practice because anyone with skills to make
cards has an obvious incentive to mine them themselves rather than
sell them.

First of all, welcome to bitcointalk.org!

Are we sure that there won't be any ASIC manufacturers that will sell them? All it takes is one volume manufacturer to make ASICs available to the masses.

Also, won't sCrypt eventually be dominated by specialized mining rigs any way? There are already FPGAs being developed for it, and if hashing sCrypt continues growing as a business, I think it's only a matter of time before specialized hardware is designed for it and GPU mining becomes out of reach.

[gmaxwell]

I think that is a bad thing for a few reasons: GPU mining is fun, it
adds the visceral gold-like aspect for users, and its inclusive, and
p2p friendly.

I wish this were true, but the feedback I've seen constantly is that many people are insulted and angered by the small amounts they get from a single small mining setup, even some who were told what to expect going into it... even when the amounts they get will actually become non-trivial when accumulated over weeks of 24/7 mining.

There are people who find it fun, but it's certainly not everyone.

Humans are a funny breed. They seem to be demotivated by the fact that someone else is making 100x more even when that person has >100x more operating costs!

ASIC mining is exclusive, not in principle - nice ASIC
PCI cards and USB boxes could be built in $100, $200, $500, $1000
increments etc - but in practice because anyone with skills to make
cards has an obvious incentive to mine them themselves rather than
sell them.

I'm now not aware of anyone making devices without selling them. (The one party I was aware of was convinced to change their practices— consider, if they don't sell devices their consolidations may threaten the decentralized security assumptions of Bitcoin— even if this doesn't immediacy debase the coins they produce the community may change the PoW and make their hardware worthless, there are some subtle reasons why changing the PoW is more viable than you might guess).

Small devices should be available soon in a number of forms.  The fact that the first major wave of deployments will be large devices also gives some advantage to smaller participants in the long run, since they won't be saddled with big investments in 110nm infrastructure. (Not to mention, that 110nm infrastructure will probably eventually resold to people who can use the waste heat for low prices)

It's my personal hope that the somewhat reduced access to the relevant equipment will be offset from decreased competition by people who are stealing resources to mine and as a result be at least a wash in terms of equality of access.

destroying
the p2p nature, and essentially removing the need for or value of
distributed time-stamping using hashcash.

I am continually very concerned by this, but I don't think the deployment of ASIC is by far the biggest threat to the distributed nature of Bitcoin.  I think the far bigger threats are that almost all mining is done through a few centralized "pools" and that fewer and fewer users run actual network nodes that independently validate the rules of the system— instead using hosted wallets and various kinds of thin clients.   If your highly casual GPU miners are just blindly selling their computing power to a pool, it doesn't contribute much to the distributed nature of the system. (It does make the economy more distributed, but they can do that by buying coins).

I suspect the network difficulty might even drop facing a wall of
ASICs over the next year or so if GPU mining goes the way of CPU
mining

The sales from one hardware vendor alone (avalon) are right now somewhat over 1500 68GH/s units as I understand it, this is enough hash to replace the entire hashrate we had from GPUs and FPGAs in January five times over. The belief is that BFL has sold many more than this.

Well my idea is this aim to get to 50:50 hashcash scrypt

I would expect this to lower costs for an attacker to reorganize the chain to conflict transactions by giving him choice of hardware.

one may want to allow the scrypt size
parameter to be network dynamic like difficulty

This would make _validation_ expensive too. A shame, as the tiny scrypt size in LTC doesn't really achieve memory hardness... and I'd bet that dedicated hardware would get a _larger_ speedup then we get for sha256 because of this.  An interesting question is: how do you create a function which is strongly memory-hard to search but not (/less) memory-hard to validate?

There are other interesting ideas in the space of memory-hardness.  For example, you could define a POW function which is an operation over the spendable transaction index which then proves that miners have high capacity for validating transactions— perhaps better aligning the operating motivates... and eliminating the miners that just blindly sell computing power without having any interest or capacity to participate in the actual validation.   (Using data in a globally known merkle tree is potentially one way to make a asymmetrically memory-hard function)

What a foolish person

Hah. You and a lot of other people, actually. I spent time talking about cryptocurrency things with Hal due to his RPOW system before Bitcoin existed, and "used" bitcoin early on (well, as much as you can use it when almost no one else does!) but didn't bother keeping my wallet. But whatever, Bitcoin is interesting and important regardless of what value people assign the coins and how much you "could have had" but don't.

[adam3us]

Are we sure that there won't be any ASIC manufacturers that will sell them? All it takes is one volume manufacturer to make ASICs available to the masses.

Well my (A-level economics grade;) economics argument is market price is set by supply and demand, the supply and competition is limited and the barrier to entry large, so its a sellers market and so the sellers will either not-sell and mine, or sell at a small margin below utility value so the buyer takes the market risk and the seller takes most of the projected profit.  Ie they'll charge a massive margin, which yes invites competition, but unlike a normal market there is a floor to how much they'll be undercut - the mining value.  The next manufacturer will do the same thing, as they also leverage their barrier overcoming investment, so I dont think the market can fix this.

Maybe bitcoin price volatility helps somewhat while it lasts - big hardware manufacturers maybe dont want penny-stock odds - thats more VC profile - established owners of fabrication plants, chip design houses etc have a business to run, and want to reduce their projected sales volatility.  However I could see bitcoin price volatility reducing as the market matures and derivatives contracts availability appears - and that would elevate the above problem.

So I am (and was from the beginning) concerned there was a risk hashcash could end up stacked in favor of big players because they can pay for the development and contracts etc and mine their own equipment.  And with hardware - hardware hackers can get somewhere, but no where near AMD gpus and Intel cpus - the analog of that level of manufacture and design.  And the AMD & Intels investment level is huge.  I think it comes down to what the price/performance/power graph looks like between generic hardware (GPU), close to current moores' hw limit big funding hardware (VC or existing big co), small biz hardware (butterfly), and hackerspace level hardware hackers can do.  If there is a big discontinuity between hackerspace or kickstarter, the p2p nature of bitcoin may erode in a few years

Maybe bitcoin ought to community use some of that $1bil market cap to do something mega-kickstart.  Maybe there is even a self-interest in that.  If bitcoin loses its p2p nature I expect the currency value to drop.

If I was a hardware guy with like ex-intel chip designer experience - I would go for this right now.  But I know close to zip about ASIC & CPU/GPU design at layout compiler etc level.  A detailed and airtight kickstarter contract could bootstrap availability of close enough to moore's law edge to defend the p2p nature for scalable investments and profitability down to $100 level.  But on the receiving end with those kickstarter projects they look like make-money-fast schemes for the operators of unknown technical skills and execution ability.  Like butterfly but much worse.  You need hardware design credibility, execution ability history, openness and a contract that on independent legal review guarantees community access without the kickstarted employees walking off with 99% of the profit or miners.

(I figured this out the hashcash big player hw design issue in 1997 and had some other candidate cost function ideas re anti-spam - note bitcoin has pushed hashcash harder than spam might have because there is more money and motive involved so the answer may change - for hashcash anti-spam / anti-DoS for anonymous remailers and other anti-DoS applications I took the risk because my estimate was the extreme simplicity, ultra fast and simple and human readable mechanism and 100% distributed and 100% scalability prototcol was just too cool to pass up and the spamming profitability business model has ultra slim margins so even with near universal scale deployment it would be safe from mega investments .  Its not many things that can accurately claim to be 100% distributed and 100% scalable.  Not a coincidence I  was at the time a distributed systems PhD student and crypto fan - distributed systems field studies scalability limits and distributed algorithms.)

Maybe thats what Satoshi's moving on plan is - protect the p2p nature with a hw manufacturing stealth project funded with discretely siphoned post anonymity bug genesis bitcoin hoard.

If there was a way to bootstrap and keep p2p levels of market availability and profitability, you can see the advantages of keeping to the hashcash gold-standard.  It stood 16 years test of time so far cryptographically, and thats worth something, quite a lot of bitcoin's viability is based on that stability.  It also keeps the satoshi-quo, which I like.

Also, won't sCrypt eventually be dominated by specialized mining rigs any way? There are already FPGAs being developed for it, and if hashing sCrypt continues growing as a business, I think it's only a matter of time before specialized hardware is designed for it and GPU mining becomes out of reach.

I agree.  Without being a concrete design, and very much wild-discussion material - maybe a fair cryptographic p2p lottery elected function each epoch chosen at random from a massive function family. 

But its hard to design  a function family where all functions have enough variability to reduce the GPU/ASIC gap, and with hashcash-like properties (fast verification, compact storage, no shortcut).

Btw it would also be desirable to have something generic enough that as the hardware that gets built would if configurable enough (if the function family heads towards general program) it has dual uses.  Ie it IS a next gen GPGPU and that in itself could help accessibility as there is lots of market demand for such things from the scientific community.


Or a 6month design competition with review for security (no hidden trap-doors), fast verification, and then a replacement chosen via fair lottery.  I figure 6months ought to break the ASIC or higher end design cycle for a new function up a bit.


Ps I presume everyone heard of Jakobsson & Juels "Bread Pudding" protocol
http://www.rsa.com/rsalabs/node.asp?id=2049

Trying to get the miners to do useful work.

However absent an efficiently publicly auditable proof-of-work that is fairly tied to the computations of a homomorphic encryption scheme, their proposal as far as I can see not possible to scale with decentralized trust.  (Email me if you understood the import of that last sentence   And I dont like non-decentralized things.

Juels was also the same author that reinvented something hashcash-like but online (Client Puzzles).  (Offline is better as its more private, and publicly auditable, client puzzles are not).  Juels was not aware of hashcash at the time.  I have a link to that one and others on:

http://hashcash.org/papers/

Adam

[passerby]

Well, if you don't mind, I will provide a few comments without specific quotes:

1) I do not think that companies producing good ASICs would be incentivized to mine themselves on a reliable basis.
There is a large number of operational costs (and risks) that are specific to the miner but not to the party producing the specialized equipment, so depending on legal, economic, and geographical circumstances it may - and often does - make business sense to produce the boards without actually using them.

This is true for a wide array of specialized equipment manufacture - and I don't think there are enough reasons to believe it won't be true for bitcoin.

2) Empirical evidence suggests that current (GPU and a bit FPGA) mining of Bitcoin is not decentralized.

While there are indeed a cute "gold rush" and "side-business" aspects to "amateur" GPU mining, nowadays a number of circumstances have forced the supermajority of individual miners into "pools" (as correctly noted above), a few of which are accountable for the absolute majority of hashrate in both BTC and LTC nets.

When you account for pooled mining, ASICS become completely irrelevant - it doesn't really matter whether there are 4000 corporate-owned ASIC farms or 4 000 000 individual GPU miners, because in both of those cases the equipment will be connected to 4-10 "megapools" which will be effectively in control of the network

It thus appears to me that, if empirical evidence is to be trusted, ASIC resistance (or lack thereof) will have little to no effect on "decentralization", primarily due to very strong centralization arising  from "pool" infrastructure.

P.S.:
My limited understanding of concepts involved suggests that "poolproof" design is possible, but my limited understanding of miner behavior suggests that it would be woefully unpopular.

P.P.S.:
As far as alt-coins go, I would prefer ppcoin and namecoin over litecoin.

Of course, I have my disagreements with ppcoin design, and namecoin is pretty much dead in the water, but at least those two are trying to significantly innovate, as opposed to doing some very meager PoW-algo jockeying and calling it a day.

[adam3us]

Or a 6month design competition with review for security (no hidden trap-doors), fast verification, and then a replacement chosen via fair lottery.  I figure 6months ought to break the ASIC or higher end design cycle for a new function up a bit.

If it wasnt clear that wild 1997-era hashcash design alternative idea was I meant this design competition would be on ongoing and a candidate picked via fair crypto lottery at each 6month epoch.  ASIC miners have to get fast off the mark or they wont recoup their investment.

A risk you run is its a bit like obfuscated malware C contest but in crypto - if someone manages to slip a backdoored design past the crypto reviewers (which could include the cryptographic community) maybe the designer of a picked design gets a small bitcoin bounty, and more importantly the breaker of a design after the submission cut off gets a bounty also to bring in the best cryptoanalytic minds from the community.

You dont really want any human intervention allowed after the lottery or its arguably destabilizing.

btw a way to think clearly about the economics of $100m+ ASIC investments - say it becomes possible to build economic machines to do alchemy (convert lead or other worthless stuff into gold).  It is actually possible presently and has been demonstrated in particle accelerators and what-not but the cost is phenomenal and they yield low.  Anyway say its possible to build one for $100m, with a yield 1000x what can be done for a $1m investment, and practical but almost zero yield machines are possible to build in your garage or buy - chance do you think you have buying one of those digital alchemy boards?  I didnt think so.

btw2 I like the argument put forward by a presenter in a Matonis + some economist guy discussion that come some unspecified pre-singularity events eg like self-replicated nano-bot gold miners, or genetically engineered algae to filter sea water for gold and dump it in locateable clumps.  Again thats going to be  government research lab or monsanto event not a garage event, and you can bet they will try to hoard the mechanism if the barrier to entry is high and not easily garage reproducible.  And anyway if they're not careful either way the bottom is going to fall out of the physical gold market   At that point its all bits an bitcoin is better than physical gold.  Singularity timeline projections: this century.  Some pre-singluarity events clearly earlier this century than later.

Adam

[/quote]

[passerby]

Well, I don't disagree with the argument that major ASIC-mining players, in all likelihood, will be organizations, not individuals ( I do not necessarily agree that the mining organization and the ASIC manufacturer will be the same person, as such an argument would require one to make prediction regarding future state of a highly unstable market) .

However

a) I think that, even if some "hypothetical situation magic" were to make bitcoin strictly GPU-minable, matters would eventually evolve towards organizations and "mining moguls" hogging majority of raw hash power

b) all organizations and individuals doing mining would  flock into pools irrespective of whether we're talking corp-owned ASIC farms or GPU farms or little Joe's garage mining device.

As long as pools are in the picture, the argument regarding "mining decentralization" will remain rather hollow and pedantic, IMHO.

[CIYAM]

Very nice to see you here (although perhaps you meant 2008-2009 wrt emails from Satoshi) - just as an offside (being someone who has implemented hashcash into a webmail app as a tip of the hat to the invention itself rather than anything I expect people to use) can you shed light on why it (hashcash) never actually took off wrt fighting spam (was it due to the emergence of smart phones that would have forced the difficulty to be too easy or the success of baysian equation algos or perhaps some other reasons)?

[TierNolan]

When you account for pooled mining, ASICS become completely irrelevant - it doesn't really matter whether there are 4000 corporate-owned ASIC farms or 4 000 000 individual GPU miners, because in both of those cases the equipment will be connected to 4-10 "megapools" which will be effectively in control of the network

I think distributed verification is key with a "falseblock" message that be broadcast which proves a block is invalid.  The main difficulty is that it you can't prove data is missing from a distributed hash table.

If someone proves a key is valid then they could broadcast a missing value warning.  It isn't clear how to prevent it being spammed though.

[passerby]

Well, distributing the verification "back" would be nice, but it seems to me (from your post and elsewhere) that there are practical issues with that (and little to no impetus for pools AND for-profit miners* to adopt such a technology).

In the end, though, all is better than it could be - we could have had just 3 pools, and we have more. We have ASIC first-mover who is very much into decentralizing mining. I'd say all turns out fairly luckily for BTC.


_______
* as a friend once said about such folks, "mah vidja-cart is shitten teh dollerz". No offense intended to for-profit miners

[Gavin Andresen]

Howdy Adam!

I'm going to quote myself, this is from an email I wrote yesterday to somebody else concerned about chip/mining centralization:

I think it will go through waves of centralization/decentralization. I can imagine bitcoin-mining electric hot water heaters installed in homes all across the world, installed by thousands of private companies that split the profits with homeowners. And thousands of die-hard do-it-youself-ers who buy the hardware and cut out the middleman.

In the very long run, mining will be dominated by your cost of electricity and your ability to put the excess heat generated to good use.

I don't think it will matter what algorithm is used or even if the algorithm was changed every six months; if a general-purpose CPU was the only thing you could use for mining, you might see general-purpose CPUs designed to operate at thousands of degrees celsius being designed so that aluminum smelting plants can also mine bitcoins with all that electricity they use turning bauxite into aluminum.

In the short run... I think there is zero chance that "we" will decide to change the hashing algorithm.

[TierNolan]

Well, distributing the verification "back" would be nice, but it seems to me (from your post and elsewhere) that there are practical issues with that (and little to no impetus for pools AND for-profit miners* to adopt such a technology).

I don't think they are necessarily insurmountable, but yeah, missing data is hard to handle.

If a transaction 20k blocks before the end of chain goes missing, does that invalidate the chain?

[kjj]

I'm going to take the pro-SHA/pro-ASIC stance.

Having a single simple hashing algorithm is better than having a difficult one, or having a pool of them chosen randomly.  The reason is that it keeps the barrier to entry lowish for new ASIC producers.

You simply cannot make an algorithm that is, in general, resistant to ASICs.  If a general purpose CPU can do it, then a purpose-built CPU can do it faster.  The best you can do is make it expensive for someone to develop an effective ASIC.  Also, time is money, so if you use a random pool of algorithms, then the only people that will have ASICs are those that can afford to develop them quickly.

Building an ASIC for SHA-256 is pretty simple.  At least 3 different groups have already done it, on shoestring budgets and somewhat quickly.  Increase that to maybe dozens if you include the not-suitable-for-bitcoin streaming hasher chips that are commercially available.  If (heh) they abuse their position as first movers, the barrier to their competition is very, very low, on the order of tens of thousands of dollars and several months to get started.

Making ASIC development more difficult will keep out the people that we want to include, and do nothing whatsoever to exclude the people that some would like excluded.

[passerby]

Well, distributing the verification "back" would be nice, but it seems to me (from your post and elsewhere) that there are practical issues with that (and little to no impetus for pools AND for-profit miners* to adopt such a technology).

I don't think they are necessarily insurmountable, but yeah, missing data is hard to handle.

Personally, I think adoption / social issues may turn out to be worse than technical ones (though the latter have not been surmounted yet, either).

Your typical pool, and your typical for-profit miners don't give a single rat's ass about decentralization or whatever. They're in it for the money, which isn't necessarily a bad thing, but could easily lead to a kind of "tragedy of the commons" scenario.

If a transaction 20k blocks before the end of chain goes missing, does that invalidate the chain?

I'm not really the To Go Guy in this regards, but it seems to me that for various "distributed work generation" systems to work, pool's clients must be kept aware about all the transactions that need to go into the block OR ELSE.

You simply cannot make an algorithm that is, in general, resistant to ASICs.  If a general purpose CPU can do it, then a purpose-built CPU can do it faster.   

While probably true in general sense and almost certainly true in the "efficiency" ("performance/J") sense, I am not convinced that the difference between ASIC and CPU can not be made to be rather unimpressive by clever algo design. There's clearly not enough work in this are, however.

Also, if you, at the very least, can drive ASIC development and manufacture costs high enough (which isn't impossible), you can render any ASIC operation economically unsound.

P.S.:

If we're talking an economically irrational opponent with virtually unlimited funds, then ASIC resistance, theoretical or otherwise, becomes irrelevant.

Such an opponent would buy up whatever equipment he needs to dominate your chain, be it CPU rigs, ASICs, or goddamn Blue Gene.

[TierNolan]

I'm not really the To Go Guy in this regards, but it seems to me that for various "distributed work generation" systems to work, pool's clients must be kept aware about all the transactions that need to go into the block OR ELSE.

There are 2 separate issues.  Distributed verification of the block chain can be slow.  A 1 hour delay before an error is detected is not that big a deal, only the latest transactions are affected.

However, if miners know that any illegal transaction in the block chain will be reversed within an hour, then they will make sure their blocks are ok.

Producing new blocks in a distributed way is harder.  You have to produce and verify the block within a very short period of time.

[gglon]

In the very long run, mining will be dominated by your cost of electricity and your ability to put the excess heat generated to good use.

In 2011 in Germany less than 25% power¹ from renewable energy sources was actually used due to the volatility of sources (something we are used to:). This number might improve much when the big network of clean energy will be build in EU. But still there will be lot time when unused power will be basically for free. And mining, unlike other activities, can be perfectly adjusted for those periods. Worldwise there will always be places where there is excess of power, so the hashrate will be somewhat stable.

I don't think electricity is the best source of heat. Especially from asics, which must operate at quite low temperatures to be efficient. And with the development of new technologies, the logic elements are smaller and smaller, which will require lower temperatures to operate properly (otherwise quantum tunneling will cause errors). So actually availability of cooling material will be important (imagine a farm on Antarctica).

¹http://www.erneuerbare-energien.de/fileadmin/ee-import/files/pdfs/allgemein/application/pdf/ee_zeitreihe.pdf

[adam3us]

In the very long run, mining will be dominated by your cost of electricity and your ability to put the excess heat generated to good use.

[...]

In the short run... I think there is zero chance that "we" will decide to change the hashing algorithm.

Go the satoshi-quo -- I am not displeased -- you're using my mining function (with pretty much no wikipedia attribution anywhere btw other than Satoshi's paper *), and I am also attached to it, and frankly I did guess that would be the likely, and with some justification, community response.  And indeed as I said in another post I appreciate the Satoshi-quo quite strongly for concept stability that may affect investors confidence.  And I'm game to see how that turns out.  It'll be an interesting ride.

It remains to be seen whether ASICs become available to the user-level participants in enough volume to mean that the network remains > 50% controlled by users.  The economics dynamic is too hard to tell.  I do very much hope it works out that way to strongly enough to keep the network well in excess of 50% p2p controlled.

What the community can do is try to bootstrap garage, kickstart, small co mining manufacturing enterprises to help retain the p2p power balance.  Unfortunately I dont have the direct skills to help with that much because I am not a hardware hacker.

If the corporate controlled entities amassed enough of a majority of network hash power (eg > 90%) for a year or so period they may feel confident enough to fork the protocol.  Dont forget they may be forced to, as advised by conservative corp lawyers, even if it may likely destroy the p2p aspects of the bitcoin network, and indirectly perhaps their own profit.  (Which they may or may not see coming).  If that happens I would be worried for the longevity of bitcoins distinguishing features (other than virtual hashcash gold based paypal like concept with the usual seizure, blocking, payment roll back etc issues).

And I suppose there is an implicit backup plan if bitcoin devolves into non-p2p, corporate controlled, stripped of most useful p2p era functions, but still working in a paypal like way (balance seizures, account blocks, transaction rollbacks included) system, then a replacement more agile mining process or other innovation crypto-currency may rise up from the ashes or be adapted by the p2p community as a continuation of the p2p bitcoin ethos.

if a general-purpose CPU was the only thing you could use for mining, you might see general-purpose CPUs designed to operate at thousands of degrees celsius being designed so that aluminum smelting plants can also mine bitcoins with all that electricity they use turning bauxite into aluminum.

Well actually that would be of general utility as a (faster at all costs) next gen CPU, and so it would more tend to have universal availability - the market for CPUs is much larger than miners - and scientific computing would love to use it.  Its also an inherently useful innovation force (in a bread pudding protocol like way) whereas ASIC hashcash miners are laser focused and of little non-bitcoin use.

There is an estimate that there is (massive) computing physical limit - that does involve very high temperatures.  I forgot the number of groups of 000s on the operations per second the physicist's paper i read had estimated, but it would make a unbelievably ferocious miner indeed if humanity could ever get that close to the physics computing limit.  (That physical limit model assumes no quantum computing).


But I've said my piece, and maybe it'll inspire people to poke at various alternatives (though please no gratuitous no-innovation bitcoin forks!).  Got the bitcoin equivalent of my 1990s "CAs are going to be abused by governments to issue rogue certs" warning in.

And I'm just warming up on the crypto suggestions...

Adam

(*) I added the hashcash ref on bitcoin wiki, or it also didnt reference as I recall, and I had a go at adding something on wikipedia but the editors/moderators didnt seem inclined and I didnt have the energy to argue with them.

[adam3us]

Well, if you don't mind, I will provide a few comments without specific quotes:

When you account for pooled mining, ASICS become completely irrelevant - it doesn't really matter whether there are 4000 corporate-owned ASIC farms or 4 000 000 individual GPU miners, because in both of those cases the equipment will be connected to 4-10 "megapools" which will be effectively in control of the network

It thus appears to me that, if empirical evidence is to be trusted, ASIC resistance (or lack thereof) will have little to no effect on "decentralization", primarily due to very strong centralization arising  from "pool" infrastructure.

Well I dont think thats as dangerous a problem as corporate control by a long way.  A pool cant misbehave much.  If it does the users will realize and pull out and it'll go under.

P.S.:
My limited understanding of concepts involved suggests that "poolproof" design is possible, but my limited understanding of miner behavior suggests that it would be woefully unpopular.

Surely thats just a question of mining in much smaller parts, so that rewards are meaured in the Satoshis range instead of 25 whole coins.  I think the harder but probably solveable problem if it was desired would be p2p traffic efficiency.  I do think poolproof would be useful.

P.P.S.:
As far as alt-coins go, I would prefer ppcoin and namecoin over litecoin.

ppcoin seems interesting.  I think I reinvented it or something similar, had another post in draft form, though ppcoin seems complicated at least the way its explained on the wiki  (not sure I fully understood it from quick skim of wiki).  Will post my similar idea next.

Adam

[adam3us]

Very nice to see you here (although perhaps you meant 2008-2009 wrt emails from Satoshi)

I did - quite significant typo/braino there    I also dont know who Satoshi is and the first I heard of bitcoin was a 2008 email from him as I mentioned.  (Or one of the crypto lists I cant remember which came first or which I saw first).

just as an offside (being someone who has implemented hashcash into a webmail app as a tip of the hat to the invention itself rather than anything I expect people to use) can you shed light on why it (hashcash) never actually took off wrt fighting spam (was it due to the emergence of smart phones that would have forced the difficulty to be too easy or the success of baysian equation algos or perhaps some other reasons)?

Not clear.  Maybe failed to achieve enough momentum on the network effect.

Its use is clearly small, but it maybe like SMIME, it may have many more clients deployed who would act on it if anyone would bother sending them some hashcash (mainly server located hashcash capable spamassassin) relative to the small the number of stamps.

There was also a nay-sayer article about the economics of it all claiming it would be insufficient to deter spammers.  "Proof of Work proves not to work" (I put it on http://hashcash.org/papers/ also.)

Also you may or may not know microsoft did their own hashcash fork (chosing it over their own R&D labs memory bound functions (first version of the concept scrypt is based on).  They deployed it I think into exchange, outlook maybe hotmail.  I didnt follow it too closely.  They released on an open spec, and one could even implement the changes into the open source hashcash.  Was on my to do list for a while, still languishing.  But who can work on spams when there are bitcoins for enciphering minds to think about

Kind of lame that I didnt put that microsoft hashcash fork link on the hashcash site that I can see now.

btw it also occurred to me recently that you could recycle low bitcount bitcoin failed hash attempts for hashcash, just stuff the email in a bitcoin ignored field.  Sure the format is binary and different, and big but maybe it could be tweaked somehow to include hash( bitcoin stuff ) to be ignored by hashcash email other than as a randomization or ignored field, in a way that still makes sense to bitcoin.  Combined anti-spam with bitcoin as a freebie   Or something the ASIC miners could do as a sideline is spam like crazy   Ok for the GPU users though.

However I do worry about the privacy implications of that.  If you mined a 25 blocker and have to disclose a recipient thats not ideal.  You could probably fix that eg though a separate field that is encrypted, before hashing, and the encryption key sent with the hashcash for the recipient to verify, but kept private from the bitcoin network.  Maybe they'd even have an indirect satoshi level value for email postage uses.  Though they are not transferable as hashcash is fully decentralized and scalable.  ie the miner has to be the mail sender generally, because the stamp includes the email recipient in the hash.  (Though the encrypt the recipient address before hash trick, would allow moderately privately outsourcing the work.  I say moderately because the miner can still correlate the stamp issued to the email if it got logged.  Dont forget these things were also meant to cope with anonymous remailers.  even for regular email it just not smart to scatter around electronic breadcrumbs in the name of outsourcing a few seconds of CPU without some cryptographic unlinkable blinding, which seems doable but I didnt explore)

Adam

[gollum]

maybe this is a noob question: why don't we use the computing power of the bitcoin network for something useful (let researches use the computation power) in combination with the current algorithm?

[adam3us]

If a general purpose CPU can do it, then a purpose-built CPU can do it faster.  The best you can do is make it expensive for someone to develop an effective ASIC.  Also, time is money, so if you use a random pool of algorithms, then the only people that will have ASICs are those that can afford to develop them quickly.

Agreed, good synopsis of the problem.

Having a single simple hashing algorithm is better than having a difficult one, or having a pool of them chosen randomly.  The reason is that it keeps the barrier to entry lowish for new ASIC producers.

Building an ASIC for SHA-256 is pretty simple.  At least 3 different groups have already done it, on shoestring budgets and somewhat quickly.  Increase that to maybe dozens if you include the not-suitable-for-bitcoin streaming hasher chips that are commercially available.  If (heh) they abuse their position as first movers, the barrier to their competition is very, very low, on the order of tens of thousands of dollars and several months to get started.

Making ASIC development more difficult will keep out the people that we want to include

Thats a rather good point, I like it.  That might even win the argument if we see ASICs of good quality and efficiency flood the market in the next few years, partly as a result of the simplicity of SHA/hashcash.

and do nothing whatsoever to exclude the people that some would like excluded.

It would do something about the people we want to exclude, that was my point/intention anyway: there are limits to custom hardware optimization where it becomes just too expensive and you're better off buying or making a faster CPU.  Intel is a target you're chasing at the speed of Moore's law.  Particularly if the algorithm is changing every 6 months in interesting and novel ways.  Imagine someone come to you with a mountain of money and says build me this custom CPU in 3 months (so there's three months left to start mining).  Maybe you cant do it in time to repay the investment.  Maybe you cant do it in the timeframe with any amount of money.  Even all of it - there are complexity and science limits for hw gurus and chip fab people etc.

But maybe thats too simplistic a view of the hw response to the challenge, eg maybe they optimize in the direction of reconfigurable flexibility - eg ultra flexible, ultra fast, 22nm FPGAs with more pre-optimized lumpy parts (FP units, cache arrays, integer units, etc).  But then there is an argument that that might however be a rather nice general purpose re-programmable CPU so maybe everyone and his dog will be able to buy cards and racks with them on par with miners.  And if it becomes reusable enough, it becomes a product with general availability, and that becomes a win for dynamic epoch redefinition of mining function.

If the target is too flexible, particularly dynamic over too short an interval, the hw guy either loses to intel, or he builds an intel competitor flexible hw reconfigurable CPU that everyone (supercomputer vendors, scientific computing, dyanmic function miners) will want to take off his hands.  Either way it a win for the dynamically changing mining function approach.

It takes a lot to compete with Intel.  Even AMD cant seem to do it these days - though AMD make real nice GPGPUs.


But your main point simple hashing algorithm ..[as it] keeps the barrier to entry lowish for new ASIC producers stands maybe is more robust than the harder to quantify difficulty of super-optimizing hw for an inventively changing mining function - harder to project what could be done, and anyway if the sheer simplicity of the hashcash mining function is enough to ensure p2p availability of hw, its is a more elegant, simpler solution.  Simplicity I like.

You know there maybe more than hw availability also to consider.  Many GPU miners are mining because they have a GPU.  If some of them had to pay for the miner they may drop off.  But bitcoin could probably live without that if it had to (sad though it would be to have them lose their fun without buying an ASIC.)

Adam

[adam3us]

(Here's a ppcoin like idea I wrote before reading about ppcoin.  I havent quite managed to decipher the ppcoin wiki page finding it hard to find isolate a concise definition of its mechanism and intended low level effects.  Maybe someone who has internalized ppcoin could skim this idea below and tell me if is the same as ppcoin (but simpler?) or not.)

There might be other ways to tilt the field towards p2p control also without changing the mining function.

One could give coins accompanied by first 4 year (50 coin block private keys) from the block chain some definitional hashcash mining boost.  This boost only has value for protocol voting, but NOT coin reward and could be an interesting drag on corporate control.  Would give Satoshi some anonymous power if he is still around and mining.  There'd have to be some coin reward to encourage the GPU miners with old private keys to play and keep the p2p aspect going, other than altruism, but it could be a different payout.  The generation 1 private keys boost level would frustrate subsequent control centraliztion.  Also the boost private keys are the first miner original keys only, the boost cant be transferred bitcoin purchase to the new address private key.

Adam

[gglon]

Well my idea is this aim to get to 50:50 hashcash scrypt [or pool of algorithms]

I can't imagine majority of miners (who are already sitting on ASICs) would accept this kind of fork.

[kjj]

and do nothing whatsoever to exclude the people that some would like excluded.

It would do something about the people we want to exclude, that was my point/intention anyway: there are limits to custom hardware optimization where it becomes just too expensive and you're better off buying or making a faster CPU.  Intel is a target you're chasing at the speed of Moore's law.  Particularly if the algorithm is changing every 6 months in interesting and novel ways.  Imagine someone come to you with a mountain of money and says build me this custom CPU in 3 months (so there's three months left to start mining).  Maybe you cant do it in time to repay the investment.  Maybe you cant do it in the timeframe with any amount of money.  Even all of it - there are complexity and science limits for hw gurus and chip fab people etc.

You are assuming that the investment must be repaid in terms that you understand.  Maybe someone is rich and just wants to mess with the network.  It seems unwise to make ourselves vulnerable to that sort of thing merely because we wouldn't take advantage of it ourselves.

[adam3us]

Well my idea is this aim to get to 50:50 hashcash scrypt [or pool of algorithms]

I can't imagine majority of miners (who are already sitting on ASICs) would accept this kind of fork.

I am anti-fork as bad for mindshare, confidence and dilutive of bitcoin and crypto currency value aggregate.

I was suggesting it maybe in the self-interests of bitcoin to think about that for the main branch.

Obviously ASIC miners wont like it short term.  I ordered some ASIC miners off butterfly also.

But my statement was bigger picture, longer term view: all bitcoiners, including ASIC miners, will like it even less in the longer term and bigger picture if the entire currency gets devolved into a non-p2p corporate controlled network.  That itself would either destroy bitcoin value via loss of interest and/or bitcoin's user-centric properties along the way.

Anyway there was some interesting discussion in this thread, and there are uncertainties about what is the right answer.  So I guess by default we're going to wait and see.

If there even exist lots of ASIC privately held at present, that in itself is an argument for p2p nature surviving ASIC with hashcash mining function.

Adam

[passerby]

Well, if you don't mind, I will provide a few comments without specific quotes:

When you account for pooled mining, ASICS become completely irrelevant - it doesn't really matter whether there are 4000 corporate-owned ASIC farms or 4 000 000 individual GPU miners, because in both of those cases the equipment will be connected to 4-10 "megapools" which will be effectively in control of the network

It thus appears to me that, if empirical evidence is to be trusted, ASIC resistance (or lack thereof) will have little to no effect on "decentralization", primarily due to very strong centralization arising  from "pool" infrastructure.

Well I dont think thats as dangerous a problem as corporate control by a long way.  A pool cant misbehave much.  If it does the users will realize and pull out and it'll go under.

It appears to me that many miners care little about protocol intricacies. As long as dollers keep falling out of the vidjacard, all is fine and dandy to such folks  .

Besides, I do think that you're overestimating corporate malice. Corporations are, by design, fairly sociopathic - but they are just profit driven decision makers, much like pool-ops, and would, just like pool-ops, seek to refrain from doing things that may break the profit model (one could argue that de-pseudonimizing bitcoin or removing the max coin count would drop the price like a giant bag of rocks, and that would not be good for Coinmining LLC, would it ?).

Also, I'm not convinced that "de-ASICing" BTC would necessarily prevent "corporate encroachment". It just so happens that it is much easier to run a large cluster of complicated equipment when you are a small company - and much more comfortable for the proprietor.

P.S.:
My limited understanding of concepts involved suggests that "poolproof" design is possible, but my limited understanding of miner behavior suggests that it would be woefully unpopular.

Surely thats just a question of mining in much smaller parts, so that rewards are meaured in the Satoshis range instead of 25 whole coins.  I think the harder but probably solveable problem if it was desired would be p2p traffic efficiency.  I do think poolproof would be useful.

Well, the problem with "mini-mining" is variance, also known as "luck" and occasionally affectionately referred to as "fuck my life"

Miners want their payoff come in stable and predictable intervals (which makes business sense). They want it so much they are ready to pay pool fees in order to ensure that stochastic nature of mining won't throw them under the proverbial bus.

And they will probably ignore a coin that does not allow for such a service to take place - it massively increases their risks without offering any benefit that a for-profit miner would consider "substantial"

ppcoin seems interesting.  I think I reinvented it or something similar, had another post in draft form, though ppcoin seems complicated at least the way its explained on the wiki  (not sure I fully understood it from quick skim of wiki).  Will post my similar idea next.

Adam

Ppcoin is incredibly contrived and opaque - I'm not too fond of it (and also, I have a conflict of interest ) but at least it is kinda trying something new, which is, one has to agree, cool...

and do nothing whatsoever to exclude the people that some would like excluded.

It would do something about the people we want to exclude, that was my point/intention anyway: there are limits to custom hardware optimization where it becomes just too expensive and you're better off buying or making a faster CPU.  Intel is a target you're chasing at the speed of Moore's law.  Particularly if the algorithm is changing every 6 months in interesting and novel ways.  Imagine someone come to you with a mountain of money and says build me this custom CPU in 3 months (so there's three months left to start mining).  Maybe you cant do it in time to repay the investment.  Maybe you cant do it in the timeframe with any amount of money.  Even all of it - there are complexity and science limits for hw gurus and chip fab people etc.

You are assuming that the investment must be repaid in terms that you understand.  Maybe someone is rich and just wants to mess with the network.  It seems unwise to make ourselves vulnerable to that sort of thing merely because we wouldn't take advantage of it ourselves.

You can not stop someone who has so-called "disposable money" in the upper millions/lower billions USD and is, as far as you can tell, insane, with just "merely" sound cryptography and better hashrate, unless this hypothetical opponent is obsessed by the idea of taking you down by hashrate alone.

If he can't out-hash you with superior ASICs, he will lobby for BTC to be banned in USA and EU.

If can't out-lawyer us, he'll directly go after the exchanges.

If that fails, who knows...
...maybe he will buy some BTC and anonymously strongly pseudonymously hire hitmen to go after everyone worth going after in the community, at which point no half-sane dev will touch this code with a ten-foot pole.

"disposable money"  in the upper millions/lower billions USD + batshit insane = IRL Saturday morning cartoon villain.

[adam3us]

Maybe someone is rich and just wants to mess with the network.  It seems unwise to make ourselves vulnerable to that sort of thing merely because we wouldn't take advantage of it ourselves.

I think that is something to think about in byzantine threat models.  Could a big and hostile player greatly out sizing bitcoin in terms of money to burn destabilize via financial exchange manipulation, or mining out the coins with vastly more CPU power, buying and deleting coins etc.  It seems often that some big players prefer covert plausibly deniable or hard to prove action than something overt.  Or alternatively they could find or make an legal excuse to cut exchanges off from the banking interface.

Even competitors like banks themselves if the bitcoins started to eat into profit margins maybe they could drive out the currency by buying all the liquid parts.  (Bad currency drives out good?)

Adam

[Sunny King]

Go the satoshi-quo -- I am not displeased -- you're using my mining function (with pretty much no wikipedia attribution anywhere btw other than Satoshi's paper *), and I am also attached to it, and frankly I did guess that would be the likely, and with some justification, community response.  And indeed as I said in another post I appreciate the Satoshi-quo quite strongly for concept stability that may affect investors confidence.  And I'm game to see how that turns out.  It'll be an interesting ride.

Hey Adam nice to see you hang out here! Don't worry your work is noted and I have hashcash listed in my history of cryptocurrency wiki page: https://github.com/ppcoin/ppcoin/wiki/History-of-cryptocurrency

(Here's a ppcoin like idea I wrote before reading about ppcoin.  I havent quite managed to decipher the ppcoin wiki page finding it hard to find isolate a concise definition of its mechanism and intended low level effects.  Maybe someone who has internalized ppcoin could skim this idea below and tell me if is the same as ppcoin (but simpler?) or not.)

There might be other ways to tilt the field towards p2p control also without changing the mining function.

One could give coins accompanied by first 4 year (50 coin block private keys) from the block chain some definitional hashcash mining boost.  This boost only has value for protocol voting, but NOT coin reward and could be an interesting drag on corporate control.  Would give Satoshi some anonymous power if he is still around and mining.  There'd have to be some coin reward to encourage the GPU miners with old private keys to play and keep the p2p aspect going, other than altruism, but it could be a different payout.  The generation 1 private keys boost level would frustrate subsequent control centraliztion.  Also the boost private keys are the first miner original keys only, the boost cant be transferred bitcoin purchase to the new address private key.

This bears some similarity to what cunicula used to push for (https://en.bitcoin.it/wiki/Proof_of_Stake). In ppcoin I gave full faith and credit to the concept of proof-of-stake and let it fly without the restraint of proof-of-work. That is how ppcoin achieves its design goal of long term energy efficiency. As far as I know I am the only one that gives full respect to proof-of-stake, others kept doubting it and try to make balance with proof-of-work, ultimately failing to produce an actual design and implementation.

[adam3us]

Surely thats just a question of mining in much smaller parts, so that rewards are meaured in the Satoshis range instead of 25 whole coins.  I think the harder but probably solveable problem if it was desired would be p2p traffic efficiency.  I do think poolproof would be useful.

Well, the problem with "mini-mining" is variance, also known as "luck" [..] Miners want their payoff come in stable and predictable intervals

Thats because the minimum network accepted virtual "nugget gold weight" is too high for the end user miner.  If the rate of average production for a spec of virtual gold dust was 1 second on a GPU (for some picosatoshi) the rate of progress would be smooooth, so its not the randomness per se, its the size of the minimum mining target.  It'll be acceptably smooth even at 1 microcoin per hour for 500MH miner at a given difficulty.

The problem and reason for big 25 coin blocks I think is p2p network scalability.

You can therefore think of pools like supernodes in a p2p network.  They hand "shares" sized chunks of work, out effectively the microcoin challenge and smooth it out for you, and like supernodes in p2p networks in general, they help the network scalability.  There is healthy competition amongst pools, and the barrier to entry is low.

In an idealized crypto currency you could argue it would be desirable to be able to mine picocoins directly with out pools.  poolproof as you called it.  But I think for now the people working on the code are having enough fun scaling for transaction volume etc with the current parameters absent some interesting new crypto to say allow secure offline combinable and splittable proofs of work.

Adam

[mmeijeri]

The risk is p2p miners arent going to be able to get access to equipment
that can financially compete with this equipment.  Butterfly seems like
a small player - maybe they'll ship.  But what can be done with the
above scale could eclipse their power and efficiency, probably in the
same way ASIC outclasses GPUs and I can see market reasons why
you or I wont be able to buy them.

I'm more worried about the possibility that governments around the world would ban private possession of ASIC mining rigs and would deploy large farms themselves. There are only so many places in the world where you can fabricate ASICs, so that would make them easy for governments to controls. Also, by definition ASICs are application-specific, so there would be no fallout on other applications.

I'd look for a hashing algorithm for which ASICs offer less than an order of magnitude improvement over at least FPGAs, which cannot be suppressed. No such improvement over GPUs would be even better and ideally ordinary desktop PCs should be competitive. Surely it must be possible to find a hashing function that requires the full functionality of a general purpose CPU.

[passerby]

Maybe someone is rich and just wants to mess with the network.  It seems unwise to make ourselves vulnerable to that sort of thing merely because we wouldn't take advantage of it ourselves.

I think that is something to think about in byzantine threat models.  Could a big and hostile player greatly out sizing bitcoin in terms of money to burn destabilize via financial exchange manipulation, or mining out the coins with vastly more CPU power, buying and deleting coins etc.  It seems often that some big players prefer covert plausibly deniable or hard to prove action than something overt.  Or alternatively they could find or make an legal excuse to cut exchanges off from the banking interface.

Even competitors like banks themselves if the bitcoins started to eat into profit margins maybe they could drive out the currency by buying all the liquid parts.  (Bad currency drives out good?)

Adam

Oh, like I said, such an attacker can do a stupidhuge number of devastating non-cryptographic attacks.

Here's another one:

Assume attacker can waste up to 500 mil. USD (I assume that is the ballpark "pocket change" figure for someone who can afford developing ASICs just to "mess with the coin guys")

Attacker creates a highly anonymous offshore structure, in this case I would probably suggest a trust (it's hard, but possible, to set up an offshore in a manner that is literally impossible to trace back to the real mastermind of the affair)

Attacker arranges for about $50 mil moved there.

Attacker locates, across numerous anonymous fora, a programmer that is both highly competent and unethical (not like there ain't places on the net where such folks hang out)

Attacker hires him to enter BTC dev circles, contribute, gain team trust, and eventually sneak a remote code execution vulnerability (disguised as a honest coding mistake, of course) into main. Attacker pays the blackhat a very lucrative salary via the offshore structure.

The attack would be completely devastating, and, in case the exploit is discovered prior to relevant code being accepted into main, the blackhat has plausible deniability (not like anyone can claim to never have made a dangerous coding mistake)

Fighting "Rich Mad" is not fun

Surely thats just a question of mining in much smaller parts, so that rewards are meaured in the Satoshis range instead of 25 whole coins.  I think the harder but probably solveable problem if it was desired would be p2p traffic efficiency.  I do think poolproof would be useful.

Well, the problem with "mini-mining" is variance, also known as "luck" [..] Miners want their payoff come in stable and predictable intervals

Thats because the minimum network accepted virtual "nugget gold weight" is too high for the end user miner.  If the rate of average production for a spec of virtual gold dust was 1 second on a GPU (for some picosatoshi) the rate of progress would be smooooth, so its not the randomness per se, its the size of the minimum mining target.  It'll be acceptably smooth even at 1 microcoin per hour for 500MH miner at a given difficulty.

The problem and reason for big 25 coin blocks I think is p2p network scalability.

You can therefore think of pools like supernodes in a p2p network.  They hand "shares" sized chunks of work, out effectively the microcoin challenge and smooth it out for you, and like supernodes in p2p networks in general, they help the network scalability.  There is healthy competition amongst pools, and the barrier to entry is low.

In an idealized crypto currency you could argue it would be desirable to be able to mine picocoins directly with out pools.  poolproof as you called it.  But I think for now the people working on the code are having enough fun scaling for transaction volume etc with the current parameters absent some interesting new crypto to say allow secure offline combinable and splittable proofs of work.

Adam

Yes, a mining algo that would allow me to mine low-diff mini - rewards blocks alongside "big" miners mining for bigger rewards  without causing a security compromise would be a huge boon (with current PoW, that won't work, at least not straightforwadly)

 It would make the poolsafe concept viable  (currently, you can make pools un-workable, but you need mini-reward scheme to make it lucrative)

Well my idea is this aim to get to 50:50 hashcash scrypt [or pool of algorithms]

I can't imagine majority of miners (who are already sitting on ASICs) would accept this kind of fork.

I am anti-fork as bad for mindshare, confidence and dilutive of bitcoin and crypto currency value aggregate.

Awwww man  

Seriously though, with all due respect (and with admittance of my conflict of interest here) - alt-coins (or rather, truly innovative alt-coins as opposed to one-two tweak clones) are useful.

They prevent monoculture.

If anything, we need more altcoins pursuing different niches (I feel that there are market niches which BTC, contrary to popular belief, fills imperfectly, allowing for an alt to take that niche without affecting mainstream btc adoption - but that's a long and boring story)

[TierNolan]

Seriously though, with all due respect (and with admittance of my conflict of interest here) - alt-coins (or rather, truly innovative alt-coins as opposed to one-two tweak clones) are useful.

They prevent monoculture.

If anything, we need more altcoins pursuing different niches (I feel that there are market niches which BTC, contrary to popular belief, fills imperfectly, allowing for an alt to take that niche without affecting mainstream btc adoption - but that's a long and boring story)

Arguably, what you want is one timestamping chain.  All other chains can then use that timestamp service to establish ordering of their transactions.

That is effectively what merged mining actually does anyway.

It would allow the main chain headers to be extremely clean.

[passerby]

Seriously though, with all due respect (and with admittance of my conflict of interest here) - alt-coins (or rather, truly innovative alt-coins as opposed to one-two tweak clones) are useful.

They prevent monoculture.

If anything, we need more altcoins pursuing different niches (I feel that there are market niches which BTC, contrary to popular belief, fills imperfectly, allowing for an alt to take that niche without affecting mainstream btc adoption - but that's a long and boring story)

Arguably, what you want is one timestamping chain.  All other chains can then use that timestamp service to establish ordering of their transactions.

That is effectively what merged mining actually does anyway.

It would allow the main chain headers to be extremely clean.

Certain practicalities (like "motivating miners of the meta-chain") aside, monoculture is admittedly very comfy.
However, non-monocultural settings are less susceptible to exploits and systemic failures of design.

Monocultures also tend to "calcify", stifling innovation and accruing institutional commitments (the latter isn't always a bad thing, but it can limit the directions project can realistically take - for instance, bitcoin becoming more anonymous would piss off FinCEN by breaking an implied institutional commitment. Or, for a more obvious example, consider the response of people who already bought ASIC units to a hypothetical PoW change )

[TierNolan]

Certain practicalities (like "motivating miners of the meta-chain") aside, monoculture is admittedly very comfy.
However, non-monocultural settings are less susceptible to exploits and systemic failures of design.

True.  Alt chains would have to have some kind of funding system.  The timestamp chain would have a single merkle root.  Alt chains which pay more are placed nearer the top.

Miners would merge miner lots of alt chains at the same time, placing the ones which pay more closer to to the top (assuming the protocol rules give better rewards for doing that).

Speaking of which, it would be nice if bitcoin supported unbalanced merkle trees.  This would allow much faster updates for the extra nonce.

Or, for a more obvious example, consider the response of people who already bought ASIC units to a hypothetical PoW change )

The timestamp chain could still be based on sha256.

[adam3us]

Attacker hires [unethical hacker] to enter BTC dev circles, contribute, gain team trust, and eventually sneak a remote code execution vulnerability (disguised as a honest coding mistake, of course) into main.

I dont think you even need a lot of money for that, the grey/black hat hacker just does it as his own project...  There ought to be some really serious scrutiny of every byte every check-in.  Maybe bitcoin should think about paying a bounty for the bugs out of some slush even.

Some of those guys ranging through black, grey to white hackers are very very smart.  If they can find new 0-days, in highly reviewed code, and sell it on the grey (legit actually) market - they are well qualified to know what a subtle mistake looks like, and how one would create one.

I am anti-fork as bad for mindshare, confidence and dilutive of bitcoin and crypto currency value aggregate.

Seriously though [...] truly innovative alt-coins as opposed to one-two tweak clones) are useful.

They prevent monoculture.

If anything, we need more altcoins pursuing different niches (I feel that there are market niches which BTC, contrary to popular belief, fills imperfectly, allowing for an alt to take that niche without affecting mainstream btc adoption - but that's a long and boring story)

Ok you called me on that.  Your points are valid also IMO.  I was mostly reacting to the 'one-two teak clones' as you put it that are basically 100% bitcoin with paramtweaks.  I should have qualified that with simple no difference forks.  Otherwise why would each person not start the same code or a paramtweak metoocoin etc in their own name and go for the first mover coins until there are 100k coins types and the concept of a cryptocurrency gets weakened by the noise!  Its confusing to the semi-technical viewer and erodes the meaning of a cryptocurrency.  But yes part of an experiment is potentially the economics which maybe you cant really tell without operating it.

There are limitations with bitcoin, things that could be improved, maybe crytpographic and/or p2p optimizations perhaps that could jump scalability up, reduce network requirements of peers, etc

Different mining and decentralization retaining features etc.

The research and experimentation brings value.  Maybe in the longer term bitcoin would merge an innovation to improve.  And worse cast, yes a monoculture defense, if bitcoin lost its way.

The first mover thing is odd though.  No one knows if an alt-coin will perhaps for some unforseen reason overtake, if bitcoin hits a big stumbling block people didnt see coming.

Adam

[ChristianK]

In an age where an attacker can rent a botnet of 1,000,000 PC, you don't want a function that can effectively run on a normal PC.

I dont think you even need a lot of money for that, the grey/black hat hacker just does it as his own project...  There ought to be some really serious scrutiny of every byte every check-in.  Maybe bitcoin should think about paying a bounty for the bugs out of some slush even.

Who's that bitcoin that you want to pay a bounty?

[passerby]

The timestamp chain could still be based on sha256.

And, that would be a kind of "institutional" commitment in a loose sense - informal and unspoken one, but commitment nonetheless.

If you decide to move away from SHA256, you'd have a bunch of very upset participants, who will at that point become fairly confrontational.

Attacker hires [unethical hacker] to enter BTC dev circles, contribute, gain team trust, and eventually sneak a remote code execution vulnerability (disguised as a honest coding mistake, of course) into main.

I dont think you even need a lot of money for that, the grey/black hat hacker just does it as his own project...  There ought to be some really serious scrutiny of every byte every check-in.  Maybe bitcoin should think about paying a bounty for the bugs out of some slush even.

Some of those guys ranging through black, grey to white hackers are very very smart.  If they can find new 0-days, in highly reviewed code, and sell it on the grey (legit actually) market - they are well qualified to know what a subtle mistake looks like, and how one would create one.

Well, having a lot of money allows you to pay the blackhat a really nice salary to ensure he devotes all his efforts to compromising BTC from "team insider" position, and the blackhat gets to keep all the coins he gains from sneaking a remote code execution exploit into BTC.

Which, I reckon, would be an offer few blackhats would decline.

The sheer effort needed to detect - and neutralize - such an attack would be tremendous.

So if we are really consider a non-economically motivated attacker with millions of dollars to spare,  exotic chippery is the least of our concerns (I'd say outright implausible, given the amount of non-cryptographic shortcut attacks a rich monomaniac can undertake)

And yes, we need a "bug bounty" and a generally more robust change review process.

Ok you called me on that.  Your points are valid also IMO.  I was mostly reacting to the 'one-two teak clones' as you put it that are basically 100% bitcoin with paramtweaks.  I should have qualified that with simple no difference forks.  Otherwise why would each person not start the same code or a paramtweak metoocoin etc in their own name and go for the first mover coins until there are 100k coins types and the concept of a cryptocurrency gets weakened by the noise!  Its confusing to the semi-technical viewer and erodes the meaning of a cryptocurrency.  But yes part of an experiment is potentially the economics which maybe you cant really tell without operating it.

There are limitations with bitcoin, things that could be improved, maybe crytpographic and/or p2p optimizations perhaps that could jump scalability up, reduce network requirements of peers, etc

Different mining and decentralization retaining features etc.

The research and experimentation brings value.  Maybe in the longer term bitcoin would merge an innovation to improve.  And worse cast, yes a monoculture defense, if bitcoin lost its way.

The first mover thing is odd though.  No one knows if an alt-coin will perhaps for some unforseen reason overtake, if bitcoin hits a big stumbling block people didnt see coming.

Adam

Well, there won't even necessarily be an overtake.
I expect  BTC and decent alties to specialize to different market segments, with BTC being more mainstream and some altcoins taking up niches that a "mainstream cryptocurrency" doesn't fit quite as well (if at all)

There's no particular reason why There Should Be Only ONE .

And don't get me started on Bitcoinomics...

Having said that, there's you know, a certain gap between "cryptocurrency ideas" and capacity to implement them.

Altcoins need more level-headed professionals, good designers, and perhaps most importantly, cryptography experts involved.

[adam3us]

In an age where an attacker can rent a botnet of 1,000,000 PC, you don't want a function that can effectively run on a normal PC.

Well thats an interesting and valid pro-ASIC friendly argument.  People with ASICs will try to secure them and notice if their coins are stolen. 

But also there is an indirect human utility to having botnets being used for mining - it is a very benign payload compared to other things criminal hacking activities have historically used botnets for.  Maybe spam would even fall if hashcash CPU/GPU mining is a more profitable market than spamming.  It seems to me highly likely that it would be even.  Maybe hashcash beats spammers yet in an incredibly indirect and unexpected way   Thats amusing.

I dont think you even need a lot of money for that, the grey/black hat hacker just does it as his own project...  There ought to be some really serious scrutiny of every byte every check-in.  Maybe bitcoin should think about paying a bounty for the bugs out of some slush even.

Who's that bitcoin that you want to pay a bounty?

Well I would be alarmed if anyone tried to impose that by fiat, as its payment system political interference EU-troika style, but what I meant for example the bitcoin foundation (and/or any other trustworthy organization with a public interest - eg EFF?) might collect donations from bitcoin users to be divided up between the most dangerous 0-day problems in bitcoin code.  And maybe the bitcoin code changes should not even be shipped until it has survived a months and a few $million of the best code analysis minds on the planets best efforts.  In that way it is actually in the bitcoin holder and users mutual and selfish interest to donate to that because if such an attack happens they maybe the losers.

I mean think about it - bitcoin surreptitious hidden code check in attacks, or accidental code mistake attacks - they could be the perfect payout allowing a 0-dayer to retire on Satoshi like money.  Say bitcoin grows by another factor of 100x in transaction volume and market cap over the next few years.  This is a higher assurance code security scenario than society has ever seen, the security of the code and development and review model maybe its only technical security weakness.

Another defensive thought: bitcoin may like to take a leaf from mondex, p2p respendable electronic currency cash card.  They had a hot spare crypto protocol ready and predeployed switched on via peer2peer transfer of signed upgrade notice cards in case of cryptographic or implementation problem.  In a bitcoin world that might more be a spare implementation in another language or something.  (Its a common concept in mission critical systems eg spacecraft navigation computer, to have two or three different implementations in different languages, by different programmers, but from the same spec, voting on what is the correct reaction and course adjustment).

Adam

[TierNolan]

But also there is an indirect human utility to having botnets being used for mining - it is a very benign payload compared to other things criminal hacking activities have historically used botnets for.  Maybe spam would even fall if hashcash CPU/GPU mining is a more profitable market than spamming.  It seems to me highly likely that it would be even.  Maybe hashcash beats spammers yet in an incredibly indirect and unexpected way   Thats amusing.

It could also up the price of botnets causing more of them to happen.

Another defensive thought: bitcoin may like to take a leaf from mondex, p2p respendable electronic currency cash card.  They had a hot spare crypto protocol ready and predeployed switched on via peer2peer transfer of signed upgrade notice cards in case of cryptographic or implementation problem.  In a bitcoin world that might more be a spare implementation in another language or something.  (Its a common concept in mission critical systems eg spacecraft navigation computer, to have two or three different implementations in different languages, by different programmers, but from the same spec, voting on what is the correct reaction and course adjustment).

This is why moving away from "the code is the spec" would be helpful.

[mmeijeri]

@Adam:

Would it be possible to use some well-known NP-complete problem (take your pick) for proof of work? Say we hash the transactions, the hash of the previous block etc and derive a random graph for which we solve the travelling saleman problem? The difficulty would be translated to the size of the random graph. Wouldn't this push decision power all the way back to CPUs and the individuals owning them?

[gglon]

Solution to TSP is not easily verifiable - you need to do all the work yourself to verify answer.

[mmeijeri]

You only have to do a polynomial amount of work to verify the answer, with difficulty N being adjustable.

[mmeijeri]

Maybe the boolean satisfiability problem would be a better choice though.

[malditonuke]

I am anti-fork as bad for mindshare, confidence and dilutive of bitcoin and crypto currency value aggregate.

Awwww man  

Seriously though, with all due respect (and with admittance of my conflict of interest here) - alt-coins (or rather, truly innovative alt-coins as opposed to one-two tweak clones) are useful.

They prevent monoculture.

If anything, we need more altcoins pursuing different niches (I feel that there are market niches which BTC, contrary to popular belief, fills imperfectly, allowing for an alt to take that niche without affecting mainstream btc adoption - but that's a long and boring story)

1. Alt-coins
2. Crypto-currency exchange
3. Currency basket

A user can hold bitcoin, litecoin and whatever-coin using any ratio that they deem fit.

[mmeijeri]

Come to think of it, boolean satisfiability isn't such a good choice after all. Hmm. Maybe NP-complete isn't such a good criterion.

[adam3us]

Come to think of it, boolean satisfiability isn't such a good choice after all. Hmm. Maybe NP-complete isn't such a good criterion.

I think one could make a mining function which was fairly hard to gain an advantage with using ASICs.  But I do think you have to target GPUs because a GPU is basically a better CPU.  The CPU has a lot of resources dedicated to optimizing the single thread execution speed (eg super scalarity, out-of-order execution etc).  Alternatively GPUs dont have that.  A 7970 has basically a 2048 RISC cores.  So I think you want to optimize for the characteristics of the GPU.  Memory line size, cache architecture, instruction set.  Make all of those things work hard, and dynamically, but in proportion to the resources the GPU has.  eg some integer instructions, some FP instructions, some memory.

Then a would be ASIC miner has to make a better GPU.  AMD is putting quite a lot of resources into that.

Also I think we could have automatically balanced algorithm mining, including mining parameters.  So the idea is anyone can introduce a new algorithm or new set of algorithm parameters.  Presumably with some public review process so that there is no trapdoor known only to the introducer.  Then each algorithm has a floating separate difficulty set by the network.  The difficulty inflation is set so that the algorithm which appears last susceptible empirically to inflation is he inflation target.  Other algorithms have their difficulty adjusted so that their inflation matches the minimum inflation algorithm.  So eg if SHA256 hashcash mining has a big batch of new fast ASICs come online, to the extent that difficulty gets much harder quickly, the difficulty is increased faster yet so that the proportion of coins producible with SHA256 mining falls and the other mining functions rise.

Adam

[mmeijeri]

Just found this interesting video of the Bitcoin conference:

Dan Kaminsky Predicts The End Of The Current Proof-Of-Work Function

[mmeijeri]

I think one could make a mining function which was fairly hard to gain an advantage with using ASICs.  But I do think you have to target GPUs because a GPU is basically a better CPU.

GPUs wouldn't necessarily bad, because they are consumer hardware with a primary purpose other than mining, and therefore impossible to suppress. But it would be nice if CPUs were still competitive, because the hardcore gamer community too is a very unrepresentative cross-section of society. But because there are so many CPUs, they might collectively still wield considerable influence even if there is a factor of ten performance difference.

[Shevek]

Just found this interesting video of the Bitcoin conference:

Dan Kaminsky Predicts The End Of The Current Proof-Of-Work Function

Actual ASIC-miners will not allow this change. And the have more votes (=hashpower) than anybody.

It's enough for them to reject the blocks with new PoW algorithm.

[adam3us]

Just found this interesting video of the Bitcoin conference:

Dan Kaminsky Predicts The End Of The Current Proof-Of-Work Function

Actual ASIC-miners will not allow this change. And the have more votes (=hashpower) than anybody.

It's enough for them to reject the blocks with new PoW algorithm.

I am not sure the ASICs actually have any protocol choice power.  If bitcoin main developer branch for some reason decided to phase in a new mining algorithm, the choice is actually the users.  If the users agree, they will keep on the main branch and accept the algorithm phase in.  If they dont someone forks the code, and the users migrate over to a new fork.

If there was a code fork like that where both forks accepted the existing coins created up to the fork date as valid, that might be kind of strange sort of like an alt-coin that accepts bticoins up to a hard-fork point in time.

Adam

[kodo]

Wow very interesting stuff in this thread, thanks!

[adam3us]

I think one could make a mining function which was fairly hard to gain an advantage with using ASICs.  But I do think you have to target GPUs because a GPU is basically a better CPU.

GPUs wouldn't necessarily bad, because they are consumer hardware with a primary purpose other than mining, and therefore impossible to suppress. But it would be nice if CPUs were still competitive, because the hardcore gamer community too is a very unrepresentative cross-section of society. But because there are so many CPUs, they might collectively still wield considerable influence even if there is a factor of ten performance difference.

I can see the attraction of CPUs however if you optimized for the CPU to the detriment of the GPU, that leaks possible advantages to ASICs over GPUs.  I think about all you can say that a CPU has is faster single core performance (irrelevant for mining: more compute bandwidth is more important than per core speed).  And main memory readable over a narrow bus (DDR3 64-bit vs DDR5 over 384-bit).  GDDR5 in an AMD 7970 is quad-pumped at 1500MT with 384-bit data bus where as DDR3 is dual-pumped a 1333MT or 1600MT etc similar speed.  So if you are reading random chunks in CPU friendly 64-bit chunks the GPU ram is still 2x speed (quad vs dual pump) even though its 6x bus-width advantage is wasted for random access.  However i7s have two memory channels so they match the GPU for 64-bit reads.  Some CPUs eg 3930k have quad channels so they can do 2x that and beat a GPU.  i7 3930k rated at 51.2GB/sec memory, regular i7 at 25.6GB/sec bandwidth, amd 7970 rated at 288GB/sec but in terms of ability to read 64-bit chunks the 7970 would do 6x less = 48GB/sec.

However the peak figures are in sequential read, DDR3 and GDDR5 are both slower with random reads.  And thrashing RAM with reads for data intentionally too big to fit in L3 is going to bog your computer down for normal use.

Adam

[adam3us]

I can see the attraction of CPUs however if you optimized for the CPU to the detriment of the GPU, that leaks possible advantages to ASICs over GPUs.  I think about all you can say that a CPU has is faster single core performance (irrelevant for mining: more compute bandwidth is more important than per core speed).  And main memory readable over a narrow bus (DDR3 64-bit vs DDR5 over 384-bit).

Another thing CPU cores have going for them over GPU is they are independent.  AMD GPU cores are in SIMD groups, eg 7970 has 2048 cores, but groups of 16 of them have to execute the same instruction each clock on different data, that means if you force them to do dynamic work, there are only really 128 cores that can do independent dynamic work.  And the cores are about 32x slower than a CPU core.  So then a four core CPU matches a GPU for dynamic workloads.

However again that is not a good ASIC-hard direction because the SIMD nature of AMD GPUs is overcomeable eg http://www.adapteva.com with a MIMD (ie no SIMD restrictions) 28nm 64 core risc CPU and plans for 1024 even 4096 risc cores per chip.  And they are low energy too.

Adam

[mmeijeri]

In addition to using memory-hard hashing algorithms, would it be useful to investigate choosing a hashing function that requires the hashing core to be of similar complexity as a typical CPU execution unit? I'm thinking of something that uses multiplication, division and modular reduction relative to some large prime number, and elliptic curve group operations rather than the typical rotate, xor and addition modulo 2^n operations. If necessary we could always xor the result with an ordinary SHA256 hash.

[bluemeanie1]

 the solution is to remove mining altogether:  https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing

[mmeijeri]

However again that is not a good ASIC-hard direction because the SIMD nature of AMD GPUs is overcomeable eg http://www.adapteva.com with a MIMD (ie no SIMD restrictions) 28nm 64 core risc CPU and plans for 1024 even 4096 risc cores per chip.  And they are low energy too.

On the up side, they are still general purpose hardware. It might be good to have a set of algorithms, so that each class of PoW hardware has at least one it excels at.

[oatmo]

Very interesting thread.

My background is 20 years of designing CPUs/ASICs/GPUs.

A few comments here:

1) There is no computational problem that you can't design custom ASIC hardware to do faster than a GPU. The extent faster is a function of the types of operations used. If you use multiply and divide, the advantage will be less. Using AND/OR/XOR logical functions makes the advantage more. ASICs will always kill the CPU in control, because general purpose code runs tons of instructions for control flow, these all make a few small gates in HW. The more complicated the decisions, in general custom HW will have a bigger advantage.

2) The way to limit ASICs is to have huge memory requirements. This essentially limits all the options at the memory controller. GPUs kill on these APPs because they are optimized around 2 things (1) massive memory bandwidth, and (2) massive numbers of threads. Basically the GPU wants to run 10000 threads at once, and assumes that every memory access is going to miss and go to memory. They are optimized around using all the parallel HW in the GPU. The one thing they suck at is memory latency, so they hide that with large numbers of threads. scrypt is essentially a large memory algorithm, which makes it difficult for ASICs. You can build large memories onto ASICs, but the cost will be probilitively large unless you can run millions of units.

Thinking out load here, the only way that I think you could design an algorithm where it wouldn't be preferred to use GPUs or ASICs, you would need something which has a lot of decisions, large memory, and chaining in the algorithm (scrypt has all these things, but some sort of chaining nonce-nonce, which is really against how the crypto currencies work).

I think a full ASIC implementation will have a unit cost which is much higher than the SHA algorithm in bitcoin, but would still produce an order of magnitude performance improvement over CPUs, but I'm not sure how much better than GPUs. In the end, if it's profitable to do so, people will design custom HW for these tasks. Right now, it doesn't look likely at litecoin's current price, but everything could change. I think if something happened to the bitcoin viability (like corporations coopting it or something like that), then people will switch to litecoin, and then it will be much more profitable.

Oatmo

[mmeijeri]

It's not necessary to prevent ASICs from doing the PoW faster than CPUs / GPUs, just to make sure they don't have more power than the huge installed based of computers bought for other purposes.

[oatmo]

It's not necessary to prevent ASICs from doing the PoW faster than CPUs / GPUs, just to make sure they don't have more power than the huge installed based of computers bought for other purposes.

Ahhh, I think scrypt is going to turn out pretty well for that purpose. I think the diff for a custom designed scrypt chip is likely going to be much smaller than SHA256.

Oatmo

[ecliptic]

Very interesting thread.

My background is 20 years of designing CPUs/ASICs/GPUs.

A few comments here:

1) There is no computational problem that you can't design custom ASIC hardware to do faster than a GPU.

Can we make a proof of work based on the mathematical principles used for rendering video games?  GPUs should be pre-optimized to this task.

Half joking.  But seriously?

x86/x64 CPUs are too unspecialised to have an algorithm made for them i would assume

[mmeijeri]

One consideration that I don't recall reading about before just occurred to me: in addition to having separate difficulties for the two hashing functions, we could also have different reward schedules. Depending on how you do it, this could either increase or decrease the potential controversy over a change in the rules, and help avoid a fork, which would be bad for everybody. If the scrypt-based hash didn't get any reward, it might not alienate the ASIC miners, while it would still give those running scrypt a say in the construction of the blockchain. To do this, you might want to adjust the difficulty so that blocks are created twice as fast to keep the BTC generation on the same schedule.

[mmeijeri]

Intel is adding new SSE instructions for SHA calculations to their processors. While this will not make CPU mining for its own sake profitable, it may make running a mining process in the background whenever your computer is on for other reasons a sensible thing to do. This should help a bit with keeping Bitcoin distributed. It would be nice if the same thing happened for GPUs too.

New Instructions Supporting the Secure Hash Algorithm on Intel® Architecture Processors