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 B94BBF67 for ; Sat, 6 Feb 2016 21:28:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2C7A106 for ; Sat, 6 Feb 2016 21:28:29 +0000 (UTC) Received: by mail-yw0-f175.google.com with SMTP id g127so77990106ywf.2 for ; Sat, 06 Feb 2016 13:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=artlery-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/5SLygB+7it10m9CZnypvVcRbIH3EHzMuQZ3DGdxOuo=; b=m+hOfFwov3gF3TrP41BmU29Q0e5D4yOrplm3ReDwr+8hzJ3y60euk2Ul1SqFdtRzTS efq35eFHVOENkE3YSDT8ztMpIl0mFGBVMJ1zgI0MwLo3UBjBAaMUcu3ewiz6ktACYFx1 qngIZfOoioENbvNJQLIpTwa25ddFJojghrIVJfHrrU9mnTwPuuvQ1O0XSqAqTe1iig8p TwQLmppETFiLCuHe4BtJ1fCP4/e8GfQx4+6jaqyixsA3RenGYw+AiP0Lr7CkHQM13ASu fQtUVlT4uSA0frZsIHRkQyHQDUvQp0kva3mmSjAblyIvCb0h3kmn1JzgoVaWcnRbcV59 qETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/5SLygB+7it10m9CZnypvVcRbIH3EHzMuQZ3DGdxOuo=; b=D7vxPiGLVphtlxrdfNXBU5/hwBHXP9EO1Pr7PfdWWOLGvZgAM7HkrGcnSiQ0VkLHpE WCF4k5AY+AaUUsUvdYcwdlFvkECDy43swimiL9t9SJEZAMEWN2VXifqKyJZ6TZoCf2An 8SR9VE8SB1kGUixa+Zt1hCT1AwzGT4/t8kpwEFX2cb+/eJt9wkoTVwk4XIhzPPpjGe8q UyeTNosbtd7A/qqXPnm1E9lE+QjkJoxrIy3y1GqL1s5fpf0dvuvz25mxanJu1b789rxT oXrPVi2U91D00uiJ8kMICwn2o1BFkaCB2ldWUv9FOr6MMzVhYoSVCuwqZYylSlPBvbkb 2zVA== X-Gm-Message-State: AG10YOQtYl7uDPIg7NLpaqGqTYW212eyURBqXz9ZZejh6jj3FreNkyOOE0qrXPZZt6S4tA== X-Received: by 10.129.152.9 with SMTP id p9mr1372840ywg.85.1454794108905; Sat, 06 Feb 2016 13:28:28 -0800 (PST) Received: from [100.119.122.105] (150.sub-70-192-33.myvzw.com. [70.192.33.150]) by smtp.gmail.com with ESMTPSA id k186sm15388635ywf.14.2016.02.06.13.28.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Feb 2016 13:28:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0 Mime-Version: 1.0 (1.0) From: David Thomson X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Sat, 6 Feb 2016 16:28:22 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <201602060012.26728.luke@dashjr.org> To: Gavin Andresen X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 06 Feb 2016 21:33:26 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes 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: Sat, 06 Feb 2016 21:28:30 -0000 --Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gavin, I saw this in your blog post: "Miners producing up-version blocks is a coordination mechanism. Other coord= ination mechanisms are possible=E2=80=93 there could be a centrally determin= ed =E2=80=9Cflag day=E2=80=9D or =E2=80=9Cflag block=E2=80=9D when everybody= (or almost everybody) agrees that a change will happen." Can you describe this a bit more? How would either a "flag day" or "flag blo= ck" work as an alternative and why did you decide against them? More thoughts and questions inline, thanks! On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev wrote: >> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote: >>=20 >> It would probably be a good idea to have a security considerations >> section >=20 > Containing what? I'm not aware of any security considerations that are an= y different from any other consensus rules change. Can you explain and justify why that is the case? It would be nice to see th= at rationale laid out more fully as to why it's no different. >=20 > (I can write a blog post summarizing our slack discussion of SPV security i= mmediately after the first greater-than-1mb-block if you like). I'm not familiar with the context of your slack discussion, but why would yo= u wait to summarize that only after the first-greater-than-1mb-block? >=20 > =20 >> , also, is there a list of which exchange, library, wallet, >> pool, stats server, hardware etc you have tested this change against? >=20 > That testing is happening by the exchange, library, wallet, etc providers t= hemselves. There is a list on the Classic home page: >=20 > https://bitcoinclassic.com/ Is there a way to provide more transparency and visibility into that process= and level of readiness? Is there an expectation of certain levels of readin= ess here before certain other things happen? I was thinking it would be real= ly useful to have a visual timeline of events associated with all of this. M= aybe you could add that to one of your web pages? > =20 >>=20 >> Do you have a rollback plan in the event the hard-fork triggers via >> false voting as seemed to be prevalent during XT? (Or rollback just >> as contingency if something unforseen goes wrong). >=20 > The only voting in this BIP is done by the miners, and that cannot be fake= d. >=20 > Are you talking about people spinning up pseudo-full-nodes that fake the u= ser-agent? >=20 > As I said, there are people who have said they will spin up thousands of f= ull nodes to help prevent possible Sybil attacks which would become marginal= ly easier to accomplish immediately after the first >1mb block was produced a= nd full nodes that hadn't upgraded were left behind. >=20 > Would Blockstream be willing to help out by running a dozen or two extra f= ull nodes? >=20 > I can't imagine any even-remotely-likely sequence of events that would req= uire a rollback, can you be more specific about what you are imagining? Min= ers suddenly getting cold feet? Well that, but also past performance isn't an indication of future performan= ce, necessarily. They might have gone out of business, to give one example. T= here is surely assumed self-interest, but I have also seen rumors floating a= round of this being used as an arbitrage opportunity. Would suck to imagine t= hat ever happening, but since this seems like it's being managed on more han= dshake type of deals (or conversations), are there any legal documents backi= ng those commitments up? Or is that definitely overkill? Maybe it's worth documenting the full range of possible series of events and= then their presumed level of unlikelihood? "What can go wrong will go wrong= ", "Black Swan" events, type of considerations. :) Often when people discuss= unlikely things like crypto being broken, it's like, "Assuming processing p= ower of x, increasing at a rate of x, and a known age of the universe of x, i= t would take a billion times the known length of the universe for that to ha= ppen". Certainly not everything fits so easily into that framing, but it would be r= eally helpful to see the "what could possibly go wrong" things fully enumera= ted. Thanks!! Dave > =20 >> How do you plan to monitor and manage security through the hard-fork? >=20 > I don't plan to monitor or manage anything; the Bitcoin network is self-mo= nitoring and self-managing. Services like statoshi.infowill do the monitorin= g, and miners and people and businesses will manage the network, as they do e= very day. >=20 > --=20 > -- > Gavin Andresen >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Gavin,

