9 ms·

Wasn't the entire point of picking SHA-256 to both check the integrity of the existing ledger (why it's a hash) AND as a proof of work lottery? The "problem" b

by mjevans 10y ago

Wasn't the entire point of picking SHA-256 to both check the integrity of the existing ledger (why it's a hash) AND as a proof of work lottery? The "problem" being that instead of being a proof of actual work, shortcuts in the work were found. It seems then that a good solution would be to force many different types of proof of work. Different basis of hashes are obvious, but maybe some type of actual work every so often as well.

jlrubin 10y ago
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 class of problem is not in the interest of the miners, hence the opposition to SegWit (which does exactly that).
- hudon 10y ago
  > 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-consensus-266d475a61ff 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 miners support, but many Core devs were vocal about their opposition to that.
  - jlrubin 10y ago
    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.
    - hudon 10y ago
      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.
      - jlrubin 10y ago
        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.
        hudon 10y ago
        > 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 :)
        jlrubin 10y ago
        https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki 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 (optional), and gradually increased over time, eventually expanding beyond the current limits.
  - midmagico 10y ago
    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.
wyager 10y ago
> 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 hash functions" is sort of a reflexive response you get a lot from non-cryptographers, but the intuitive reason this is a bad idea is that if your hash function isn't broken, your cryptosystem shouldn't be either. It's better to fix the cryptosystem than to half-assedly patch it over by obfuscating any problems with more hash functions. > but maybe some type of actual work every so often as well. What do you mean by "actual work"? In all likelihood, whatever you're thinking of has none of the properties that make PoW a viable mechanism for sybil resistance.
- petertodd 10y ago
  > 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 playing field a lot less level than we'd like.
  - shea256 10y ago
    Exactly, I'd go further and say that if a particular technique is patented and cannot be matched by a related technique, giving a permanent unfair advantage, it is up to the community to change the proof of work and work around the advantage imposed by a state monopoly.
    - jcoffland 10y ago
      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.
jcoffland 10y ago
> It seems then that a good solution would be to force many different types of proof of work. This would create many more opportunities for finding shortcuts like ASCIBOOST. Some of them might be much worse.
- MichaelGG 10y ago
  Really? Suppose both a SHA256 and a SHA1 hash were needed. How could it be possible that it's easier to find a simultaneous weakness in both? I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently.
  - jcoffland 10y ago
    First of all we aren't talking about weaknesses in hash functions. We are talking about ways to compute hashes faster. > But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently. One could then use both SHA1 and MD5 shortcuts.
    - MichaelGG 10y ago
      OK, but having to use both a SHA1 and MD5 shortcut is still going to be more work than using just one of them.
      - yorwba 10y ago
        But it's less work than having to compute both SHA1 and MD5 without shortcut, which is the comparison that matters.
  - lmm 10y ago
    > I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently. Even a crappy 256-bit hash (by using two 128-bit hashes) will probably be more secure than a (single) 128-bit hash, sure. But it won't be anywhere near as secure as a proper 256-bit hash. If you can afford 256 bits of hash, the best way to spend them is on a dedicated 256-bit hash.
midmagico 10y ago
> The "problem" being that instead of being a proof of actual work, shortcuts in the work were found. Nope, the problem is that covert ASICBoost mining has created a strong, valuable incentive for miners to oppose protocol upgrades while supporting much more destructive ones like the recent extblocks, which is susceptible to instantaneous, irreversible full transaction invalidation on a reorg. ASICBoost in its other forms is completely compatible with SegWit.

by mjevans 10y ago

jlrubin 10y ago

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 class of problem is not in the interest of the miners, hence the opposition to SegWit (which does exactly that).

hudon 10y ago
> 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-consensus-266d475a61ff 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 miners support, but many Core devs were vocal about their opposition to that.
- jlrubin 10y ago
  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.
  - hudon 10y ago
    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.
    - jlrubin 10y ago
      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.
      - hudon 10y ago
        > 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 :)
        jlrubin 10y ago
        https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki 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 (optional), and gradually increased over time, eventually expanding beyond the current limits.
- midmagico 10y ago
  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.

wyager 10y ago

> 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 hash functions" is sort of a reflexive response you get a lot from non-cryptographers, but the intuitive reason this is a bad idea is that if your hash function isn't broken, your cryptosystem shouldn't be either. It's better to fix the cryptosystem than to half-assedly patch it over by obfuscating any problems with more hash functions. > but maybe some type of actual work every so often as well. What do you mean by "actual work"? In all likelihood, whatever you're thinking of has none of the properties that make PoW a viable mechanism for sybil resistance.

petertodd 10y ago
> 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 playing field a lot less level than we'd like.
- shea256 10y ago
  Exactly, I'd go further and say that if a particular technique is patented and cannot be matched by a related technique, giving a permanent unfair advantage, it is up to the community to change the proof of work and work around the advantage imposed by a state monopoly.
  - jcoffland 10y ago
    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.

jcoffland 10y ago

> It seems then that a good solution would be to force many different types of proof of work. This would create many more opportunities for finding shortcuts like ASCIBOOST. Some of them might be much worse.

MichaelGG 10y ago
Really? Suppose both a SHA256 and a SHA1 hash were needed. How could it be possible that it's easier to find a simultaneous weakness in both? I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently.
- jcoffland 10y ago
  First of all we aren't talking about weaknesses in hash functions. We are talking about ways to compute hashes faster. > But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently. One could then use both SHA1 and MD5 shortcuts.
  - MichaelGG 10y ago
    OK, but having to use both a SHA1 and MD5 shortcut is still going to be more work than using just one of them.
    - yorwba 10y ago
      But it's less work than having to compute both SHA1 and MD5 without shortcut, which is the comparison that matters.
- lmm 10y ago
  > I get that randomly throwing stuff together isn't favoured (like TLS's PRF SHA1+MD5 construction). But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently. Even a crappy 256-bit hash (by using two 128-bit hashes) will probably be more secure than a (single) 128-bit hash, sure. But it won't be anywhere near as secure as a proper 256-bit hash. If you can afford 256 bits of hash, the best way to spend them is on a dedicated 256-bit hash.

midmagico 10y ago

> The "problem" being that instead of being a proof of actual work, shortcuts in the work were found. Nope, the problem is that covert ASICBoost mining has created a strong, valuable incentive for miners to oppose protocol upgrades while supporting much more destructive ones like the recent extblocks, which is susceptible to instantaneous, irreversible full transaction invalidation on a reorg. ASICBoost in its other forms is completely compatible with SegWit.