BIP 100 initial public draft:=C2=A0https://github.com/jg= arzik/bip100/blob/master/bip-0100.mediawiki

Emphasis= on "initial" =C2=A0This is a starting point for the usual open s= ource feedback/iteration cycle, not an endpoint that Must Be This Way.

--f46d043be24e5ab345051ecf7207-- 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 2D4F9EE2 for ; Thu, 3 Sep 2015 04:45:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20B0E16C for ; Thu, 3 Sep 2015 04:45:39 +0000 (UTC) Received: by obuk4 with SMTP id k4so26176141obu.2 for ; Wed, 02 Sep 2015 21:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lxHTfK7JYVl7TU6ssVkYGWCiNyzbgY5hNuK2A+wM8Q8=; b=dxv6jKZV4yNABNccyPyBt9m8A9mgOLKO3ZL3VoKnhwJZefrQIt0hSJuhgKgHyq20pH BvHXGF/Ege1pJWkTKU+tIWzgkg7is977RIzmhhzRsI/0t6k8T/c9JlvsmswClVXUiU6s 5DfjOtma+YXUsSfnvF/9ztmkAbv0jWzZm+PDpo5yb+pt/I+4Qll/zuUttWS0eemSN0ub a6pATbKoHjCcRkaTbfNcjxxEJFR0IAcrEhs/9H0hivCIganzx/ORFc8/KilquE9j1fz9 8IBDjsKmBk0Ri7HPoyxUnOV3pZekdiDAMlXE5LmoxD4dovVhd8/Pnfh4swVN8APpHyMY RDKA== MIME-Version: 1.0 X-Received: by 10.182.240.135 with SMTP id wa7mr25219017obc.63.1441255538505; Wed, 02 Sep 2015 21:45:38 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.202.201.2 with HTTP; Wed, 2 Sep 2015 21:45:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Sep 2015 21:45:38 -0700 X-Google-Sender-Auth: Ulu49qPR7NUnj3tAPeUsOKsy_Z8 Message-ID: From: Dave Scotese To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a11c1dfc06741ce051ed074bc X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 04:45:40 -0000 --001a11c1dfc06741ce051ed074bc Content-Type: text/plain; charset=UTF-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suggest revising these items for clarity (and I'm guessing on the first one) Calculate hardLimit by examining the coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20th percentile. A new hardLimit may not increase or decrease by more than 1.2x beyond the prior hardLimit. to: The new hardLimit is calculated by sorting the coinbase scriptSig votes of the last 12,000 blocks from lowest to highest and using the vote of the 2400th block. If the vote of the 2400th block is a change of less than 20%, use it as the new hardLimit. Otherwise, change the hardLimit to be closer to that vote, to either 120% or 80% of the current hardLimit. I don't understand #5, 75% rule. Shouldn't invalid version 4 blocks always be rejected? notplato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJV58/5AAoJEL8dSijmIbHt16IH/0jAr3v1HjWW7N1awNxeAABs GIvOFYuZAcPkZvWZQc4JRAppglqeBfYqWl2gpyywSBK1SXjsY8zdo3t7xAK/IJfB 05hnv1GGutG3dLTzJBEXaPx62SLukepC1pzEH7rlwWvVuE9zcRqVE1eGbBEUjA9c sGPr0z9BNeLoTbllyl3Jndz9N2Vnd6bBTxRgBlfkm/Y5ovc+GhyKZyX3Pdmj5Pga E6foOsvqNXQJqPl8WCODsnfPSshyb7YRNFrBB9A+tpjvj4UMc8PxOpL6IX/nJpOt jlfRoKVw2YBEodvda+9P6S54GlGFazyHhwJ11F5YCNnWW1bKoQrqJU6ofgmyxMM= =QWra -----END PGP SIGNATURE----- On Wed, Sep 2, 2015 at 8:33 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > BIP 100 initial public draft: > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > Emphasis on "initial" This is a starting point for the usual open source > feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a11c1dfc06741ce051ed074bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I suggest revising these items for clarity (and I'm guessing on t= he first one)

=C2=A0=C2=A0=C2=A0 Calculate hardLimit by examining th= e coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20= th percentile.
=C2=A0=C2=A0=C2=A0 A new hardLimit may not increase or de= crease by more than 1.2x beyond the prior hardLimit.

to:

=C2= =A0=C2=A0=C2=A0 The new hardLimit is calculated by sorting the coinbase scr= iptSig votes of the last 12,000 blocks from lowest to highest and using the= vote of the 2400th block.
=C2=A0=C2=A0=C2=A0 If the vote of the 2400th = block is a change of less than 20%, use it as the new hardLimit.=C2=A0 Othe= rwise, change the hardLimit to be closer to that vote, to either 120% or 80= % of the current hardLimit.

I don't understand #5, 75% rule.=C2= =A0 Shouldn't invalid version 4 blocks always be rejected?

notpl= ato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAg= AGBQJV58/5AAoJEL8dSijmIbHt16IH/0jAr3v1HjWW7N1awNxeAABs
GIvOFYuZAcPkZvWZQ= c4JRAppglqeBfYqWl2gpyywSBK1SXjsY8zdo3t7xAK/IJfB
05hnv1GGutG3dLTzJBEXaPx6= 2SLukepC1pzEH7rlwWvVuE9zcRqVE1eGbBEUjA9c
sGPr0z9BNeLoTbllyl3Jndz9N2Vnd6b= BTxRgBlfkm/Y5ovc+GhyKZyX3Pdmj5Pga
E6foOsvqNXQJqPl8WCODsnfPSshyb7YRNFrBB9= A+tpjvj4UMc8PxOpL6IX/nJpOt
jlfRoKVw2YBEodvda+9P6S54GlGFazyHhwJ11F5YCNnWW= 1bKoQrqJU6ofgmyxMM=3D
=3DQWra
-----END PGP SIGNATURE-----

On We= d, Sep 2, 2015 at 8:33 PM, Jeff Garzik via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:

BIP 100 initial public draft:=C2=A0https://github.com/jgarzik/bip100/blob/master/bip-0100.me= diawiki

Emphasis on "initial" =C2=A0This i= s a starting point for the usual open source feedback/iteration cycle, not = an endpoint that Must Be This Way.

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

I like to provide some work at no charge to pr= ove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm th= e webmaster for T= he Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante= .
"He ought to find it more profitable to play by the rules" -= Satoshi Nakamoto

--001a11c1dfc06741ce051ed074bc-- 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 DDA94F99 for ; Thu, 3 Sep 2015 07:57:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ACAE149 for ; Thu, 3 Sep 2015 07:57:10 +0000 (UTC) Received: from localhost ([::1]:40246 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZXPOP-00257P-RY; Thu, 03 Sep 2015 03:57:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f22692d174c8b182acef4bf5ba1b6ed0" Date: Thu, 03 Sep 2015 03:57:09 -0400 From: jl2012@xbt.hk To: Jeff Garzik In-Reply-To: References: Message-ID: X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 07:57:12 -0000 --=_f22692d174c8b182acef4bf5ba1b6ed0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Some comments: * The 75% rule is meaningless here. Since this is a pure relaxation of rules, there is no such thing as "invalid version 4 blocks" * The implication threshold is unclear. Is it 95% or 80%? * Softfork requires a very high threshold (95%) to "attack" the original fork. This makes sure that unupgraded client will only see the new fork. * In the case of hardfork, however, the new fork is unable to attack the original fork, and unupgraded client will never see the new fork. The initiation of a hardfork should be based on its acceptance by the economic majority, not miner support. 95% is an overkill and may probably never accomplished. I strongly prefer a 80% threshold rather than 95%. * As I've pointed out, using 20-percentile rather than median creates an incentive to 51% attack the uncooperative minority. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html Having said that, I don't have a strong feeling about the use of 20-percentile as threshold to increase the block size. That means the block size is increased only when most miners agree, which sounds ok to me. However, using 20-percentile as threshold to DECREASE the block size could be very dangerous. Consider that the block size has been stable at 8MB for a few years. Everyone are happy with that. An attacker would just need to acquire 21% of mining power to break the status quo and send us all the way to 1MB. The only way to stop such attempt is to 51% attack the attacker. That'd be really ugly. For technical and ethical reasons, I believe the thresholds for increase and decrease must be symmetrical: increase the block size when the x-percentile is bigger than the current size, decrease the block size when the (100-x)-percentile is smaller than the current size. The overall effect is: the block size remains unchanged unless 80% of miners agree to. * Please consider the use of "hardfork bit" to signify the hardfork: https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/ https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki * Or, alternatively, please combine the hardfork with a softfork. I'm rewriting the specification as follow (changes underlined): * Replace static 1M block size hard limit with a floating limit ("hardLimit"). * hardLimit floats within the range 1-32M, inclusive. * Initial value of hardLimit is 1M, preserving current system. * Changing hardLimit is accomplished by encoding a proposed value within a block's coinbase scriptSig. * Votes refer to a byte value, encoded within the pattern "/BVd+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one match with with pattern, the first match is counted. * Absent/invalid votes and votes below minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes. * A new hardLimit is calculated at each difficult adjustment period (2016 blocks), and applies to the next 2016 blocks. * Calculate hardLimit by examining the coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20th percentile and 80th percentile. * New hardLimit is the median of the followings: * min(current hardLimit * 1.2, 20-percentile) * max(current hardLimit / 1.2, 80-percentile) * current hardLimit * version 4 block: the coinbase of a version 4 block must match this pattern: "/BVd+/" * 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000) * 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last 1000) * Block version number is calculated after masking out high 16 bits (final bit count TBD by versionBits outcome). Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到: > BIP 100 initial public draft: > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] > > Emphasis on "initial" This is a starting point for the usual open > source feedback/iteration cycle, not an endpoint that Must Be This > Way. > > > > Links: > ------ > [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=_f22692d174c8b182acef4bf5ba1b6ed0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Some comments:

The 75% rule is meaningless here. Since this is a pure relaxation of ru= les, there is no such thing as "invalid version 4 blocks"

The implication threshold is unclear. Is it 95% or 80%?

Softfork requires a very high threshold (95%) to "attack" the original = fork. This makes sure that unupgraded client will only see the new fork.
In the case of hardfork, however, the new fork is unable to attack the = original fork, and unupgraded client will never see the new fork. The initi= ation of a hardfork should be based on its acceptance by the economic major= ity, not miner support. 95% is an overkill and may probably never accomplis= hed. I strongly prefer a 80% threshold rather than 95%.

As I've pointed out, using 20-percentile rather than median creates an = incentive to 51% attack the uncooperative minority. https://lists.linuxfoun= dation.org/pipermail/bitcoin-dev/2015-August/010690.html

Hav= ing said that, I don't have a strong feeling about the use of 20-percentile= as threshold to increase the block size. That means the block size is incr= eased only when most miners agree, which sounds ok to me.

However, using 20-percentile as threshold to DECREASE the block size co= uld be very dangerous. Consider that the block size has been stable at 8MB = for a few years. Everyone are happy with that. An attacker would just need = to acquire 21% of mining power to break the status quo and send us all the = way to 1MB. The only way to stop such attempt is to 51% attack the attacker= =2E That'd be really ugly.

For= technical and ethical reasons, I believe the thresholds for increase and d= ecrease must be symmetrical: increase the block size when the x-percentile = is bigger than the current size, decrease the block size when the (100-x)-p= ercentile is smaller than the current size. The overall effect is: the bloc= k size remains unchanged unless 80% of miners agree to.

Please consider the use of "hardfork bit" to signify the hardfork:

htt= ps://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bi= t_jl2012_at_xbthk_jul_23_2015/

htt= ps://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki

Or, alternatively, please combine the hardfork with a softfork. I'm rew= riting the specification as follow (changes underlined):

Replace static 1M block size hard limit with a floating limit ("hardLim= it").

hardLimit floats within the range 1-32M, inclusive.

Initial value of hardLimit is 1M, preserving current system.

Changing hardLimit is accomplish= ed by encoding a proposed value within a block's coinbase scriptSig.=

Votes refer to a byte value, enc= oded within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 = byte hardLimit. If there is more than one match with with pattern, the first= match is counted.
Absent/invalid votes and votes b= elow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap = (32M) are counted as 32M votes.
A new hardLimit is calculated at= each difficult adjustment period (2016 blocks), and applies to the next 20= 16 blocks.
Calculate hardLimit by examining= the coinbase scriptSig votes of the previous 12,000 blocks, and taking the = 20th percentile and 80th percentile.
New = hardLimit is the median of the followings:

min(c= urrent hardLimit * 1.2, 20-percentile)
max(= current hardLimit / 1.2, 80-percentile)
curr= ent hardLimit

version 4 block: the coinbase of = a version 4 block must match this pattern: "/BV\d+/"
70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, reject invalid versio= n 4 blocks. (testnet4: 501 of last 1000)
80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are version 4 or greater= , reject all version <=3D 3 blocks. (testnet4: 750 of last 1000)<= /li>
Block version number is calculat= ed after masking out high 16 bits (final bit count TBD by versionBits outco= me).

Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=B0:
> BIP 100 initial public draft:
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>=20
> Emphasis on "initial"  This is a starting point for the usual open
> source feedback/iteration cycle, not an endpoint that Must Be This
> Way.
>=20
>=20
>=20
> Links:
> ------
> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--=_f22692d174c8b182acef4bf5ba1b6ed0-- 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 7DCABDB1 for ; Thu, 3 Sep 2015 11:20:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 91B4910D for ; Thu, 3 Sep 2015 11:20:29 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so16255537wic.1 for ; Thu, 03 Sep 2015 04:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EH9BpYKSSP5ERw8BQGu2/ii/kwS8Jy7/VmyBipijASM=; b=P6yM84QzgnF3zhLjYNLGJyStEUMDwLop0IM42NJgDnWWbFpPMXmDaMMQPBPpJi/Ok6 nDH5FN7P6JJKJBzXCvXccix261K7b5bXx1t0vNNR+Bv9SuSCGJYIxZtcUCB6yMs+jNnV 8mYq3SHjmnU+Gf4f+90lmhE9uJJdcPB5tD4M8bLkQd9oZ4QGwiNsrUnjAICUx1B+Y194 OxNchYzw+wissahvdIokGV4KQymsw8so8HzcvylGrnxn6FRYKSe/A5HYC0a/72G+wwCI VITNJIGoQ4YdsnmQ+h97CuDIw63nww9QC5ONCwoEp/xcwo1JPAp/1jaUTKPBXLts2CJb 2Xvg== X-Received: by 10.180.187.170 with SMTP id ft10mr13241175wic.15.1441279228069; Thu, 03 Sep 2015 04:20:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.26.10 with HTTP; Thu, 3 Sep 2015 04:20:08 -0700 (PDT) In-Reply-To: References: From: Btc Drak Date: Thu, 3 Sep 2015 12:20:08 +0100 Message-ID: To: jl2012@xbt.hk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:20:30 -0000 We should avoid discussing actual hard fork/softfork deployment methodologies when discussing blocksize proposals because deployment is a separate issue. As a recent case in point, look at how BIP65 (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. That lead to a focused discussion of the functionality and relatively quick inclusion. Deployment really is a separate issue than the mechanics of how BIP100 will function after activation. On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev wrote: > Some comments: > > The 75% rule is meaningless here. Since this is a pure relaxation of rule= s, > there is no such thing as "invalid version 4 blocks" > > The implication threshold is unclear. Is it 95% or 80%? > > Softfork requires a very high threshold (95%) to "attack" the original fo= rk. > This makes sure that unupgraded client will only see the new fork. > In the case of hardfork, however, the new fork is unable to attack the > original fork, and unupgraded client will never see the new fork. The > initiation of a hardfork should be based on its acceptance by the economi= c > majority, not miner support. 95% is an overkill and may probably never > accomplished. I strongly prefer a 80% threshold rather than 95%. > > As I've pointed out, using 20-percentile rather than median creates an > incentive to 51% attack the uncooperative minority. > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01069= 0.html > > Having said that, I don't have a strong feeling about the use of > 20-percentile as threshold to increase the block size. That means the blo= ck > size is increased only when most miners agree, which sounds ok to me. > > However, using 20-percentile as threshold to DECREASE the block size coul= d > be very dangerous. Consider that the block size has been stable at 8MB fo= r a > few years. Everyone are happy with that. An attacker would just need to > acquire 21% of mining power to break the status quo and send us all the w= ay > to 1MB. The only way to stop such attempt is to 51% attack the attacker. > That'd be really ugly. > > For technical and ethical reasons, I believe the thresholds for increase = and > decrease must be symmetrical: increase the block size when the x-percenti= le > is bigger than the current size, decrease the block size when the > (100-x)-percentile is smaller than the current size. The overall effect i= s: > the block size remains unchanged unless 80% of miners agree to. > > Please consider the use of "hardfork bit" to signify the hardfork: > > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo= rk_bit_jl2012_at_xbthk_jul_23_2015/ > > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki > > Or, alternatively, please combine the hardfork with a softfork. I'm > rewriting the specification as follow (changes underlined): > > Replace static 1M block size hard limit with a floating limit ("hardLimit= "). > > hardLimit floats within the range 1-32M, inclusive. > > Initial value of hardLimit is 1M, preserving current system. > > Changing hardLimit is accomplished by encoding a proposed value within a > block's coinbase scriptSig. > > Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example= : > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one > match with with pattern, the first match is counted. > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M > votes. Votes above the maximum cap (32M) are counted as 32M votes. > A new hardLimit is calculated at each difficult adjustment period (2016 > blocks), and applies to the next 2016 blocks. > Calculate hardLimit by examining the coinbase scriptSig votes of the > previous 12,000 blocks, and taking the 20th percentile and 80th percentil= e. > New hardLimit is the median of the followings: > > min(current hardLimit * 1.2, 20-percentile) > max(current hardLimit / 1.2, 80-percentile) > current hardLimit > > version 4 block: the coinbase of a version 4 block must match this patter= n: > "/BV\d+/" > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, > reject invalid version 4 blocks. (testnet4: 501 of last 1000) > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are > version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750 of= last > 1000) > Block version number is calculated after masking out high 16 bits (final = bit > count TBD by versionBits outcome). > > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=B0= : >> BIP 100 initial public draft: >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] >> >> Emphasis on "initial" This is a starting point for the usual open >> source feedback/iteration cycle, not an endpoint that Must Be This >> Way. >> >> >> >> Links: >> ------ >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki >> >> _______________________________________________ >> 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 > 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 95278116C for ; Thu, 3 Sep 2015 11:59:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC5A319C for ; Thu, 3 Sep 2015 11:59:01 +0000 (UTC) Received: by qkcj187 with SMTP id j187so19884909qkc.2 for ; Thu, 03 Sep 2015 04:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=myNQSAVK4762WS0Zx4qG1WL1AZPYciFbzSJsQloODAQ=; b=0Q0oo6O0fl1p0PDO6+t99WfsVebm7ImlveAtvT3bjk9iFEHO+c2Tv4QjjJHZmgC5PS HA1z4pad226P4KzqH5Xm8UDlrSjGizNMHPkRHmzAV1xe2S5jrpa99ndFOrtzOHkXA8Hx Tpa3IiTRrL9Sgg54Pl3hxNDSSQEvJll4bRYVQTQf7QQjIUdc6Nsp1peKJnbkgSu6B2Rl KyoECs9C8TaZ+6n8V9gxqeB97cDJ8RaSOfUbxFvPck2Ku0v1xuRCfjaUr2J8z3pyPWoN G1aXC9b1YGFZ8XVq/wEb14N1zB1I1cyL05YZ7ydb6/Y8M4zC/9U9yf7uJPSNrLC4EvDq XV1Q== MIME-Version: 1.0 X-Received: by 10.55.42.163 with SMTP id q35mr36933423qkq.107.1441281541202; Thu, 03 Sep 2015 04:59:01 -0700 (PDT) Received: by 10.140.107.4 with HTTP; Thu, 3 Sep 2015 04:59:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Sep 2015 12:59:01 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin development mailing list Content-Type: multipart/alternative; boundary=001a11493ef44905d5051ed682a1 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:59:02 -0000 --001a11493ef44905d5051ed682a1 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 1. > > hardLimit floats within the range 1-32M, inclusive. > > > Does the 32MB limit actually still exist anywhere in the code? In effect, it is re-instating a legacy limitation. The message size limit is to minimize the storage required per peer. If a 32MB block size is required, then each network input buffer must be at least 32MB. This makes it harder for a node to support a large number of peers. There is no reason why a single message is used for each block. Using the merkleblock message (or a different dedicated message), it would be possible to send messages which only contain part of a block and have a limited maximum size. This would allow receiving parts of a block from multiple sources. This is a separate issue but should be considered if moving past 32MB block sizes (or maybe as a later protocol change). > > 1. Changing hardLimit is accomplished by encoding a proposed value > within a block's coinbase scriptSig. > 1. Votes refer to a byte value, encoded within the pattern > "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If > there is more than one match with with pattern, the first match is counted. > > Is there a need for byte resolution? Using MB resolution would use up much fewer bytes in the coinbase. Even with the +/- 20% rule, miners could vote for the nearest MB. Once the block size exceeds 5MB, then there is enough resolution anyway. > 1. Absent/invalid votes and votes below minimum cap (1M) are counted > as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes. > > I think abstains should count for the status quo. Votes which are out of range should be clamped. Having said that, if core supports the change, then most miners will probably vote one way or another. > New hardLimit is the median of the followings: > min(current hardLimit * 1.2, 20-percentile) > max(current hardLimit / 1.2, 80-percentile) > current hardLimit I think this is unclear, though mathematically exact. Sort the votes for the last 12,000 blocks from lowest to highest. Blocks which don't have a vote are considered a vote for the status quo. Votes are limited to +/- 20% of the current value. Votes that are out of range are considered to vote for the nearest in range value. The raise value is defined as the vote for the 2400th highest block (20th percentile). The lower value is defined as the vote for the 9600th highest block (80th percentile). If the raise value is higher than the status quo, then the new limit is set to the raise value. If the lower value is lower than the status quo, then the new limit is set to the lower value. Otherwise, the size limit is unchanged. --001a11493ef44905d5051ed682a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

hardLimit floats within the range 1-32M, inclusive.

Does the 32MB limit actually still exis= t anywhere in the code?=C2=A0 In effect, it is re-instating a legacy limita= tion.

The message size limit is to minimize the storage r= equired per peer.=C2=A0 If a 32MB block size is required, then each network= input buffer must be at least 32MB. This makes it harder for a node to sup= port a large number of peers.

There is no reason why a si= ngle message is used for each block.=C2=A0 Using the merkleblock message (o= r a different dedicated message), it would be possible to send messages whi= ch only contain part of a block and have a limited maximum size.

This would allow receiving parts of a block from multiple sources.= =C2=A0

This is a separate issue but should be considered= if moving past 32MB block sizes (or maybe as a later protocol change).
=

=C2=A0

<= span style=3D"white-space:pre-wrap">Changing hardLimit is accomplished by e= ncoding a proposed value within a block's coinbase scriptSig.

Votes refer to a byte value, encod= ed within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,= 000,000 byte hardLimit. If there is more than one match with with pattern, the f= irst match is counted.

Is ther= e a need for byte resolution?=C2=A0 Using MB resolution would use up much f= ewer bytes in the coinbase.

Even with the +/- 20% rule, m= iners could vote for the nearest MB.=C2=A0 Once the block size exceeds 5MB,= then there is enough resolution anyway.

Absent/invalid votes and votes bel= ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3= 2M) are counted as 32M votes.

I think abstains should count for the status quo.=C2=A0 Vote= s which are out of range should be clamped.

Having said t= hat, if core supports the change, then most miners will probably vote one w= ay or another.

> New hardLim= it is the median of the followings:
> min(current ha= rdLimit * 1.2, 20-percentile)> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit

I thin= k this is unclear, though mathematically exact.

Sor= t the votes for the last 12,000 blocks from lowest to highest.=C2=A0
Blocks which don't have a vote are considered a vote for the status q= uo.

Votes are limited to +/- 20% of= the current value.=C2=A0 Votes that are out of range are considered to vot= e for the nearest in range value.

T= he raise value is defined as the vote for the 2400th highest block (20th pe= rcentile).

The lower value=C2=A0 is def= ined as the vote for the 9600th highest block (80th percentile).

If the raise value is higher than the status = quo, then the new limit is set to the raise value.

If the lower value is lower than the status quo, then the new l= imit is set to the lower value.

Otherwi= se, the size limit is unchanged.

--001a11493ef44905d5051ed682a1-- 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 68805119B for ; Thu, 3 Sep 2015 14:34:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF86410B for ; Thu, 3 Sep 2015 14:34:03 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so22151120wic.1 for ; Thu, 03 Sep 2015 07:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wEc2dgx51YFCkI8lyqVXHHQonWQkv3Y82rDo/INu758=; b=IPBMBYGLzJCHSDx3BTWWc1SVjKczJDfvKbqlo9kYL+VXcToI769m7esQE5YLZAm7gO 9DDK9GUiAmId8gk4PBXSYSOcpjANR0WykiZACwgGxVLEHpWq9MLplftjUz1tPYiiWsJu z/6p4NwpVRUnZONb39oUM2KWstn+NnOGrJV6SQyBa++tINdMiFfTyo0myJHSQjjcSKHP mciU+leLGkoI1khRECk++z7WTffRPhJiQiC1vqxtEwil33h4LvGUo8hgTNlZYBvbhtha rPJIXCUe0rhhj2+I7YnZrwTmFPi3UrpyMp0Irv786FX8B6Wg+kteLGbXVcy0CtI4QQgc VSJg== MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr50047597wjc.109.1441290842753; Thu, 03 Sep 2015 07:34:02 -0700 (PDT) Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:34:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Sep 2015 10:34:02 -0400 Message-ID: From: Jeff Garzik To: Btc Drak Content-Type: multipart/alternative; boundary=089e0141aa1ab3516f051ed8ac78 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:34:05 -0000 --089e0141aa1ab3516f051ed8ac78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A discussion of rolling out BIP 100 will not be avoided :) It is a hard fork; it would be silly to elide discussion of these key issues. I don't get the community's recent interest in avoiding certain topics. On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak wrote: > We should avoid discussing actual hard fork/softfork deployment > methodologies when discussing blocksize proposals because deployment > is a separate issue. As a recent case in point, look at how BIP65 > (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. > That lead to a focused discussion of the functionality and relatively > quick inclusion. > > Deployment really is a separate issue than the mechanics of how BIP100 > will function after activation. > > On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev > wrote: > > Some comments: > > > > The 75% rule is meaningless here. Since this is a pure relaxation of > rules, > > there is no such thing as "invalid version 4 blocks" > > > > The implication threshold is unclear. Is it 95% or 80%? > > > > Softfork requires a very high threshold (95%) to "attack" the original > fork. > > This makes sure that unupgraded client will only see the new fork. > > In the case of hardfork, however, the new fork is unable to attack the > > original fork, and unupgraded client will never see the new fork. The > > initiation of a hardfork should be based on its acceptance by the > economic > > majority, not miner support. 95% is an overkill and may probably never > > accomplished. I strongly prefer a 80% threshold rather than 95%. > > > > As I've pointed out, using 20-percentile rather than median creates an > > incentive to 51% attack the uncooperative minority. > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01069= 0.html > > > > Having said that, I don't have a strong feeling about the use of > > 20-percentile as threshold to increase the block size. That means the > block > > size is increased only when most miners agree, which sounds ok to me. > > > > However, using 20-percentile as threshold to DECREASE the block size > could > > be very dangerous. Consider that the block size has been stable at 8MB > for a > > few years. Everyone are happy with that. An attacker would just need to > > acquire 21% of mining power to break the status quo and send us all the > way > > to 1MB. The only way to stop such attempt is to 51% attack the attacker= . > > That'd be really ugly. > > > > For technical and ethical reasons, I believe the thresholds for increas= e > and > > decrease must be symmetrical: increase the block size when the > x-percentile > > is bigger than the current size, decrease the block size when the > > (100-x)-percentile is smaller than the current size. The overall effect > is: > > the block size remains unchanged unless 80% of miners agree to. > > > > Please consider the use of "hardfork bit" to signify the hardfork: > > > > > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo= rk_bit_jl2012_at_xbthk_jul_23_2015/ > > > > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki > > > > Or, alternatively, please combine the hardfork with a softfork. I'm > > rewriting the specification as follow (changes underlined): > > > > Replace static 1M block size hard limit with a floating limit > ("hardLimit"). > > > > hardLimit floats within the range 1-32M, inclusive. > > > > Initial value of hardLimit is 1M, preserving current system. > > > > Changing hardLimit is accomplished by encoding a proposed value within = a > > block's coinbase scriptSig. > > > > Votes refer to a byte value, encoded within the pattern "/BV\d+/" > Example: > > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than o= ne > > match with with pattern, the first match is counted. > > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M > > votes. Votes above the maximum cap (32M) are counted as 32M votes. > > A new hardLimit is calculated at each difficult adjustment period (2016 > > blocks), and applies to the next 2016 blocks. > > Calculate hardLimit by examining the coinbase scriptSig votes of the > > previous 12,000 blocks, and taking the 20th percentile and 80th > percentile. > > New hardLimit is the median of the followings: > > > > min(current hardLimit * 1.2, 20-percentile) > > max(current hardLimit / 1.2, 80-percentile) > > current hardLimit > > > > version 4 block: the coinbase of a version 4 block must match this > pattern: > > "/BV\d+/" > > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, > > reject invalid version 4 blocks. (testnet4: 501 of last 1000) > > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are > > version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750 = of > last > > 1000) > > Block version number is calculated after masking out high 16 bits (fina= l > bit > > count TBD by versionBits outcome). > > > > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= =B0: > >> BIP 100 initial public draft: > >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] > >> > >> Emphasis on "initial" This is a starting point for the usual open > >> source feedback/iteration cycle, not an endpoint that Must Be This > >> Way. > >> > >> > >> > >> Links: > >> ------ > >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > >> > >> _______________________________________________ > >> 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 > > > --089e0141aa1ab3516f051ed8ac78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A discussion of rolling out BIP 100 will not be avoided :)=

It is a hard fork; it would be silly to elide discussio= n of these key issues.

I don't get the communi= ty's recent interest in avoiding certain topics.

On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail.com> wrote:

We should avoid discussing actu= al hard fork/softfork deployment
methodologies when discussing blocksize proposals because deployment
is a separate issue. As a recent case in point, look at how BIP65
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
That lead to a focused discussion of the functionality and relatively
quick inclusion.

Deployment really is a separate issue than the mechanics of how BIP100
will function after activation.

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of r= ules,
> there is no such thing as "invalid version 4 blocks"
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> Softfork requires a very high threshold (95%) to "attack" th= e original fork.
> This makes sure that unupgraded client will only see the new fork.
> In the case of hardfork, however, the new fork is unable to attack the=
> original fork, and unupgraded client will never see the new fork. The<= br> > initiation of a hardfork should be based on its acceptance by the econ= omic
> majority, not miner support. 95% is an overkill and may probably never=
> accomplished. I strongly prefer a 80% threshold rather than 95%.
>
> As I've pointed out, using 20-percentile rather than median create= s an
> incentive to 51% attack the uncooperative minority.
> https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of > 20-percentile as threshold to increase the block size. That means the = block
> size is increased only when most miners agree, which sounds ok to me.<= br> >
> However, using 20-percentile as threshold to DECREASE the block size c= ould
> be very dangerous. Consider that the block size has been stable at 8MB= for a
> few years. Everyone are happy with that. An attacker would just need t= o
> acquire 21% of mining power to break the status quo and send us all th= e way
> to 1MB. The only way to stop such attempt is to 51% attack the attacke= r.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increa= se and
> decrease must be symmetrical: increase the block size when the x-perce= ntile
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effec= t is:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the har= dfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_d= raft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/= blob/master/hardforkbit.mediawiki
>
> Or, alternatively, please combine the hardfork with a softfork. I'= m
> rewriting the specification as follow (changes underlined):
>
> Replace static 1M block size hard limit with a floating limit ("h= ardLimit").
>
> hardLimit floats within the range 1-32M, inclusive.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> Changing hardLimit is accomplished by encoding a proposed value within= a
> block's coinbase scriptSig.
>
> Votes refer to a byte value, encoded within the pattern "/BV\d+/&= quot; Example:
> /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than = one
> match with with pattern, the first match is counted.
> Absent/invalid votes and votes below minimum cap (1M) are counted as 1= M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (201= 6
> blocks), and applies to the next 2016 blocks.
> Calculate hardLimit by examining the coinbase scriptSig votes of the > previous 12,000 blocks, and taking the 20th percentile and 80th percen= tile.
> New hardLimit is the median of the followings:
>
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this pat= tern:
> "/BV\d+/"
> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,=
> reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 80% rule ("Point of no return"): If 9,600 of the last 12,000= blocks are
> version 4 or greater, reject all version <=3D 3 blocks. (testnet4: = 750 of last
> 1000)
> Block version number is calculated after masking out high 16 bits (fin= al bit
> count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= =B0:
>> BIP 100 initial public draft:
>> https://github.com/jgarzik/= bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial"=C2=A0 This is a starting point for= the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This=
>> Way.
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/jgar= zik/bip100/blob/master/bip-0100.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--089e0141aa1ab3516f051ed8ac78-- 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 1169C1119 for ; Thu, 3 Sep 2015 14:35:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8BB9210B for ; Thu, 3 Sep 2015 14:35:57 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so10544742wic.1 for ; Thu, 03 Sep 2015 07:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+0M7vWOVxf6EH0RdLZ1Yse0mvkF+odoV9xfQ9OicJ+8=; b=xmTNjRjr/eWpM0sqYX8+nDbergj37zIoStcmdKjTxheXsdp0FYEjm/WbTRxm8FATie aytkUrovQXx0Ilw8gMEtfX1owS1Ft6MLSaCmExbM2S6yGZF6LS6Nm/gALZcLXDHDVMtN mVBFEJsNI+zdbODGaH4K4jhYETGEdZ3v4puLqzpnA20FM9rxa3N/EaqgGvMp6RTiA2Hj SikZuXQzdUx1UqHu3DccamGGlvWpJX8B+yl/uiGAvSM+NxTpe2oFfiakJB5Iewn96Una WwdEkUOZwlX001t9ij+KApR6BiHqpjoRNfERAx3Aw2qlde5nPpsXAg/1cswT6dKA2XBq gL5Q== MIME-Version: 1.0 X-Received: by 10.195.18.5 with SMTP id gi5mr54820904wjd.0.1441290956202; Thu, 03 Sep 2015 07:35:56 -0700 (PDT) Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:35:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Sep 2015 10:35:56 -0400 Message-ID: From: Jeff Garzik To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a11c282147667dc051ed8b383 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:35:59 -0000 --001a11c282147667dc051ed8b383 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks - several good suggestions, including some in common. Will comment & revise today. Currently in "collecting" mode, to avoid duplicative comments in multiple locales. On Thu, Sep 3, 2015 at 3:57 AM, wrote: > Some comments: > > > - The 75% rule is meaningless here. Since this is a pure relaxation of > rules, there is no such thing as "invalid version 4 blocks" > > > - > > The implication threshold is unclear. Is it 95% or 80%? > > - Softfork requires a very high threshold (95%) to "attack" the > original fork. This makes sure that unupgraded client will only see= the new > fork. > - In the case of hardfork, however, the new fork is unable to > attack the original fork, and unupgraded client will never see the = new > fork. The initiation of a hardfork should be based on its acceptanc= e by the > economic majority, not miner support. 95% is an overkill and may pr= obably > never accomplished. I strongly prefer a 80% threshold rather than 9= 5%. > > > - As I've pointed out, using 20-percentile rather than median creates > an incentive to 51% attack the uncooperative minority. > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01= 0690.html > > Having said that, I don't have a strong feeling about the use of > 20-percentile as threshold to increase the block size. That means the blo= ck > size is increased only when most miners agree, which sounds ok to me. > > However, using 20-percentile as threshold to DECREASE the block size coul= d > be very dangerous. Consider that the block size has been stable at 8MB fo= r > a few years. Everyone are happy with that. An attacker would just need to > acquire 21% of mining power to break the status quo and send us all the w= ay > to 1MB. The only way to stop such attempt is to 51% attack the attacker. > That'd be really ugly. > > For technical and ethical reasons, I believe the thresholds for increase > and decrease must be symmetrical: increase the block size when the > x-percentile is bigger than the current size, decrease the block size whe= n > the (100-x)-percentile is smaller than the current size. The overall effe= ct > is: the block size remains unchanged unless 80% of miners agree to. > > - Please consider the use of "hardfork bit" to signify the hardfork: > > > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo= rk_bit_jl2012_at_xbthk_jul_23_2015/ > > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki > > - Or, alternatively, please combine the hardfork with a softfork. I'm > rewriting the specification as follow (changes underlined): > > > 1. Replace static 1M block size hard limit with a floating limit > ("hardLimit"). > 2. > > hardLimit floats within the range 1-32M, inclusive. > > 3. > > Initial value of hardLimit is 1M, preserving current system. > > 4. Changing hardLimit is accomplished by encoding a proposed value > within a block's coinbase scriptSig. > 1. Votes refer to a byte value, encoded within the pattern > "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. = If > there is more than one match with with pattern, the first match is = counted. > 2. Absent/invalid votes and votes below minimum cap (1M) are > counted as 1M votes. Votes above the maximum cap (32M) are counted = as 32M > votes. > 3. A new hardLimit is calculated at each difficult adjustment > period (2016 blocks), and applies to the next 2016 blocks. > 4. Calculate hardLimit by examining the coinbase scriptSig votes of > the previous 12,000 blocks, and taking the 20th percentile and 80th > percentile. > 5. New hardLimit is the median of the followings: > 1. min(current hardLimit * 1.2, 20-percentile) > 2. max(current hardLimit / 1.2, 80-percentile) > 3. current hardLimit > 5. version 4 block: the coinbase of a version 4 block must match > this pattern: "/BV\d+/" > 6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or > greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000) > 7. 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks > are version 4 or greater, reject all version <=3D 3 blocks. (testnet4:= 750 of > last 1000) > 8. Block version number is calculated after masking out high 16 bits > (final bit count TBD by versionBits outcome). > > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=B0= : > > BIP 100 initial public draft: > > https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] > > > > Emphasis on "initial" This is a starting point for the usual open > > source feedback/iteration cycle, not an endpoint that Must Be This > > Way. > > > > > > > > Links: > > ------ > > [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11c282147667dc051ed8b383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks - several good suggestions, including some in commo= n.=C2=A0 Will comment & revise today.

Currently in &= quot;collecting" mode, to avoid duplicative comments in multiple local= es.

On Thu, Sep 3, 2015 at 3:57 AM, <jl2012@xbt.hk> wrote:

Some comments:

The 75% rule is meaningless here. Since this is a pure relaxation of ru= les, there is no such thing as "invalid version 4 blocks"

The implication threshold is unclear. Is it 95% or 80%?

Softfork requires a very high threshold (95%) to "attack" the= original fork. This makes sure that unupgraded client will only see the ne= w fork.

In the case of hardfork, however, the new fork is unable to attack the = original fork, and unupgraded client will never see the new fork. The initi= ation of a hardfork should be based on its acceptance by the economic major= ity, not miner support. 95% is an overkill and may probably never accomplis= hed. I strongly prefer a 80% threshold rather than 95%.

As I've pointed out, using 20-percentile rather than median creates= an incentive to 51% attack the uncooperative minority. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= 5-August/010690.html

Having = said that, I don't have a strong feeling about the use of 20-percentile= as threshold to increase the block size. That means the block size is incr= eased only when most miners agree, which sounds ok to me.

= However, using 20-percentile as threshold to DECREASE the block size could = be very dangerous. Consider that the block size has been stable at 8MB for = a few years. Everyone are happy with that. An attacker would just need to a= cquire 21% of mining power to break the status quo and send us all the way = to 1MB. The only way to stop such attempt is to 51% attack the attacker. Th= at'd be really ugly.

For tec= hnical and ethical reasons, I believe the thresholds for increase and decre= ase must be symmetrical: increase the block size when the x-percentile is b= igger than the current size, decrease the block size when the (100-x)-perce= ntile is smaller than the current size. The overall effect is: the block si= ze remains unchanged unless 80% of miners agree to.

Please consider the use of "hardfork bit" to signify the hard= fork:

https://www.reddit= .com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbt= hk_jul_23_2015/

https://github.com/jl2012/bips/blob/master/hardforkbit.mediawi= ki

Or, alternatively, please combine the hardfork with a softfork. I'm= rewriting the specification as follow (changes underlined):

Replace static 1M block size hard limit with a floating limit ("ha= rdLimit").

hardLimit floats within the range 1-32M, inclusive.

Initial value of hardLimit is 1M, preserving current system.

Changing hardLimit is accomplished= by encoding a proposed value within a block's coinbase scriptSig.

Votes refer to a byte value, encod= ed within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,= 000,000 byte hardLimit. If there is more than one match with with pattern, the f= irst match is counted.

Absent/invalid votes and votes bel= ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3= 2M) are counted as 32M votes.

A new hardLimit is calculated at e= ach difficult adjustment period (2016 blocks), and applies to the next 2016= blocks.

Calculate hardLimit by examining t= he coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20th p= ercentile and 80th percentile.

New hard= Limit is the median of the followings:

m= in(current h= ardLimit * 1.2, 20-percentile)

max(curr= ent hardLimit / 1.2, 80-percentile)

current = hardLimit

version 4 block: the coinbase of a vers= ion 4 block must match this pattern: "/BV\d+/"

70% rule: If 8,400 of the last = 12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (t= estnet4: 501 of last 1000)

80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are version 4 or greater, re= ject all version <=3D 3 blocks. (testnet4: 750 of last 1000)

Block version number is calculated= after masking out high 16 bits (final bit count TBD by versionBits outcome= ).

Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= =B0: > BIP 100 initial public draft: > https://github.com/jgarzik/bip100/blob/master/bip-= 0100.mediawiki [1] >=20 > Emphasis on "initial" This is a starting point for the usua= l open > source feedback/iteration cycle, not an endpoint that Must Be This > Way. >=20 >=20 >=20 > Links: > ------ > [1] https://github.com/jgarzik/bip100/blob/master/= bip-0100.mediawiki >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/b= itcoin-dev

--001a11c282147667dc051ed8b383-- 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 12AE211D8 for ; Thu, 3 Sep 2015 15:58:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B2C61AA for ; Thu, 3 Sep 2015 15:58:24 +0000 (UTC) Received: by iofh134 with SMTP id h134so63554016iof.0 for ; Thu, 03 Sep 2015 08:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eJyPJxBgdy6tlP3sBhW0iZisySyAVyxcneKIFcp3aQs=; b=PJCKrWfL/7WZ2tP1fAw4eW3+Xjn5n4QTwu8VtHJBkzpe9I1a4Xvpby6Zi7yX1LnIdc /7qW+JF4XyAe/vifOwTdot0xoJg9Zb9O9d+l3wuivyiuPj77jleTPX9sI6nbYP5nC2C0 NsN3MgCGRBJOMDTAlLINmmdrvcrZmMMm6xfC4U50GSkB8tW14vAIG4otpLXXMIMQ6Blq M9x+CuAXAwsbTMoSwjirajl8nsLhcxk8tMFam6okoelR9XPIxL57r4npfROWJC/PREC/ 0y/nWI8Y/V4s+NphAQaDiY1eNA0qEnD3iFa87Z6Kx8ZyBY9OwwNOcn4WgjSDXs7GYf+K tdHg== X-Received: by 10.107.162.205 with SMTP id l196mr21646444ioe.3.1441295903685; Thu, 03 Sep 2015 08:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.40 with HTTP; Thu, 3 Sep 2015 08:58:04 -0700 (PDT) In-Reply-To: References:

From: Btc Drak Date: Thu, 3 Sep 2015 16:58:04 +0100 Message-ID: To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:58:26 -0000 On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik wrote: > A discussion of rolling out BIP 100 will not be avoided :) > > It is a hard fork; it would be silly to elide discussion of these key > issues. > > I don't get the community's recent interest in avoiding certain topics. It's not a matter of avoiding the subject, it's a whole separate discussion and in the interests of efficient discussion, it is best done separately. There's a whole BIP dedicated to the discussion of consensus forks which you should probably give some input in also, BIP99 [1] Once we come to an agreement and can say "here's what we're doing about blocksize, it will be X, or we'll raise by this algo", then we can discuss the best way to implement the hard fork. [1] https://github.com/bitcoin/bips/pull/181 > > > > On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak wrote: >> >> We should avoid discussing actual hard fork/softfork deployment >> methodologies when discussing blocksize proposals because deployment >> is a separate issue. As a recent case in point, look at how BIP65 >> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. >> That lead to a focused discussion of the functionality and relatively >> quick inclusion. >> >> Deployment really is a separate issue than the mechanics of how BIP100 >> will function after activation. >> >> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >> wrote: >> > Some comments: >> > >> > The 75% rule is meaningless here. Since this is a pure relaxation of >> > rules, >> > there is no such thing as "invalid version 4 blocks" >> > >> > The implication threshold is unclear. Is it 95% or 80%? >> > >> > Softfork requires a very high threshold (95%) to "attack" the original >> > fork. >> > This makes sure that unupgraded client will only see the new fork. >> > In the case of hardfork, however, the new fork is unable to attack the >> > original fork, and unupgraded client will never see the new fork. The >> > initiation of a hardfork should be based on its acceptance by the >> > economic >> > majority, not miner support. 95% is an overkill and may probably never >> > accomplished. I strongly prefer a 80% threshold rather than 95%. >> > >> > As I've pointed out, using 20-percentile rather than median creates an >> > incentive to 51% attack the uncooperative minority. >> > >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01= 0690.html >> > >> > Having said that, I don't have a strong feeling about the use of >> > 20-percentile as threshold to increase the block size. That means the >> > block >> > size is increased only when most miners agree, which sounds ok to me. >> > >> > However, using 20-percentile as threshold to DECREASE the block size >> > could >> > be very dangerous. Consider that the block size has been stable at 8MB >> > for a >> > few years. Everyone are happy with that. An attacker would just need t= o >> > acquire 21% of mining power to break the status quo and send us all th= e >> > way >> > to 1MB. The only way to stop such attempt is to 51% attack the attacke= r. >> > That'd be really ugly. >> > >> > For technical and ethical reasons, I believe the thresholds for increa= se >> > and >> > decrease must be symmetrical: increase the block size when the >> > x-percentile >> > is bigger than the current size, decrease the block size when the >> > (100-x)-percentile is smaller than the current size. The overall effec= t >> > is: >> > the block size remains unchanged unless 80% of miners agree to. >> > >> > Please consider the use of "hardfork bit" to signify the hardfork: >> > >> > >> > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_har= dfork_bit_jl2012_at_xbthk_jul_23_2015/ >> > >> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki >> > >> > Or, alternatively, please combine the hardfork with a softfork. I'm >> > rewriting the specification as follow (changes underlined): >> > >> > Replace static 1M block size hard limit with a floating limit >> > ("hardLimit"). >> > >> > hardLimit floats within the range 1-32M, inclusive. >> > >> > Initial value of hardLimit is 1M, preserving current system. >> > >> > Changing hardLimit is accomplished by encoding a proposed value within= a >> > block's coinbase scriptSig. >> > >> > Votes refer to a byte value, encoded within the pattern "/BV\d+/" >> > Example: >> > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than >> > one >> > match with with pattern, the first match is counted. >> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1= M >> > votes. Votes above the maximum cap (32M) are counted as 32M votes. >> > A new hardLimit is calculated at each difficult adjustment period (201= 6 >> > blocks), and applies to the next 2016 blocks. >> > Calculate hardLimit by examining the coinbase scriptSig votes of the >> > previous 12,000 blocks, and taking the 20th percentile and 80th >> > percentile. >> > New hardLimit is the median of the followings: >> > >> > min(current hardLimit * 1.2, 20-percentile) >> > max(current hardLimit / 1.2, 80-percentile) >> > current hardLimit >> > >> > version 4 block: the coinbase of a version 4 block must match this >> > pattern: >> > "/BV\d+/" >> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, >> > reject invalid version 4 blocks. (testnet4: 501 of last 1000) >> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks ar= e >> > version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750= of >> > last >> > 1000) >> > Block version number is calculated after masking out high 16 bits (fin= al >> > bit >> > count TBD by versionBits outcome). >> > >> > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= =B0: >> >> BIP 100 initial public draft: >> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] >> >> >> >> Emphasis on "initial" This is a starting point for the usual open >> >> source feedback/iteration cycle, not an endpoint that Must Be This >> >> Way. >> >> >> >> >> >> >> >> Links: >> >> ------ >> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki >> >> >> >> _______________________________________________ >> >> 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 >> > > > 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 5F9781255 for ; Thu, 3 Sep 2015 16:13:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC4901C9 for ; Thu, 3 Sep 2015 16:13:36 +0000 (UTC) Received: by wibz8 with SMTP id z8so104475311wib.1 for ; Thu, 03 Sep 2015 09:13:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gv3R0N0oIMVLdMQ2vyY2RPi5JYsCBmHpCcVVvtRUT7o=; b=gvokl0bp5VggrXKKxnFg7tv9l/e/T+JgmwPC0I5VN98LzNpYDKD3nlFZzk7dT7BRmo ZeH3ptvQ4w/5P/+QTGJReYLktPy+Pmp8U66L0J3YCu4B4EmqgLykXSc9TwpHuWpIiEy/ niOXl+xEjYg93QPnttDJBZdp5kr2ZdLX/ha+yZkMSz52sRtMw8bmOD32giYzYOf5Si5N lDqwsfVxMijKkUCPZpXR+EepRK1R2bv5/PxVuEluJ6RY01iDxzbprc3dKYbU7K+8Z12X 3VCYyGHXsHhCEqhXGqVZUB1iIJFIN+QdjUM0bd5vQnarxHxyckrp9f4EN72qn950rgjD acUw== X-Gm-Message-State: ALoCoQkFtTrtNPZcjjJbTMdN6bb/GLHGAS7JNMSO3H5yTJNnedAOSAzLK7QASfq6mG4ud7pVZkbj MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr52113069wjb.26.1441296815089; Thu, 03 Sep 2015 09:13:35 -0700 (PDT) Received: by 10.194.31.166 with HTTP; Thu, 3 Sep 2015 09:13:34 -0700 (PDT) Received: by 10.194.31.166 with HTTP; Thu, 3 Sep 2015 09:13:34 -0700 (PDT) In-Reply-To: References:

