Return-Path: <david@artlery.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B94BBF67 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Sat, 6 Feb 2016 21:28:29 +0000 (UTC) Received: by mail-yw0-f175.google.com with SMTP id g127so77990106ywf.2 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <david@artlery.com> X-Mailer: iPhone Mail (13D15) In-Reply-To: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com> Date: Sat, 6 Feb 2016 16:28:22 -0500 Content-Transfer-Encoding: 7bit Message-Id: <E17AC2D4-AA22-48CD-9065-7D2071A3D8EA@artlery.com> References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com> <201602060012.26728.luke@dashjr.org> <CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com> <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com> <CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com> <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com> To: Gavin Andresen <gavinandresen@gmail.com> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lis= ts.linuxfoundation.org> wrote: >> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> 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 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div><div><span style=3D"background-color: r= gba(255, 255, 255, 0);">Gavin,</span></div><div><span style=3D"background-co= lor: rgba(255, 255, 255, 0);"><br></span></div><div><span style=3D"backgroun= d-color: rgba(255, 255, 255, 0);">I saw this in your blog post:</span></div>= <div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></= div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">"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."</span></div><div><span styl= e=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span s= tyle=3D"background-color: rgba(255, 255, 255, 0);">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?</span></div><div><span style=3D"backg= round-color: rgba(255, 255, 255, 0);"><br></span></div><div><div><span style= =3D"background-color: rgba(255, 255, 255, 0);">More thoughts and questions i= nline, thanks!</span></div><div><span style=3D"background-color: rgba(255, 2= 55, 255, 0);"><br></span></div><span style=3D"background-color: rgba(255, 25= 5, 255, 0);">On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev <= ;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= linuxfoundation.org</a>> wrote:<br><br></span></div><blockquote type=3D"c= ite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">= <blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"background-= color: rgba(255, 255, 255, 0);">On Sat, Feb 6, 2016 at 12:01 PM, Adam Back&n= bsp;<span dir=3D"ltr"><<a href=3D"mailto:adam@cypherspace.org" target=3D"= _blank">adam@cypherspace.org</a>></span> wrote:<br></span></font></b= lockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8= ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><font color=3D= "#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br>It w= ould probably be a good idea to have a security considerations<br>section</s= pan></font></blockquote><div><font color=3D"#000000"><span style=3D"backgrou= nd-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D= "#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">Containi= ng what? I'm not aware of any security considerations that are any dif= ferent from any other consensus rules change.</span></font></div></div></div= ></div></blockquote><div><span style=3D"background-color: rgba(255, 255, 255= , 0);"><br></span></div><span style=3D"background-color: rgba(255, 255, 255,= 0);">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.</span><di= v><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span><bloc= kquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D= "gmail_quote"><div><font color=3D"#000000"><span style=3D"background-color: r= gba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D"#000000"= ><span style=3D"background-color: rgba(255, 255, 255, 0);">(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).</span></font></div></div></div= ></div></blockquote><div><span style=3D"background-color: rgba(255, 255, 255= , 0);"><br></span></div><div><span style=3D"background-color: rgba(255, 255,= 255, 0);">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?</span></div><span style=3D"background-color: rgba(255, 255, 255, 0);"><= br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_ext= ra"><div class=3D"gmail_quote"><div><font color=3D"#000000"><span style=3D"b= ackground-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font= color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"= > </span></font></div><blockquote class=3D"gmail_quote" style=3D"margin= : 0px 0px 0px 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: 1e= x;"><font color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 2= 55, 0);">, also, is there a list of which exchange, library, wallet,<br>pool= , stats server, hardware etc you have tested this change against?</span></fo= nt></blockquote><div><font color=3D"#000000"><span style=3D"background-color= : rgba(255, 255, 255, 0);"><br></span></font></div><div><font color=3D"#0000= 00"><span style=3D"background-color: rgba(255, 255, 255, 0);">That testing i= s happening by the exchange, library, wallet, etc providers themselves. Ther= e is a list on the Classic home page:</span></font></div><div><font color=3D= "#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp= an></font></div><div><a href=3D"https://bitcoinclassic.com/" style=3D"backgr= ound-color: rgba(255, 255, 255, 0);"><font color=3D"#000000">https://bitcoin= classic.com/</font></a></div></div></div></div></blockquote><div><span style= =3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span s= tyle=3D"background-color: rgba(255, 255, 255, 0);">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?</span></div><span style=3D"background-color: rgba(25= 5, 255, 255, 0);"><br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div= class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font color=3D"#00000= 0"><span style=3D"background-color: rgba(255, 255, 255, 0);"> <br></spa= n></font></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p= x 0.8ex; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><font co= lor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><b= r>Do you have a rollback plan in the event the hard-fork triggers via<br>fal= se voting as seemed to be prevalent during XT? (Or rollback just<br>as= contingency if something unforseen goes wrong).</span></font></blockquote><= div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 255, 2= 55, 0);"><br></span></font></div><div><font color=3D"#000000"><span style=3D= "background-color: rgba(255, 255, 255, 0);">The only voting in this BIP is d= one by the miners, and that cannot be faked.</span></font></div><div><font c= olor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><= br></span></font></div><div><font color=3D"#000000"><span style=3D"backgroun= d-color: rgba(255, 255, 255, 0);">Are you talking about people spinning up p= seudo-full-nodes that fake the user-agent?</span></font></div><div><font col= or=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);"><br= ></span></font></div><div><font color=3D"#000000"><span style=3D"background-= color: rgba(255, 255, 255, 0);">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.</span></font></div><div><font color=3D"#000000"><span style=3D"bac= kground-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font c= olor=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">W= ould Blockstream be willing to help out by running a dozen or two extra full= nodes?</span></font></div><div><font color=3D"#000000"><span style=3D"backg= round-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font col= or=3D"#000000"><span style=3D"background-color: rgba(255, 255, 255, 0);">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?</span></font></div></div></div></div></blockq= uote><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp= an></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">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?</span></div><div><span s= tyle=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><sp= an style=3D"background-color: rgba(255, 255, 255, 0);">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".</span></div><di= v><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></div= ><div><span style=3D"background-color: rgba(255, 255, 255, 0);">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.</span><= /div><div><span style=3D"background-color: rgba(255, 255, 255, 0);"><br></sp= an></div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">Than= ks!!</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0= );"><br></span></div><div><span style=3D"background-color: rgba(255, 255, 25= 5, 0);">Dave</span></div><span style=3D"background-color: rgba(255, 255, 255= , 0);"><br></span><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"g= mail_extra"><div class=3D"gmail_quote"><div><font color=3D"#000000"><span st= yle=3D"background-color: rgba(255, 255, 255, 0);"> </span></font></div>= <blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border= -left-color: rgb(204, 204, 204); padding-left: 1ex;"><font color=3D"#000000"= ><span style=3D"background-color: rgba(255, 255, 255, 0);">How do you plan t= o monitor and manage security through the hard-fork?</span></font></blockquo= te><div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 2= 55, 255, 0);"><br></span></font></div><div><font color=3D"#000000"><span sty= le=3D"background-color: rgba(255, 255, 255, 0);">I don't plan to monitor or m= anage anything; the Bitcoin network is self-monitoring and self-managing. Se= rvices like <a href=3D"http://statoshi.info/">statoshi.info</a>will do t= he monitoring, and miners and people and businesses will manage the network,= as they do every day.</span></font></div><div><font color=3D"#000000"><span= style=3D"background-color: rgba(255, 255, 255, 0);"><br></span></font></div= ></div><font color=3D"#000000"><span style=3D"background-color: rgba(255, 25= 5, 255, 0);">-- <br></span></font><div class=3D"gmail_signature"><div d= ir=3D"ltr"><div dir=3D"ltr"><div><font color=3D"#000000"><span style=3D"back= ground-color: rgba(255, 255, 255, 0);">--<br>Gavin Andresen<br></span></font= ></div><div><font color=3D"#000000"><span style=3D"background-color: rgba(25= 5, 255, 255, 0);"><br></span></font></div></div></div></div></div></div></bl= ockquote><blockquote type=3D"cite"><font color=3D"#000000"><span style=3D"ba= ckground-color: rgba(255, 255, 255, 0);">___________________________________= ____________<br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-dev@li= sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br><a hre= f=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https:/= /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span></font></b= lockquote></div></div></body></html>= --Apple-Mail-EB8059C0-6ED2-408E-B58B-B06E3D1F2FA0--