path: root/14/02c66d2188dedd37e8c4f5a7a56533e0d242a3

Return-Path: <m@ib.tc>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 564A0C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 06:38:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 4F8E886760
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 06:38:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XQENBSwcadMn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 06:38:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com
 [209.85.221.48])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 4003586750
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 06:38:01 +0000 (UTC)
Received: by mail-wr1-f48.google.com with SMTP id j2so419767wrx.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 23:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=bg4/hsoPg60sxNNye21B8VqiPo2dCmWZAtIHGE822hQ=;
 b=QEtZjbYNr2ugpe2bhXXKyaYFzRCOe16uIuq1XuO3iM5ne3BvivLGkLuwgSGeKB23U5
 XmzJ/4b44l2LsNNuyNYfRMt6fvF84Xc0thlot1tfpLpAR/mD23t1XUKyjhuefUxmcXrt
 Gocaqiy3F/CAQzoo3I+RwZ/XfTTDgJr545qQhM8SGhUmdxD/rAM9jTh8c4PBX9OYwjmd
 r53DWDov/GUdmCyi1U/yit7pNVDLwBEktiTdd2Cv56JoDEP/emyPw5HIis3eq0LVlS9N
 7oJe07NaesWH8Yf0/S7Lp+t3m+uB8C6lGZDaE9IbjfiXPOGcki9shMl8l6hL5bVwn4pV
 Pw6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=bg4/hsoPg60sxNNye21B8VqiPo2dCmWZAtIHGE822hQ=;
 b=lbYyh9SI75BE26CMzSKryidUA9jl3uiCT8xXs0Hhkl2hbVWq9j3XLSVq/J+bWY6T0p
 lzWISj4d0vOrUCszai5Z4D91v7647gIA3IQN0pPuN9zrSxM9A5ulVSO/e5S/7PYkKBxN
 fwH9EEGnzj4OOvyNIMEKWvNL9HKyheHxfQeBubEgbiLB7bjqABBU8Cf8ilt2rSg195gF
 2tZJtxmiXAU+690oh/pEgPuDp3FdWOvdksO0o33ur6RWMahwyLPuezhWpdsFLeiqB8rd
 aira86ZUm38/oDVDHXw4e2hTAlXGhwDyUV5dad16H1yxDOtbNajJ+kcvrC74DUbTJFrV
 0+bw==
X-Gm-Message-State: AOAM533AaNyE/m0mykxWt8g/Xi+O4wrKNjWbQ6ffgLrTFC3yybpXzzOM
 ew68WlkvBZULhAwEWS3bbK/hhQIwfhQNIP7iON3nFA==
X-Google-Smtp-Source: ABdhPJxUQ2SNfGAXInb/W3E5oIPLfhUuaGlHsu4TCp9rWnnTkd+HMeNzoNWSXWU+Nd7pKyI9TdhxuyxvpPX81uPj/V8=
X-Received: by 2002:adf:fc4e:: with SMTP id e14mr1276276wrs.329.1601447879288; 
 Tue, 29 Sep 2020 23:37:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
 <CALFqKjQP75TdaDeop-bxpcW5PHpmG4RwW-MDjUFGrqUy=xNdoQ@mail.gmail.com>
 <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com>
In-Reply-To: <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com>
From: Mike Brooks <m@ib.tc>
Date: Tue, 29 Sep 2020 23:37:47 -0700
Message-ID: <CALFqKjQDx7BrGEUJLhN=VXS8c--bVOJV4pvQTV6ag2Cy+GjWbw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f8c24605b0822331"
X-Mailman-Approved-At: Wed, 30 Sep 2020 07:42:42 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Mike Brooks <f@in.st.capital>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 30 Sep 2020 06:38:02 -0000

--000000000000f8c24605b0822331
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

ZmnSCPxj,

No, it would be better to use parachains for Mars.

-Mike Brooks

