5 ms·

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

by AgentME 10y ago

>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 transactions that can be trivially fixed is just a bug. Imagine a mining "optimization" which involved miners making only empty blocks. That goes against why Bitcoin has mining in the first place, and would delay transactions eventually to a halt as more took advantage of the optimization. A trick that only often encourages miners to make empty blocks isn't categorically different, and it's something suboptimal about Bitcoin that can be fixed.

makomk 10y ago
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.
- nullc 10y ago
  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.
  - jlrubin 10y ago
    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.
    - optimiz3 10y ago
      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.
6nf 10y ago
> 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.
- AgentME 10y ago
  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.
  - TD-Linux 10y ago
    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.
  - jcoffland 10y ago
    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?
mrb 10y ago
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.
- mrb 10y ago
  Hah! There is actually a 4th patent for asicboost: https://medium.com/@vcorem/the-real-savings-from-asicboost-to-bitmaintech-ff265c2d305b https://medium.com/@vcorem/the-real-savings-from-asicboost-t... 4 patents (applications) from 4 different holders! This provides enough competing interests that it is even less likely that asicboost will ever turn out to be a "problem".

by AgentME 10y ago

makomk 10y ago

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.

nullc 10y ago
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.
- jlrubin 10y ago
  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.
  - optimiz3 10y ago
    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.

6nf 10y ago

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

AgentME 10y ago
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.
- TD-Linux 10y ago
  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.
- jcoffland 10y ago
  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?

mrb 10y ago

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.

mrb 10y ago
Hah! There is actually a 4th patent for asicboost: https://medium.com/@vcorem/the-real-savings-from-asicboost-to-bitmaintech-ff265c2d305b https://medium.com/@vcorem/the-real-savings-from-asicboost-t... 4 patents (applications) from 4 different holders! This provides enough competing interests that it is even less likely that asicboost will ever turn out to be a "problem".