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
>
>