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

121–130 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#121

Post by shea256 »

midmagico wrote: post #99
shea256 wrote: post #63

Earlier quoted context omitted.

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

You're right, I mean that he's opposed to the "segwit only for the near term" plan. IIRC, he is in favor of segwit plus a block size increase.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#122

Post by _coldfire »

fpgaminer wrote: post #100
_coldfire wrote: post #58

Earlier quoted context omitted.

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

Bitmain claims they don't use it on mainnet

https://blog.bitmain.com/en/

>Our ASIC chips, like those of some other manufacturers, have a circuit design that supports ASICBOOST. However, the ASICBOOST method has not been used by us on the mainnet. We have not seen any evidence yet on the main net that anyone has used it in the patented way.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#123

Post by jcoffland »

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

Earlier quoted context omitted.

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

The ASICBOOST encourages empty blocks argument does not make sense to me. How would you permute the Merkel tree without any transactions in it? More transactions would give you more permutations. Does this have something to do with transaction ordering requirements?

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#124

Post by jcoffland »

shea256 wrote: post #66
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…

> Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This is not true at all and highly deceptive. They originally were supportive of doubling the transaction count via an increase to 2MB blocks and then realized they could accomplish this without a hard fork via SegWit. SegWit does in fact allow for 1.7x the number of single-signature transactions per block a…

There is nothing deceptive about saying Core did not deliver on their promise to increase the block size. We still don't have a block size increase. Saying that SegWit provides the promised increase is deceptive. SegWit provides a theoretical 1.7x increase but only if everyone switches to SegWit transactions. To send a SegWit transaction you must upgrade your software, understand how to configure it to send SegWit transactions and be sure that the receiver's software understands SegWit. The only conclusion is that SegWit's effective block size increase will not take effective immediately.

Regardless, Core signed an agreement with a majority of miners that they would implement a block size increase, not an effective block size increase but a real one. They reneged on this promise and are instead telling everyone that they are going to do as they please because miners don't control BitCoin.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#125

Post by jcoffland »

6nf wrote: post #120
shea256 wrote: post #66

Earlier quoted context omitted.

> Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This is not true at all and highly deceptive. They originally were supportive of doubling the transaction count via an increase to 2MB blocks and then realized they could accomplish this without a hard fork via SegWit. SegWit does in fact allow for 1.7x the number of single-signature transactions per block a…

> Block size doubling and cutting transaction sizes in half each double the throughput. You can only cut transaction sizes in half once, but you can always double the block size again. Let's just double the block size?

SegWit does not cut block sizes in half it moves some data out of the main block and in to the SegWit block. Full nodes will need more disk space per transaction with SegWit not less.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#126

Post by jcoffland »

jlrubin wrote: post #18
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…

Another problem with ASICBOOST is that it incentivizes a miner to try to partition the network such that the orphan rate increases, because mining on top of orphan blocks is more profitable. If we have two competing successors (S_1 and S_2) to a Block B, an ASICBOOST miner can mine both simultaneously by creating Chunk 1's with different parent blocks. I call it "The Oliver Twist Attack". Increasing the Oprhan rate i…

This would be easy to detect. Just look for miners who regularly revive orphaned blocks.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#127

Post by jcoffland »

TD-Linux wrote: post #82
jcoffland wrote: post #34

Earlier quoted context omitted.

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

Certain miners implementing ASICBOOST in their ASIC also have a FPGA with DRAM that could be used to find the 4 byte collisions extremely quickly. The calculation can be used for the hundreds of ASICs attached to the FPGA board. It's an easy win.

Right, but we're discussing the cost of finding more than two collisions.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#128

Post by jcoffland »

jlrubin wrote: post #74
jcoffland wrote: post #34

Earlier quoted context omitted.

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

Do you have actual numbers handy? The point is that you only have about 10 mins to work on a block. The longer it takes to compute collisions the less benefit you get from them. That is unless you precompute the collisions using irrelevant transaction data. The collisions must be recomputed everytime one of the transactions used is accepted on the blockchain.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#130

Post by TD-Linux »

jcoffland wrote: post #127
TD-Linux wrote: post #82

Earlier quoted context omitted.

Certain miners implementing ASICBOOST in their ASIC also have a FPGA with DRAM that could be used to find the 4 byte collisions extremely quickly. The calculation can be used for the hundreds of ASICs attached to the FPGA board. It's an easy win.

Right, but we're discussing the cost of finding more than two collisions.

Yes, you ideally want four, as that seems to be the maximum number that the chips support. I believe the zynq is still capable of that.
Post reply on HN