Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin's ASICBOOST Problem Explained [pdf]

rubin.io

Post reply on HN
Print view View original

41–50 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#41

Post by makomk »

jlrubin wrote: post #17
tromp wrote: post #13

Earlier quoted context omitted.

The AsicBoost inventors also wrote a good technical explanation at https://arxiv.org/pdf/1604.00575v1

Notably, they don't include the optimal root generation algorithm, nor do they discuss segwit incompatibilities. Also, their 20% figure is unclear. The more collisions you can find, the more hash per second you should be able to gain.

Indeed. As I understand it, the core Bitcoin developers only fully figured out how the covert version of ASICBOOST was implemented in practice and realised that it was incompatible with not just Segwit but a whole class of Bitcoin extensions a few days ago: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... Think about that. It looks like miners had been blocking a scalability extension for over a year not because of any of their stated complaints against it, but because they'd secretly rolled out hardware using a secret acceleration technique that was incompatible with extending Bitcoin. That's scary. (There's some explanation of which other kinds of improvements it'd block in the follow-up here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... ) Furthermore, the miners in question were apparently plotting a Bitcoin protocol change without public discussion whose actual purpose appeared to be permanently blocking such future enhancements: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#42

Post by Taek »

jcoffland wrote: post #9
shea256 wrote: post #7

Earlier quoted context omitted.

Exactly, I'd go further and say that if a particular technique is patented and cannot be matched by a related technique, giving a permanent unfair advantage, it is up to the community to change the proof of work and work around the advantage imposed by a state monopoly.

Then Bitcoin has to hard fork every time someone comes up with a new patentable idea. I don't see why people think mining must be fair. It only has to not become completely centralized.

Someone who can control the majority of the hashrate can enforce a transaction whitelist. Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#43

Post by Taek »

tlrobinson wrote: post #15
jcoffland wrote: post #9

Earlier quoted context omitted.

Then Bitcoin has to hard fork every time someone comes up with a new patentable idea. I don't see why people think mining must be fair. It only has to not become completely centralized.

But if one miner has a significant advantage for a long enough time then mining will become unprofitable for everyone else, ultimately leading to nearly complete centralization.

People forget that profits can be reinvested. If one miner has 10% extra profits, they will have 10% extra hashrate growth. This leads to effective monopoly.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#44

Post by lmm »

MichaelGG wrote: post #28
jcoffland wrote: post #11

Earlier quoted context omitted.

> It seems then that a good solution would be to force many different types of proof of work. This would create many more opportunities for finding shortcuts like ASCIBOOST. Some of them might be much worse.

Really? Suppose both a SHA256 and a SHA1 hash were needed. How could it be possible that it's easier to find a simultaneous weakness in both? I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently.

> I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently.

Even a crappy 256-bit hash (by using two 128-bit hashes) will probably be more secure than a (single) 128-bit hash, sure. But it won't be anywhere near as secure as a proper 256-bit hash. If you can afford 256 bits of hash, the best way to spend them is on a dedicated 256-bit hash.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#45

Post by verroq »

timq wrote: post #20

Just to point out that SegWit is everything but "already adopted in the industry". It turns out that SegWit is the solution promoted by the developers of bitcoin core to allow for bigger blocks, and solve some issues like transactions maleability. It's more than 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways. Not to add that a company calle…

>a growing majority of miners

Just a single large Chinese miner trying to hold back progress, who likely has an economic incentive to do so due to his usage of ASICBOOST.

You are severely overestimating the amount of support BU has, and downplaying the support of segwit, which the majority of nodes and Bitcoin companies are supporting.

See here, almost nobody supports BU. https://coin.dance/poli

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#46

Post by kylebenzle »

ShellGh0st wrote: post #39
doctorfoo wrote: post #37

Earlier quoted context omitted.

SegWit is controversial because it is a key part of Core's off-chain scaling roadmap, as opposed to alternative, on chain scaling. It's pure politics: If SegWit "wins", we go down a certain route of scaling and cement Core as being the only group that has control over Bitcoin's future. There are some technical arguments against SegWit but they are largely unrelated to what makes it so controversial. > Blockstream emp…

Yep, it basically looks like core devs have this plan to: -Keep bitcoin broken so fees go sky-high -Push people towards their sketchy off-chain transactions Bitcoin then becomes "bank coin", where large providers handle all the micro transactions and "settle up" with huge 1000+ btc chunks. It's a scam and while I have my own reservations about bitcoin unlimited and making miners "too powerful" at least their plan is…

