From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <rsomsen@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A13EB3EE for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 11 Sep 2019 04:59:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A78D77DB for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 11 Sep 2019 04:59:11 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id p7so1780077wmp.4 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 10 Sep 2019 21:59:11 -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=qzkfBvADrLqaTbL3moLNA5P/o8ZTVG8AL64DAurudlI=; b=PyqF5CpPm054QqbYBrSZuY89VJsZT9B8A4VQhduf0GxsJU2YhZNuYo4Z7olLnvFhRf Xcm8PkiNQShYY6qZuzpl/IUdC7LOyOF//kP8ZlIyIs8BvFRc6N0u7IrG/mp8UEHrhnep 6onP9L1/HmJ9w1pLxh/527BUgwJ1kLWBYqMK6ECU+HUG18ldKyvmRFqa5pcFOBHUBEeD W5SynfRa5BJ2bxijR/EwwvY3m0/JXogmG5yjtFnsk/T4O8vSKUq7CY7sI91oRX/c0YN/ NIcOfP1csAXvAV+3S6nxsaNtrO/gpS/26URkVX/bRuS278CEfzEUIHnDjDQpP/6vCnTJ 1j+Q== 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=qzkfBvADrLqaTbL3moLNA5P/o8ZTVG8AL64DAurudlI=; b=NityY04DNb2OGDK1coMuGgI/X2nJBtTYr3lpFbnr3yYF+Hg5mt+qiNlFZ7mZ5Ese52 XwAbJcECrFLBBgVZDdwzNPaCnZocxiQYGoCoT598vxp0cTMdtaxCCy92L6A6Dvkrnb0j VCuVF0Osu1DCRHijdBUC0QOcH6pyXEtJzoa0bUigDrlGp8n//it8yd2e2VOisGBPW8XX B6uW07w5ou8kXiseiAwSY7fkrXV9FTwniyXkPH8pOUajchNO2RQoHKGbQ1ujWsqDeP72 utIE9UksL6jinsW5VTtRxB2jnZq3QcYKwNtxJVl00I1Btts6ZtNRj8ldB79Th8WiIF9/ vbjg== X-Gm-Message-State: APjAAAWyXtVdUHHuS/jYBaQpl3GT8QS1YKORgvHuLoEfFkvxNWKUxPGr pTYB5RT2ShU2zyon6jwh/pql8h/kSldr2RBeSzw= X-Google-Smtp-Source: APXvYqzVI9RZ/09A6VSBoWa+/HOPkKapO8EIyiXhAA973Pd7uaHGNbLlWtxkxh1DDJxEmB5Bpaxf2KQLFSXTQ2AZNC4= X-Received: by 2002:a1c:cf05:: with SMTP id f5mr2184355wmg.131.1568177950231; Tue, 10 Sep 2019 21:59:10 -0700 (PDT) MIME-Version: 1.0 References: <CAPv7TjaE1wF-25R=LaOES33A78ovDAp9-waiC7n5YLJnMmNs9A@mail.gmail.com> <uVQNn9hhpqlQuS-RzrUkpClVtegMRUoyIL6ITaYfNkjd_XYyu9Fh9vdAeLguzOyOrNx5FtuHk7yyZAdivqCVR2PKzF_PsoWJlsSY9oJTF7s=@protonmail.com> <CAPv7TjYE1rp2EEo247fKmmN=q9QBqCHPBy56xvBymOv418LFDw@mail.gmail.com> <y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com> In-Reply-To: <y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com> From: Ruben Somsen <rsomsen@gmail.com> Date: Wed, 11 Sep 2019 06:58:57 +0200 Message-ID: <CAPv7TjaMm5q8Q-AXbVcjx5RoKt-5y7t4Fx+CMhJ=cabLysc9=w@mail.gmail.com> To: ZmnSCPxj <ZmnSCPxj@protonmail.com> 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: Wed, 11 Sep 2019 04:59:37 +0000 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] PoW fraud proofs without a soft fork 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: Wed, 11 Sep 2019 04:59:12 -0000 Hi ZmnSCPxj, >I suppose the critical difference is that invalid inflation can fool the S= PV node, the fullnode will not be so fooled. That is correct. If you sybil the SPV node, you can break any consensus rule you like. I believe this is inherent to fraud proofs in general, because you skip consensus checks unless you're able to receive a fraud proof. But note that my goal in the comparison was to assert that there is no security difference between committing or not committing the utreexo hash into a block. The attack your describe works in either situation, so my conclusion remains that committing the hash adds no security. Other weaknesses compared to full nodes are: - the SPV nodes rely on the existence of a healthy network of utreexo supporting full nodes - at least one honest block needs to be mined - consensus slows down, because you need to allow time for an honest minority to produce a block Cheers, Ruben On Mon, Sep 9, 2019 at 8:58 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote: > > Good morning Ruben, > > Yes, I suppose that is correct. > > I suppose the critical difference is that invalid inflation can fool the = SPV node, the fullnode will not be so fooled. > > A somewhat larger-scale attack is to force a miner-supported miner-subsid= y-increase / blocksize-increase hard fork. > If enough such SPV nodes can be sybilled, they can be forced to use the h= ard fork, which might incentivize them to support the hard fork rather than= back-compatible consensus chain. > > Regards, > ZmnSCPxj > > > Hi ZmnSCPxj, > > > > Thank you for your comments. You raise an important point that I should= clarify. > > > > > 1. In event of a sybil attack, a fullnode will stall and think the b= lockchain has no more miners. > > > > You can still attack the full node by feeding it a minority PoW chain, > > then it won't stall. > > > > > 2. In event of a sybil attack, an SPV, even using this style, will f= ollow the false blockchain. > > > > Correct, but this false blockchain does need to have valid PoW. > > > > So in both cases valid PoW is required to fool nodes. The one > > difference is that for a full node, the blocks themselves also need to > > be valid (except for the fact that they are in a minority chain), but > > the end result is still that a victim can be successfully double spent > > and lose money. > > > > I hope this clarifies why I consider the security for these two > > situations to be roughly equivalent. In either situation, victims can > > be fooled into accepting invalid payments. > > > > Cheers, > > Ruben > > > > On Mon, Sep 9, 2019 at 6:14 AM ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > > > > Good morning Ruben, > > > > > > > One might intuitively feel that the lack of a commitment is uns= afe, > > > > but there seems to be no impact on security (only bandwidth). T= he only > > > > way you can be fooled is if all peers lie to you (Sybil), causi= ng you > > > > to follow a malicious minority chain. But even full nodes (or t= he > > > > committed version of PoW fraud proofs) can be fooled in this wa= y if > > > > they are denied access to the valid most PoW chain. If there ar= e > > > > additional security concerns I overlooked, I=E2=80=99d love to = hear them. > > > > > > > > > > I think it would be better to more precisely say that: > > > > > > 1. In event of a sybil attack, a fullnode will stall and think the b= lockchain has no more miners. > > > 2. In event of a sybil attack, an SPV, even using this style, will f= ollow the false blockchain. > > > > > > This has some differences when considering automated systems. > > > Onchain automated payment processing systems, which use a fullnode, w= ill refuse to acknowledge any incoming payments. > > > This will lead to noisy complaints from clients of the automated paym= ent processor, but this is a good thing since it warns the automated paymen= t processor of the possibility of this attack occurring on them. > > > The use of a timeout wherein if the fullnode is unable to see a new b= lock for, say, 6 hours, could be done, to warn higher-layer management syst= ems to pay attention. > > > While it is sometimes the case that the real network will be unable t= o find a new block for hours at a time, this warning can be used to confirm= if such an event is occurring, rather than a sybil attack targeting that f= ullnode. > > > On the other hand, such a payment processing system, which uses an SP= V with PoW fraud proofs, will be able to at least see incoming payments, an= d continue to release product in exchange for payment. > > > Yet this is precisely a point of attack, where the automated payment = processing system is sybilled and then false payments are given to the paym= ent processor on the attack chain, which are double-spent on the global con= sensus chain. > > > And the automated system may very well not be able to notice this. > > > Regards, > > > ZmnSCPxj > >