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 08AE1B6B for ; Mon, 13 Mar 2017 10:35:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C63DCB for ; Mon, 13 Mar 2017 10:35:40 +0000 (UTC) Received: by mail-wr0-f169.google.com with SMTP id g10so100604686wrg.2 for ; Mon, 13 Mar 2017 03:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x2dKbX1cRjwrjh4eoiFDTuYMs1A54WbDhlZhkOTXFQY=; b=rQI/kGsmSBojJhm/GP724f5+iQeL4xhAYjCV3QZhRyaajrJNIiZTkLDrjszKsCuk5d 7ysk3RE6V3DlAbj6NXWnF8+JrhE9Cqr2UQvlKajkoj/+lwewkTBdURKP0k7hksFIOiqk 5FWWTyJTGG50WCjOQvYwXNkqBvGQ8cqX1hsp8XbgZCYyqkIwoRfNyAcwd28DrnkjUkJG 77KtRLMI4BGxolie20BSbypgsZBaFYlMNNVnuY7+X7iQlAYRDg/VMb3FPTrJ5he2Oduh ABatwkHdJ0aAJpyDxSGHKnBYtE8O4Be7mjy8lKVbvZMtE/Xww6Go268jz76eIiMkMRh8 2efw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x2dKbX1cRjwrjh4eoiFDTuYMs1A54WbDhlZhkOTXFQY=; b=TJznGR9RqTDCMvCn/JUTa1Yahreupc7s89571XGQmyqxkqA0Rwydkc0dUoBgmGBixO AvYo1F0nu0/U7etHphbQfxiD9yiqsLNDXD8JnWXo/nyyq627PH+thjQlxrV6IBikd9MO WerV1gwanwu+A5hOe9GV7qbRBtfVvRBqvlbGd8me0vhzN9AGSOHd9qA7KgztCyVsBZQM 6xV5aB7mg4JCQUPOIZ3RQpUuF8dnDgkcWmoGMbjsVmT4yY1unZjfpvoayxCk2jiHHnGR 14AygSvT0v6jk1fIJmrhRsOKdhVs+Z7t8RnlR6PoYrXfefH/enHLFt1J30TLcWN29eB0 p6Sw== X-Gm-Message-State: AMke39mf16fi5RJ/yfw4GlOFwcKjVZL/K6nOilREw4w/5Phj4AoNCO3jaK7BM6JwbiYOGmrxgHa1HEoPNEihpA== X-Received: by 10.223.161.213 with SMTP id v21mr25295952wrv.144.1489401339548; Mon, 13 Mar 2017 03:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.92.193 with HTTP; Mon, 13 Mar 2017 03:35:38 -0700 (PDT) Received: by 10.28.92.193 with HTTP; Mon, 13 Mar 2017 03:35:38 -0700 (PDT) In-Reply-To: References: From: David Vorick Date: Mon, 13 Mar 2017 06:35:38 -0400 Message-ID: To: Nick ODell , Bitcoin Dev Content-Type: multipart/alternative; boundary=f403045f21eac5a7d9054a9a457a X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Flag day activation of segwit 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: Mon, 13 Mar 2017 10:35:43 -0000 --f403045f21eac5a7d9054a9a457a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's simply a 51% attack choosing to censor transactions. We could do that today, ban all transactions that aren't approved by the PBoC. You respond to that with a PoW hardfork, or by finding some way to prop up / subsidize non-censorship miners. On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > The problem with modifying Bitcoin to work around community norms is that > it's a two-way street. Other people can do it too. > > Let me propose a counter-fork, or a "Double UASF." This is also a BIP9 > fork, and it uses, say, bit 2. starttime is 1489449600, and the end time = is > 1506812400. It enforces every rule that UASF enforces, plus one additiona= l > rule. If 60% of blocks in any retargeting period signal for Double UASF, > any descendant block that creates or spends a segregated witness output i= s > invalid. > > Double UASF signaling never coincides with UASF signaling, because the > signaling periods don't overlap. Full nodes happily validate the chain, > because Double UASF doesn't break any rules; it just adds new ones. Miner= s > who adopt Double UASF don't need to understand segwit, because all segwit > transactions are banned. Miners don't need to commit to a wtxid structure= , > either. Per BIP 141, "If all transactions in a block do not have witness > data, the commitment is optional." Segwit is activated, but useless. Mine= rs > who *do* adopt segwit will lose money, as their blocks are orphaned. > > Thanks, > --Nick > > On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I recently posted about so called "user activated soft forks" and >> received a lot of feedback. Much of this was how such methodologies coul= d >> be applied to segwit which appears to have fallen under the miner veto >> category I explained in my original proposal, where there is apparently = a >> lot of support for the proposal from the economy, but a few mining pools >> are vetoing the activation. >> >> It turns out Bitcoin already used flag day activation for P2SH[1 >> ], >> a soft fork which is remarkably similar to segwit. The disadvantage of a >> UASF for segwit is there is an existing deployment. A UASF would require >> another wide upgrade cycle (from what I can see, around 80% of existing >> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2 >> ][3 >> ]. >> While absolute node count is meaningless, the uprgrade trend from versio= n >> to version seems significant. >> >> Also it is quite clear a substantial portion of the ecosystem industry >> has put in time and resources into segwit adoption, in the form of >> upgrading wallet code, updating libraries and various other integration >> work that requires significant time and money. Further more, others have >> built systems that rely on segwit, having put significant engineering >> resources into developing systems that require segwit - such as several >> lightning network system. This is much more significant social proof tha= n >> running a node. >> >> The delayed activation of segwit is also holding back a raft protocol of >> innovations such as MAST, Covenants, Schnorr signature schemes and >> signature aggregation and other script innovations of which, much of the >> development work is already done. >> >> A better option would be to release code that causes the existing segwit >> deployment to activate without requiring a completely new deployment nor >> subject to hash power veto. This could be achieved if the economic major= ity >> agree to run code that rejects non-signalling segwit blocks. Then from t= he >> perspective of all existing witness nodes, miners trigger the BIP9 >> activation. Such a rule could come into effect 4-6 weeks before the BIP9 >> timeout. If a large part of the economic majority publicly say that they >> will adopt this new client, miners will have to signal bip9 segwit >> activation in order for their blocks to be valid. >> >> I have drafted a BIP proposal so the community may discuss >> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (ful= l >> text below). >> >> References: >> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/ >> main.cpp#L1281-L1283 >> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html >> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden >> ce_of_widespread_segwit_support_near50_of/ >> >> Proposal text: >> >> 
>>   BIP: bip-segwit-flagday
>>   Title: Flag day activation for segwit deployment
>>   Author: Shaolin Fry 
>>   Comments-Summary: No comments yet.
>>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>>   Status: Draft
>>   Type: Informational
>>   Created: 2017-03-12
>>   License: BSD-3-Clause
>>            CC0-1.0
>>
>> >> =3D=3DAbstract=3D=3D >> >> This document specifies a BIP16 like soft fork flag day activation of th= e segregated witness BIP9 deployment known as "segwit". >> >> =3D=3DDefinitions=3D=3D >> >> "existing segwit deployment" refer to the BIP9 "segwit" deployment using= bit 1, between November 15th 2016 and November 15th 2017 to activate BIP14= 1, BIP143 and BIP147. >> >> =3D=3DMotivation=3D=3D >> >> Cause the mandatory activation of the existing segwit deployment before = the end of midnight November 15th 2017. >> >> =3D=3DSpecification=3D=3D >> >> All times are specified according to median past time. >> >> This BIP will be activate between midnight October 1st 2017 (epoch time = 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the = existing segwit deployment is not activated before epoch time 1538352000. T= his BIP will cease to be active when the existing segwit deployment activat= es. >> >> While this BIP is active, all blocks must set the nVersion header top 3 = bits to 001 together with bit field (1<<1) (according to the existing segwi= t deployment). Blocks that do not signal as required will be rejected. >> >> =3D=3D=3D Reference implementation =3D=3D=3D >> >> 
>> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 in=
clusive
>> if (pindex->GetMedianTimePast() >=3D 1538352000 && pindex->GetMedianTime=
Past() <=3D 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetC=
onsensus())) {
>>     if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D VERSIONBITS_T=
OP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYME=
NT_SEGWIT)) !=3D 0) {
>>         return state.DoS(2, error("ConnectBlock(): relayed block must si=
gnal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>     }
>> }
>>
>> >> =3D=3DBackwards Compatibility=3D=3D >> >> This deployment is compatible with the existing "segwit" bit 1 deploymen= t scheduled between midnight November 15th, 2016 and midnight November 15th= , 2017. >> >> =3D=3DRationale=3D=3D >> >> Historically, the P2SH soft fork (BIP16) was activated using a predeterm= ined flag day where nodes began enforcing the new rules. P2SH was successfu= lly activated with relatively few issues >> >> By orphaning non-signalling blocks during the last month of the BIP9 bit= 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment= to activate without needing to release a new deployment. >> >> =3D=3DReferences=3D=3D >> >> [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283= P2SH flag day activation]. >> >> =3D=3DCopyright=3D=3D >> >> This document is placed in the public domain. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045f21eac5a7d9054a9a457a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's simply a 51% attack choosing to censor transac= tions. We could do that today, ban all transactions that aren't approve= d by the PBoC.

You respond to = that with a PoW hardfork, or by finding some way to prop up / subsidize non= -censorship miners.

On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev&quo= t; <bitcoin-dev= @lists.linuxfoundation.org> wrote:
The problem with modifying= Bitcoin to work around community norms is that it's a two-way street. = Other people can do it too.

Let me propose a count= er-fork, or a "Double UASF." This is also a BIP9 fork, and it use= s, say, bit 2. starttime is 1489449600, and the end time is 1506812400. It = enforces every rule that UASF enforces, plus one additional rule. If 60% of= blocks in any retargeting period signal for Double UASF, any descendant bl= ock that creates or spends a segregated witness output is invalid.

Double UASF signaling never coincides with UASF signaling,= because the signaling periods don't overlap. Full nodes happily valida= te the chain, because Double UASF doesn't break any rules; it just adds= new ones. Miners who adopt Double UASF don't need to understand segwit= , because all segwit transactions are banned. Miners don't need to comm= it to a wtxid structure, either. Per BIP 141, "If all transactions in = a block do not have witness data, the commitment is optional." Segwit = is activated, but useless. Miners who *do* adopt segwit will lose money, as= their blocks are orphaned.

Thanks,
--Ni= ck

On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote= :
I recently posted about so called "user activated soft f= orks" and received a lot of feedback. Much of this was how such method= ologies could be applied to segwit which appears to have fallen under the m= iner veto category I explained in my original proposal, where there is appa= rently a lot of support for the proposal from the economy, but a few mining= pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for P2SH[1= ], a soft fork which is remarkably similar to segwit. The disadvantage = of a UASF for segwit is there is an existing deployment. A=C2=A0UASF would = require another wide upgrade cycle (from what I can see, around 80% of exis= ting nodes have upgraded from pre-witness, to NODE_WITNESS capability[2][3]. While absolute node count is meaningless, = the uprgrade trend from version to version seems significant.

Also it is quite clear a substantial p= ortion of the ecosystem industry has put in time and resources into segwit = adoption, in the form of upgrading wallet code, updating libraries and vari= ous other integration work that requires significant time and money. Furthe= r more, others have built systems that rely on segwit, having put significa= nt engineering resources into developing systems that require segwit - such= as several lightning network system. This is much more significant social = proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of = innovations such as MAST, Covenants, Schnorr signature schemes and signatur= e aggregation and other script innovations of which, much of the developmen= t work is already done.

A= better option would be to release code that causes the existing segwit dep= loyment to activate without requiring a completely new deployment nor subje= ct to hash power veto. This could be achieved if the economic majority agre= e to run code that rejects non-signalling segwit blocks. Then from the pers= pective of all existing witness nodes, miners trigger the BIP9 activation. = Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a = large part of the economic majority publicly say that they will adopt this = new client, miners will have to signal bip9 segwit activation in order for = their blocks to be valid.

I have drafted a BIP proposal so the community may discuss=C2=A0https://gis= t.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c=C2= =A0(full text below).

Ref= erences:
[2]:=C2= =A0http://luke.d= ashjr.org/programs/bitcoin/files/charts/services.html

Proposal text:

<pre&=
gt;
  BIP: bip-segwit-flagday
  Title: Flag day activation for segwit deployment
  Author: Shaolin Fry <shaolinfry@protonmail.ch>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BI=
P-????
  Status: Draft
  Type: Informational
  Created: 2017-03-12
  License: BSD-3-Clause
           CC0-1.0
</pre>

=3D=3DAbstract=3D=3D

This document specifies a BIP16 like soft fork flag day activation of the s=
egregated witness BIP9 deployment known as "segwit".

=3D=3DDefinitions=3D=3D

"existing segwit deployment" refer to the BIP9 "segwit"=
 deployment using bit 1, between November 15th 2016 and November 15th 2017 =
to activate BIP141, BIP143 and BIP147.

=3D=3DMotivation=3D=3D

Cause the mandatory activation of the existing segwit deployment before the=
 end of midnight November 15th 2017.

=3D=3DSpecification=3D=3D

All times are specified according to median past time.

This BIP will be activate between midnight October 1st 2017 (epoch time 153=
8352000) and midnight November 15th 2017 (epoch time 1510704000) if the exi=
sting segwit deployment is not activated before epoch time 1538352000. This=
 BIP will cease to be active when the existing segwit deployment activates.

While this BIP is active, all blocks must set the nVersion header top 3 bit=
s to 001 together with bit field (1<<1) (according to the existing se=
gwit deployment). Blocks that do not signal as required will be rejected.

=3D=3D=3D Reference implementation =3D=3D=3D

<pre>
// mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclu=
sive
if (pindex->GetMedianTimePast() >=3D 1538352000 && pindex->=
;GetMedianTimePast() <=3D 1510704000 && !IsWitnessEnabled(pindex=
->pprev, chainparams.GetConsensus())) {
    if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D VERSIONBI=
TS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, =
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0) {
        return state.DoS(2, error("ConnectBlock(): relayed block must =
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segw=
it");
    }
}
</pre>

=3D=3DBackwards Compatibility=3D=3D

This deployment is compatible with the existing "segwit" bit 1 de=
ployment scheduled between midnight November 15th, 2016 and midnight Novemb=
er 15th, 2017.

=3D=3DRationale=3D=3D

Historically, the P2SH soft fork (BIP16) was activated using a predetermine=
d flag day where nodes began enforcing the new rules. P2SH was successfully=
 activated with relatively few issues

By orphaning non-signalling blocks during the last month of the BIP9 bit 1 =
"segwit" deployment, this BIP can cause the existing "segwit=
" deployment to activate without needing to release a new deployment.

=3D=3DReferences=3D=3D

[https://github.com/bitcoin/bitcoin/blob/v0=
.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].

=3D=3DCopyright=3D=3D

This document is placed in the public domain.



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--f403045f21eac5a7d9054a9a457a--