[Bitcoin-segwit2x] Alpha Milestone

Diego Gutierrez Zaldivar dgz at rootstock.io
Wed Jun 14 20:26:25 UTC 2017


If a method for tx originators (wallets & exchanges) to signal readiness is
implemented, even if it's not used to activate the HF, it can provide
better visibility on how prepared are the users / economic actors to
upgrade.

Cheers,
Diego

<http://www.rsk.co>

*Diego Gutiérrez Zaldívar*
*CEO & Co-founder*
*rsk.co <http://rsk.co/>*

PGP Public Key
<https://keys.mailvelope.com/pks/lookup?op=get&search=0x132DEFB17AB2EA3C>

"Real knowledge is to know the extent of one's ignorance". *Confucius.*

On 14 June 2017 at 16:14, Mike Belshe via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

>
>
> On Wed, Jun 14, 2017 at 11:56 AM, Alex Bosworth <alex.bosworth at gmail.com>
> wrote:
>
>> 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
>>
>
>
> Since this proposal requires every wallet / exchange / payment processor /
> etc to change, it exacerbates the split. While we know we can get massive
> support in the block processors (ie miners), we also know that we can't get
> every wallet to update.  So this proposal is far more risky and dangerous.
> It makes the split far worse.
>
> A better plan, imho, is to continue to garner more support among key
> participants for this plan.  Assuming we can do that, we'll have less
> splitting and a safer path forward.
>
> Mike
>
>
>
>>
>> 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
>>
>
>
>
> --
>
>
> *Mike Belshe*
> *CEO, BitGo, Inc*408-718-6885
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170614/ad06a9a7/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list