Date: Thu, 3 Sep 2015 18:13:34 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Btc Drak Content-Type: multipart/alternative; boundary=089e01228c70ae0187051eda10d0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 16:13:37 -0000 --089e01228c70ae0187051eda10d0 Content-Type: text/plain; charset=UTF-8 On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik wrote: > > A discussion of rolling out BIP 100 will not be avoided :) > > > > It is a hard fork; it would be silly to elide discussion of these key > > issues. > > > > I don't get the community's recent interest in avoiding certain topics. > > It's not a matter of avoiding the subject, it's a whole separate > discussion and in the interests of efficient discussion, it is best > done separately. There's a whole BIP dedicated to the discussion of > consensus forks which you should probably give some input in also, > BIP99 [1] > > Once we come to an agreement and can say "here's what we're doing > about blocksize, it will be X, or we'll raise by this algo", then we > can discuss the best way to implement the hard fork. > > [1] https://github.com/bitcoin/bips/pull/181 In fact, that discussion can happen in parallel. But it is more efficient to do so in one place instead of in each of the 5+ hardfork proposals (bip99 itself has a hardfork proposal with its code ready). --089e01228c70ae0187051eda10d0 Content-Type: text/html; charset=UTF-8

On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> > A discussion of rolling out BIP 100 will not be avoided :)
> >
> > It is a hard fork; it would be silly to elide discussion of these key
> > issues.
> >
> > I don't get the community's recent interest in avoiding certain topics.
>
> It's not a matter of avoiding the subject, it's a whole separate
> discussion and in the interests of efficient discussion, it is best
> done separately. There's a whole BIP dedicated to the discussion of
> consensus forks which you should probably give some input in also,
> BIP99 [1]
>
> Once we come to an agreement and can say "here's what we're doing
> about blocksize, it will be X, or we'll raise by this algo", then we
> can discuss the best way to implement the hard fork.
>
> [1] https://github.com/bitcoin/bips/pull/181

