diff options
| author | Ethan Heilman <eth3rs@gmail.com> | 2019-04-18 16:12:20 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-04-18 20:12:59 +0000 |
| commit | 2269b3598477591e68d9422f8223a4ab2bfb4f64 (patch) | |
| tree | 31353ef2f6ba71071cf0b6a235139a817c09f0bd | |
| parent | 8b46e191c13983dc363c46203a381f1f67d07408 (diff) | |
| download | pi-bitcoindev-2269b3598477591e68d9422f8223a4ab2bfb4f64.tar.gz pi-bitcoindev-2269b3598477591e68d9422f8223a4ab2bfb4f64.zip | |
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
| -rw-r--r-- | bc/f975a4e76340c3fa9e4f7666d4d0ed9bcbdd2a | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/bc/f975a4e76340c3fa9e4f7666d4d0ed9bcbdd2a b/bc/f975a4e76340c3fa9e4f7666d4d0ed9bcbdd2a new file mode 100644 index 000000000..282f22bbc --- /dev/null +++ b/bc/f975a4e76340c3fa9e4f7666d4d0ed9bcbdd2a @@ -0,0 +1,181 @@ +Return-Path: <eth3rs@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 2AFE51D51 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Apr 2019 20:12:59 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com + [209.85.214.176]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27A876C5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Apr 2019 20:12:58 +0000 (UTC) +Received: by mail-pl1-f176.google.com with SMTP id n8so1644392plp.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Apr 2019 13:12:58 -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:content-transfer-encoding; + bh=5VWu37CpKckfwfHLfcOqqUvfBXQEmDOZ66Y9u052YDU=; + b=k0zkZ0y5ZVrFTZh4GbjQP7G5eCwCKUMxCxfdW6roJwy9pmr9VjYc0L8cIzMNRJ3JIx + xLr2nhWzqLydH4WY83PCaPV74ed2WBZD70f4q6txDnlw1nmH2iwU5wx8IbPZcpwML3n4 + DmT2Gkj4NItvDV08e5DfneQta6wDBfP47Thkr/aM8D0vG1QRhwp4Eg7XwaH62VGjl5pQ + wjcvcgwuRjHHk7jAwEFk+IHqow60adbPSdGghTkdqVHZXhDZE30rj49SR3LUT0zCVhlk + wIyhCxNGoXT2EhTdFBYJ23K47tGDV7O/vkcyA4u+vV+FgGLAAsAgkXFDK62/6h+rsXOU + U7VQ== +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:content-transfer-encoding; + bh=5VWu37CpKckfwfHLfcOqqUvfBXQEmDOZ66Y9u052YDU=; + b=Wt9fah7vUTJ2OPI7AMDmUzvtkuvHJpd0+tLHGw9qRWruvDcd9Y3e+UkcYeRCg9/PTf + IrV+YbimkCJtfen6ijbuLrPkAq+14szvO0PnRsLrti85WFc/F3i4v6/PQzbr+KmGnlZl + M/qE3aEUuxaNjHZlPNOXc2GepZVj3nbUPW9ZX55Peuh8XfgzlWNtlCxYfGD6xJ50WJpL + 8CezlvBYoUbPxshYVwZARUr7tEcnZE7tHB97j/W0rCgeJkKsdQPnJN17tWtpZCyl/zyW + 3BFHW2c/1j10iIq5lhBqbSEfA/dWhnsQDICRFCPUt/6ArWqM7x+Y8icXWZv7NULiiWL4 + W/vQ== +X-Gm-Message-State: APjAAAUk4Iw0w2SncTQaEMLmGHS+gwhlL6c6ba2jNKh2Cv4IHbYkdamZ + GHZDCLCkO+9orE8w27jvEOIBjez3QEzReE5mOgM= +X-Google-Smtp-Source: APXvYqzbNYBA3RvRpwr7w9DiFDO7zyG6qXsRc1o3yCaW+pYaxFUwveEji41TGClWWKFGfHon6dWlyO+H1yIUkUMGEuM= +X-Received: by 2002:a17:902:b78c:: with SMTP id + e12mr45350095pls.29.1555618377561; + Thu, 18 Apr 2019 13:12:57 -0700 (PDT) +MIME-Version: 1.0 +References: <CAPv7TjYspkc1M=TKmBK8k0Zy857=bR7jSTarRDCr_5m2ktYHDQ@mail.gmail.com> + <-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com> +In-Reply-To: <-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com> +From: Ethan Heilman <eth3rs@gmail.com> +Date: Thu, 18 Apr 2019 16:12:20 -0400 +Message-ID: <CAEM=y+W==_+AW6ga9WMf=aAX-xPGUfhEJQFvUtdFodGGv-6eAg@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + 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: Fri, 19 Apr 2019 13:57:03 +0000 +Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs +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: Thu, 18 Apr 2019 20:12:59 -0000 + +I'm probably repeating a point which has been said before. + +>I suppose a minority miner that wants to disrupt the network could simply = +create a *valid* block at block N+1 and deliberately ignore every other val= +id block at N+1, N+2, N+3 etc. that it did not create itself. +If this minority miner has > 10% of network hashrate, then the rule of +thumb above would, on average, give it the ability to disrupt the +SPV-using network. + +Proposed rule: +Whenever a chainsplit occurs SPV clients should download and validate +the "longest chain" up to more than one block greater than the height +of the losing chain. + +Lets say a block split causes chain A and chain B: Chain A is N blocks +long, chain B is M blocks long, and N < M. Then the SPV client should +download all the block data of N+1 blocks from Chain B to verify +availability of chain B. Once the SPV client has verified that chain B +is available they can use fraud proofs determine if chain B is valid. + +An attacker could use this to force SPV clients to download 1 block +per block the attacker mines. This is strictly weaker security than +provided by a full-node because chain B will only be validated if the +client knows chain A exists. If the SPV client's view of the +blockchain is eclipsed then the client will never learn that chain A +exists and thus never validate chain B's availability nor will the +client be able to learn fraud proofs about chain B. A full node in +this circumstance would notice that the chain B is invalid and reject +it because a full node would not depend on fraud proofs. That being +said this rule would provide strictly more security than current SPV +clients. + +On Thu, Apr 18, 2019 at 3:08 PM ZmnSCPxj via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> Good morning Ruben, +> +> +> Sent with ProtonMail Secure Email. +> +> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = +Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 +> On Thursday, April 18, 2019 9:44 PM, Ruben Somsen via bitcoin-dev <bitcoi= +n-dev@lists.linuxfoundation.org> wrote: +> +> > Simplified-Payment-Verification (SPV) is secure under the assumption +> > that the chain with the most Proof-of-Work (PoW) is valid. As many +> > have pointed out before, and attacks like Segwit2x have shown, this is +> > not a safe assumption. What I propose below improves this assumption +> > -- invalid blocks will be rejected as long as there are enough honest +> > miners to create a block within a reasonable time frame. This still +> > doesn=E2=80=99t fully inoculate SPV clients against dishonest miners, b= +ut is a +> > clear improvement over regular SPV (and compatible with the privacy +> > improvements of BIP157[0]). +> > +> > The idea is that a fork is an indication of potential misbehavior -- +> > its block header can serve as a PoW fraud proof. Conversely, the lack +> > of a fork is an indication that a block is valid. If a fork is created +> > from a block at height N, this means a subset of miners may disagree +> > on the validity of block N+1. If SPV clients download and verify this +> > block, they can judge for themselves whether or not the chain should +> > be rejected. Of course it could simply be a natural fork, in which +> > case we continue following the chain with the most PoW. +> +> I presume you mean a chain split? +> +> > +> > The way Bitcoin currently works, it is impossible to verify the +> > validity of block N+1 without knowing the UTXO set at block N, even if +> > you are willing to assume that block N (and everything before it) is +> > valid. This would change with the introduction of UTXO set +> > commitments, allowing block N+1 to be validated by verifying whether +> > its inputs are present in the UTXO set that was committed to in block +> > N. An open question is whether a similar result can be achieved +> > without a soft fork that commits to the UTXO set[0][1]. +> > +> > If an invalid block is created and only 10% of the miners are honest, +> > on average it would take 100 minutes for a valid block to appear. +> > During this time, the SPV client will be following the invalid chain +> > and see roughly 9 confirmations before the chain gets rejected. It may +> > therefore be prudent to wait for a number of confirmations that +> > corresponds to the time it may take for the conservative percentage of +> > miners that you think may behave honestly to create a block (including +> > variance). +> +> I suppose a minority miner that wants to disrupt the network could simply= + create a *valid* block at block N+1 and deliberately ignore every other va= +lid block at N+1, N+2, N+3 etc. that it did not create itself. +> If this minority miner has > 10% of network hashrate, then the rule of th= +umb above would, on average, give it the ability to disrupt the SPV-using n= +etwork. +> +> >10% of network hashrate to disrupt the SPV-using nodes would be a rather= + low bar to disruption. +> Consider that SPV-using nodes would be disrupted, without this rule, only= + by >50% network hashrate. +> +> It is helpful to consider that every rule you impose is potentially a loo= +phole by which a new attack is possible. +> +> Regards, +> ZmnSCPxj +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |