4 ms·

> Bloq and Metronome’s authors will receive 20% of the initial MTN offering as a one-time author’s retention. I don't know Jeff Garzik's reputation well, but I

> Bloq and Metronome’s authors will receive 20% of the initial MTN offering as a one-time author’s retention. I don't know Jeff Garzik's reputation well, but I've heard his name many times. The fact that he endorses Segwit2x [1] and that he wants a premine/grant for his altcoin are concerning IMO. [1] https://medium.com/@jgarzik/why-segwit2x-is-the-best-path-for-bitcoin-d9a4103f2fda https://medium.com/@jgarzik/why-segwit2x-is-the-best-path-fo...

kobeya 9y ago
He IS s2x.
- shp0ngle 9y ago
  This is important to note. He is the main and, it can be argued, the only developer of the bitcoin segwit2x attack/upgrade (depending on which propaganda do you prefer). https://github.com/btc1/bitcoin/commits/segwit2x https://github.com/btc1/bitcoin/commits/segwit2x
  - rothbardrand 9y ago
    I think lack of replay protection and making the nodes pretend to be core nodes makes the intentions clear. If you're honest you don't need to deceive like that.
Kiro 9y ago
What's the problem with endorsing Segwit2x?
- kobeya 9y ago
  While you’re simultaneously launching a competing altcoin? That’s a little weird.
  - phaser 9y ago
    launching a competing altcoin while pumping a solution to the very same disruption a bitcoin fork would cause
    - rothbardrand 9y ago
      disruption that is unnecessary and only going to happen because this "fork" is literally malware. Look at BCH for an example of a responsible fork. They did the right things and still people lost money, but they did at least do their best. BCH is an ideological fork for bigger blocks and no segwit. I think they are wrong, but they did it in a relatively responsible manner. 2X is straight up malware.
      - kobeya 9y ago
        Well to be fair if bitcoin ever hard forked it would not have two-way replay protection in the way BCH has because replay protection would break all pre-signed transactions. The problem with B2X is the purposeful takeover of a decentralized protocol by an industry cabal, not any specific technical aspect of it (although it does have flaws).
        rothbardrand 9y ago
        By "pre-signed" transactions you mean ones still in the mempool? Actually not a problem, with the change to the ten opcode those would succeed on the correct chain. Bitcoin has forked, by the way, August was a soft fork, and it has had a couple hard forks in the past. What's new is that 2X is an attack fork. (Maybe "assault fork"?) Sorry if my response seems pedantic, I am agreeing with you.
        kobeya 9y ago
        No, I mean locktimed transactions, or chains of transactions as you see in payment channels. Doing a mandatory change to how signatures are calculated invalidates all of these constructs, potentially burning coins (if people lock-timed them to the future) and certainly breaking the security of all existing payment channels.
