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