diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2019-10-12 21:46:40 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-10-12 20:47:19 +0000 |
| commit | 7b778c4d5385a7d18296c28c8048aa614fcba761 (patch) | |
| tree | 4bce69f03f0343dd7725df3f058f10479ded4d36 | |
| parent | 58aacc2dfc58274b1c621aaa190be0f1de818e86 (diff) | |
| download | pi-bitcoindev-7b778c4d5385a7d18296c28c8048aa614fcba761.tar.gz pi-bitcoindev-7b778c4d5385a7d18296c28c8048aa614fcba761.zip | |
Re: [bitcoin-dev] Chain width expansion
| -rw-r--r-- | c7/5d6be411e292fe21c1bd5d8ac5a2d3fb64e3a8 | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/c7/5d6be411e292fe21c1bd5d8ac5a2d3fb64e3a8 b/c7/5d6be411e292fe21c1bd5d8ac5a2d3fb64e3a8 new file mode 100644 index 000000000..3771d03f4 --- /dev/null +++ b/c7/5d6be411e292fe21c1bd5d8ac5a2d3fb64e3a8 @@ -0,0 +1,185 @@ +Return-Path: <tier.nolan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F0122109 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 12 Oct 2019 20:47:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com + [209.85.128.42]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5161FD0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 12 Oct 2019 20:47:18 +0000 (UTC) +Received: by mail-wm1-f42.google.com with SMTP id f22so13158491wmc.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 12 Oct 2019 13:47:18 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=lrOQ7goIq+GPJ91Jo11ANTPUsSHwyzWa/cv/CAQHINw=; + b=uH4C1gA0if8j4/l/psVcXlM84u78Ex7QMocgfLDQpAdT4lQW0yc1zf8LgjceC9c/FR + DJmbawDL9EWOscN14wsnuiBPNXjO5j0KTugq7DAK1/OYwPdu1NrD5Nk6l3tDt5Xzg198 + Uk3ucrgKpm0zL7ibfxjQGvUU9GPuilLM3mAJC8Go3F/y7z9TKjvfmrVlajv8QMoc7opf + E1nQBq2MaNu2QMC81vgzoedXfZxZqZ+RJ4++IVT+RJhIn5tb1wCNF4w61ZHfcK9S/l7I + Eth/4WZMKvIUWXTXhE9or4RleKr3CjglI4+Da4IXaw9j2vv2bXGqUibwn4dTuON3RP5p + TZsg== +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=lrOQ7goIq+GPJ91Jo11ANTPUsSHwyzWa/cv/CAQHINw=; + b=k2FG89lafbmZFfQ8ZyWknTRW8z+o2dBhhISlkow9k8/+mEE8PSHB8AEyrb/xIRKhDe + tcPdC3TLop7MSjw98oC4vwr/rwu6D9vb9fI0OA83baw5kIgc9b6+UHUDcbGXhvGKbQdw + h/q1jorS76p7INvI4eQE/kUkZ1GcRtCpKVx94n07QD6Xn6CUPnNJFUwfdG21nJ5yqicF + yYqSM1yLjfioX5zXVCg9yUo1Mdtbs0NSqmV422f85FLAN37+/ic8PXnkTSx15pQJtLAW + tTLF5i+zFg2TqiwgOaXNLCXEnso1lT1vxhf8WGjojWB6sSx5vRw97u9rW9pQID8ZmN54 + 2ePg== +X-Gm-Message-State: APjAAAU73NJOcYBStoayEkw5mU8eCV5Q19MqinbwB2c79CRE3My8BAQA + ZOKxak57oCa8/R1utF3xz0m8+uFTW9rhU3UKYJk= +X-Google-Smtp-Source: APXvYqzRkhDPvqvBnvoZA5yoN9a2neWQui5u7OZOqt7I2xsGXH0ji+lFcAIZnnIqataQ4ywDNg40s6vi/g5BzVftC/g= +X-Received: by 2002:a05:600c:40f:: with SMTP id + q15mr8340030wmb.30.1570913236857; + Sat, 12 Oct 2019 13:47:16 -0700 (PDT) +MIME-Version: 1.0 +References: <42cd5ffd-63e8-b738-c4ea-13d0699b1268@purse.io> + <CAE-z3OV_LL+Jww3e=gO6t=02VW7m9PK+8EaYoEVLy9NKNMiSaQ@mail.gmail.com> + <e9c5e519-ea8a-f0e2-d8fb-c955b5c2de40@purse.io> + <CAE-z3OXyTc0aoJJVNLS5MReE7+Nhckyrjf22+yCSjXF8=bNbXQ@mail.gmail.com> + <H_Yq1W3SffFweLPPXiUiA4EeU2yU7c8LVcqw5AbajovWTWMt5hKQARKglEQwCjPpXvjiBfvmTnaXJwivkGkT8BDha8k303DNbFB-ECes0d4=@protonmail.com> +In-Reply-To: <H_Yq1W3SffFweLPPXiUiA4EeU2yU7c8LVcqw5AbajovWTWMt5hKQARKglEQwCjPpXvjiBfvmTnaXJwivkGkT8BDha8k303DNbFB-ECes0d4=@protonmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +Date: Sat, 12 Oct 2019 21:46:40 +0100 +Message-ID: <CAE-z3OVqU5n8H9vKj9Pn7k80guMTsxt_CkN9qwpfCK8HB4PDgQ@mail.gmail.com> +To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000074b94b0594bcbd70" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + 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 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Chain width expansion +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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: Sat, 12 Oct 2019 20:47:19 -0000 + +--00000000000074b94b0594bcbd70 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +On Sat, Oct 12, 2019 at 6:56 PM Joachim Str=C3=B6mbergson < +joachimstr@protonmail.com> wrote: + +> I like the backwards syncing idea. First you provide proof of your best +> block height via coinbase, then sync backwards. It solves lots of related +> problems. You know how much you can expect from the given peer. +> + +It shows you which nodes are on the same chain too. + +If you have 8 peers and you ask the 8 of them for their 8 best, then they +should all agree on most of them. + +You can then ask each of the 8 to start sending you headers backwards from +one of the 8 seeds. + +They will all roughly split the chain into 8 equal pieces, though the split +will be based on work rather than header height. + +If there is disagreement, you can give priority to the node(s) with the +lowest headers until they have completed their download. + +It requires a network protocol change to allow reverse block downloads +though (and messages to indicate lowest headers etc.) + +On different note, one of the problems that I haven't seen mentioned here +> yet is the timewarp attack. It is relevant to some of the proposed +> solutions. It should be possible, IIRC, for a malicious node to generate +> much longer chain with superslow timestamp increase (~5 blocks in 1 secon= +d) +> without increasing difficulty (i.e. staying at min. diff.). This could +> produce chain that is ~2500 times longer than main chain without having +> multiple branches. +> + +That is a good point. It answers my question about formula for maximum +number of blocks. + +5 * 60 * 60 * 24 * 365 =3D 157,680,000 + +That's around 150 million blocks per year at that rate. + +I assume the 5 per second limit is that it is greater that the median of +the last 11 rather than greater or equal? + +The timewarp bug can be fixed by a basic soft fork. You just need to limit +the maximum difference between the timestamp for the first header in a +period and the last header in the previous period. + +An alternative would be to soft fork in a maximum block rate. In addition +to the current rules, you could limit it to a maximum of 1 block every 2 +mins. That rule shouldn't activate normally. + + block.height <=3D (block.timestamp - genesis.timestamp) / (2 mins) + +It could have some weird incentives if it actually activated though. +Miners would have to shutdown mining if they were finding blocks to fast. + +--00000000000074b94b0594bcbd70 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= +_attr">On Sat, Oct 12, 2019 at 6:56 PM Joachim Str=C3=B6mbergson <<a hre= +f=3D"mailto:joachimstr@protonmail.com">joachimstr@protonmail.com</a>> wr= +ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= + 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I like= + the backwards syncing idea. First you provide proof of your best block hei= +ght via coinbase, then sync backwards. It solves lots of related problems. = +You know how much you can expect from the given peer.<br></div></blockquote= +><div><br></div><div>It shows you which nodes are on the same chain too.</d= +iv><div><br></div><div>If you have 8 peers and you ask the 8 of them for th= +eir 8 best, then they should all agree on most of them.</div><div><br></div= +><div>You can then ask each of the 8 to start sending you headers backwards= + from one of the 8 seeds.</div><div><br></div><div>They will all roughly sp= +lit the chain into 8 equal pieces, though the split will be based on work r= +ather than header height.</div><div><br></div><div>If there is disagreement= +, you can give priority to the node(s) with the lowest headers until they h= +ave completed their download.</div><div><br></div><div>It requires a networ= +k protocol change to allow reverse block downloads though (and messages to = +indicate lowest headers etc.)<br></div><div><br></div><blockquote class=3D"= +gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= +4,204,204);padding-left:1ex"><div>On different note, one of the problems th= +at I haven't seen mentioned here yet is the timewarp attack. It is rele= +vant to some of the proposed solutions. It should be possible, IIRC, for a = +malicious node to generate much longer chain with superslow timestamp incre= +ase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at = +min. diff.). This could produce chain that is ~2500 times longer than main = +chain without having multiple branches. <br></div></blockquote><div><br></d= +iv><div>That is a good point.=C2=A0 It answers my question about formula fo= +r maximum number of blocks.</div><div><br></div><div>5 * 60 * 60 * 24 * 365= + =3D 157,680,000</div><div><br></div><div>That's around 150 million blo= +cks per year at that rate.</div><div><br></div><div>I assume the 5 per seco= +nd limit is that it is greater that the median of the last 11 rather than g= +reater or equal?</div><div><br></div><div>The timewarp bug can be fixed by = +a basic soft fork.=C2=A0 You just need to limit the maximum difference betw= +een the timestamp for the first header in a period and the last header in t= +he previous period.</div><div><br></div><div>An alternative would be to sof= +t fork in a maximum block rate.=C2=A0 In addition to the current rules, you= + could limit it to a maximum of 1 block every 2 mins.=C2=A0 That rule shoul= +dn't activate normally.<br></div><div><br></div><div>=C2=A0=C2=A0 block= +.height <=3D (block.timestamp - genesis.timestamp) / (2 mins) <br></div>= +<div><br></div><div>It could have some weird incentives if it actually acti= +vated though.=C2=A0 Miners would have to shutdown mining if they were findi= +ng blocks to fast.<br></div></div></div> + +--00000000000074b94b0594bcbd70-- + |