- rothbardrand 9y ago
  It would degrade Bitcoin security, but worse, it's untested, behind several releases, has no replay protection and the nodes are designed to pretend to be core nodes to confuse the network. It's literally malware at this point.
  - mrb 9y ago
    I did not think Core propaganda would have made its way to HN :-( Segwit2x would not degrade security. People think it would because they assume larger blocks would reduce the absolute number of full nodes, but historically this is not what we have seen: https://twitter.com/zorinaq/status/918133693964865538 https://twitter.com/zorinaq/status/918133693964865538 The "untested" claim is false. The BTC1 reference implementation has unit tests, and is currently run by at least ~700 nodes: https://coin.dance/nodes https://coin.dance/nodes The fact the BTC1 repo is currently based on Core 0.14.2 (released June 18, 2017) instead of Core 0.15.0.1 (released Sep 19, 2017) is not really much of a problem. It has been explained numerous time why we do not want replay protection: to remove the need to upgrade millions of SPV wallets. BTC1 nodes do not pretend to be Core nodes to "confuse" the network. They did it (https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b2c412a157839608fed0 https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b...) in response to Bitcoin Core's hostile attempt to disconnect segwit2x nodes (https://github.com/bitcoin/bitcoin/pull/10982 https://github.com/bitcoin/bitcoin/pull/10982) which would have made the network less reliable between now and the HF, by intentionally disconnecting nodes just because they are not "liked".
    - rothbardrand 9y ago
      You know when you start by calling your opponents positions "propaganda" that it kinda impeaches your argument before you've even begun. Bitcoin has already gone from 1-4mb max blocks this August, going to 8mb is unproven.... and it does reduce security because it increases centralization. The great firewall of china is a real thing, and I've seen first hand that 1mb blocks have trouble crossing it. Absolute number of full nodes is not a relevant measure in this issue... miner centralization is. Untested is true... the 700 nodes that were spun up in the past could of days are not running a test network, and thus it is untested, and also 700 insta-clone AWS instances that are there just as part of the attack do not constitute testing. The fact that BTC1 is months behind is in fact a problem, its one developer has clearly been working on his alt, and there's no indication that the code will be maintained going forward-- especially since it is months behind already. I think it's hilarious to rephrase "Wanting to steal the bitcoin of SPV wallet users" as a "feature" of "not having to upgrade." BCH put in replay protection and did a good job of trying to be a good citizen and still people lost money. You guys are flagrantly pushing malware that hides its nature and ARE going to cause people to lose funds... hell, you guys have been talking about straight up attacks on bitcoin as part of your attempt to launch your scam coin. It's not hostile to disconnect incompatible nodes that are going to cause a hard fork-- you guys keep redefining terms and putting spin on your actions in a way that tells me that you know you're supporting a scam. Nodes that do not follow the consensus rules will be disconnected anyway, this is the way bitcoin works, disconnecting immediately simple saves the network a lot of effort to discover the incompatibility... but hiding it is great if your goal-- as has been stated by you guys on multiple occasions-- to attack bitcoin.

kobeya 9y ago

He IS s2x.

shp0ngle 9y ago
This is important to note. He is the main and, it can be argued, the only developer of the bitcoin segwit2x attack/upgrade (depending on which propaganda do you prefer). https://github.com/btc1/bitcoin/commits/segwit2x https://github.com/btc1/bitcoin/commits/segwit2x
- rothbardrand 9y ago
  I think lack of replay protection and making the nodes pretend to be core nodes makes the intentions clear. If you're honest you don't need to deceive like that.

Kiro 9y ago

What's the problem with endorsing Segwit2x?

kobeya 9y ago
While you’re simultaneously launching a competing altcoin? That’s a little weird.
- phaser 9y ago
  launching a competing altcoin while pumping a solution to the very same disruption a bitcoin fork would cause
  - rothbardrand 9y ago
    disruption that is unnecessary and only going to happen because this "fork" is literally malware. Look at BCH for an example of a responsible fork. They did the right things and still people lost money, but they did at least do their best. BCH is an ideological fork for bigger blocks and no segwit. I think they are wrong, but they did it in a relatively responsible manner. 2X is straight up malware.
    - kobeya 9y ago
      Well to be fair if bitcoin ever hard forked it would not have two-way replay protection in the way BCH has because replay protection would break all pre-signed transactions. The problem with B2X is the purposeful takeover of a decentralized protocol by an industry cabal, not any specific technical aspect of it (although it does have flaws).
      - rothbardrand 9y ago
        By "pre-signed" transactions you mean ones still in the mempool? Actually not a problem, with the change to the ten opcode those would succeed on the correct chain. Bitcoin has forked, by the way, August was a soft fork, and it has had a couple hard forks in the past. What's new is that 2X is an attack fork. (Maybe "assault fork"?) Sorry if my response seems pedantic, I am agreeing with you.
        kobeya 9y ago
        No, I mean locktimed transactions, or chains of transactions as you see in payment channels. Doing a mandatory change to how signatures are calculated invalidates all of these constructs, potentially burning coins (if people lock-timed them to the future) and certainly breaking the security of all existing payment channels.
rothbardrand 9y ago
It would degrade Bitcoin security, but worse, it's untested, behind several releases, has no replay protection and the nodes are designed to pretend to be core nodes to confuse the network. It's literally malware at this point.
- mrb 9y ago
  I did not think Core propaganda would have made its way to HN :-( Segwit2x would not degrade security. People think it would because they assume larger blocks would reduce the absolute number of full nodes, but historically this is not what we have seen: https://twitter.com/zorinaq/status/918133693964865538 https://twitter.com/zorinaq/status/918133693964865538 The "untested" claim is false. The BTC1 reference implementation has unit tests, and is currently run by at least ~700 nodes: https://coin.dance/nodes https://coin.dance/nodes The fact the BTC1 repo is currently based on Core 0.14.2 (released June 18, 2017) instead of Core 0.15.0.1 (released Sep 19, 2017) is not really much of a problem. It has been explained numerous time why we do not want replay protection: to remove the need to upgrade millions of SPV wallets. BTC1 nodes do not pretend to be Core nodes to "confuse" the network. They did it (https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b2c412a157839608fed0 https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b...) in response to Bitcoin Core's hostile attempt to disconnect segwit2x nodes (https://github.com/bitcoin/bitcoin/pull/10982 https://github.com/bitcoin/bitcoin/pull/10982) which would have made the network less reliable between now and the HF, by intentionally disconnecting nodes just because they are not "liked".
  - rothbardrand 9y ago
    You know when you start by calling your opponents positions "propaganda" that it kinda impeaches your argument before you've even begun. Bitcoin has already gone from 1-4mb max blocks this August, going to 8mb is unproven.... and it does reduce security because it increases centralization. The great firewall of china is a real thing, and I've seen first hand that 1mb blocks have trouble crossing it. Absolute number of full nodes is not a relevant measure in this issue... miner centralization is. Untested is true... the 700 nodes that were spun up in the past could of days are not running a test network, and thus it is untested, and also 700 insta-clone AWS instances that are there just as part of the attack do not constitute testing. The fact that BTC1 is months behind is in fact a problem, its one developer has clearly been working on his alt, and there's no indication that the code will be maintained going forward-- especially since it is months behind already. I think it's hilarious to rephrase "Wanting to steal the bitcoin of SPV wallet users" as a "feature" of "not having to upgrade." BCH put in replay protection and did a good job of trying to be a good citizen and still people lost money. You guys are flagrantly pushing malware that hides its nature and ARE going to cause people to lose funds... hell, you guys have been talking about straight up attacks on bitcoin as part of your attempt to launch your scam coin. It's not hostile to disconnect incompatible nodes that are going to cause a hard fork-- you guys keep redefining terms and putting spin on your actions in a way that tells me that you know you're supporting a scam. Nodes that do not follow the consensus rules will be disconnected anyway, this is the way bitcoin works, disconnecting immediately simple saves the network a lot of effort to discover the incompatibility... but hiding it is great if your goal-- as has been stated by you guys on multiple occasions-- to attack bitcoin.