I saw this in your blog post:
=

"Miners p= roducing up-version blocks is a coordination mechanism. Other coordination m= echanisms are possible=E2=80=93 there could be a centrally determined =E2=80= =9Cflag day=E2=80=9D or =E2=80=9Cflag block=E2=80=9D when everybody (or almo= st everybody) agrees that a change will happen."

Can you describe this a b= it more? How would either a "flag day" or "flag block" work as an alternativ= e and why did you decide against them?

More thoughts and questions i= nline, thanks!

On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev <= ;bitcoin-dev@lists.= linuxfoundation.org> wrote:

=
On Sat, Feb 6, 2016 at 12:01 PM, Adam Back&n= bsp;<adam@cypherspace.org> wrote:

It w= ould probably be a good idea to have a security considerations
section

Containi= ng what?  I'm not aware of any security considerations that are any dif= ferent from any other consensus rules change.

Can you explain and justify why that is the case? It would be nice to s= ee that rationale laid out more fully as to why it's no different.

(I can write a bl= og post summarizing our slack discussion of SPV security immediately after t= he first greater-than-1mb-block if you like).

I'm not familiar with the context of your slack discussion, but w= hy would you wait to summarize that only after the first-greater-than-1mb-bl= ock?
<= br>

 
, also, is there a list of which exchange, library, wallet,
pool= , stats server, hardware etc you have tested this change against?

That testing i= s happening by the exchange, library, wallet, etc providers themselves. Ther= e is a list on the Classic home page:


Is there a way to provide= more transparency and visibility into that process and level of readiness? I= s there an expectation of certain levels of readiness here before certain ot= her things happen? I was thinking it would be really useful to have a visual= timeline of events associated with all of this. Maybe you could add that to= one of your web pages?

 
Do you have a rollback plan in the event the hard-fork triggers via
fal= se voting as seemed to be prevalent during XT?  (Or rollback just
as= contingency if something unforseen goes wrong).
<= div>
The only voting in this BIP is d= one by the miners, and that cannot be faked.
<= br>
Are you talking about people spinning up p= seudo-full-nodes that fake the user-agent?
As I said, there are people who have said th= ey will spin up thousands of full nodes to help prevent possible Sybil attac= ks which would become marginally easier to accomplish immediately after the f= irst >1mb block was produced and full nodes that hadn't upgraded were lef= t behind.

W= ould Blockstream be willing to help out by running a dozen or two extra full= nodes?

I c= an't imagine any even-remotely-likely sequence of events that would require a= rollback, can you be more specific about what you are imagining?  Mine= rs suddenly getting cold feet?

Well= that, but also past performance isn't an indication of future performance, n= ecessarily. They might have gone out of business, to give one example. There= is surely assumed self-interest, but I have also seen rumors floating aroun= d of this being used as an arbitrage opportunity. Would suck to imagine that= ever happening, but since this seems like it's being managed on more handsh= ake type of deals (or conversations), are there any legal documents backing t= hose commitments up? Or is that definitely overkill?

Maybe it's worth docu= menting the full range of possible series of events and then their presumed l= evel of unlikelihood? "What can go wrong will go wrong", "Black Swan" events= , type of considerations. :) Often when people discuss unlikely things like c= rypto being broken, it's like, "Assuming processing power of x, increasing a= t a rate of x, and a known age of the universe of x, it would take a billion= times the known length of the universe for that to happen".

Certainly no= t everything fits so easily into that framing, but it would be really helpfu= l to see the "what could possibly go wrong" things fully enumerated.<= /div>

Than= ks!!

Dave

 
=
How do you plan t= o monitor and manage security through the hard-fork?

I don't plan to monitor or m= anage anything; the Bitcoin network is self-monitoring and self-managing. Se= rvices like statoshi.infowill do t= he monitoring, and miners and people and businesses will manage the network,= as they do every day.

-- 
--
Gavin Andresen

___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https:/= /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0--