On Tue, Sep 29, 2020, 11:31 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
> >  At this point very little is stopping us from speeding up block
> creation times. PoS networks are proving that conformations can be a minu=
te
> or less - why not allow for a block formation time that is 6 or 12 times
> faster than the current target and have 1/6th (or 1/12th) of the subsidy =
to
> keep an identical inflation target.
>
> What?
>
> That is surprising information to me.
>
> My understanding is that speeding up block creation times is highly risky
> due to increasing the tendency to "race" in mining.
>
> The average time to propagate to all miners should be negligible to the
> average inter-block time.
> Efforts like compact blocks and FIBRE already work at the very edges of
> our capability to keep the propagation time negligible.
>
> Indeed, looking forward, part of my plans for Earth-based civilization
> involves sending out hapless humans into space and forcing them to surviv=
e
> there, thus the inter-block time may need to be *increased* in
> consideration of interplanetary communications times, otherwise Bitcoin
> would dangerously centralize around Earth, potentially leading to the
> Universal Century and awesome giant robot battles.
>
> (Hmmm, on the one hand, centralizing around Earth is dangerous, on the
> other hand, giant robots, hmmm)
>
> "PoS" networks mean nothing, as most of them are not global in the scale
> that Bitcoin is, and all of them have a very different block discovery
> model from proof-of-work.
> In particular, I believe there is no "racing" involved in most PoS scheme=
s
> in practice.
>
> >
> > =E2=80=A6 The really interesting part is the doors that this patch open=
s.
> Bitcoin is the best network, we have the most miners and we as developers
> have the opportunity to build an even better system - all with incrementa=
l
> soft-forks - which is so exciting.
>
> Changing inter-block times is not possible as a softfork, unless you are
> planning to (ab)use the timewarp bug, which I believe was proposed by
> maaku7 before.
> My understanding is that the preferred approach would be to close the
> timewarp bug, in which case increasing the block rate would not be doable
> as a softfork anymore.
>
> Regards,
> ZmnSCPxj
>

--000000000000f8c24605b0822331
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">ZmnSCPxj,<div dir=3D"auto"><br></div><div dir=3D"auto">No=
, it would be better to use parachains for Mars.=C2=A0</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">-Mike Brooks</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 29, 2020, 11:3=
1 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@proto=
nmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt;=C2=A0 At this point very little is stopping us from speeding up block =
creation times. PoS networks are proving that conformations can be a minute=
 or less - why not allow for a block formation time that is 6 or 12 times f=
aster than the current target and have 1/6th (or 1/12th) of the subsidy to =
keep an identical inflation target.<br>
<br>
What?<br>
<br>
That is surprising information to me.<br>
<br>
My understanding is that speeding up block creation times is highly risky d=
ue to increasing the tendency to &quot;race&quot; in mining.<br>
<br>
The average time to propagate to all miners should be negligible to the ave=
rage inter-block time.<br>
Efforts like compact blocks and FIBRE already work at the very edges of our=
 capability to keep the propagation time negligible.<br>
<br>
Indeed, looking forward, part of my plans for Earth-based civilization invo=
lves sending out hapless humans into space and forcing them to survive ther=
e, thus the inter-block time may need to be *increased* in consideration of=
 interplanetary communications times, otherwise Bitcoin would dangerously c=
entralize around Earth, potentially leading to the Universal Century and aw=
esome giant robot battles.<br>
<br>
(Hmmm, on the one hand, centralizing around Earth is dangerous, on the othe=
r hand, giant robots, hmmm)<br>
<br>
&quot;PoS&quot; networks mean nothing, as most of them are not global in th=
e scale that Bitcoin is, and all of them have a very different block discov=
ery model from proof-of-work.<br>
In particular, I believe there is no &quot;racing&quot; involved in most Po=
S schemes in practice.<br>
<br>
&gt;<br>
&gt; =E2=80=A6 The really interesting part is the doors that this patch ope=
ns. Bitcoin is the best network, we have the most miners and we as develope=
rs have the opportunity to build an even better system - all with increment=
al soft-forks - which is so exciting.<br>
<br>
Changing inter-block times is not possible as a softfork, unless you are pl=
anning to (ab)use the timewarp bug, which I believe was proposed by maaku7 =
before.<br>
My understanding is that the preferred approach would be to close the timew=
arp bug, in which case increasing the block rate would not be doable as a s=
oftfork anymore.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000f8c24605b0822331--