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

81–90 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#81

Post by TD-Linux »

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.

And note that both the overt and covert methods of ASICBOOST work on normal blocks, though they make block generation harder and so likely increase the number of empty blocks seen.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#82

Post by TD-Linux »

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…

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.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#83

Post by jlrubin »

hudon wrote: post #35
jlrubin wrote: post #25

Earlier quoted context omitted.

SegWit + HF does not eliminate this class of optimization. Most SegWit+HF proposals would reorganize the bitcoin header structure so as to be compatible with ASICBOOST-like optimizations.

I see what you're saying, but I don't think you read the agreement. > We understand that SegWit continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months, as originally scheduled. The key part here being that SegWit as a soft-fork is what was agreed to.

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 annoying parts of the protocol (like version numbers -- breaking compatibility on headers) unrelated to block size. I can't speak for Luke, but if someone had told Luke about ASICBOOST's concern with SegWit, I'm sure he would have made his 3 BIPs address that too.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#84

Post by hudon »

jlrubin wrote: post #83
hudon wrote: post #35

Earlier quoted context omitted.

I see what you're saying, but I don't think you read the agreement. > We understand that SegWit continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months, as originally scheduled. The key part here being that SegWit as a soft-fork is what was agreed to.

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

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#85

Post by hudon »

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…

> But to say they reneged on providing a scaling solution is wrong.

Regardless of your position in the debate, to say that many well-known Core developers reneged is absolutely defensible, given than they signed this: https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con...

The agreement between all these parties was that they'd all support a SegWit soft-fork if Core developers also provided code and support for a ~2mb hard fork.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#86

Post by mrb »

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…

Reordering or dropping transactions is a non-issue. All you need to covertly implement Asicboost is dropping 2 random tx on the left side of the tree, and 2 on the right side (out of ~2000!) That's enough combinations to find enough partial merkle collisions. So at worst these 4 dropped collisions will be included in the next block because the next miner, even if he also implements Asicboost, will statistically almost certainly drop 4 different collisions.

And it's not true that a "significant" number of blocks are empty. Only ~2% of them are.

Furthermore the reason some blocks are empty is not due to Asicboost. It's because after a new block is found, there is a small delay until a miner can assemble the new set of txs, and during this period of time the hardware has to mine on something (empty block).

Above all, it would be in an Asicboost miner's interest to include as many tx as possible in order to gain a ~10% increase in revenues from tx fees!

So, no, I disagree that Asicboost is a "problem". It's not. It looks like Gregory Maxwell either misunderstands/misanalyzed the "risks" or is simply dramatizing the situation for his own personal (political) reasons which would be part of his plan (Blockstream's plan?) to attack and discredit large-scale miners in the overall debate of Segwit vs. Bitcoin Unlimited.

Asicboost could hypothetically become a problem only if (a) mining profit margins became very thin caused for example by a multi years period of BTC losing value or remaining flat, (b) if somehow the 3 Asicboost patents (Bitmain's, KnC's, Hanke's) were never licensed to anyone else, (c) if the patents owners actually did evil things by abusing their patent rights, and (d) while all this chaos is happening everyone else sits on their hands instead of ignoring the patent and adding the optimization to their ASICs for the benefit of Bitcoin's health or survival if it came to that...

It's very unlikely that (a) (b) (c) (d) all occur at the same time.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#87

Post by fpgaminer »

TD-Linux wrote: post #64
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…

One minor niggle: Segwit does increase block size, up to a 4MB maximum (though it's expected that most blocks will be about 2.1MB).

I mentioned that in my comment, though I know the comment is a bit long so it's easy to miss :P

But yes, it is a somewhat important detail. It's not a long term fix, but it makes arguments for 2MB hardfork + SegWit a bit ... odd? And a more immediate increase in block size is nice, to hold us over until the proposed "better"* layer 2 solutions show up (Lightning network or otherwise).

* I put that in quotes because I haven't studied the proposed Lightning network or alternatives (if any exist?), so I can't say for sure if they are indeed better. And again, it's irrelevant whether they're better; SegWit is an improvement to Bitcoin regardless of whether those layer 2 solutions pan out for solving transaction congestion.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#88

Post by TD-Linux »

stale2002 wrote: post #72
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 ni…

lukejr is nowhere near the "lead bitcoin developer". Wladimir van der Laan is the Bitcoin Core maintainer, not lukejr. lukejr even maintains his own fork (Bitcoin Knots) for stuff that didn't make it into Core.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#89

Post by fpgaminer »

stale2002 wrote: post #72
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 ni…

I'm happy to have some big blocker perspective, as I know my comment perhaps paints "Big Blockers" in less than favorable light. Not intentionally. It's a bit hard to be completely fair in a short summary, given the events that have occurred, even though those events are likely not the fault of real big blockers.

That said, good technology should _never_ be used as a bartering chip.

I think it's hypocritical of any Bitcoin user to be against SegWit for political reasons. From day 1 Bitcoin has suffered of accusations of being used for illegal and evil activities. And from day 1 we, as a community, have had to fend off those claims saying "Yes, it _can_ be used for illegal activities. But that's not what it's about. It's about a revolutionary technology that, for the most part, will be used for good."

To block SegWit is to go against that ethos, an ethos so embedded into Bitcoin. It's about technology; about changing the world. SegWit enables so many cool new uses for Bitcoin. Can it be used to create off-chain transactions; something some big blockers are against? Sure. But that's no reason to stop good technology. Just like it was no reason to stop Bitcoin itself, just because it _could_ be used for illegal activities.

> 2MB HF + segwit proposal

I don't understand that proposal at all. SegWit _is_ an increase in block size, by on average 2MB. So why have the additional hard fork if the block size is already increasing?

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

The one good thing to come out of this years long battle in the community, is that ultimately users and miners are in charge. If big blockers wanted big blocks, all they have to do is offer them. Offer real specifications and real code with real tests and real study. To date, I've never seen that from the big blocker camp.

I'm not in either camp, really. Small or big. Personally, I think Bitcoin will need to increase block size eventually anyway, whether directly or indirectly. 1MB forever is silly. But nobody has offered a reasonable, long term solution to increasing block size, besides SegWit. Hard forking is very risky. Emergent consensus is risky.

All the big block supporting altcoins I've seen are cobbled together messes. And I'm not speaking as a user; I'm speaking as someone who writes code for a living, implemented the foundation of all modern mining ASICs, and have dealt with the Bitcoin Core code specifically as well.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#90

Post by Kinnard »

jlrubin wrote: post #80
Kinnard wrote: post #77

Earlier quoted context omitted.

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.

Perhaps this is semantic?
Post reply on HN