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

111–120 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#111

Post by midmagico »

hudon wrote: post #23
jlrubin wrote: post #4

Earlier quoted context omitted.

The problem with the proof of work is that the machinery became dependent on the selection of transactions in the block. A "standard" miner does not have this dependency. It's not a problem (depending on who you ask) that an optimization was found, the amount of work expended is still the same. It's not clear that switching proof of works would eliminate this class of concern. It's also clear that eliminating this cl…

> It's also clear that eliminating this class of problem is not in the interest of the miners, hence the opposition to SegWit Most miners have been supportive of SegWit for at least a year, see the HK agreement: https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con... The agreement was that they'd support it if it came with a 2mb hardfork, and it never did. Sergio Lerner released segwit2mb recently, which the…

No, instead of came with a 4MB softfork, which is a strictly superior alternative, since for all the reasons they support extblocks, SegWit is completely superior.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#112

Post by midmagico »

Taek wrote: post #42
jcoffland wrote: post #9

Earlier quoted context omitted.

Then Bitcoin has to hard fork every time someone comes up with a new patentable idea. I don't see why people think mining must be fair. It only has to not become completely centralized.

Someone who can control the majority of the hashrate can enforce a transaction whitelist. Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.

> Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.

Too late. :-)

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#113

Post by midmagico »

gcb0 wrote: post #8
petertodd wrote: post #6

Earlier quoted context omitted.

> everyone else uses it soon enough. Unfortunately in this case, ASICBOOST is both patented, and adds a fair bit of complexity to mining hardware. Both these problems have the undesirable effect of increasing the barriers to entry for new asic manufacturers - an undesirable thing from the point of view of Bitcoin users. You're quite correct that shortcuts are irrelevant, but the reality of manufacturing makes the pla…

> both patented and adds complexity just like any CPU or GPU solutions. just because they are more readily available you can ignore it for those cases?

Nobody is saying we have to close off ASICBoost. Just the covert method of it which is incentive-incompatible with important protocol upgrades.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#114

Post by midmagico »

MertsA wrote: post #91
wyager wrote: post #5

Earlier quoted context omitted.

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

Correct! And yet nobody is seriously (i.e. with code in a PR) wanting to completely disable all forms of ASICBoost. Just the covert kind which is incompatible with a bunch of important protocol upgrades and interesting ideas that make Bitcoin stronger.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#115

Post by optimiz3 »

jlrubin wrote: post #78
nullc wrote: post #71

Earlier quoted context omitted.

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.

A SegWit commitment on the left hand side causes any permutation on the right hand side to force a recalculation of the left hand side.

This is still a non-issue as a solid GPU farm can crunch the SegWit version trivially and there are ASICBOOST compatible optimizations for SegWit that have not been publicly discussed.

One should look at the R&D on ZCash's equihash to see some of the work that has gone into collision finding.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#116

Post by jlrubin »

Kinnard wrote: post #90
jlrubin wrote: post #80

Earlier quoted context omitted.

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?

It's not semantic, it is substantive. A maximally utilized SegWit block is larger than a maximally utilized current block.

I.e., if you were planning out how much disk space you needed years in advance, you would have to increase that figure non-negligibly if SegWit activates.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#117

Post by hudon »

jlrubin wrote: post #92
hudon wrote: post #84

Earlier quoted context omitted.

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

Thanks for the link with details. As you can see, the proposed hard fork starts with a decrease to ~300k. The increase past 1mb starts in 2024... that is in 7 years.

It's not hard to see that this fails to meet the bar of a 2mb hard fork now. Luke is playing a game, basically saying: "you didn't specify exactly what year you wanted the block size increase in ;)"

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#118

Post by makomk »

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?

Not really. SegWit transactions are on-blockchain like any other - the only difference is that nodes which aren't keeping a full copy of the blockchain can save some extra space by discarding the witness part immediately after processing the block. (So I guess if you wanted to be pedantic you might be able to argue the witness part is off-blockchain in some sense, but even then the transfer of bitcoins still happens on the main blockchain.)

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#119

Post by swedrupe »

9 months ago people already claimed on Reddit that Antminer H/W was using AsicBoost.

This story seems just being dug up now by GMax for one or more of several reasons:

* discredit Jihan / Bitmain / AntPool who support BU

* distract from SegWit problems, buy time

* solidify the "Chinese miners bad, Core good" narrative to support UASF, SegWit's final death throw

* maybe give BitFury and other ASIC manufacturers some more business by scaring customers away from Bitmain

In truth, there's no emergency or attack from ASIC manufacturers on Bitcoin, mining is more decentralized than before through many pools. This is about the politics of a small clique in the incumbent dev team who don't want to let go of power, at all costs, nor do they seem to be very worried about what happens to Bitcoin because of their unwillingness to compromise and even to deliver on their agreements.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#120

Post by 6nf »

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…

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

Post reply on HN