In fact, that discussion can happen in parallel. But it is more efficient to do so in one place instead of in each of the 5+ hardfork proposals (bip99 itself has a hardfork proposal with its code ready).

--089e01228c70ae0187051eda10d0-- 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 60BA4F44 for ; Thu, 3 Sep 2015 16:32:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D4F61D9 for ; Thu, 3 Sep 2015 16:32:16 +0000 (UTC) Received: from localhost ([::1]:46954 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZXXQt-0022Rv-5q; Thu, 03 Sep 2015 12:32:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 03 Sep 2015 12:32:15 -0400 From: jl2012@xbt.hk To: Tier Nolan In-Reply-To: References:

Message-ID: <301aa5f682f8aa408b9f6f4618095fe2@xbt.hk> X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 16:32:17 -0000 1. I think there is no need to have resolution at byte level, while resolution at MB level is not enough. kB would be a better choice. 2. In my specification a v4 block without a vote is invalid, so there is no need to consider absent or invalid votes 3. We should allow miners to explicitly vote for the status quo, so they don't need to change the coinbase vote every time the size is changed. They may indicate it by /BV/ in the coinbase, and we should look for the first "/BVd*/" instead of "/BVd+/" 4. Alternatively, miners may vote in different styles: /BV1234567/, /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到: > On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev > wrote: > >> * >> >> hardLimit floats within the range 1-32M, inclusive. > > Does the 32MB limit actually still exist anywhere in the code? In > effect, it is re-instating a legacy limitation. > > The message size limit is to minimize the storage required per peer. > If a 32MB block size is required, then each network input buffer must > be at least 32MB. This makes it harder for a node to support a large > number of peers. > > There is no reason why a single message is used for each block. Using > the merkleblock message (or a different dedicated message), it would > be possible to send messages which only contain part of a block and > have a limited maximum size. > > This would allow receiving parts of a block from multiple sources. > > This is a separate issue but should be considered if moving past 32MB > block sizes (or maybe as a later protocol change). > >> * Changing hardLimit is accomplished by encoding a proposed value >> within a block's coinbase scriptSig. >> >> * Votes refer to a byte value, encoded within the pattern "/BVd+/" >> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is >> more than one match with with pattern, the first match is counted. > > Is there a need for byte resolution? Using MB resolution would use up > much fewer bytes in the coinbase. > > Even with the +/- 20% rule, miners could vote for the nearest MB. > Once the block size exceeds 5MB, then there is enough resolution > anyway. > >> * Absent/invalid votes and votes below minimum cap (1M) are >> counted as 1M votes. Votes above the maximum cap (32M) are counted >> as 32M votes. > > I think abstains should count for the status quo. Votes which are out > of range should be clamped. > > Having said that, if core supports the change, then most miners will > probably vote one way or another. > >> New hardLimit is the median of the followings: >> min(current hardLimit * 1.2, 20-percentile) >> max(current hardLimit / 1.2, 80-percentile) >> current hardLimit > > I think this is unclear, though mathematically exact. > > Sort the votes for the last 12,000 blocks from lowest to highest. > > Blocks which don't have a vote are considered a vote for the status > quo. > > Votes are limited to +/- 20% of the current value. Votes that are out > of range are considered to vote for the nearest in range value. > > The raise value is defined as the vote for the 2400th highest block > (20th percentile). > > The lower value is defined as the vote for the 9600th highest block > (80th percentile). > > If the raise value is higher than the status quo, then the new limit > is set to the raise value. > > If the lower value is lower than the status quo, then the new limit is > set to the lower value. > > Otherwise, the size limit is unchanged. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 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 1F06CE66 for ; Thu, 3 Sep 2015 16:35:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF84C1E8 for ; Thu, 3 Sep 2015 16:35:24 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so4917032wic.0 for ; Thu, 03 Sep 2015 09:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kyTeM+DHgAKs7+L3wH1uT7rWa5PS61o0r7lPHqYB86w=; b=AjSZyW2m09oBhR7sheNoJAiwlBsnj4fSZWR4PDqsztB6kYXY7/4UoPSj1O3sFsUfi7 zbWGC7Wz1xDo3/BPa1aLJpoYJwv46ayhTcBaKYe+g9Az0YX2yDc7L3FvU9M37oJ4b+Ol xfhwmPBmZZCykP11GC6LPMQiuvExUHvckKG+y2f2BmiZyHxLchxMr3DNu8cN4lAT/1wV cNnuiDz/AcwS30bze2Y8+z4DprtpJzHBZwVyX7YWhKkR6kCKiElrSWHPGkFa1Oa5Bova NEO4G1kPc9yKa+aC8TaXl1avmK9HBB5dEN3c0qTW7eRcNGDItwnAKT/0y2UXE/hMrY5y 5vTQ== MIME-Version: 1.0 X-Received: by 10.180.87.1 with SMTP id t1mr15720367wiz.33.1441298123658; Thu, 03 Sep 2015 09:35:23 -0700 (PDT) Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 09:35:23 -0700 (PDT) In-Reply-To: <301aa5f682f8aa408b9f6f4618095fe2@xbt.hk> References:

<301aa5f682f8aa408b9f6f4618095fe2@xbt.hk> Date: Thu, 3 Sep 2015 12:35:23 -0400 Message-ID: From: Jeff Garzik To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=f46d044481afad1b83051eda5e5c X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 16:35:27 -0000 --f46d044481afad1b83051eda5e5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Take a look at the latest update: - swiped Tier Nolan verbiage, which I agree was usefully more clear - added 'M' suffix and removed 'V' from coinbase scriptSig On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1. I think there is no need to have resolution at byte level, while > resolution at MB level is not enough. kB would be a better choice. > > 2. In my specification a v4 block without a vote is invalid, so there is > no need to consider absent or invalid votes > > 3. We should allow miners to explicitly vote for the status quo, so they > don't need to change the coinbase vote every time the size is changed. Th= ey > may indicate it by /BV/ in the coinbase, and we should look for the first > "/BVd*/" instead of "/BVd+/" > > 4. Alternatively, miners may vote in different styles: /BV1234567/, > /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5M= B, > the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" > > Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0: > >> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >> wrote: >> >> * >>> >>> hardLimit floats within the range 1-32M, inclusive. >>> >> >> Does the 32MB limit actually still exist anywhere in the code? In >> effect, it is re-instating a legacy limitation. >> >> The message size limit is to minimize the storage required per peer. >> If a 32MB block size is required, then each network input buffer must >> be at least 32MB. This makes it harder for a node to support a large >> number of peers. >> >> There is no reason why a single message is used for each block. Using >> the merkleblock message (or a different dedicated message), it would >> be possible to send messages which only contain part of a block and >> have a limited maximum size. >> >> This would allow receiving parts of a block from multiple sources. >> >> This is a separate issue but should be considered if moving past 32MB >> block sizes (or maybe as a later protocol change). >> >> * Changing hardLimit is accomplished by encoding a proposed value >>> within a block's coinbase scriptSig. >>> >>> * Votes refer to a byte value, encoded within the pattern "/BVd+/" >>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is >>> more than one match with with pattern, the first match is counted. >>> >> >> Is there a need for byte resolution? Using MB resolution would use up >> much fewer bytes in the coinbase. >> >> Even with the +/- 20% rule, miners could vote for the nearest MB. >> Once the block size exceeds 5MB, then there is enough resolution >> anyway. >> >> * Absent/invalid votes and votes below minimum cap (1M) are >>> >>> counted as 1M votes. Votes above the maximum cap (32M) are counted >>> as 32M votes. >>> >> >> I think abstains should count for the status quo. Votes which are out >> of range should be clamped. >> >> Having said that, if core supports the change, then most miners will >> probably vote one way or another. >> >> New hardLimit is the median of the followings: >>> min(current hardLimit * 1.2, 20-percentile) >>> max(current hardLimit / 1.2, 80-percentile) >>> current hardLimit >>> >> >> I think this is unclear, though mathematically exact. >> >> Sort the votes for the last 12,000 blocks from lowest to highest. >> >> Blocks which don't have a vote are considered a vote for the status >> quo. >> >> Votes are limited to +/- 20% of the current value. Votes that are out >> of range are considered to vote for the nearest in range value. >> >> The raise value is defined as the vote for the 2400th highest block >> (20th percentile). >> >> The lower value is defined as the vote for the 9600th highest block >> (80th percentile). >> >> If the raise value is higher than the status quo, then the new limit >> is set to the raise value. >> >> If the lower value is lower than the status quo, then the new limit is >> set to the lower value. >> >> Otherwise, the size limit is unchanged. >> >> _______________________________________________ >> 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 > --f46d044481afad1b83051eda5e5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Take a look at the latest update:

- swi= ped Tier Nolan verbiage, which I agree was usefully more clear

- = added 'M' suffix and removed 'V' from coinbase scriptSig

On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=

1. I think there is no need to have resoluti= on at byte level, while resolution at MB level is not enough. kB would be a= better choice.

2. In my specification a v4 block without a vote is invalid, so there is no= need to consider absent or invalid votes

3. We should allow miners to explicitly vote for the status quo, so they do= n't need to change the coinbase vote every time the size is changed. Th= ey may indicate it by /BV/ in the coinbase, and we should look for the firs= t "/BVd*/" instead of "/BVd+/"

4. Alternatively, miners may vote in different styles: /BV1234567/, /BV1500= K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the la= st one is 3MB. The pattern is "/BV(\d+[KM]?)?/"

Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0:
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

*

hardLimit floats within the range 1-32M, inclusive.

Does the 32MB limit actually still exist anywhere in the code?=C2=A0 In
effect, it is re-instating a legacy limitation.

The message size limit is to minimize the storage required per peer.
If a 32MB block size is required, then each network input buffer must
be at least 32MB. This makes it harder for a node to support a large
number of peers.

There is no reason why a single message is used for each block.=C2=A0 Using=
the merkleblock message (or a different dedicated message), it would
be possible to send messages which only contain part of a block and
have a limited maximum size.

This would allow receiving parts of a block from multiple sources.

This is a separate issue but should be considered if moving past 32MB
block sizes (or maybe as a later protocol change).

* Changing hardLimit is accomplished by encoding a proposed value
within a block's coinbase scriptSig.

* Votes refer to a byte value, encoded within the pattern "/BVd+/"= ;
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
more than one match with with pattern, the first match is counted.

Is there a need for byte resolution?=C2=A0 Using MB resolution would use up=
much fewer bytes in the coinbase.

Even with the +/- 20% rule, miners could vote for the nearest MB.
Once the block size exceeds 5MB, then there is enough resolution
anyway.

* Absent/invalid votes and votes below minimum cap (1M) are

counted as 1M votes. Votes above the maximum cap (32M) are counted
as 32M votes.

I think abstains should count for the status quo.=C2=A0 Votes which are out=
of range should be clamped.

Having said that, if core supports the change, then most miners will
probably vote one way or another.

New hardLimit is the median of the followings:
min(current hardLimit * 1.2, 20-percentile)
max(current hardLimit / 1.2, 80-percentile)
current hardLimit

I think this is unclear, though mathematically exact.

Sort the votes for the last 12,000 blocks from lowest to highest.

Blocks which don't have a vote are considered a vote for the status
quo.

Votes are limited to +/- 20% of the current value.=C2=A0 Votes that are out=
of range are considered to vote for the nearest in range value.

The raise value is defined as the vote for the 2400th highest block
(20th percentile).

The lower value=C2=A0 is defined as the vote for the 9600th highest block (80th percentile).

If the raise value is higher than the status quo, then the new limit
is set to the raise value.

If the lower value is lower than the status quo, then the new limit is
set to the lower value.

Otherwise, the size limit is unchanged.

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

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

--f46d044481afad1b83051eda5e5c-- 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 3B08B1159 for ; Thu, 3 Sep 2015 17:32:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7182710B for ; Thu, 3 Sep 2015 17:32:30 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so60008073wic.0 for ; Thu, 03 Sep 2015 10:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=wLAwFETIzz+nYR2sUVTjhggYpHGYG8XvztEXgokZ7VU=; b=JRSxNAsKBMA5YWNqetU34bQDCuOfzhDNCwFqtwgK7f7xsNEzznPHrlv9y7zn0MT3H0 0ZATWOtRdL4tqaPrfKs/tJC8kOgZCmgmlff+2LjeyJrt9hPlOcR/ByeBG8zwShwQ1rq3 3z1nZn+cOeQFmFrYX7QucmuB9iqRAU8oHWAWzwRJn+tDVzK0LeP+BXXh3fJNyqHvrIeG +nUiAJop8reUy7vlyVPKKHFw5mEasoLz4ThXMD1zWTPVwYuFraXEI7tP4slwHxHuESd/ hcyoCTG7YM1L0DKEW8GnFQm6s092WbI6mZ5Vw34A+nZLtVl/tGjvQhNr0e9FbJVjAICO XqgA== X-Received: by 10.194.191.164 with SMTP id gz4mr53131086wjc.21.1441301548948; Thu, 03 Sep 2015 10:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.16 with HTTP; Thu, 3 Sep 2015 10:32:09 -0700 (PDT) In-Reply-To: References:

<301aa5f682f8aa408b9f6f4618095fe2@xbt.hk> From: Btc Drak Date: Thu, 3 Sep 2015 18:32:09 +0100 Message-ID: To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 17:32:31 -0000 Just use a 4-byte unsigned integer where the integer is the size in bytes. It's concise and less complex (and less complex to implement). There's no need for human readable strings here. On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev wrote: > Take a look at the latest update: > > - swiped Tier Nolan verbiage, which I agree was usefully more clear > - added 'M' suffix and removed 'V' from coinbase scriptSig > > > On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev > wrote: >> >> 1. I think there is no need to have resolution at byte level, while >> resolution at MB level is not enough. kB would be a better choice. >> >> 2. In my specification a v4 block without a vote is invalid, so there is >> no need to consider absent or invalid votes >> >> 3. We should allow miners to explicitly vote for the status quo, so they >> don't need to change the coinbase vote every time the size is changed. T= hey >> may indicate it by /BV/ in the coinbase, and we should look for the firs= t >> "/BVd*/" instead of "/BVd+/" >> >> 4. Alternatively, miners may vote in different styles: /BV1234567/, >> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5= MB, >> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" >> >> Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0= : >>> >>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev >>> wrote: >>> >>>> * >>>> >>>> hardLimit floats within the range 1-32M, inclusive. >>> >>> >>> Does the 32MB limit actually still exist anywhere in the code? In >>> effect, it is re-instating a legacy limitation. >>> >>> The message size limit is to minimize the storage required per peer. >>> If a 32MB block size is required, then each network input buffer must >>> be at least 32MB. This makes it harder for a node to support a large >>> number of peers. >>> >>> There is no reason why a single message is used for each block. Using >>> the merkleblock message (or a different dedicated message), it would >>> be possible to send messages which only contain part of a block and >>> have a limited maximum size. >>> >>> This would allow receiving parts of a block from multiple sources. >>> >>> This is a separate issue but should be considered if moving past 32MB >>> block sizes (or maybe as a later protocol change). >>> >>>> * Changing hardLimit is accomplished by encoding a proposed value >>>> within a block's coinbase scriptSig. >>>> >>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/" >>>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is >>>> more than one match with with pattern, the first match is counted. >>> >>> >>> Is there a need for byte resolution? Using MB resolution would use up >>> much fewer bytes in the coinbase. >>> >>> Even with the +/- 20% rule, miners could vote for the nearest MB. >>> Once the block size exceeds 5MB, then there is enough resolution >>> anyway. >>> >>>> * Absent/invalid votes and votes below minimum cap (1M) are >>>> >>>> counted as 1M votes. Votes above the maximum cap (32M) are counted >>>> as 32M votes. >>> >>> >>> I think abstains should count for the status quo. Votes which are out >>> of range should be clamped. >>> >>> Having said that, if core supports the change, then most miners will >>> probably vote one way or another. >>> >>>> New hardLimit is the median of the followings: >>>> min(current hardLimit * 1.2, 20-percentile) >>>> max(current hardLimit / 1.2, 80-percentile) >>>> current hardLimit >>> >>> >>> I think this is unclear, though mathematically exact. >>> >>> Sort the votes for the last 12,000 blocks from lowest to highest. >>> >>> Blocks which don't have a vote are considered a vote for the status >>> quo. >>> >>> Votes are limited to +/- 20% of the current value. Votes that are out >>> of range are considered to vote for the nearest in range value. >>> >>> The raise value is defined as the vote for the 2400th highest block >>> (20th percentile). >>> >>> The lower value is defined as the vote for the 9600th highest block >>> (80th percentile). >>> >>> If the raise value is higher than the status quo, then the new limit >>> is set to the raise value. >>> >>> If the lower value is lower than the status quo, then the new limit is >>> set to the lower value. >>> >>> Otherwise, the size limit is unchanged. >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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 23C1FDC0 for ; Thu, 3 Sep 2015 17:53:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148154.authsmtp.co.uk (outmail148154.authsmtp.co.uk [62.13.148.154]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 756D8A8 for ; Thu, 3 Sep 2015 17:53:02 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t83Hr0lg093633; Thu, 3 Sep 2015 18:53:00 +0100 (BST) Received: from muck (cpe-24-164-134-182.nyc.res.rr.com [24.164.134.182]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t83Hqt9T049782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Sep 2015 18:52:58 +0100 (BST) Date: Thu, 3 Sep 2015 13:52:55 -0400 From: Peter Todd To: Btc Drak Message-ID: <20150903175255.GB9647@muck> References:

<301aa5f682f8aa408b9f6f4618095fe2@xbt.hk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: X-Server-Quench: 9cdbbbc7-5264-11e5-9f76-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgEUC1AEAgsB AmMbWlxeVV97XGs7 aQ5PbANZfEtNWxtr WEpWR1pVCwQmRRQC fl9aW31ycwxBcHw+ Y09nWT5SDxAoJxQu RVNRF2sCeGZhPWUC WRZfcR5UcAFPdx8U a1N6AHBDAzANdhEy HhM4ODE3eDlSNhEd aCA1ZQtKGQ4QBjM3 Rh4DFjwzHEoDLwAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.164.134.182/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 17:53:03 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote: > Just use a 4-byte unsigned integer where the integer is the size in > bytes. It's concise and less complex (and less complex to implement). > There's no need for human readable strings here. Solid NACK on making string parsers part of the consensus critical codebase. (WTF=E2=80=BD) --=20 'peter'[:-1]@petertodd.org 00000000000000000c69430beea18c71be1d34114d7e1d4023dd1ffe1d9bc7f0 --K8nIJk4ghYZn606h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV6Ij0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwYzY5NDMwYmVlYTE4YzcxYmUxZDM0MTE0ZDdlMWQ0MDIz ZGQxZmZlMWQ5YmM3ZjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzE1Qf7B6AgEViVLLStso4mGPeFuyeI 2crAPD2XcCKTWXWw4BkWl2N7mybEk2FeYYR9CyCn5x0MabNDxqzRy8kxapiEz4s2 Uw+aJJxfRVbpEcMJyOI+buVTqSWlmBD5sxEXqsoH8JrzT2Qbv5uiFpffJvasGVUV euUrljcMQoMqGoHBg4alMvdM9gO93ceCsiVaYcdt+NXEWN8YhFVRkbfSBqlyTtWl /gctnIakU4ZerCuOBCSFMSavgO+T246hUw4UgzHn0Ydcj/hBuV5+xW1tNXcQI4oO ENpbusc8iN/m5L2X+cjFMFl8PnwoQ9i9e6uY6S99vrZIPW1PVD2EHtP1fZihBg== =Wded -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- 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 34918E3C for ; Thu, 3 Sep 2015 19:40:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C817A199 for ; Thu, 3 Sep 2015 19:40:55 +0000 (UTC) Received: by padfa1 with SMTP id fa1so13221704pad.1 for ; Thu, 03 Sep 2015 12:40:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XR4GYm/W5bWIfFGmWJP6Mri890riSEEqTPK2VQvaln8=; b=WGoNL4yR/1a3yzWvlYncICphCeNSRp4COZvfpcKbhjtDRWmRDPRmcYJvWWu6FbOy8l ufllHEDaMpfKIT3D1Sjre1rrt46hCIuPbb0RAB2zl2/dlISlhvwSkO9Yc++Hq/7eY2C5 iWYCORQ2sVBx6UYzlKH9TCrcyis3RSYU1fyAMVqShX5L8+VVz5/IBv9leut6OO40hPwr oyUAYE1vkuWRLlZTnScfXxLljQ8l+bwFdOT98VDxcHhJlSJDomFh/KqGuYER8aL2ZFTl ZFJS6EDWi4XdlKVwsf8I2cbmEIENfR4qa+tWg8d4leNwDvLLwy1891pKX/Q94KaL8K1m FDfQ== X-Gm-Message-State: ALoCoQlSAXvNLiey9U9rhe5NeOl0o1yfXGChpY5D0HJgHo0HAUY3/hvOF9NKL8gLBWK/XzcAI5IR X-Received: by 10.68.248.102 with SMTP id yl6mr72166875pbc.66.1441309255475; Thu, 03 Sep 2015 12:40:55 -0700 (PDT) Received: from [192.168.2.13] (c-24-5-43-190.hsd1.ca.comcast.net. [24.5.43.190]) by smtp.googlemail.com with ESMTPSA id hz5sm26145327pbb.39.2015.09.03.12.40.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2015 12:40:54 -0700 (PDT) Message-ID: <55E8A246.7030102@bitcartel.com> Date: Thu, 03 Sep 2015 12:40:54 -0700 From: Simon Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeff Garzik , Bitcoin development mailing list References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 19:40:56 -0000 Hi Jeff, Thoughts on this part of the proposal: "Absent/invalid votes are counted as votes for the current hardLimit. Out of range votes are counted as the nearest in-range value." 1. Why should an absent vote be considered a vote for the status quo? A non-voter should have zero impact on the result. 2. Why should out of range votes be counted? They're an invalid vote, a spoiled ballot as such, and thus it would be better if they were discarded. Regards, Simon On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote: > BIP 100 initial public > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > Emphasis on "initial" This is a starting point for the usual open > source feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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 0F74A111B for ; Thu, 3 Sep 2015 20:16:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E80B428F for ; Thu, 3 Sep 2015 20:15:59 +0000 (UTC) Received: by obqa2 with SMTP id a2so616143obq.3 for ; Thu, 03 Sep 2015 13:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x+iq5Ui+fNcCA3Z9/GFgvTnkZRS/FfBlTxCcoZ5GA8I=; b=m8pcy2RKL1rrFdeAYgyxN8OTEavVP7oHEvYEq9ygSZzGuUlg6s7jRlToJsYv5ab4xT ChCZJULR65Plvs5CY55xqpO3OuX/h4LIWx6fnG1ddqP2YobB+rBn7nT8vAVqR9Qq7Etl IECRSqvinv5BFxhTG+6XIWavcQ6SsOQRDBMaPpHmlX7IEhgFYmTDUgFMhu/RehuRA+ol 1TH3djmCqfO6V9bG4FurZqi/GqCB1/yQtO+W7wnqLzOUbpp0VqZhccXb5vtdIkB4GD6I Hp8b78tDvGgHWq1qgL9yCNLjJMck9MIbW57mo/q5uMQPwbqNhexZmhHSFQhhODvtpZkx BNoA== MIME-Version: 1.0 X-Received: by 10.60.98.40 with SMTP id ef8mr29586668oeb.7.1441311359166; Thu, 03 Sep 2015 13:15:59 -0700 (PDT) Received: by 10.76.57.195 with HTTP; Thu, 3 Sep 2015 13:15:58 -0700 (PDT) Received: by 10.76.57.195 with HTTP; Thu, 3 Sep 2015 13:15:58 -0700 (PDT) In-Reply-To: <55E8A246.7030102@bitcartel.com> References: <55E8A246.7030102@bitcartel.com> Date: Thu, 3 Sep 2015 16:15:58 -0400 Message-ID: From: Oliver Petruzel To: Simon Liu Content-Type: multipart/alternative; boundary=089e013a18229329ea051edd7317 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 20:16:02 -0000 --089e013a18229329ea051edd7317 Content-Type: text/plain; charset=UTF-8 I agree with Simon's sentiments for question #1, and was actually going to pose the same question. Non-votes seem like they may poison the well mathematically, and counting them anyway seems to encourage a lack of participation at a time when miners really need to be very much involved. Since we're handing them even more control over the ecosystem with this BIP, it would be nice to ensure they (all miners) seriously consider their impact and role on a regular basis. I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may be a great reason that I can't think of, but it's eluding me... LOL) That said, I don't see any issue with counting votes from outside of the range as the maximum/minimum accordingly (Simon's question #2). In fact, such votes would be very interesting (worthy of further discussion) if they begin to lean heavily in either direction. V/r, Oliver On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Jeff, > > Thoughts on this part of the proposal: > > "Absent/invalid votes are counted as votes for the current hardLimit. > Out of range votes are counted as the nearest in-range value." > > 1. Why should an absent vote be considered a vote for the status quo? A > non-voter should have zero impact on the result. > > 2. Why should out of range votes be counted? They're an invalid vote, a > spoiled ballot as such, and thus it would be better if they were discarded. > > Regards, > Simon > > > On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote: > > BIP 100 initial public > > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki > > > > Emphasis on "initial" This is a starting point for the usual open > > source feedback/iteration cycle, not an endpoint that Must Be This Way. > > > > > > > > > > _______________________________________________ > > 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 > --089e013a18229329ea051edd7317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with Simon's sentiments for question #1, and was= actually going to pose the same question. Non-votes seem like they may poi= son the well mathematically, and counting them anyway seems to encourage a = lack of participation at a time when miners really need to be very much inv= olved. Since we're handing them even more control over the ecosystem wi= th this BIP, it would be nice to ensure they (all miners) seriously conside= r their impact and role on a regular basis.

I'm curious why we couldn't/shouldn't simply dro= p the non-votes. (There may be a great reason that I can't think of, bu= t it's eluding me... LOL)

That said, I don't see any issue with counting votes fro= m outside of the range as the maximum/minimum accordingly (Simon's ques= tion #2). In fact, such votes would be very interesting (worthy of further = discussion) if they begin to lean heavily in either direction.

V/r,
Oliver

On Sep 3, 2015 3:41 PM, "Simon Liu via bitc= oin-dev" <= bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi Jeff,

Thoughts on this part of the proposal:

"Absent/invalid votes are counted as votes for the current hardLimit.<= br> Out of range votes are counted as the nearest in-range value."

1. Why should an absent vote be considered a vote for the status quo?=C2=A0= A
non-voter should have zero impact on the result.

2. Why should out of range votes be counted?=C2=A0 They're an invalid v= ote, a
spoiled ballot as such, and thus it would be better if they were discarded.=

Regards,
Simon

On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> BIP 100 initial public
> draft: https://github.com/jgarz= ik/bip100/blob/master/bip-0100.mediawiki
>
> Emphasis on "initial"=C2=A0 This is a starting point for the= usual open
> source feedback/iteration cycle, not an endpoint that Must Be This Way= .
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e013a18229329ea051edd7317-- 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 8DA85D28 for ; Thu, 3 Sep 2015 20:34:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30BC617D for ; Thu, 3 Sep 2015 20:34:55 +0000 (UTC) Received: by obbbh8 with SMTP id bh8so1157480obb.0 for ; Thu, 03 Sep 2015 13:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=QXCASksIcu788X6qJ4/qNq423st/kHZ9VQ0DYx9a9dk=; b=k2GNGQS+Db7UbxGMyPnazgvlrJoVFHf0FuqEesBN+L544a+RBUv0muN8XoTLC7kzVA b3YHYoqh5ROQww63hKU9GPypy/y5Wnj2mgHyVQtv+M0io7cgo8r3cbge+6fvw3tkeA9B JVuoSJAnVCKT71/0XSY4jQNUxJ/R0sY6j1tITk7ehqdwh15JlZY+6w9Kw99DR0cdlr+U kiY6UWkKGIWGHML0/Ax6Frd3VjA6Bf5ceUelgY6BfOB0IZWO/vrkpuatuOOXFRcOTW3j 3ISWPOI3EXEMKszrdEDJnq47XI5+nja2Ux7KDf1VhTvQOBEmxLnltpO1qfkkMRbuxdKO Qp3g== MIME-Version: 1.0 X-Received: by 10.182.28.105 with SMTP id a9mr14722395obh.51.1441312494555; Thu, 03 Sep 2015 13:34:54 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.202.201.2 with HTTP; Thu, 3 Sep 2015 13:34:54 -0700 (PDT) In-Reply-To: References: <55E8A246.7030102@bitcartel.com> Date: Thu, 3 Sep 2015 13:34:54 -0700 X-Google-Sender-Auth: OpUSfk3nM5CIzKqJFgNcbG6h2XA Message-ID: From: Dave Scotese To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0149c2063f9622051eddb7a9 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 20:34:55 -0000 --089e0149c2063f9622051eddb7a9 Content-Type: text/plain; charset=UTF-8 I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot people round it, so I like the K spec best. I also see value in having human readable data. The spec should nail down these details. --089e0149c2063f9622051eddb7a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have seen "1M" mean 1,000,000 bytes as well as= 1,048,576bytes and 1,024,000 bytes.=C2=A0 I believe the best policy is to = use "megabyte" to mean 2^20 (1,048,576) bytes.=C2=A0 Kb always me= ans 1024 bytes, even when a lot people round it, so I like the K spec best.= =C2=A0 I also see value in having human readable data.=C2=A0 The spec shoul= d nail down these details.

--089e0149c2063f9622051eddb7a9-- 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 E388E1071 for ; Fri, 4 Sep 2015 03:50:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148102.authsmtp.net (outmail148102.authsmtp.net [62.13.148.102]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3B836154 for ; Fri, 4 Sep 2015 03:50:50 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t843om19048341; Fri, 4 Sep 2015 04:50:48 +0100 (BST) Received: from muck (030-098.web.ny.np1.net [64.61.30.98] (may be forged)) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t843oirK010303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Sep 2015 04:50:47 +0100 (BST) Date: Thu, 3 Sep 2015 23:50:45 -0400 From: Peter Todd To: Dave Scotese Message-ID: <20150904035045.GA9821@muck> References: <55E8A246.7030102@bitcartel.com>

MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: X-Server-Quench: 208a7d9f-52b8-11e5-b399-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgYUC1AEAgsB AmMbW1BeVV17XWQ7 bQ5PawRDYUpQVg11 VUBOXVMcUA1sAkNY RGUeUxlxdwYIfHh3 ZwhgXngKWxBzI1t4 QBxcCGwHMGJ9OmMW WV1YdwFReQMbfxoR O1cxNiYHcQ5VPz4z GA41ejw8IwAXAgVt ClhVdRoJWUsAHzA9 TBkeHDIpdQAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 64.61.30.98/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 03:50:51 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrot= e: > I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and > 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean > 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot peop= le > round it, so I like the K spec best. I also see value in having human > readable data. The spec should nail down these details. The IEC standard is to use the prefix MiB for 2^20 bytes: https://en.wikipedia.org/wiki/Binary_prefix --=20 'peter'[:-1]@petertodd.org 000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18 --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV6RURXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMGY5ZTk1YWZmNjQ1NGZlZGI5ZDBhNGI5MmE0MTA4ZTk0 NDljNTA3OTM2ZjlmMTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzp7Af/etizdLVR57SFo6VH0bPUC+H1 R/l6930A4a1sdK8i2uBUC+/zAr6WT0nEc6dSr6+9AU8ftbzgC8JghkXaiHIft3QC 8k0qpDek4tH5gC8+7tpK/AReX/4s0jMCo4D8K0Cy8wwT1J4HX20mAJHcR2sfNWbI Aa/deRf2PsrCKHZJtHYjLdrSKE4XjS7agBBBootjNiAHnQMsG89lE3bQUzJ+LhDu DBU5Vmr34vZemXRhXHc2OLK4SudWiNEq7z2U7+4VyXZghg9r8lFw9bcgx3aPTy5N DD2Pl29a4GqAfxNNI9umyJYeukl4gb5aqfErY6dKSEG4WPFbzLiCYVnJztWq8w== =MD+x -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- 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 1D052F0B for ; Fri, 4 Sep 2015 07:54:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB5F210C for ; Fri, 4 Sep 2015 07:54:08 +0000 (UTC) Received: by ioii196 with SMTP id i196so15049312ioi.3 for ; Fri, 04 Sep 2015 00:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=DNo9RV5fKKRpZZDsMgWVqzx/J8MFbetWgDA8tHwotkA=; b=fWXWi0Qhz+5W1mGrpsEaPw65GoOQYcaxWY7C5RyYcuiXz6brXwT0YbP3HBn+xfOlda s6XWOt6wOVJK/+IKcX4hqwYGKMxj3ctOy2J1SJucBAFZtrPRSjCr7UbZN9/9Zg/LdOu9 qmwHD/7Pl9Ulm5CbBZEXnpPUMprTe/VfkyFylZFof6ejy7fHDMNypYyQ8Hq/wMapE/jG vw/Opxl3+xKNVf7adn6sVEFZO0WvHRLguqbXqYSS4zyZVg2RJOJk/AdEraaCabc6mJYw 75lF+jNDAPsVHa2PhHLI6yO69qw0mtqSiFsgx61ZyNuzuXCNEunYmAAH+Gf2bN4jGGeJ Xuag== X-Received: by 10.107.166.139 with SMTP id p133mr4435748ioe.113.1441353248336; Fri, 04 Sep 2015 00:54:08 -0700 (PDT) MIME-Version: 1.0 Sender: asperous2@gmail.com Received: by 10.50.3.33 with HTTP; Fri, 4 Sep 2015 00:53:48 -0700 (PDT) In-Reply-To: References:

From: Andy Chase Date: Fri, 4 Sep 2015 00:53:48 -0700 X-Google-Sender-Auth: nG6CUOX7uXzlxoyuLqgjyWIzPbg Message-ID: To: Tier Nolan , jgarzik@gmail.com, bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1141ef3c5cf440051ee73434 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 07:54:10 -0000 --001a1141ef3c5cf440051ee73434 Content-Type: text/plain; charset=UTF-8 The 32Mb limit is here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25 It's to keep the message size small enough that messages can be serialized in memory. Jeff if you decide to lift the 32MB limit (you really should, unless your plan is to potentially hard force another Blocksize discussion again which might be okay). I suggest having the 32MB ceiling auto-raise according to a exponential factor (1.5?) starting 1 year from now. Basically hard limit ceiling 2016-2017: 32 MB Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB The factor could be 2 like BIP-101 but I imagine you will want to be more conservative. The delay time could also be longer if you think it will take longer to fix the message size issue across all implementations. On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> 1. >> >> hardLimit floats within the range 1-32M, inclusive. >> >> >> > Does the 32MB limit actually still exist anywhere in the code? In effect, > it is re-instating a legacy limitation. > > The message size limit is to minimize the storage required per peer. If a > 32MB block size is required, then each network input buffer must be at > least 32MB. This makes it harder for a node to support a large number of > peers. > > There is no reason why a single message is used for each block. Using the > merkleblock message (or a different dedicated message), it would be > possible to send messages which only contain part of a block and have a > limited maximum size. > > This would allow receiving parts of a block from multiple sources. > > This is a separate issue but should be considered if moving past 32MB > block sizes (or maybe as a later protocol change). > > >> >> 1. Changing hardLimit is accomplished by encoding a proposed value >> within a block's coinbase scriptSig. >> 1. Votes refer to a byte value, encoded within the pattern >> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If >> there is more than one match with with pattern, the first match is counted. >> >> Is there a need for byte resolution? Using MB resolution would use up > much fewer bytes in the coinbase. > > Even with the +/- 20% rule, miners could vote for the nearest MB. Once > the block size exceeds 5MB, then there is enough resolution anyway. > > >> 1. Absent/invalid votes and votes below minimum cap (1M) are counted >> as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes. >> >> > I think abstains should count for the status quo. Votes which are out of > range should be clamped. > > Having said that, if core supports the change, then most miners will > probably vote one way or another. > > > New hardLimit is the median of the followings: > > min(current hardLimit * 1.2, 20-percentile) > > max(current hardLimit / 1.2, 80-percentile) > > current hardLimit > > I think this is unclear, though mathematically exact. > > Sort the votes for the last 12,000 blocks from lowest to highest. > > Blocks which don't have a vote are considered a vote for the status quo. > > Votes are limited to +/- 20% of the current value. Votes that are out of > range are considered to vote for the nearest in range value. > > The raise value is defined as the vote for the 2400th highest block (20th > percentile). > The lower value is defined as the vote for the 9600th highest block (80th > percentile). > > If the raise value is higher than the status quo, then the new limit is > set to the raise value. > If the lower value is lower than the status quo, then the new limit is set > to the lower value. > Otherwise, the size limit is unchanged. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1141ef3c5cf440051ee73434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The 32Mb limit is here:=C2=A0https://github.com/bitcoi= n/bitcoin/blob/master/src/serialize.h#L25

It's t= o keep the message size small enough that messages can be serialized in mem= ory.

Jeff if you decide to lift the 32MB limit (yo= u really should, unless your plan is to potentially hard force another Bloc= ksize discussion again which might be okay). I suggest having the 32MB ceil= ing auto-raise according to a exponential factor (1.5?) starting 1 year fro= m now.

Basically hard limit ceiling 2016-2017: 32 = MB

Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB

The factor could be 2 like BIP-101 but I imagine you wi= ll want to be more conservative. The delay time could also be longer if you= think it will take longer to fix the message size issue across all impleme= ntations.

On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Thu, Se= p 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:

hardLimit floats within the range 1-32M, inclusive.

Does the 32MB limit actually sti= ll exist anywhere in the code?=C2=A0 In effect, it is re-instating a legacy= limitation.

The message size limit is to minimize the st= orage required per peer.=C2=A0 If a 32MB block size is required, then each = network input buffer must be at least 32MB. This makes it harder for a node= to support a large number of peers.

There is no reason w= hy a single message is used for each block.=C2=A0 Using the merkleblock mes= sage (or a different dedicated message), it would be possible to send messa= ges which only contain part of a block and have a limited maximum size.
=
This would allow receiving parts of a block from multiple so= urces.=C2=A0

This is a separate issue but should be cons= idered if moving past 32MB block sizes (or maybe as a later protocol change= ).
=C2=A0
Changing hardLim= it is accomplished by encoding a proposed value within a block's coinba= se scriptSig.

Votes refer to a byte value, encod= ed within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,= 000,000 byte hardLimit. If there is more than one match with with pattern, the f= irst match is counted.
= Is there a need for byte resolution?=C2=A0 Using MB resolution would use up= much fewer bytes in the coinbase.

Even with the +/- 20% = rule, miners could vote for the nearest MB.=C2=A0 Once the block size excee= ds 5MB, then there is enough resolution anyway.
<= div>
Absent/invalid votes and votes bel= ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3= 2M) are counted as 32M votes.
=
I think abstains should count for the status quo.=C2= =A0 Votes which are out of range should be clamped.

Havin= g said that, if core supports the change, then most miners will probably vo= te one way or another.

> New hardLimit is the median of the followings:
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percent= ile)
> current hardLi= mit=

