[Bitcoin-segwit2x] Alpha Milestone

Roger Ver roger at bitcoin.com
Thu Jun 15 12:39:55 UTC 2017


Adam,

You are out of touch with reality on many of the points you tried to make, and your email is more than a bit insulting to the many technical people on this list.
In case you didn’t notice you directly  CCed Mike Belsh,  one of the principle authors of HTTP 2.0, and someone who has a very very long string of technical accomplishments.
There are numerous other very technical people on this list as well.


1.  Peter is correct about what users of Bitcoin want.  The companies on this mailing list serve millions of bitcoin users, and are in tune with what they want.
They see the support tickets every day from users with stuck transactions, and other problems caused by your intentional policy of full blocks.
You must not see any of these user support requests because Blockstream doesn’t have any users.

2. This list is about Segwit2x,not BU, but the Bitfinex BTU contract was so biased against BU that no one in their right mind would be willing it.
That shouldn’t come as a surprise since it came from one of the only exchanges that supports Core’s roadmap.

3. Adam,  you had a personal invitation from Satoshi to participate in Bitcoin’s ICO before it even launched.  You ignored the invite and didn’t get involved in any way until after bitcoin was around  $1,000 many years later.
I think this is firm evidence that you have no idea why Bitcoin became used as money,  and you have no clue as to what the users of Bitcoin want today.

Bluntly,  Bitcoin doesn’t need any more of your “help”.



Roger Ver
roger at bitcoin.com
Visit the all new https://www.bitcoin.com