It is nothing sinister though. It is just when Mr. Maxwell and Dr. Back started Blockstream they expected the 1 mb blocksize to stay 1 mb. On this assumption they built their company and sold their services as "Core" maintainers.

The Fork to a chain that does scale on its own seems inevitable and was fully expected by the original developer. It seems like an uphill battle for Core to convince people to NOT upgrade the network.

The "sketchy" off chain stuff is not sketchy either, it is just off chain. If you mean that they may be able to profit from it, I don't see why that is evil or even wrong, it is just their business plan.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#47

Post by ftlio »

ShellGh0st wrote: post #39
doctorfoo wrote: post #37

Earlier quoted context omitted.

SegWit is controversial because it is a key part of Core's off-chain scaling roadmap, as opposed to alternative, on chain scaling. It's pure politics: If SegWit "wins", we go down a certain route of scaling and cement Core as being the only group that has control over Bitcoin's future. There are some technical arguments against SegWit but they are largely unrelated to what makes it so controversial. > Blockstream emp…

Yep, it basically looks like core devs have this plan to: -Keep bitcoin broken so fees go sky-high -Push people towards their sketchy off-chain transactions Bitcoin then becomes "bank coin", where large providers handle all the micro transactions and "settle up" with huge 1000+ btc chunks. It's a scam and while I have my own reservations about bitcoin unlimited and making miners "too powerful" at least their plan is…

You realize a lot of people pushing the supposedly nefarious agenda you're saying here own a lot of bitcoins, and even belong to companies where timelocked bitcoins act as an incentive program, right? The conspiracy theories surrounding Core's agenda never have sensical incentive structures. This is why nobody listens to the conspiracy theorists when it comes to designing a protocol that relies entirely on incentives adding up.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#48

Post by nomailing »

clarkmoody wrote: post #24
timq wrote: post #20

Just to point out that SegWit is everything but "already adopted in the industry". It turns out that SegWit is the solution promoted by the developers of bitcoin core to allow for bigger blocks, and solve some issues like transactions maleability. It's more than 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways. Not to add that a company calle…

^^^ Summary of /r/btc, for those wondering Sigh > 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways Most of those lines of code are tests. It would be nice for you to say why SegWit is controversial, beyond being proposed around the same time that fees got high. Bitcoin has had soft forks before. This one will do great many great things for tr…

> Censorship is horrible, but do you have proof that Blockstream supports it?

Here is some very strong evidence for it: http://telegra.ph/Inside-the-Dragons-Den-Bitcoin-Cores-Troll...

Obviously, people could always say that there is no proof, because "supporting" is such a vague term. It is hard to come up with a mathematical proof. But I would say, it is already a proof that they participate mostly in /r/bitcoin and not in /r/btc. Reddit depends on participation. Therefore with their participation in censored forums in contrast to uncensored forums they at least indirectly support the censorship.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#49

Post by kylebenzle »

AgentME wrote: post #22
wmf wrote: post #12

Some context: http://hackingdistributed.com/2017/04/05/bitcoin-drama-respo...

I find this article very misleading. >2. If ASICBOOST was actually used, we'd see ample evidence on the blockchain. The covert form of ASICBOOST (where they don't use the version field, the form that was only recently publicly discovered) would only show up as a higher than usual number of empty blocks or blocks with reordered or missing transactions (depending on how the attacker implemented it; it's not necessarily…

Either I am crazy and don't understand bitcoin or some well funded group is spending a lot of money to support SegWit and push Core's agenda.

The few sensible posts like yours are downvoted to hell and back while pro-SegWit rocket to the top. Every point you make is spot on and there is no sensible reply to any of them, just a bunch of garbage about no one supports BU and BU will never happen...

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#50

Post by makomk »

AgentME wrote: post #16
jcoffland wrote: post #10

This is excellent. I've been trying to find a technical explanation of ASCIBOOST for some time. Most of the articles and discussions gloss over the details. It is possible that this is part of the reason some miners are blocking SegWit but there is more to it. Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This pissed a lot of people off and led to the blo…

>I don't see ASCIBOOST as a real problem for Bitcoin. It often incentivizes miners to reorder or drop transactions until they hash to a specific value. (A certain mining pool is publishing a significant number of empty blocks.) Miners exist to verify transactions, and Bitcoin was designed with transaction fees in order to incentivize miners to include transactions. A competing force pushing miners away from including…

I believe it also probably incentivizes miners to create smaller blocks full stop, since dealing with transaction dependencies - something this glosses over - means that the cost will likely scale with the number of transactions. This rather undercuts the supposed block size scaling justification for opposing Segwit, to put it mildly.
Post reply on HN