[Bitcoin-segwit2x] Alpha Milestone

Thu Jun 15 16:34:44 UTC 2017

1. Prior to the hardfork, there is no need for replay protection; Not
only is the segwit portion unlikely to be as controversial, it appears
that @jgarzik is moving the project in the direction of not only
BIP141 compatibility(aka bit4+bit1) but also possibly BIP148
compatibility(aka BIP91; Faster activation to make timelines
coincide).

2. After the hardfork, unless consensus towards the hardfork becomes
far stronger at multiple difficult-to-measure levels, or unless the
signatories are willing to use their hashpower to attack and disable
the legacy chain for as long as necessary, there must be strong replay
protection.  This is a simple fact of how the users and exchanges
interact.  The hardfork should definitely introduce replay protection
to be utilized at all; The vast majority of clients already must
update their clients to follow the hardfork chain.  Coin-splitting
procedures are not going to be sufficient for the vast majority of
users and use-cases, and are not sufficient replay protection unless
the legacy chain is almost guaranteed to die.

Gavin's suggestion is good, and could be done on both sides:

> Adding an extra OP_RETURN output to your transaction should be much easier and safer than messing with your transaction signing code.

If the hardfork required a magic-value OP_RETURN on all transactions
between block-height <hardfork> and <hardfork+12 months> for
transactions to be valid, that gives substantial time for the
community to either converge upon a winning consensus system or for
signature changes to be created and tested for a permanent replay
protection.

Core could similarly implement a rule where that specific OP_RETURN
magic value is not considered a valid transaction for the same time
period unless mined(or perhaps not at all), and coordinate with all
remaining legacy miners to reject them.  It is possible that Core
could refuse to implement such a softfork, but if the legacy chain is
going to become the minority chain as implied by the 84% signatories,
and if blocksize increases are desirable as signaled by several
exchanges, then it should be possible to apply tremendous pressure for
this replay protection method to become two-way.

Jared

On Wed, Jun 14, 2017 at 11:07 PM, Jameson Lopp via Bitcoin-segwit2x
<bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> Regarding replay protection: it seems highly unlikely to me that it could
> get implemented in a way that satisfies all parties and also meets the
> project milestones. Thus my question becomes: what is the agreement (if any)
> amongst the entities supporting SegWit2X regarding supporting other chain
> forks? Especially exchanges, given that they are incentivized to support
> multiple chain forks.
>
> If the plan is to move forward without replay protection, is the assumption
> that SegWit2X participants will
>
> A) Not support a BIP148 chain fork if it occurs
> B) Not support the counter-BIP148 hard fork proposed by Bitmain if it occurs
> C) Not support the original 1MB base chain fork after the 2MB base hard fork
> occurs
>
> Neither I nor any of my colleagues are particularly enthusiastic about the
> prospect of potentially having to support many chain forks without native
> replay protection - what are everyone else's thoughts on the matter?
>
> - Jameson
>
> On Wed, Jun 14, 2017 at 5:04 PM, Oliver Petruzel via Bitcoin-segwit2x
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>> Hugh -
>> The link on Bitcoin.org will simply have to change if/when SegWit2x
>> successfully becomes the new reference client.
>>
>> Alternatively, Core would also merge the hardfork changes into their own
>> client, and Bitcoin.org would provide links to both (all) compatible clients
>> -- with "compatibility" defined as any client that implements the consensus
>> rules found in SegWit2x.
>>
>> I think the current focus is rightfully on existing
>> nodes/businesses/users, so let's not put the cart before the horse.
>>
>> Oliver
>>
>> On Jun 14, 2017 19:52, "Hugh Madden via Bitcoin-segwit2x"
>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>
>>> Ultimately most users and businesses will simply apt-get update or
>>> download the client from bitcoin.org
>>>
>>> If we expect incoming and unsophisticated users to choose a fork to be
>>> compatible with s2x it's dead in the water IMHO
>>>
>>>
>>>
>>> On 15 Jun. 2017 1:35 am, "Alex Bosworth via Bitcoin-segwit2x"
>>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>>
>>>> Are things still on track for the hard fork aspect? Specifically I
>>>> haven't identified code in the alpha for providing strong 2-way replay
>>>> protection? (This means transactions valid on one chain should be invalid on
>>>> the other, and vice-versa) And for wipe-out protection? (Once forked, the
>>>> fork should remain permanent).
>>>>
>>>> Absent firm support for this specific hard fork from BitFinex (the
>>>> largest volume exchange, Local Bitcoins (the largest volume peer exchange),
>>>> Slush pool, Trezor, Ledger, Electrum, and many others in the industry and
>>>> individuals in the development and broader community, the chance for a
>>>> contentious fork is present, which would suggest those hard fork features
>>>> would help make a BIP 102 hard fork supportable by neutral service providers
>>>>
>>>> On Wed, Jun 14, 2017 at 10:08 AM Mike Belshe via Bitcoin-segwit2x
>>>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Hi Segwit2x team:
>>>>>
>>>>>
>>>>>
>>>>> As we approach the June 15 Alpha milestone, we wanted to compile a
>>>>> status update.
>>>>>
>>>>>
>>>>>
>>>>> General
>>>>>
>>>>> Segwit2x development has been moving quickly according to plan, and the
>>>>> project is in good shape.  The  development of the alpha version is near
>>>>> complete, as is the initial round of testing. Testnet5 has been released,
>>>>> and we we will be releasing alpha binaries by June 16th, as planned, which
>>>>> are ready for further testing with the larger group.
>>>>>
>>>>>
>>>>>
>>>>> June 16 Alpha Deliverable
>>>>>
>>>>> BIP91 w/ bit4 Segwit Activation at 80%
>>>>>
>>>>> BIP102-style 2MB base block size increase 3mo after Segwit Activation
>>>>>
>>>>> Created testnet5 for testing
>>>>>
>>>>> Manual testing
>>>>>
>>>>>
>>>>>
>>>>> Alpha Period Dry Runs
>>>>>
>>>>> During the Alpha period, we are scheduling multiple “dry run” dates.
>>>>> These are scheduled times when we’ll execute the 2MB Blocksize increase
>>>>> across multiple parties on the test network.  We encourage as many
>>>>> participants as possible to participate in these dry runs and report status
>>>>> of how various node versions (both newer and older) execute during the
>>>>> upgrade process.  To participate, parties need to run the testnet5 alpha
>>>>> binaries available on the btc1 github.
>>>>>
>>>>>
>>>>>
>>>>> To Do List
>>>>>
>>>>> Here are some of the open items:
>>>>>
>>>>> Additional testing from all parties
>>>>>
>>>>> Published Test Plan to date
>>>>>
>>>>> Write a BIP for the process
>>>>>
>>>>> Coordinate multiple “dry run” dates until the process is smooth
>>>>>
>>>>> Production of Gitian builds
>>>>>
>>>>>
>>>>>
>>>>> Communications
>>>>>
>>>>> Follow the github here: https://github.com/btc1
>>>>>
>>>>> Subscribe the mailing list:
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ng
>>>>>
>>>>>
>>>>>
>>>>> Thank You
>>>>>
>>>>> Finally, a big thank you to all that have contributed so far.  We still
>>>>> need more developers and testers in the phases ahead, but the project has
>>>>> been growing every week!
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bitcoin-segwit2x mailing list
>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>>
>>>> --
>>>> Sent from my iPhone
>>>>
>>>> _______________________________________________
>>>> Bitcoin-segwit2x mailing list
>>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>>
>>>
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>
>>
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>