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

71–80 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#71

Post by nullc »

makomk wrote: post #50
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…

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.

This is perhaps misinformed. There is not reason to deal with transaction dependencies because permutation is just one option and not an especially attractive one.

Without protocol upgrades that include commitments to other parts of the block (E.g. committed utxo, committed bloom filters, stxo, segwit, fraud proofs, etc) you can simply compute 4096 variations of left- side of the tree by altering the coinbase transaction and 4096 versions of the right side of the tree by just substituting any transaction on the right side with alternatives. Then combine the two in to the ~2^24-ish needed for a collision with only a single operation per try which is independent of the size of the block.

The lack of a commitment gets you another effective sqrt speedup and makes all the other costs negligible.

Now, as far as permutation goes, if you want to permute instead of replace you need only permute 7 transaction on the right side to get the variations you need. Virtually no blocks with more than a dozen transactions don't have at least 7 on the right side with no dependencies at all.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#72

Post by stale2002 »

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…

Hey, the big reason to oppose segwit is mostly as a negotiation tactic.

Many of the bitcoin developers , small blockers, and the blockstream people really, REALLY want segwit to activate.

They are so desperate to have it, that although they may not explicitly agree to a "compromise" 2MB HF + segwit proposal, they might at the very least not go freaking nuclear or something in their attempts to oppose it.

Segwit is nice, sure. But us big blockers know that if it gets activated now, then we are never going to see big blocks, regardless of how much support we get.

Don't believe me? Just check out some of the stuff that lukejr (the lead bitcoin developer) says.

They explicitly say that it could be decades before any more block size increases come around.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#73

Post by [deleted] »

stale2002 wrote: post #69
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 does not want blocksize increases. They explicitly want prices to be high/number of transactions to be limited (think, supply and demand) . This is because transaction "price" is equivalent to "amount of money spent on securing the blockchain".

[deleted]

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#74

Post by jlrubin »

jcoffland wrote: post #34
jlrubin wrote: post #17

Earlier quoted context omitted.

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.

> The more collisions you can find, the more hash per second you should be able to gain. But the chance of finding three blocks with the necessary 4 byte collision is much more difficult. It's the same problem as finding 3 people with the same birthday. You need 87 people to have a 50/50 chance of three people having the same birthday vs. 23 for two people who share a birthday. That's nearly a 4x increase in required…

It's not that big of a computation even at 4 collisions, but yes, I'm familiar with the math (I wrote the PDF).

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#75

Post by timq »

verroq wrote: post #45
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

I hope people on Hacker news doesn't get duped by all the toxic people dismissing BU and promoting Core. The facts are that r/Bitcoin and bitcointalk.org, both owned by theymos and a handful of other people, are paid by Blockstream to censor any dissident opinions. About the ongoing censorship, have a look to this article [1], which is a compilation of facts, it's very depressing. Up to a point where a second subreddit /r/btc full of banned people have almost half of the active user of /r/bitcoin, despite its relative young age.

Bitcoin core also organize troll campaigns [2], push for a radical, unwanted change of Bitcoin with SegWit, coordinate attack on nodes when a vulnerability is discovered [3], and spread FUD everyday, sometimes technical nonsens like this very non-issue that is ASICBOOST. Those people work fulltime to stole bitcoin from the community, thanks to the huge bank account of Blockstream, the company behind all this shit show.

At least this proove that Bitcoin rely on a very solid basis, because despite having 75 million in bank, blockstream opted to corrupt core developpers and community managers instead of competing for hashrate. But still, the situation is pretty bad right now.

[1]: https://news.bitcoin.com/brief-history-censorship-bitcoin/

[2]: http://telegra.ph/Inside-the-Dragons-Den-Bitcoin-Cores-Troll...

[3]: https://www.reddit.com/r/btc/comments/5zgefe/this_was_an_orc...

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#76

Post by zik »

futuravenir wrote: post #26
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…

I want to say that I've been on the anti-censorship boat and the 'AXA money is sketchy' and the unlimited train for as long as I've heard of it. Just recently, someone in the ecosystem that I've known since the beginning of my time with Bitcoin came out in support of Blockstream and Segwit with a backing of other Canadian support. https://medium.com/@francispouliot/canadian-bitcoin-economic... I don't know what to ma…

That was the exact point of the ASICBOOST FUD we've seen in the last week - to cast uncertainty and doubt. Taking a step back though it all seems like just the latest attempt to distract from real issues. ASICBOOST is just another optimisation from companies who make their living working on these kinds of things. It's been known about for many months now so the last few days just seem like a bizarre attempt to demonise the miners for doing what they do.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#77

Post by Kinnard »

shea256 wrote: post #70
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.

SegWit does in fact represent a block size increase. It results in 1.7x the # of single-signature transactions per block and 4x the # of multi-signature transactions per block. Unlimited block size? There are many reasons that's a very bad idea but here are a few: 1. It would put immense pressure on the network in terms of latency between miners, leading to less stable mining, a higher rate of reorganizations, and a…

That's not an increase in the size of the block per se, as much as it is an increase in the efficiency of encoding off-Blockchain information, no?

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#78

Post by jlrubin »

nullc wrote: post #71
makomk wrote: post #50

Earlier quoted context omitted.

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.

This is perhaps misinformed. There is not reason to deal with transaction dependencies because permutation is just one option and not an especially attractive one. Without protocol upgrades that include commitments to other parts of the block (E.g. committed utxo, committed bloom filters, stxo, segwit, fraud proofs, etc) you can simply compute 4096 variations of left- side of the tree by altering the coinbase transac…

Greg, I think the recursive algorithm should still be faster on the left hand side than just rolling the coinbase extra nonce, but after the first sqrt the numbers are pretty small so maybe the constants dominate.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#79

Post by jlrubin »

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…

Thanks Ryan, these are good clarifications to the parent's post.

For full transparency, I [OP, author of the PDF] am currently contracting with (but am not employed by) Chaincode and am currently #39 by commits (#26 by additions though! ;)). I also think that SegWit is the best way forward; no one pays me to say that.

If Blockstream sent money to developers to endorse SegWit, they must have skipped me!

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#80

Post by jlrubin »

Kinnard wrote: post #77
shea256 wrote: post #70

Earlier quoted context omitted.

SegWit does in fact represent a block size increase. It results in 1.7x the # of single-signature transactions per block and 4x the # of multi-signature transactions per block. Unlimited block size? There are many reasons that's a very bad idea but here are a few: 1. It would put immense pressure on the network in terms of latency between miners, leading to less stable mining, a higher rate of reorganizations, and a…

That's not an increase in the size of the block per se, as much as it is an increase in the efficiency of encoding off-Blockchain information, no?

No, it is a space increase! Witness data is counted with a discount. Blocks can be larger than 1MB under SegWit.
Post reply on HN