[bitcoin-discuss] [Bitcoin-segwit2x] Alpha Milestone

Luke Dashjr luke at dashjr.org
Fri Jun 16 04:32:51 UTC 2017


(I think this thread might be off-topic for Segwit2x, so I'm redirecting to 
the bitcoin-discuss@ mailing list.)

IMO, these two visions are *not* fundamentally incompatible. (For the purposes 
of this email, I am going to refer to the two groups as "decentralisation-
first" and "adoption-first", respectively.)

Paul Sztorc's drivechains concept can potentially deliver miner-controlled, 
much larger blocks in the near future. This comes at the expense of 
decentralisation, of course, but as a drivechain, this loss does not directly 
affect the main chain, which can continue to develop according to the goals of 
the decentralisation-first group. There is a reduction in security of the 
drivechain since miners effectively make all the final decisions for it, but 
the adoption-first group tends to embrace and desire this miner-driven model 
anyway.

So by using a drivechain, it is in fact possible to achieve two blockchains 
achieving the goals of each group, and both remaining part of the same Bitcoin 
network and using the same bitcoins.

Luke


On Wednesday 14 June 2017 10:20:33 PM Sergio Lerner via Bitcoin-segwit2x 
wrote:
> There are two group of people which have two different visions for Bitcoin.
> 
> None of these visions is "wrong".
> 
> One group values more things like decentralization, lack of government,
>  censorship resistance, anonymity. This group thinks that Bitcoin will
> transform our world in 20-30 years. To reach this goal, it's of utter
> importance to stick to those values. There is no rush.
> 
> The other group values more things like reaching one billion users in the
> next 5 years, or serving real unbanked users today, even if that requires a
> political agreement now.
> 
> Both visions have their merits. But they are incompatible.
> 
> Replay protection gives a chance to each of these "bitcoiners" to fully
> push their own vision. Both visions can co-exists. I don't care if one
> Bitcoin is called "Bitcoin Utopia" and the other is called "Bitcoin
> Enterprise". Or whatever name they are given.
> 
> Please consider replay protection in segwit2x.
> 
> 2017-06-14 15:22 GMT-03:00 Mike Belshe via Bitcoin-segwit2x <
> 
> bitcoin-segwit2x at lists.linuxfoundation.org>:
> > 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
> > 
> > _______________________________________________
> > Bitcoin-segwit2x mailing list
> > Bitcoin-segwit2x at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x


More information about the bitcoin-discuss mailing list