Skip to content
This repository has been archived by the owner on Feb 25, 2024. It is now read-only.

Add announcement #6

Merged
merged 5 commits into from Aug 16, 2017
Merged

Add announcement #6

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
608862e
Add announcement
Aug 8, 2017
6c1c28e
Add seeds and Bitcoin Classic
Aug 10, 2017
41a2896
Change block size to base block size
Aug 11, 2017
b4ee88a
Reduce 90-year hard-fork timeline to three months
Aug 11, 2017
5b1babc
Reword to base block size
Aug 13, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
50 changes: 50 additions & 0 deletions segwit2x-annuncement.md
View file
Open in desktop
@@ -0,0 +1,50 @@
# Bitcoin Upgrade at Block 494,784

During the month of November 2017, approximately 90 days after the activation of Segregated Witnesses in the Bitcoin blockchain, a block between 1MB and 2MB in size will be generated by Bitcoin miners in a move to increase network capacity. At this point it is expected that more than 90% of the computational capacity that secures the Bitcoin network will carry on mining on top of this large block.

The upgrade to 2MB blocks has been agreed first during the [Bitcoin Roundtable Consensus in Hong-Kong](https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff) on February 2016, and then ratified by the [Bitcoin Scaling Agreement in New York](https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77) on May 2017. These agreements stipulate the activation of Segregated Witness support and an increase of the maximum base block size from 1MB to 2MB.

Segregated Witness support has been locked-in as a soft fork expected to activate around August 23 2017 (block height 481,824). Bitcoin clients that are not currently SegWit-compatible and wish to benefit from the new type of transaction must perform extensive upgrades to various subsystems, including changes to transaction serialization, signature hash computation, block weight calculation, scripting engine, block validation, a new address scheme, and P2P protocol upgrades. Fortunately Segregated Witness compatibility is opt-in, and existing Simplifed Payment Verification (SPV) wallets and full nodes are expected to continue working without changes after SegWit activates.

## Readiness Checklist

The November 2017 upgrade to 2MB blocks is a hard-fork, but necessary changes are trivial to perform. Some SPV clients are expected to work without any change at all. Most clients will need to tweak only two constants to remain compatible with the new larger blocks:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The word "necessary" here is misleading because it wrongly suggests that this hard fork is necessary.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be less misleading if it said "politically compulsory" instead.


For SegWit-compatible clients:

- Maximum block weight doubles from 4,000,000 to 8,000,000
- Sig-ops per block doubles from 80,000 to 160,000

For non-SegWit-capable clients:

- Maximum base block size doubles from 1,000,000 to 2,000,000
- Sig-ops per block doubles from 20,000 to 40,000

Both types of clients should add new DNS seeds:

- BitPay: seed.mainnet.b-pay.net
- OB1: seed.ob1.io
- Blockchain: seed.blockchain.info
- Bloq: bitcoin.bloqseeds.net

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the "require a large block on forking point" rule? Clients without this could break away from 2x's consensus.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, assuming the hashrate does not follow 2X, but it is not absolutely necessary to add this rule to make clients compatible with the majority hashrate, which is the intention.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the majority hashrate ever switches back to mining the non-2x chain, users of software that your checklist considers ready would have the entire 2x history - potentially years of it - wiped out from their clients in a massive reorg. Just puff, and their coins are gone.

Can you guarantee to the users following your "Readiness Checklist" that the mining majority will never switch back? Is that a risk you're willing to take for them?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Total hashrate in bitcoin doubles every few months. This is likely to continue. 90% hashrate now can be 40% in six months, even if none of the signatories reduce their hashrate.

## Testnet5

For testing purposes, a new Testnet5 network that builds on the same Genesis block as the existing Testnet3 network has been created. In order to update a client for compatibility with Testnet5, do these changes to existing Testnet3 settings:

- Port changes from 18333 to 18555.
- Network magic changes from `0x0b110907` to `0x6e657400`
- BIP-34, BIP-66, BIP-65 and single checkpoint all refer to the block at height 10001 with hash `00000000fb7c0a2aeb5f1244e81921b84b7ac770004543144e10c2284f89bfd8`
- DNS seeds are available at `seed.testnet5.b-pay.net` and `bitcoin-testnet.bloqseeds.net`

Block size/weight and sig-ops changes above also apply to Testnet5.

## Compatible Fully-Validating Node Software

- BTC1: https://github.com/btc1/bitcoin
- Bitcoin Unlimited: https://www.bitcoinunlimited.info/
- Bitcoin Classic: https://bitcoinclassic.com/

## Incompatible Fully-Validating Node Software

- Bitcoin Core: https://github.com/bitcoin/bitcoin
- Bitcoin UASF: http://www.uasf.co/
Copy link

@shesek shesek Aug 11, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few more incompatible rule-validating software that you forgot to mention:

  • libbitcoin
  • bcoin
  • btcd
  • knots
  • bitcore
  • haskoin
  • nbitcoin
  • pynode
  • toshi (now retired, but probably still has users?)

Has there been any efforts to reach out to them? Are you okay with leaving users of these implementations behind?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment I have decided to go for a shorter list of fully-validating nodes that I am sure are compatible or not, and likely to remain so for the foreseeable future, and are frequently used in the wild or otherwise highly relevant. Some of these libraries and clients that you mentioned may deserve their own separate sections in the document. Feel free to submit a pull request with an update to the document if you are sure about 2MB (8MB?)-readiness of each.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I clarify that with separate sections I mean “libraries” or “wallets” or “lightweight nodes”.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that bcoin, btcd, nbitcoin and knots are full node software, not a library / lightweight wallet.