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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Mike Brooks <f@in.st.capital>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Precedence: list

--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--