3 ms·

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 d

by 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.
        hudon 10y ago
        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 ;)"
- 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.

by jlrubin 10y ago

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.
        hudon 10y ago
        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 ;)"
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.