> On Jun 15, 2017, at 5:24 PM, Dr Adam Back via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> 
> Bitcoin companies serve users, and we should not lose track of that.
> A number of polls say the opposite of what you are saying Peter,
> though of course it is hard to measure accurately, and the BU project
> which has similar intent, and methodology of community engagement has
> a future contract who's price collapsed in the market: BTU on
> Bitfinex.  It is not at all surprising to me that Bitcoin users would
> tend to reject dictate from a small group of companies and miners,
> think about the audience and the independent mindset that saw them
> self-select to join Bitcoin in the first place.  We should not be
> looking for a fight, nor to override or bully but to be inclusive and
> hope to reach consensus.
> 
> Excluding key participants and the "we're doing this, get on the train
> or be left behind" that brooks no review, nor concern that there be
> ecosystem consensus, nor technical consensus is an anathema to
> Bitcoin.
> 
> There are filter bubbles all around, eg there are no technical
> community members on this list, nor the slack (I am also not on the
> slack).  That allows people to self-vindicate and shields you from
> peer review and public commentary. For example
> https://www.reddit.com/r/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/divtc93/
> 
> A core developer was told he need not apply to join the (list/slack?)
> unless he pre-agreed to the conclusion - that is not inviting review.
> That sounds like BU pledge of allegiance and has no part in a FOSS p2p
> currency.  Even the forming of distinct and closed communication
> channels is not inviting review.  Why would this project be special in
> needing to work in closed/controlled environments and not participate
> openly like the 6 or so other implementations and hundreds of
> developers across dozens of companies, institutions and individuals.
> 
> To come back to the key point however, which I have made repeatedly,
> is WHY do things in a self-sabotaging manner.  Why is it so against
> the grain for participants to use wording seeking community review and
> hoping that the ecosystem will find consensus.  It's like one sentence
> and you guys cant bring yourself to say it?  Why?
> 
> Adam
> 
> On Thu, Jun 15, 2017 at 9:30 AM, Peter Smith <peter at blockchain.com> wrote:
>> where
>> community and user consensus is not a consideration, I continue to
>> think that is a mistake
>> 
>> 
>> Adam, I think you are mistaking R/Bitcoin and certain twitter clusters for
>> the "community" and "users."
>> 
>> More people log into our alone platform in a day than log in those forums in
>> a month.
>> 
>> Even if it is inconvenient for you personally, or Blockstream
>> professionally, the vast majority of Bitcoin users and community is
>> represented by the people on this mailing list.
>> 
>> If working with, and for, that community of users is important to you, would
>> you consider leading your company to supporting this upgrade on behalf of
>> users?
>> 
>> Sorry Mike for off topic.
>> 
>> 
>> 
>> 
>> On Jun 15, 2017, at 12:18 AM, Dr Adam Back via Bitcoin-segwit2x
>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> 
>> Mike
>> 
>> I know everyone here wants good things but we have to be realistic.
>> I'm not sure about you, but for many people Bitcoin holds > 50% or
>> more of their personal net worth, they do not want to see semi-tested,
>> unreviewed changes being pushed into production on a time-schedule
>> that risks their money or an unnecessary chain split.
>> 
>> For objective measures, consider for comparison the design, review,
>> implementation, testing that went into SegWit.  It took 12 months plus
>> activation time, and involved multiple implementations, many hours of
>> review from a wide group and 5 year+ experienced of people, with
>> direct experience of consensus code, and bitcoin internals, and
>> activation is currently at 6months and counting.  And a period of
>> integration work from many companies - including BitGo.  I think those
>> are objective measures.  And that was a soft-fork without the strong
>> coordination requirement.  In the past even Jeff if I recall, who was
>> one of the more optimistic, suggested a 6month activation period after
>> development, of a tested hard-fork (and others have suggested 12months
>> or more).
>> 
>> I understand that several companies and participants declined to sign
>> the agreement at various stages, specifically because of the time
>> frame, so I don't think this is going out on a limb in terms of even
>> participants never mind the technical community across 6 or so
>> cross-compatible bitcoin implementations.
>> 
>> I am a bit concerned that no experienced protocol developers are
>> involved.  Over the years people learned respect the hard-way for the
>> fragility and deceptive complexity of game-theory and bit-level
>> compatibility of consensus rules.  I think without benefit of the
>> wider technical communities participation unnecessary risks are being
>> contemplated.  No offence to anyone but it could be instructive to
>> review why no developers are participating.
>> 
>> I posit it is largely to do with the "forgone conclusion" where
>> community and user consensus is not a consideration, I continue to
>> think that is a mistake and tried to advise people against that
>> approach.
>> 
>> Adam
>> 
>> On Thu, Jun 15, 2017 at 12:42 AM, Mike Belshe <mike at bitgo.com> wrote:
>> 
>> Thanks, Adam -
>> 
>> 
>> Unlike other forums - where going off topic is okay - this topic is for
>> 
>> discussing segwit2x and positively moving it forward.
>> 
>> 
>> * Drivechains can be discussed elsewhere.
>> 
>> * Quotes like "rushing a hard-fork" are emotional and cannot be debated
>> 
>> constructively.  Please use objective measures.
>> 
>> 
>> Thanks,
>> 
>> 
>> Mike
>> 
>> 
>> 
>> On Wed, Jun 14, 2017 at 3:35 PM, Dr Adam Back <adam at blockstream.com> wrote:
>> 
>> 
>> I would prefer to see segwit first, as the wording in the agreement
>> 
>> even said, and for the companies interested in extended block-space,
>> 
>> for them to collaborate on adopting Paul Sztorc's slow return
>> 
>> drivechain as a better extension-block.  He has posted recently an
>> 
>> implementation and has been working on this topic for some time.
>> 
>> 
>> Rushing a hard-fork seems highly likely to lead to a major problems.
>> 
>> I don't think anyone has thought through the magnitude of the
>> 
>> coordination problem.
>> 
>> 
>> There seems to be little interest in seeking technical nor user
>> 
>> community consensus, which many find problematic.
>> 
>> 
>> Adam
>> 
>> 
>> On Thu, Jun 15, 2017 at 12:20 AM, Sergio Lerner via Bitcoin-segwit2x
>> 
>> <bitcoin-segwit2x at lists.linuxfoundation.org> 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.
>> 
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> --
>> 
>> Sergio Demian Lerner
>> 
>> Chief Scientist, RSK Labs
>> 
>> 
>> _______________________________________________
>> 
>> Bitcoin-segwit2x mailing list
>> 
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 
>> 
>> 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
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170615/587df612/attachment-0001.sig>


More information about the Bitcoin-segwit2x mailing list