From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 564A0C0051 for ; 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 ; 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 ; 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 ; Wed, 30 Sep 2020 06:38:01 +0000 (UTC) Received: by mail-wr1-f48.google.com with SMTP id j2so419767wrx.7 for ; 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: <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com> In-Reply-To: <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com> From: Mike Brooks Date: Tue, 29 Sep 2020 23:37:47 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000f8c24605b0822331" X-Mailman-Approved-At: Wed, 30 Sep 2020 07:42:42 +0000 Cc: Bitcoin Protocol Discussion , Mike Brooks 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
ZmnSCPxj,

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

-Mike Brooks

On Tue, Sep 29, 2020, 11:3= 1 PM ZmnSCPxj <ZmnSCPxj@proto= nmail.com> wrote:

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

What?

That is surprising information to me.

My understanding is that speeding up block creation times is highly risky d= ue to increasing the tendency to "race" in mining.

The average time to propagate to all miners should be negligible to the ave= rage 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 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.

(Hmmm, on the one hand, centralizing around Earth is dangerous, on the othe= r hand, giant robots, hmmm)

"PoS" 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.
In particular, I believe there is no "racing" involved in most Po= S schemes in practice.

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

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

Regards,
ZmnSCPxj
--000000000000f8c24605b0822331--