[Bitcoin-segwit2x] Bitcoin Protocol Change Specifications

Jeff Garzik jeff at bloq.com
Mon Oct 9 17:19:44 UTC 2017


Introduction
----------------------
A familiar claim is that specifications for segwit2x do not exist, or
segwit2x is "unspecified."   This was false (link
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014708.html>,
link
<https://github.com/btc1/specifications/commit/49191e2a90418c4e80096475e561842a5434ff95>)
-- but it is a fair criticism that you have to google for them, and that
shouldn't be the case.

Specifications are also an issue in our wider community.  To make it easier
for both segwit2x and post-segwit2x development, there is a repository and
simple process for Protocol Change Specifications (PCS) at
https://github.com/btc1/specifications

The process
-------------------------
1) Create a specification, stored as *drafts/PCS-$username-$featurename*
 format.

2) When code exists, is production ready and *may potentially activate*,
move the specification to *PCS/PCS-$year-$number-$featurename*

Engineers will be familiar with an IETF-like process.

It is important for non-engineers to understand *creating a specification
does not mean a change is accepted on the network - that's outside
anybody's control*.  The goal is to document what changes are live, or may
go live.

Current contents
-------------------------------
The first few documents are the tx-size PCS and a clone of Sergio's
segwit2x BIP into the PCS repo.

1) tx-size:  tl;dr Goal is to state "tx limits don't change, even as block
size increases" - tx limits are frozen for wallet compatibility.

2) segwit2x:  Document SegWit + 2M multi-phase upgrade.

This will also be where the replay protection proposal would be documented.


Who is welcome?
----------------------------------

The wider community needs to open the innovative process to more
developers.  We would welcome and encourage Bitcoin and
*Bitcoin-compatible* developers
to contribute specifications:   Bitcoin, Bitcoin Cash, Litecoin, Zcash,
Bitcoin-compatible Drivechain, etc.

The current BIP process and the overall toxic environment do not create
welcoming, pro-developer outcomes where we all work together to create the
best technology possible.  Let's change that.


What are the goals?
---------------------------------------

1. Shared innovation:  It is way too early in the crypto game for
infighting, or innovation gatekeeping by a small clique.  We need to be
sharing innovations across teams and chains, working together, beta
testing *with
real money* on litecoin or bitcoin cash or a sidechain, then adding that
feature to bitcoin more conservatively (or not at all, if RM testing shows
flaws).  This was the flight path of SegWit (litecoin RM testing first) and
now block size increase (Bitcoin Cash RM testing first).

The best way to share innovation is working together on common
specifications and best practices across chains.

"Way back" in 2010, many of us simply assumed that bitcoin governance and
upgradability would allow bitcoin to rapidly digest the latest innovations
such as zero-knowledge proofs.  This has not happened.


2. Increase focus on specification - push back on "the code is the spec"
mentality.  Work towards a multi-implementation network.


3. Solution sharing.  Sharing of bug fixes (vs. features, #1, above).

Real world example - A performance problem in bitcoin-derived zcash, found
& fixed by zcash team, can be backported to bitcoin and other bitcoin
clones.

Most of these codebases are derived from Bitcoin, and benefit from sharing
fixes.

-- 
Jeff Garzik
CEO and Co Founder
Bloq, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171009/286821ff/attachment.html>


More information about the Bitcoin-segwit2x mailing list