Topic: Why ASIC BOOST is necessary. - page 3. (Read 2175 times)

You seem to confuse "average" and "standard deviation".   You could just as well say that mining with a higher efficiency doesn't make any sense, because the standard deviation on what you are doing is of the same order than your efficiency (for a Poissonian stream).  This is not true of course, because ON AVERAGE you win more, even though your fluctuations are larger than the gain.

Suppose that you win, on average, 10% of the blocks (you have 10% of the total hash rate).   It means you have a probability of 0.1 to win a block.   The standard deviation of "winning one block" is also 10%.  You might say that upping my hash rate from 10 to 15% doesn't make much sense, because the 5% extra is smaller than the variation of my single process chance, 10%.   But of course, in the long term, my revenue has increased with 50% !

BTW, I already explained why I "explain" stuff here: I write out my proper understanding of the thing, and look at the technical arguments against it, to learn from it, which is the sole reason why I am here.

This thread is a good bud sad example of what happens when people don't know what they don't know.

You guys keep writing about ASICBOOST like some godsend. But the best achievable boosting gains are still lower than the manufacturing tolerances in the commercial semiconductor fabrication.

From the AB whitepaper:

	Number of colliding work items	1	2	4	5	8	16
	Gain in percent	0.00	12.50	18.75	20.00	21.9	23.4

So the maximum theoretically achievable gain for a 16-way boosted chip is 23.4% provided that the chip can only work boosted and is no longer capable of mining non-boosted because the 1-way (non-boosted) logic was removed.

Guy Corem of Spoondolies posted his very optimistic estimate that the achievable ASIC gain from boosting is 15% in a chip than can mine both non-boosted and boosted. I consider his estimate to be super-optimistic, in the past he was always giving bombastic predictions.

I'm no longer under any NDA and my experience with semiconductor fabbing relates to the processes now obsolete. The normal commercial manufacturing tolerances then were between +/- 10% and +/- 20%, with the clear trend up: each newer process started with wider tolerances than the previous generation at their inception. So lets make a scientific wild-ass guess that the current acceptable tolerances are +/- 30%.

Note +/- above. Even in the most optimistic assumptions the gain from boosting is within the margins of normal manufacturing variation.

You guys keep making completely wild extrapolations from your initial bad assumption.

The reality is that if the guy at the fab does something like eat phosphorus-rich food (e.g. fish) (Ph is a n-dopant for Si) and neglects the customary crouching when sneezing in the fab, he is apt to more affect the mining chip performance than the ASICBOOST. When some gal at the fab doesn't wash down her aluminum-containing makeup (Al is a p-dopant for Si) before entering the clean rooms at the fab she will have more effect on the mining that what you are discussing.

I can't say that you are spewing bullshit, because the typical bullshitters are aware that they are bullshitting.

But the net-effect of your discussion is quite similar. Please have mercy on us and yourself. We are drowning in whatever you are spewing.

Well, of course, in a permissionless, trustless system, all parties are supposed to act out of self interest.  So what is "an attack on bitcoin" ?
It can mean two things, that touch upon the immutability of bitcoin:
- its protocol
- its transaction history

I was essentially talking about the transaction history, because the *cryptographic protection by PoW* only protects that, of course.  Miners pushing BU don't do this, I think, in order to modify the transaction history.   

So the only thing left, as an "attack" is the desire to modify the protocol.  But then, anyone wanting to modify the protocol, in the first place, Core with its segwit, is an attacker of bitcoin.  As I think that BU was only a way to keep segwit away, because small blocs and high fees are a benefit to miners, you could then even say that BU backing to keep off segwit, was in fact, protecting the current protocol of bitcoin from Core's Segwit attack, that wants to modify it.   
If you see "modifying the protocol" as an attack, then anything else but the current bitcoin protocol (including 1 MB blocks) is an attack.  And if you are considering that protocol modifications are to be envisioned, then increasing the block size is just as well a possible protocol modification than introducing segwit, so if one is an attack, the other is one too.

That depends on how you see it. Some might see Bitcoin Unlimited as an attack to BTC itself. They presume that some of the miners are acting together on their own self interest by rallying behind the hard fork. Bitmain also made their intentions clear of using their power to kill the original chain.

BTC never needs protection from miners, as miners are those that provide the protection.  BTC needs protection from attackers, that want to redo the history of transactions (orphan long pieces of chain on purpose).

BTW, should your remark also apply to the standard algorithm, where the first compression function is not re-calculated ?

In fact, all of these strategies of improved calculation come about because the PoW principle was somehow clumsily designed.  For instance, if SHA-512 had been used, no such techniques would have been possible, as there was only one single compression round to be had ; and if the nonce were not way too small (only 32 bits !) and were "distributed" over the whole header, that would have made any "strategy" impossible.

If ASIC BOOST is necessary can somebody also say that a POW UPGRADE is necessary too? The reason is to improve the security of BTC and to protect it from crafty miners who can find the ability to conceal that they are using ASIC BOOST.

Mining profit margins for Jihan Wu will be a lot higher than that, because BITMAIN's mining facilities are based in China with very low electricity costs and a high profit margin anyway.  It wouldn't actually be that extreme, although you do have a point that it's not just 20% for practical purposes.

what make you think that those "other miners" don't have access to asic boost, it's not different than gpu mning in the end everyone will have the same speed, this is about more efficiency but it's the same

if all miners have the same advantage no miner have any advantage