I think this is unclear, though mathematically ex= act.

Sort the votes for the last 12,000 blocks from= lowest to highest.=C2=A0

Blocks which don't have a vote are co= nsidered a vote for the status quo.
Votes are limited to +/- 20% of the current value.=C2=A0 Votes that are ou= t of range are considered to vote for the nearest in range value.
=
The raise value is defined as the vote for t= he 2400th highest block (20th percentile).
The lower value=C2=A0 is defined as the vote for the 9600th highest blo= ck (80th percentile).

If the raise = value is higher than the status quo, then the new limit is set to the raise= value.
If the lower value is lower tha= n the status quo, then the new limit is set to the lower value.
Otherwise, the size limit is unchanged.
<= /div>

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

--001a1141ef3c5cf440051ee73434-- 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 894A4EB2 for ; Fri, 4 Sep 2015 15:37:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 17570223 for ; Fri, 4 Sep 2015 15:37:40 +0000 (UTC) Received: by pacfv12 with SMTP id fv12so28062973pac.2 for ; Fri, 04 Sep 2015 08:37:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=e4ghbmq6S64WP6GwZ7S71r00waAbGnxenKZI8r8DxLU=; b=T3+lrSIC+R2sje/iNsC/2DZLgJ3IGnERQK3XA7mfEoWEcb9o5ZlUYv1rt//GxAx8oC 6K7vIieKj/dBFccOj257A8PR9rxifMhORKQV8Rp2T1rj9/BZlw5FjtYefIK1A85NxXg0 zS9aecI2wdjNjnMQn5h2FFqDP4iNKFdxeZI1A7zC+rZJ7LtPBzBnIzUCNnCfpcZ0C+8y GA8wl3j9eMLXaalJqZkNTWp3+yQT0zzuePcGqo9s8edkZmFBT/rl1ojtr5SmkYJN0TJx fNenL2EBgX75lceWyVq1EctGCDBe52bKsYY3k8Z5CQaM8a4LCt7A6lMsihGHmB9DWPqJ jtPg== X-Gm-Message-State: ALoCoQl1lORexwRm8VX0U0ngEKgvWbs+wQ64ToJscBBgFJM6+IPI/2c60UoWZv5jHVWh72HZeBUU X-Received: by 10.66.159.162 with SMTP id xd2mr9388779pab.91.1441381059678; Fri, 04 Sep 2015 08:37:39 -0700 (PDT) Received: from [192.168.2.13] (c-24-5-43-190.hsd1.ca.comcast.net. [24.5.43.190]) by smtp.googlemail.com with ESMTPSA id jv5sm2918826pbc.47.2015.09.04.08.37.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 08:37:33 -0700 (PDT) Message-ID: <55E9BABD.7080505@bitcartel.com> Date: Fri, 04 Sep 2015 08:37:33 -0700 From: Simon Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Chase , Tier Nolan , jgarzik@gmail.com, bitcoin-dev@lists.linuxfoundation.org References:

In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 15:37:40 -0000 Maybe grab some code from BIP101 ? It permits block messages > 2MB, while retaining the current limit of 2 MB imposed on other network messages. The 32 MB limit was patched a few months ago. Links to code: https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/ On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote: > The 32Mb limit is > here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25 > > It's to keep the message size small enough that messages can be > serialized in memory. > > Jeff if you decide to lift the 32MB limit (you really should, unless > your plan is to potentially hard force another Blocksize discussion > again which might be okay). I suggest having the 32MB ceiling auto-raise > according to a exponential factor (1.5?) starting 1 year from now. > > Basically hard limit ceiling 2016-2017: 32 MB > Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB > > The factor could be 2 like BIP-101 but I imagine you will want to be > more conservative. The delay time could also be longer if you think it > will take longer to fix the message size issue across all implementations. > 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 C43A0E9F for ; Fri, 4 Sep 2015 15:40:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 24DA025B for ; Fri, 4 Sep 2015 15:40:47 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so22103781wic.1 for ; Fri, 04 Sep 2015 08:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7PEbuwzJMwAnLrZdTbDzRzbBApRF5LXDBH2gm/uZdU0=; b=LqVouiZBtKpfGpD5lqL3RAuqt0J6cb0oQ1QhKuwhZ+my0o8FtCCveALvl1/SZZ/iba NGk1d8RHzNo6Y6JRuXbd4vw9QvRJOBGGkRmM7lbUhQsQzrYl82NxFqeHZyuW6i0HwDBm q6i9CBwdEytlb5sjp6/2lErqO/xeBno8EkZNFo8YLU04HevFiZLiye30rwaOB2ftriiQ pS0FJH/rNbp3rbdopSBZpowBjAK0W6s/x6vIvo74T/ahkjDF/mrMnYlTIngCj3faCuNl qhw+P/P0I3MOp+gK2rckG1xygfGhk7EfZIaVsSKFE+Ak1R6LtO+yf61mPmS7ivnvtCyr iS4Q== X-Received: by 10.194.191.164 with SMTP id gz4mr8521313wjc.21.1441381245863; Fri, 04 Sep 2015 08:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.16 with HTTP; Fri, 4 Sep 2015 08:40:26 -0700 (PDT) In-Reply-To: <55E9BABD.7080505@bitcartel.com> References:

