path: root/0a/67faef36d34bbbb97d840a1ca47dd67f0e7c28

Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E55921A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 19 Apr 2019 03:22:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com
	[209.85.215.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 653AC108
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 19 Apr 2019 03:22:30 +0000 (UTC)
Received: by mail-pg1-f169.google.com with SMTP id f6so2072176pgs.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Apr 2019 20:22:30 -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=8pOETUxtvOmRjp6M6nk95EgpbKswPzy4VvYH5HRwrq8=;
	b=XA64gX8DKP4ard9qUVsG2fUtKSpNLgElVlFXMzNcsslexwm6x3DRcCVEc8Iats3Zqv
	KZtqz3qpObRldpxzdBSlDW34kPwXYaOQMVjKMYPn4D4tCMdnywaRhsqEVEw2k5+9kSWc
	MpvKNBWfnMuBHRODcsTFVbe/MGzEctjLS7wjnD3iHuQio//6xi5E/9XYrQj2M09LboaN
	Q69vWDt/kVDtT+IE+ZUFXUtEkycoaccaHq1mc/1X2W6VIUFOsUJ7o97OOD78MvlbtdjY
	lowe1MC0Q/YKk4AVlCsnzn7e7EJcmuecZ6cYwIUVT1k02JVmsbhqQ2wy9iwJxVZ4WFBp
	wQFg==
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=8pOETUxtvOmRjp6M6nk95EgpbKswPzy4VvYH5HRwrq8=;
	b=OqaV8m/SEELd67nyu3Q5aaX6wqSiw/y9GD0prM9L6gg6dQmDiWIT129CGBK3Ns4Z4a
	Ty5qS+7FuQMd+zg0BmmirGkWwfuGELVxsZiUpObQ9zFtU5aOhfg0WHpXmsJRBv3dnaVM
	4QQHsKOfjsW/F6sL/AH+sOqruxPdCg1n9qcArAn8pdlJCcwdSYh4bqhZATT+pYTX77BD
	Xcbm+R87yq+bAchBn0o633OoIiI2ffoc+/pBuNUe0NaLtqc2wcF06vFbluSz0qtW4C3y
	7LNDRSICbmAVx7kuppSgC1FrWZuMvpNBn8jTbPEvz3xsIynzP/jwXTuyojRqOIKY9rmx
	H2Lg==
X-Gm-Message-State: APjAAAWsb8Q3bSw/1UnZfjEzroFlt9lSruH/EoKNwISnOlZB66CPWFVj
	7UjOqQTk1jBAIqxBUt/2oO2vKVJh7YUACn1J33E=
X-Google-Smtp-Source: APXvYqxteUFTUtmUqIQEZIsmFVPySP+YYr3LNAzzlS0SoUWisFwxUjJqKpW5OhFU4x8HmYFB0ZrZkSUljkq778wlScM=
X-Received: by 2002:a63:f115:: with SMTP id f21mr1570273pgi.65.1555644149604; 
	Thu, 18 Apr 2019 20:22:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjYspkc1M=TKmBK8k0Zy857=bR7jSTarRDCr_5m2ktYHDQ@mail.gmail.com>
	<-tCD0qh97dAiz-VGkDQTwSbSQIm9cLF1kOzaWCnUDTI4dKdsmMgHJsGDntQhABZdE2_yBYpPAAdulm8EpdNxOB8o3lI6ZQJBJZWF1INzUrE=@protonmail.com>
	<CAEM=y+W==_+AW6ga9WMf=aAX-xPGUfhEJQFvUtdFodGGv-6eAg@mail.gmail.com>
	<xqVUmHu0RXeogboFL8ivsZywPQKEqLCsUZTV1NbsxNB4CYqrNqS8TpYsP8PJSowIGUeq8Nu1XPVd9N9Exg5Is11767ytI0Sq4lVp9MGdII4=@protonmail.com>
	<CAEM=y+WVQz5x916sjCjWVmeEbRp4NoTyryxSH7uKNTHYz+Sdnw@mail.gmail.com>
	<xNr214GpQ7_9duD4RV0j2nufLLMff4ipqPcZEAsDIsjLwWDan9UijTADW0iJ76pUuaXgYth_BHla-p6G3SOksaySbDZXKhQPLvIfLqo0JeA=@protonmail.com>
In-Reply-To: <xNr214GpQ7_9duD4RV0j2nufLLMff4ipqPcZEAsDIsjLwWDan9UijTADW0iJ76pUuaXgYth_BHla-p6G3SOksaySbDZXKhQPLvIfLqo0JeA=@protonmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Thu, 18 Apr 2019 23:21:53 -0400
Message-ID: <CAEM=y+V0tMYBBLJhePfGUzyFNXVe9hr0F3QrX9JYFrDg5N1qXg@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: Fri, 19 Apr 2019 13:57:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 <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: Fri, 19 Apr 2019 03:22:31 -0000

Good morning to you as well ZmnSCPxj,

My above email contains an error. The SPV client needs to only
download S+1, not S+1 and S+2.

I agree with you that a weakness of this approach is a miner can make
SPV clients do substantially more work. However:

1. Mining a block which will never be accepted is an expensive way to
make SPV clients download, validate and discard ~2-4 megabytes of
data. There are far less expensive ways of wasting the resources of
SPV clients. Its unclear why someone would want to do this instead of
just packeting full nodes or SPV servers like we saw with the recent
DDoS attacks against electrum servers.

2. SPV clients may not even learn about these splits because it
requires that someone relay the split to them. Honest full nodes
should not relay such splits. To their bitcoin's worth the attacker
must also connect to lots of SPV clients.

3. Having SPV clients slow down or become full nodes when a malicious
miner with significant mining power is attempting to disrupt the
network is probably a best case outcome. I would prefer this failure
mode to the current SPV behavior which is to just go with the
"longest" chain.

Thanks,
Ethan

On Thu, Apr 18, 2019 at 10:53 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Ethan,
>
> Thank you for clarifying, I understand better now.
>
> It seems that minority miners can disrupt SPV clients such that SPV clien=
ts will download 2 blocks for every block the minority miner can find, not =
1.
>
> This can be done by simply making multiple 1-block chainsplits, rather th=
an a single persistent chainsplit, and alternating split-off and non-split-=
off.
>
> For instance, such a minority miner might split at S+1, forcing SPV clien=
ts to download S+1 and S+2.
> Then the minority miner splits at S+3, forcing SPV clients to download S+=
3 and S+4.
> With a mere 33% hashrate, this can force SPV clients to download every bl=
ock, i.e. become a fullnode anyway.
>
> Since there exist pools with >33% hashrate, the above attack is possible =
so the only solution is to become a fullnode anyway.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Friday, April 19, 2019 9:13 AM, Ethan Heilman <eth3rs@gmail.com> wrote=
:
>
> > Hi ZmnSCPxj,
> >
> > Let's see if I understand what you are saying. In your scenario chain
> > A consists of honest miners (10% of the hash rate) and chain B (90%
> > of the hash rate) consists of dishonest miners who are inflating the
> > coin supply.
> >
> > Chain A: S, S+1
> > Chain B: S, S+1 (invalid), S+2, S+3, S+4, S+5, S+6, S+7, S+8, S+9
> >
> > Chain B S+1 has a invalid coinbase
> >
> > > At around height S+9, the minority miners generate an alternate block=
 at height S+1. So SPV nodes download S+9 and S+8 on the longer chain, and =
see nothing wrong with those blocks.
> >
> > What I am suggesting is that when the minority miners generate an
> > alternate block at S+1 (chain A) the SPV node would download blocks
> > S+1 and S+2 from chain B (the dishonest chain). Since S+1 has the
> > invalid coinbase the SPV node would learn that chain B is invalid and
> > abandon it.
> >
> > Bitcoin is in big trouble if a malicious party controls 90% of the
> > mining power. The malicious miners can spend +11% of their mining
> > power ensuring that the honest chain never reaches consensus by
> > continuously forking it. The malicious miners can then extend their
> > favored chain using the other 79% of the mining power. This would
> > produce a scenario in which users are forced to choose between a
> > stable chain that violates a consensus rule and an unstable honest
> > chain that is completely unusable and which never pays out mining
> > rewards. I agree that SPV nodes and many wallets would make this even
> > worse especially in their current condition where they just trust the
> > hash rate/wallet provider and there are no fraud proofs.
> >
> > On Thu, Apr 18, 2019 at 8:25 PM ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> >
> > > Good morning Ethan,
> > > Sent with ProtonMail Secure Email.
> > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origi=
nal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> > > On Friday, April 19, 2019 4:12 AM, Ethan Heilman eth3rs@gmail.com wro=
te:
> > >
> > > > I'm probably repeating a point which has been said before.
> > > >
> > > > > I suppose a minority miner that wants to disrupt the network coul=
d simply create a valid block at block N+1 and deliberately ignore every ot=
her valid block at N+1, N+2, N+3 etc. that it did not create itself.
> > > >
> > > > If this minority miner has > 10% of network hashrate, then the rule=
 of
> > > > thumb above would, on average, give it the ability to disrupt the
> > > > SPV-using network.
> > > > Proposed rule:
> > > > Whenever a chainsplit occurs SPV clients should download and valida=
te
> > > > the "longest chain" up to more than one block greater than the heig=
ht
> > > > of the losing chain.
> > > > Lets say a block split causes chain A and chain B: Chain A is N blo=
cks
> > > > long, chain B is M blocks long, and N < M. Then the SPV client shou=
ld
> > > > download all the block data of N+1 blocks from Chain B to verify
> > > > availability of chain B. Once the SPV client has verified that chai=
n B
> > > > is available they can use fraud proofs determine if chain B is vali=
d.
> > >
> > > Let us then revert to the original scenario.
> > > Suppose a supermajority (90%) of miners decide to increase inflation =
of the currency.
> > > They do this by imposing the rule:
> > >
> > > 1.  For 1 block, the coinbase is 21,000,000 times the pre-fork coinba=
se value.
> > > 2.  For 9 blocks, the coinbase is the pre-fork value.
> > > 3.  Repeat this pattern every 10 blocks.
> > >
> > > The above is a hardfork.
> > > However, as they believe that SPV nodes dominate the economy, this mi=
ning supermajority believes it can take over the network hashpower and impo=
se its will on the network.
> > > At height S+1, they begin the above rule.
> > > This implies that at heights S+1, S+11, S+21, s+31... the coinbase vi=
olates the pre-hardfork rules.
> > > At around height S+9, the minority miners generate an alternate block=
 at height S+1.
> > > So SPV nodes download S+9 and S+8 on the longer chain, and see nothin=
g wrong with those blocks.
> > > At around height S+18, the minority miners generate an alternate bloc=
k at height S+2.
> > > So SPV nodes download S+18, S+17, S+16 and again see nothing wrong wi=
th those blocsk.
> > > This can go on for a good amount of time.
> > > With a "rare enough" inflation event, miners may even be able to spen=
d some coinbases on SPV nodes that SPV nodes become unwilling to revert to =
the minority pre-hardfork chain, economically locking in the post-hardfork =
inflation.
> > > Again: every rule is an opportunity to loophole.
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > An attacker could use this to force SPV clients to download 1 block
> > > > per block the attacker mines. This is strictly weaker security than
> > > > provided by a full-node because chain B will only be validated if t=
he
> > > > client knows chain A exists. If the SPV client's view of the
> > > > blockchain is eclipsed then the client will never learn that chain =
A
> > > > exists and thus never validate chain B's availability nor will the
> > > > client be able to learn fraud proofs about chain B. A full node in
> > > > this circumstance would notice that the chain B is invalid and reje=
ct
> > > > it because a full node would not depend on fraud proofs. That being
> > > > said this rule would provide strictly more security than current SP=
V
> > > > clients.
> > > > On Thu, Apr 18, 2019 at 3:08 PM ZmnSCPxj via bitcoin-dev
> > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > >
> > > > > Good morning Ruben,
> > > > > Sent with ProtonMail Secure Email.
> > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 O=
riginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=
=80=90
> > > > > On Thursday, April 18, 2019 9:44 PM, Ruben Somsen via bitcoin-dev=
 bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > >
> > > > > > Simplified-Payment-Verification (SPV) is secure under the assum=
ption
> > > > > > that the chain with the most Proof-of-Work (PoW) is valid. As m=
any
> > > > > > have pointed out before, and attacks like Segwit2x have shown, =
this is
> > > > > > not a safe assumption. What I propose below improves this assum=
ption
> > > > > > -- invalid blocks will be rejected as long as there are enough =
honest
> > > > > > miners to create a block within a reasonable time frame. This s=
till
> > > > > > doesn=E2=80=99t fully inoculate SPV clients against dishonest m=
iners, but is a
> > > > > > clear improvement over regular SPV (and compatible with the pri=
vacy
> > > > > > improvements of BIP157[0]).
> > > > > > The idea is that a fork is an indication of potential misbehavi=
or --
> > > > > > its block header can serve as a PoW fraud proof. Conversely, th=
e 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 dis=
agree
> > > > > > on the validity of block N+1. If SPV clients download and verif=
y this
> > > > > > block, they can judge for themselves whether or not the chain s=
hould
> > > > > > be rejected. Of course it could simply be a natural fork, in wh=
ich
> > > > > > case we continue following the chain with the most PoW.
> > > > >
> > > > > I presume you mean a chain split?
> > > > >
> > > > > > 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 i=
t) is
> > > > > > valid. This would change with the introduction of UTXO set
> > > > > > commitments, allowing block N+1 to be validated by verifying wh=
ether
> > > > > > 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 h=
onest,
> > > > > > on average it would take 100 minutes for a valid block to appea=
r.
> > > > > > 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 percen=
tage of
> > > > > > miners that you think may behave honestly to create a block (in=
cluding
> > > > > > variance).
> > > > >
> > > > > I suppose a minority miner that wants to disrupt the network coul=
d simply create a valid block at block N+1 and deliberately ignore every ot=
her valid block at N+1, N+2, N+3 etc. that it did not create itself.
> > > > > If this minority miner has > 10% of network hashrate, then the ru=
le of thumb above would, on average, give it the ability to disrupt the SPV=
-using network.
> > > > >
> > > > > > 10% of network hashrate to disrupt the SPV-using nodes would be=
 a rather low bar to disruption.
> > > > > > Consider that SPV-using nodes would be disrupted, without this =
rule, only by >50% network hashrate.
> > > > >
> > > > > It is helpful to consider that every rule you impose is potential=
ly a loophole by which a new attack is possible.
> > > > > Regards,
> > > > > ZmnSCPxj
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>