Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD97C7F6 for ; Mon, 15 Apr 2019 06:38:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E14E828 for ; Mon, 15 Apr 2019 06:38:06 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id k17so15611030wrx.10 for ; Sun, 14 Apr 2019 23:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=K4rUtFZl3tCXw/ujeDAs/ih6lBYTB4HzVP2wevL3nI4=; b=Y9kcv4nFgC9RDV5IIgZU8ZlGu2SKJyEM7dmOcL9cJh81Ff7ayHpEW1lkRENOL6x5IH SF0t9pU6PXKo7hiaILNfqMjSDqSOCFJiIO0TcVIomZFmARMu1fQp6dvuPCUboeVSW77m f27/SzmTFnOPt5yTTHFaKmVzF7ieMJ5H2aBLcxcufotilu5ln49kwEVELAVxpGESc/dN 8Zq+gMpKwRyficYJqeygNPe7PSIQuKu/p75pciA212UpRrb1QpqhDANt9PJcalYz1UwG dTAuFB8ulANQaj+bU3xAfJfyZ8HpGLAEW4TRCqL3SZlWPoF7gIRPvIeduzgqCy6Fja3k pZ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=K4rUtFZl3tCXw/ujeDAs/ih6lBYTB4HzVP2wevL3nI4=; b=R2oywN11hKU1KRbI47xO9389VkLoJVX2IUE0t5Ze8Mn01k2hG/6i6s5qpVgXRaSfyb ScryS+j7I7gr9LviDEotKhP78Ybw6Q34liY45Xdgif+x3aCmVRSuombW1zfqsnUO7PxZ Gc8O1Yn9XSyQlYFV4EuBsGBlAX1ZepHJeOY3djIRRq6AQVPxSiLBz/VEYwsxFmXJljPD 5d8Us1q+YiA4QE897NvZSn4kfK4F9CRROfd2YV7lIHUan8mB4/t8QEcGLiqFAyleRiQz IdwPBqpC8McLSC9l+1pUGJr5xSzkrMm1GgfB4OpwVWgLJZQLwliKsjOeL0c5+hYuXOBV 9v7A== X-Gm-Message-State: APjAAAUsf4lnFYYPh4sGXDu0/nhv6Y7mTsxSkzgCS9nEpKrgbhXJXCGq DjQcRHY4OppSWTrGlMqnClInh4GPp35lUq2hYqhmVsRp X-Google-Smtp-Source: APXvYqx/nAJ+KE3EvYgCi1F/dK6ZWRy0rPiBQkIqH7nFnYAKac3xHKLyXQ1BPuKRtWn3g6CaN5roOZ4lLGp1Xx0h4CM= X-Received: by 2002:adf:ff88:: with SMTP id j8mr45614162wrr.1.1555310284589; Sun, 14 Apr 2019 23:38:04 -0700 (PDT) MIME-Version: 1.0 From: Ruben Somsen Date: Mon, 15 Apr 2019 08:37:43 +0200 Message-ID: To: Bitcoin Protocol Discussion 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: Thu, 18 Apr 2019 13:43:50 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 06:38:06 -0000 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, but i= s 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. 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). If users do not wait and happen to accept payments from an invalid chain during this time, these payments could get reverted. This is a weakness, but still seems preferably to continually following an invalid chain. As long as a reasonable number of miners remains honest, a dishonest majority can only temporarily control the network, and their blocks (and all coins gained from it) will eventually be rejected. -- Ruben Somsen [0] Olaoluwa Osuntokun, BIP 157: Client Side Block Filtering, https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki [1] Peter Todd, TXO commitments do not need a soft-fork to be useful, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/01359= 1.html