From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ZmnSCPxj@protonmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D9676D9D for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 9 Sep 2019 06:58:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3EDAEC for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 9 Sep 2019 06:58:22 +0000 (UTC) Date: Mon, 09 Sep 2019 06:58:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568012300; bh=ANCl3rHk1Z+YzgG3VIqLPPYZa4n//7KYrOYBs7QHweU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Rs6W/xdeDV3TjMNVxhE/Hys5UNlY0YWoWqSEZhzJXAF89dc/VJATJ7fkXYsKa1fWw XALXs71AdhLOuPLhQr8bPj6iezhnyQjvSXD0i8Nwa/qS0LN/ol/qpy0b6Ehs2V0D+Y VrGSiM8i372v4LHIBXqAnGgHAGcz8U8aFYtCvX3o= To: Ruben Somsen <rsomsen@gmail.com> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <y8brIayR1YQIud3TxdgiBJK3zrxclhcICAJgSw3tqqJM2jP9WA1SWiesXcNSrRxiIM7m8cRkZlLdu0sz2lNFEe5HbQI4TIRvkoA3yysMzKE=@protonmail.com> In-Reply-To: <CAPv7TjYE1rp2EEo247fKmmN=q9QBqCHPBy56xvBymOv418LFDw@mail.gmail.com> References: <CAPv7TjaE1wF-25R=LaOES33A78ovDAp9-waiC7n5YLJnMmNs9A@mail.gmail.com> <uVQNn9hhpqlQuS-RzrUkpClVtegMRUoyIL6ITaYfNkjd_XYyu9Fh9vdAeLguzOyOrNx5FtuHk7yyZAdivqCVR2PKzF_PsoWJlsSY9oJTF7s=@protonmail.com> <CAPv7TjYE1rp2EEo247fKmmN=q9QBqCHPBy56xvBymOv418LFDw@mail.gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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] 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: Mon, 09 Sep 2019 06:58:25 -0000 Good morning Ruben, Yes, I suppose that is correct. I suppose the critical difference is that invalid inflation can fool the SP= V node, the fullnode will not be so fooled. A somewhat larger-scale attack is to force a miner-supported miner-subsidy-= increase / blocksize-increase hard fork. If enough such SPV nodes can be sybilled, they can be forced to use the har= d fork, which might incentivize them to support the hard fork rather than b= ack-compatible consensus chain. Regards, ZmnSCPxj > Hi ZmnSCPxj, > > Thank you for your comments. You raise an important point that I should c= larify. > > > 1. In event of a sybil attack, a fullnode will stall and think the blo= ckchain 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 fol= low 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 unsaf= e, > > > but there seems to be no impact on security (only bandwidth). The= only > > > way you can be fooled is if all peers lie to you (Sybil), causing= you > > > to follow a malicious minority chain. But even full nodes (or the > > > committed version of PoW fraud proofs) can be fooled in this way = if > > > they are denied access to the valid most PoW chain. If there are > > > additional security concerns I overlooked, I=E2=80=99d love to he= ar 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 blo= ckchain has no more miners. > > 2. In event of a sybil attack, an SPV, even using this style, will fol= low the false blockchain. > > > > This has some differences when considering automated systems. > > Onchain automated payment processing systems, which use a fullnode, wil= l refuse to acknowledge any incoming payments. > > This will lead to noisy complaints from clients of the automated paymen= t processor, but this is a good thing since it warns the automated payment = 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 blo= ck for, say, 6 hours, could be done, to warn higher-layer management system= s to pay attention. > > While it is sometimes the case that the real network will be unable to = find a new block for hours at a time, this warning can be used to confirm i= f such an event is occurring, rather than a sybil attack targeting that ful= lnode. > > On the other hand, such a payment processing system, which uses an SPV = with PoW fraud proofs, will be able to at least see incoming payments, and = continue to release product in exchange for payment. > > Yet this is precisely a point of attack, where the automated payment pr= ocessing system is sybilled and then false payments are given to the paymen= t processor on the attack chain, which are double-spent on the global conse= nsus chain. > > And the automated system may very well not be able to notice this. > > Regards, > > ZmnSCPxj