4 ms·

Notably, they don't include the optimal root generation algorithm, nor do they discuss segwit incompatibilities. Also, their 20% figure is unclear. The more co

by jlrubin 10y ago

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.

jcoffland 10y ago
> 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 computation for a small increase in effective hash rate.
- jlrubin 10y ago
  It's not that big of a computation even at 4 collisions, but yes, I'm familiar with the math (I wrote the PDF).
  - jcoffland 10y ago
    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.
- TD-Linux 10y ago
  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.
  - jcoffland 10y ago
    Right, but we're discussing the cost of finding more than two collisions.
    - TD-Linux 10y ago
      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.
makomk 10y ago
Indeed. As I understand it, the core Bitcoin developers only fully figured out how the covert version of ASICBOOST was implemented in practice and realised that it was incompatible with not just Segwit but a whole class of Bitcoin extensions a few days ago: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... Think about that. It looks like miners had been blocking a scalability extension for over a year not because of any of their stated complaints against it, but because they'd secretly rolled out hardware using a secret acceleration technique that was incompatible with extending Bitcoin. That's scary. (There's some explanation of which other kinds of improvements it'd block in the follow-up here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014000.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... ) Furthermore, the miners in question were apparently plotting a Bitcoin protocol change without public discussion whose actual purpose appeared to be permanently blocking such future enhancements: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014003.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

by jlrubin 10y ago

jcoffland 10y ago

> 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 computation for a small increase in effective hash rate.

jlrubin 10y ago
It's not that big of a computation even at 4 collisions, but yes, I'm familiar with the math (I wrote the PDF).
- jcoffland 10y ago
  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.
TD-Linux 10y ago
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.
- jcoffland 10y ago
  Right, but we're discussing the cost of finding more than two collisions.
  - TD-Linux 10y ago
    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.

makomk 10y ago

Indeed. As I understand it, the core Bitcoin developers only fully figured out how the covert version of ASICBOOST was implemented in practice and realised that it was incompatible with not just Segwit but a whole class of Bitcoin extensions a few days ago: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... Think about that. It looks like miners had been blocking a scalability extension for over a year not because of any of their stated complaints against it, but because they'd secretly rolled out hardware using a secret acceleration technique that was incompatible with extending Bitcoin. That's scary. (There's some explanation of which other kinds of improvements it'd block in the follow-up here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014000.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017... ) Furthermore, the miners in question were apparently plotting a Bitcoin protocol change without public discussion whose actual purpose appeared to be permanently blocking such future enhancements: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014003.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...