From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C8429B63 for ; Sat, 15 Apr 2017 08:05:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42858E2 for ; Sat, 15 Apr 2017 08:05:15 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id 88so1956555lfr.0 for ; Sat, 15 Apr 2017 01:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LixYhSE0Egjrah+5MIrAqkSShK/n+X1FP2l67gxcpPg=; b=EjpdjX/b5gegV5YctUEqlxEu7aTIVd//8J9z5htTcKDAdEGvzmoraFIAlNMUx8pNcb 5y51y6j+aahWmJxPXlQSLPwmqYnbYqY8fDl3kIPrra4fKpklGFbhiZBBdAEnQdwhZoHM V3OG1C706ecBihjSPfDGqnuVUEEBErG9tnwkLGsFZ/9K1NA+n3OHLN2mQY5zkAHIXbyH TWw07403/jz6VS1D0oJKbJGL0VPkEJtLJpzkywLJJUKc3YFVygmCSuFO5WJ8GNsxKoWh qgGrJsoJl/ruLV8iUZdFYHQ+fgIrCHz/hAfbYmLvp+B0yY5tAoIScc/I0TWdHsmFhOWY w7og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LixYhSE0Egjrah+5MIrAqkSShK/n+X1FP2l67gxcpPg=; b=C/fUGYuOyahQqnaGh3qGROokUWf6MoE2yiS5KABlB+v2uJ7uLCwCJausjQDrVwh54Q 5jo6lrgy4e9idF8Z6rpChHtda/0TZe+bHkibJNr0WZzKVB2VlNquVSraO7LuX79eC2wR tzADQYjqG1ot7+eSpmiUZq22/YOvTm1zGbxq1mT6JW3A8LR+ixWRwwwpUMg2owadIH09 HZ6PeGgqlKQNgvmE927Z5A0DEk2gWvkYjZTWH7rCoX6p0D25QT3ePTrhd5nWTCZcragk /U2vS4NkxckbInOrwcyBKvc9nerTQ4rqwXNsIMA2CoiZuduT5lmDuNa1hVXilvzHvDGl iwtA== X-Gm-Message-State: AN3rC/79F18PBJ2tfOfvyq8XTbZORtFm3CFf/m3SLUdmcPgYn4Y6nSvT s0GWQtWGgBTx3w== X-Received: by 10.46.88.29 with SMTP id m29mr356565ljb.91.1492243513580; Sat, 15 Apr 2017 01:05:13 -0700 (PDT) Received: from [192.168.0.102] ([78.26.162.42]) by smtp.gmail.com with ESMTPSA id x22sm255730ljd.38.2017.04.15.01.05.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 01:05:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Cameron Garnham In-Reply-To: Date: Sat, 15 Apr 2017 11:05:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <99CEF27C-4C2B-4F62-91D4-37ACB63B443A@gmail.com> References: To: Gregory Maxwell X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, LOTS_OF_MONEY, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 08:05:19 -0000 Thank-you for your prompt response, I believe I must have a different prospective of Bitcoin to you. = Ideologically I don=E2=80=99t agree that miners can be passive = participants in the Bitcoin Network; and I certainly don=E2=80=99t see = them acting as passive participants in the Bitcoin Community now. The miners are very much political actors. Hence why I fail to = take-to-heart your concern "that the proposal will reject the blocks of = passive participants=E2=80=9D. With AsicBoost, there are three miner groups: Those who use it (and have = legal sanction to do so); Those who use it (without legal sanction); and = those who don=E2=80=99t use it. If SegWit didn=E2=80=99t directly = affect miners, then one could possibly claim that there could be an = ideal passive participant miner in reality. However since your important = revelations on AsicBoost: SegWit cannot be a =E2=80=98passive=E2=80=99 = option for miners. Hence, I don=E2=80=99t care about orphaning the blocks of of the = theoretical "passive participant=E2=80=9D miner. As I have no logical = reasoning to suggest one could exists; and a large amount of evidence to = suggesting one dose not exit. On BIP 16 vs. BIP 17; I cannot see how BIP 148 similar engineering = tradeoffs. Is there any long-term =E2=80=98technical debt=E2=80=99 from = BIP 148 that I=E2=80=99m unaware of that could be similar to BIP 16? On the Drama: Well 100M USD p/a can pay for lots of Drama; Hence going = back to the first point: The miners are not passive participants when it = comes to *any* form of activation of SegWit. Cameron. > On 15 Apr 2017, at 10:04 AM, Gregory Maxwell wrote: >=20 > On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham = wrote: >> As many may remember, there was quite some controversy about the = BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of = P2SH, and how this was the already =E2=80=9Ctested and proven to work=E2=80= =9D solution. >=20 > And as a result we ultimately got a clearly inferior solution (520 > byte script limit; 80-bit security; months of orphaned blocks-- and > two of those were not issues in BIP17). I went along for the cram > fest on 16 after 12 caught fire, and I was mistaken to do so. >=20 > Doubly so because it took years for P2SH to achieve any kind of mass > deployment due to issues far away from consensus. An extra two months > spent on some ground-work (including communications and documentation) > could have pulled forward practical deployment by a year and given > time to find and fix some of the flaws in the design of P2SH. >=20 >> BIP 148 is out (our?) terms of peace. The Bitcoin Community is = tired-to-death of this war and wants a resolution swiftly. BIP 148 = proves a outlet, and in Maxwell words: =E2=80=9C...almost guarantees at = a minor level of disruption.=E2=80=9D. >=20 > It seems I lost a word in my comment: that should have been "almost > guarantees at _least_ a minor level of disruption". A minor level of > disruption is the _minimum_ amount of disruption, and for no good > reason except an unprecedented and unjustified level of haste. >=20 > Considering that you did not spare a single word about the specific > property that I am concerned about-- that the proposal will reject the > blocks of passive participants, due to avoidable design limitations-- > I can't help but feel that you don't even care to understand the > concern I was bringing up. :( >=20 > How many people barely reviewed the specifics of the proposal simply > because they want something fast and this proposal does something > fast? >=20 >> tired-to-death of this war and wants a resolution swiftly >=20 > By now competitors and opponents to Bitcoin have surely realized that > they can attack Bitcoin by stirring up drama. >=20 > As a result, the only way that we will ever be free from "war" is if > we choose to not let it impact us as much as possible. We must be > imperturbable and continue working at the same level of excellence as > if virtual shells weren't flying overhead-- or otherwise there is an > incentive to keep them flying 24/7. Internet drama is remarkably cheap > to generate. "The only thing we have to fear is fear itself". >=20 > The alternative is that we hand opponents a ready made formula for > disruption: astroturf enough drama up that Bitcoiners "sacrifice > correctness" themselves right off a cliff in a futile attempt to make > it go away. :)