[Bitcoin-segwit2x] Alpha Milestone

Alex Bosworth alex.bosworth at gmail.com
Wed Jun 14 18:56:07 UTC 2017


I'm not sure that a 2mb increase is so simple and that transaction
processors do not need modification, for the reason of protecting from
replay attacks. Some additional minimal modifications may be necessary.

Certainly if a hard fork had a vast majority support things would be
different, my query only applies to the potential for a contentious split,
which as things stand today seems possible.

Transaction replay is a difficult problem to solve conclusively, but maybe
a compromise can be to use the transaction version. I would suggest
Spoonnet as a specific proposal to draw from for solving the replay problem
and other hard fork issues, which seeks to make it easy for developers to
maintain continuity with minimal development work -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

On Wed, Jun 14, 2017 at 11:22 AM Mike Belshe <mike at bitgo.com> wrote:

> Thanks for raising this question, Alex.
>
> The team has considered this and is open to specific proposals.
>
> As you know, one of the primary benefits of the simple 2mb increase
> approach is that existing transaction processors on the chain do not need
> modification.  The challenge with transaction level replay protection is
> that for most implementations, you need to rewrite all the transaction
> processors to change (set some additional bit or something).  Done
> improperly, this could make deployment of the 2mb increase very difficult
> on any timeframe as you'd have to modify every wallet, exchange, payment
> processor, etc.
>
> By contrast, if we have vast majority support combined with adequate
> preparation time for all participants & exchanges, the need for this is
> minimal.
>
> Do you have a specific technical solution to consider?  If you propose
> one, it is easier to discuss than discussing in abstract.
>
> Mike
>
>
>
> On Jun 14, 2017 10:35 AM, "Alex Bosworth" <alex.bosworth at gmail.com> 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 <https://github.com/btc1>.
>>>
>>>
>>>
>>> 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
>>
> --
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170614/fddfc041/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list