<55E9BABD.7080505@bitcartel.com> From: Btc Drak Date: Fri, 4 Sep 2015 16:40:26 +0100 Message-ID: To: Simon Liu Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, RCVD_IN_DNSWL_LOW autolearn=ham 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] BIP 100 specification X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 15:40:47 -0000 If you read between the lines of what was recently changed and why (reducing to 2MB), it seems reasonable to assume BIP101's allowance opens up some of the attack vector again. On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev wrote: > Maybe grab some code from BIP101 ? It permits block messages > 2MB, > while retaining the current limit of 2 MB imposed on other network > messages. The 32 MB limit was patched a few months ago. > > Links to code: > > https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/ > > > > On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote: >> The 32Mb limit is >> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25 >> >> It's to keep the message size small enough that messages can be >> serialized in memory. >> >> Jeff if you decide to lift the 32MB limit (you really should, unless >> your plan is to potentially hard force another Blocksize discussion >> again which might be okay). I suggest having the 32MB ceiling auto-raise >> according to a exponential factor (1.5?) starting 1 year from now. >> >> Basically hard limit ceiling 2016-2017: 32 MB >> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB >> >> The factor could be 2 like BIP-101 but I imagine you will want to be >> more conservative. The delay time could also be longer if you think it >> will take longer to fix the message size issue across all implementations. >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev