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

91–100 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#91

Post by MertsA »

wyager wrote: post #5
mjevans wrote: post #2

Wasn't the entire point of picking SHA-256 to both check the integrity of the existing ledger (why it's a hash) AND as a proof of work lottery? The "problem" being that instead of being a proof of actual work, shortcuts in the work were found. It seems then that a good solution would be to force many different types of proof of work. Different basis of hashes are obvious, but maybe some type of actual work every so o…

> The "problem" being that instead of being a proof of actual work, shortcuts in the work were found. The same "problem" occurred when people invented GPU mining, then FPGA mining, then ASIC mining. As long as SHA256 isn't broken, it doesn't matter what kind of speedup miners manage to get; whenever someone finds a big advantage, everyone else uses it soon enough. > Different basis of hashes are obvious "Use more has…

>The same "problem" occurred when people invented GPU mining, then FPGA mining, then ASIC mining. As long as SHA256 isn't broken, it doesn't matter what kind of speedup miners manage to get

This isn't a break of SHA256 obviously but it is a break of the PoW for Bitcoin. The whole point is that you have to hash the same amount of data for each attempt to find a block. ASICBOOST is about not having to hash the same amount of data. This isn't a speedup of the hashing algorithm, this is about avoiding needing to hash the same amount of data for every attempt. Call it an optimization if you want, but Bitcoin was designed with the goal that this wasn't possible.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#92

Post by jlrubin »

hudon wrote: post #84
jlrubin wrote: post #83

Earlier quoted context omitted.

That's one way to read it. Another way is: we are OK with a segwit soft-fork sooner so long as we can later clean it up with a hard-fork and re-enable our optimizations by June 2017. When a hard-fork happens, it can do almost anything, including rewrite a soft fork to be cleaner. Luke Dashjr's hard-fork proposals, fulfilling his end of the HK agreement, did not modify SegWit's commitment, but did modify other annoyin…

> Luke Dashjr's hard-fork proposals, fulfilling his end of the HK agreement, [...] Which proposal are you talking about? Luke proposed a block size decrease , followed by a small increase in a decade... The HK agreement asks for a max block size increase, not a decrease and Luke never proposed such a hard fork. Again, I recommend reading the link I posted so we can discuss without false statements :)

https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize..., which includes a reference implementation. It does optionally include an immediate reduction, followed by a gradual increase. This was developed, as far as I understand, because Luke felt it fulfilled his personal end of the HK agreement -- to develop a hard-fork proposal.

To quote the intro: > The block size limit is reduced to a reasonably safe value (optional), and gradually increased over time, eventually expanding beyond the current limits.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#93

Post by clarkmoody »

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…

Obviously, you don't understand off-chain transactions.

If you do a tad bit of investigation, you will find that your fears are entirely unfounded.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#94

Post by midmagico »

doctorfoo wrote: post #37
clarkmoody wrote: post #24

Earlier quoted context omitted.

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

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…

Actually by the numbers, gmax posts almost more than anyone else in r\btc. So that's just incorrect.

Neither does Blockstream "employ" the developers in a bitcoin-development capacity. The number of people it employs to develop Bitcoin is something like. 1.5. That's out of hundreds of people.

The apparent consensus amongst the literally hundreds of individuals who have contributed to core should be demonstrative of the fact that a majority of technically-aware developers think SW is the safest and best way to increase on-chain capacity—this is a developer majority just by the numbers themselves.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#95

Post by midmagico »

kylebenzle wrote: post #46
ShellGh0st wrote: post #39

Earlier quoted context omitted.

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

That is incorrect. Literally nobody expects blocksize to stay at 1MB permanently. If they did, SW wouldn't exist, since that is a blocksize increase to about 2MB.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#96

Post by midmagico »

lawn wrote: post #33
clarkmoody wrote: post #24

Earlier quoted context omitted.

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

^^^ Summary of /r/bitcoin, for those wondering. Sigh > Bitcoin has had soft forks before. This one will do great many great things for transaction throughput and privacy. It's an inefficient hack. For example: https://medium.com/the-publius-letters/segregated-witness-a-... > Censorship is horrible, but do you have proof that Blockstream supports it? All signs points towards it. Do the Blockstream people even speak ou…

> Do the Blockstream people even speak out against the censorship on /r/bitcoin?

Yes, gmax has, literally every time he is asked about it. His complaint is that r\btc as an organizational/policy difference is a worse place. That's by comparison. -- Which it is, since e.g. users like /u/pagex still haven't been banned after direct physical threats.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#97

Post by clarkmoody »

tlrobinson wrote: post #60

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.

The Core team scaling plan is to do a block size increase after SegWit.

Propagation times have been addressed by multiple technologies, including FIBRE (http://bitcoinfibre.org/).

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#98

Post by midmagico »

timq wrote: post #52
efesak wrote: post #27

Earlier quoted context omitted.

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

> but somehow this paper doesn't propose anything else other than segwit

Literally there's another solution that has nothing to do with Segwit. gmax himself proposed it to block off covert ASICBoost. Here's a link:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

Also, miners do not establish consensus. That is why if a miner mines an invalid block, even if other miners extend it, no nodes will accept it.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#99

Post by midmagico »

shea256 wrote: post #63
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 few red flags came up for me with this post. I feel I have an obligation to post a response to this to clarify some things, lest people less involved in the community come away with a misinformed view. A few facts on the core developers: -- There are hundreds of developers who contribute to Bitcoin Core. Over 50 of them have 10+ commits to Bitcoin Core. -- Blockstream employs 7 of these developers, including Pieter…

> Former project lead Gavin Andresen (no longer associated with the project) is perhaps the most notable opponent.

This is incorrect. Gavin Andresen supports SegWit. Your facts are incorrect:

https://www.reddit.com/r/btc/comments/60i4jl/miners_we_are_a...

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#100

Post by fpgaminer »

_coldfire wrote: post #58
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…

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

Didn't Bitmain themselves confirm their chips support ASICBoost? I mean, they do hold a patent for it ... and tested it. So...

But, sure, that's not proof they've been _using_ covert ASICBOOST on mainnet.

We'll see what happens when the patch gets pushed through that fixes covert ASICBOOST. If Bitmain complains about it, or suddenly their economic strength weakens, then, well...

> Apt username

Yeah ... it's a shame I never pivoted our company into developing ASICs. Would have been nice to have another non-scam company in the mix, but ... such as it is. Nowadays I'd have go raise an order of magnitude more money to get started :/

Post reply on HN