My point is that ANY increase in efficiency of PoW calculations, when publicly known, is necessary to implement by miners.  By efficiency, I mean the ratio between the difficulty attained, and the economic cost related to it.  Because the cryptographic protection of the bitcoin block chain only comes from the economic cost of attaining the difficulty in the "false" chain.  Any means that lowers this cost to the attacker, lowers the security of the "good" chain, unless the miners (those making the good chain) use (at least) the same efficiency increase.

ASICBOOST is not a necessary one at present, but the miners group who have been supporting Bitcoin Unlimited have made it effective for the mining purpose describing it as the effecient mining booster which helps with reduction of power and the major concern with the usage is to delay the segwit activation when it suddenly started to gain support from more than 60% miners.

Like ASICS offered monumental competitive advantage over GPU miners.  What's the difference ?  Are you whining that now happens to the non-asicboost asic miners, what they did to the GPU miners back long ago ?

But what about cryptographic PoW security, also dimished by 20% because of the knowledge of ASICboost ?

And what about the fact that the standard mining algorithm is already "not calculating the complete work" and skips about 25% of it ?

By this last point, I mean that if the difficulty is, say, 2^30, then on average NOT 2^30 complete header hashes have been calculated with the standard algorithm either, that is not all the naively "proved work" has been done either.

Current mining profit margins are roughly 1%.

ASICBOOST increases power efficiency 20%.

That increases profit margin to roughly 20%.

That is a two thousand percent increase in profit margin for anyone using an ASICBOOST compatible miner.

That, and that alone, is the only reason anyone would be in favor of it.  It offers a monumental competitive advantage over other miners.

Yes.  But not for matters of "fairness", but rather for matters of the inherent cryptographic security requirements (which are very bad !) of PoW.  PoW security is based upon the attacker needing to spend at least as much economical effort than the "good guy" (in PoW crypto, the good guy is by definition, the miner that ADDS a block, because he's the one determining the latest consensus).  The "bad guy" is the one trying to modify former consensus for other reasons than "orphaning by error", in order to reverse a transaction (and double spend) ; censor a transaction (DoS), ....  If techniques are known to the bad guy, that the good guy is not supposed to use, then the economic cost of an attack becomes less than than the cost of making the original consensus !


Well, I haven't studied that part, but I have a hard part imagining that asicboost cannot be applied to whatever change in the protocol.  Maybe the calculations have to be re-organized or so, but, without having looked into it in detail, I don't see at first sight how you cannot use ASIC BOOST, because the way I understand it, it is just a smarter re-organisation of calculations that have to be done *in any case*.  So essentially, instead of doing them over at random orders, you organize them better so that you can re-use calculations you would simply do over without thinking.  But maybe that the *way* of organizing this is different with a new protocol, and maybe that this screws up the way it is *currently* implemented. (*)

I wanted to point out too, that already now, the standard way of doing the hash calculations, does a very similar thing, by organizing the calculations in such a way that a lot of them don't have to be stupidly re-done: the first compression function call is NOT re-done when looping over the nonce that only occurs in the second block.  So "organizing your calculations so that you don't do all explicit full hashes of all tested blocks, but re-use results" is already standard practice.  Asic boost simply pushes this somewhat further.

(*) The reason why I think that, is simply the following, but as I said, there may be technicalities that escape me, as I didn't look into it.

What happens now is that there are two fields in the header that can be tuned in order to satisfy the difficulty: there is the nonce, of 32 bits, in the second part of the header, and there is the merkle tree root (32 bytes in total, 256 bits), of which 28 bytes are in the first part, and 4 bytes (32 bits) are in the second part.
The trick of ASIC boost is that instead of using the merkle tree roots that one needs to try in an arbitrary order, one can organize them in chunks where the 4 last bytes are the same (that happens once for every 65000 merkle tree roots tried, so if you're going to try a billion merkle tree roots, you use them in packets of about 15000 roots with the same last 32 bits, and then you try for each nonce value, the 15000 roots first, and you have to re-calculate the "key schedule" of the second block only once in 15000).

I don't see how this will change if we keep the same header structure.  Maybe the way the Merkle tree will have to be calculated will be different, but it is the only handle one has, next to the nonce, which is too small.  So I don't see how asic boost in some or other form, will go away.

when core use a backdoor to go soft its called a "potential improvements to the protocol"
when anything else wants to use it its called an attack.

ask yourself:
if hearne made segwit with the intention of offering future backdoors to be made easier to do things soft for things like commercial LN hubs for banks. where the code was line for line exactly the same as blockstreams..where the only difference is WHO implemented it

would you call segwits half baked code a "potential improvements to the protocol" or an attack on bitcoin.

would you then think that filling that backdoor by allowing the mining community to secure bitcoin further with a higher difficulty by allowing asic boost an efficiency benefit


think open minded
having a back door where code changes can be slid in without needing node consensus.. vs  allowing mining to be more efficiently done to increase difficulty. which would you choose.

remember saying let the coders have the back door and keep bitcoin miners from being 20% efficient can be used against bitcoin by outside parties.

But to create a level playing field, it requires a change to render AsicBoost useless. This has to be a fork, or the AsicBoosters just use an older version of the software.

You aren't really arguing that AsicBoost itself is necessary. You are arguing that a level playing field is necessary.

I totally agree with that, but a level playing field without AsicBoost is preferable because it interferes with potential improvements to the protocol.

I think you make some good arguments for it.

What about the difference between overt and covert boosting and what are the detrimental affects on the network by using these techniques?

Would the patents hold up in court?