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

51–60 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#51

Post by 6nf »

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…

> Imagine a mining "optimization" which involved miners making only empty blocks.

Transaction fees are going up and the block reward is dropping so long term this won't be a problem. Miners mining empty blocks will not make money any more.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#52

Post by timq »

efesak wrote: post #27
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…

- there are ~5000 LOC of https://github.com/bitcoin/bitcoin/pull/7910/files and almost 3/4 of these lines are tests. - Segwit actualy block harmful form of ASICBOOST - by "growing majority" you mean handful of chinese miners and 2% of nodes ( http://luke.dashjr.org/programs/bitcoin/files/charts/softwar... )

> - Segwit actualy block harmful form of ASICBOOST

It's - of course - not the only solution to this "problem", but somehow this paper doesn't propose anything else other than segwit, and his conclusion is a typical Bitcoin Core propaganda.

> by "growing majority" you mean handful of chinese miners and 2% of nodes (http://luke.dashjr.org/programs/bitcoin/files/charts/softwar...)

You aren't without knowing that in Bitcoin, miners establish consensus by voting with their hashrate. Nodes count doesn't prove anything because its really easy to host a node. The point is: there is more miners supporting BU than Segwit [1].

[1]: http://xtnodes.com/#bitcoin_classic_blocks

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#53

Post by MichaelGG »

jcoffland wrote: post #32
MichaelGG wrote: post #28

Earlier quoted context omitted.

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.

First of all we aren't talking about weaknesses in hash functions. We are talking about ways to compute hashes faster. > 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. One could then use both SHA1 and MD5 shortcuts.

OK, but having to use both a SHA1 and MD5 shortcut is still going to be more work than using just one of them.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#54

Post by AgentME »

kylebenzle wrote: post #49
AgentME wrote: post #22

Earlier quoted context omitted.

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...

I'm not really sure you replied to the right post, or you might be mixing up some things.

The hackingdistributed article I was criticizing was framing Greg Maxwell as making up the whole ASICBOOST attack as pro-SegWit propaganda. There seems to be a group that's extremely anti-SegWit that thinks that the ASICBOOST news is made up to push SegWit through, and the article is following that pattern.

I wouldn't necessarily call my criticisms "pro-SegWit", but it's definitely not on the mentioned anti-SegWit "side" if someone were to group things by side.

>or some well funded group is spending a lot of money to support SegWit and push Core's agenda.

The operator of Antpool has been one of the people speaking out against SegWit, and it's just been revealed that he most likely has had a huge secret monetary incentive against SegWit and not for the good of the network.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#55

Post by AgentME »

6nf wrote: post #51
AgentME wrote: post #16

Earlier quoted context omitted.

>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…

> Imagine a mining "optimization" which involved miners making only empty blocks. Transaction fees are going up and the block reward is dropping so long term this won't be a problem. Miners mining empty blocks will not make money any more.

ASICBOOST gives a +30% efficiency boost requiring empty blocks in some cases. Transaction fees would have to be more than 30% of the block reward to be make them worth it over ASICBOOST.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#57

Post by AgentME »

fpgaminer wrote: post #40

Besides the technical issues involved here, there's been a lot of political quarrels as well. Here's my run down of them. Note that I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently. As with all things political, take my interpretations with a grain of salt: 1) The Bitcoin network began experiencing congestion due to rise in popularity driving large numbers of t…

Just to add on to this: even ignoring the SegWit incompatibility, ASICBOOST has real downsides. ASICBOOST incentivizes miners to do things like drop transactions or even create empty blocks often, delaying transactions and going against the reason Bitcoin has mining. If it was discovered as Bitcoin was being created, it would have been fixed like any other bug. But now, since it's being used by people known to be very anti-SegWit, some are politicizing the issue as if wanting to fix ASICBOOST is just a petty attack by (pro-SegWit) Core.

Then add on the possibility that the anti-SegWit movement might have been spawned or funded by people secretly using ASICBOOST who had no true philosophical positions about SegWit or the good of the Bitcoin network, and things are looking very... shady.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#58

Post by _coldfire »

fpgaminer wrote: post #40

Besides the technical issues involved here, there's been a lot of political quarrels as well. Here's my run down of them. Note that I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently. As with all things political, take my interpretations with a grain of salt: 1) The Bitcoin network began experiencing congestion due to rise in popularity driving large numbers of t…

Best summary here, came to this thread all excited for some technical talk, a bit disappointing to see it immediately descend into the madness of the reddit-schism and bitcointalk

Feels pointless trying to argue an opinion lately, all the arguments have been made ad nauseum, nothing new is being said, all that exists is a WW1 trench warfare stalemate.

If proven, having Asicboost hardware seriously undermines Wu et al, but fear the fact will change little. People have taken sides, it's very hard to undo such a thing.

Note there currently is no proof of these claims, it's legitimacy from authority, would be wonderful to see some proof, and who exactly did the testing on the chip? In such a highly politicised environment, evidence is far preferable to sledging your opponent for a week and then backtracking once the damage is done.

Regardless, Asicboost would explain recent actions by mining pools that looks like self-harm to outsiders.

### On a lighter note ###

>I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently.

Apt username

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#59

Post by STRML »

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…

I have been a fan of Gun's and the HackingDistributed blog for a long time. It's one of the few sites I regularly read on my RSS feed, and he's one of the few people who really seems to "get" Bitcoin and on-chain scaling.

That said, I am surprised at how much this article seems to miss the point, given his otherwise stellar work. Gun, like many in the field, would agree that one of the defining characteristics of Bitcoin is its decentralization. Why, then, push the narrative that the current state of mining centralization is okay? Furthermore, how could it possibly be fine with him that these groups use a patented process - exclusive patents go against everything Bitcoin stands for - to cement their domination over other miners?

In my opinion, the fact that this was hidden invalidates much of the anti-SegWit rhetoric coming from the miners. We all can agree that the soft-fork is large and complex, but it is well-engineered, well-tested, and solves several hard problems while opening Bitcoin up to a variety of novel scaling situations. Now we learn that the opposition's absolute opposition was based on a hidden advantage, not any technical failing of SegWit itself. It is not possible to consider many of these criticisms honestly given this regressive, protectionist hidden motive.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#60

Post by tlrobinson »

This might not be the place for this question, but can someone explain why we can't / shouldn't have both unlimited block sizes and SegWit?

Block sizes will supposedly be constrained by bandwidth / propagation times. SegWit will allow more transactions to occur off chain, reducing the need for larger blocks.

They seem complementary to me.

Post reply on HN