path: root/57/2c6010b849d069b95ff2b0b0780e2f063e1767

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 23E4315ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 20 Jul 2019 00:45:44 +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 B6B02E6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 20 Jul 2019 00:45:42 +0000 (UTC)
Date: Sat, 20 Jul 2019 00:45:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1563583539;
	bh=4uODFFz3ZuxmAeZkkGtMS0Y79nw1yrKIK5q/1Qk8ZH8=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=emIA7TKsmpDoyRzwkbLdrOBGPJbWsdHW+vYCjs9FFN9RrK8SHkLDxX+sS5NdShmHW
	2hloT2sYwSn869pWEzsdRlspnOUdWnvzcx7TqdZ3tg2lu5svjqw/zwlE76olpVScz8
	tR/19nRjrtrADZ5AezFenIijIKQ8OSrps0UXa1jg=
To: "Kenshiro []" <tensiam@hotmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <zs4_imeOmpTHJLNyl90kuY8HWoLEjgmCcims6fESt2Fg5goLfUdcKdcPIsKCWRfojPifaNfg5XKi24fwAIRW_LUnAz-yzwOA6S362R4g5RA=@protonmail.com>
In-Reply-To: <DB6PR10MB1832EF2ACF6539E03494A381A6CB0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
	<DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>,
	<brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
	<DB6PR10MB183268A7D3C744B1269E46EAA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com>
	<DB6PR10MB1832C21C602126F797132A4AA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<hv2EyhKHfNd-TmH2j-8jLFWw6nUMYHOsNF_5Vy-eZLQLessR9Quy4uXn8ZVYLK4dZrwcVq3QeCcEXdCHPOJ0tgya5P34S1seEAGSRyPYpks=@protonmail.com>
	<DB6PR10MB1832EF2ACF6539E03494A381A6CB0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.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,
	LOTS_OF_MONEY, 
	RCVD_IN_DNSWL_LOW,T_MONEY_PERCENT 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: Sat, 20 Jul 2019 03:25:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
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: Sat, 20 Jul 2019 00:45:44 -0000

Good morning Kenshiro,

> >>>=C2=A0I already told you that it is always possible to get around this=
: leverage by use of short options.
> Short the coin to attack, then perform your attack by censorship.
> Coin value will drop due to reduced utility of the coin, then you reap th=
e rewards of the short option you prepared beforehand.
> By this, you can steal the entire marketcap of the coin.
>
> >>>Then you still have the economic power (plus what you managed to steal=
), which you can then use to take over another proof-of-stake coin, regardl=
ess of whether it uses the same proof-of-stake algorithm or not.
>
> My trading level is very basic and I don't understand this attack

A short option is an option to force another party to buy an asset at a set=
 price (the contract price) on a future date.
In order to get that option, you first pay that party today, a fee called "=
premium" (usually a small fraction of the contract price).

The effect is that, at that future date, if the asset is ***lower*** in pri=
ce than the contract price, you earn by buying it at the market price, then=
 force the party to buy it at the contract price, earning the difference.
The other party, in order to mitigate its loss, then sells the asset back t=
o the market at market price.
(in practice, nobody goes through the rigmarole of buying, forcing the trad=
e, then selling, instead the other party just outright gives you the differ=
ence in contract price vs market price).

However, if at that future date, the asset is ***higher*** in price than th=
e contract price, there is no rational reason for you to buy it at market p=
rice, then force the other party to buy at the contract price, as you would=
 lose money.
As this is an option for you, not an obligation, you can simply ignore the =
option and not take it.
However, do note that you did pay the premium when you bought the option, s=
o you lose out on that.

Short options are often used by producers of a good in order to hedge their=
 losses, i.e. insurance against changes in market price.
For example, a farmer might purchase such an option, with a maturity date a=
t the harvest season, for the price of wheat.
The farmer would buy an option whose contract price is the price at the thr=
eshold of profitability, i.e. if the price falls below the contract price t=
he farmer would lose money relative to their investment.
If the price of wheat drops below the contract price, the farmer earns from=
 the short option, reducing the impact of the low price.
If the price of wheat is above the contract price, the farmer still earns f=
rom sale of the wheat, and only loses on the (comparatively small) premium =
of the option.

A short option can be leveraged by those with inside knowledge as an econom=
ic attack.
For example, if you are capable of disrupting a coin such that its value is=
 very likely to drop, you can buy short options as leverage.
Suppose you hold a large stake of coins and know you control a significant =
fraction, enough that a censorship attack by you will be so disruptive that=
 the coin price will drop.
You take out a short contract with the contract price at the "hopium" level=
 others have (say 10% higher), buying enough options that you can cover the=
 current price of your owned stake, plus some more options.
Suppose you buy, a number of options equal to twice your stake.

Then you attack the coin, dropping its price by 90% instead of the expected=
 10% price increase, earning the difference from the short option, about eq=
ual to the price of the coin.
Since you bought twice the number of options as your stake, you get about t=
wice the value of your stake in earnings from the short option.
You have recouped the cost of your stake and would not care if it was burne=
d, and now are holding twice the value of your original stake in a differen=
t asset, probably fiat.
You then move on and attack the next coin.

The only protection against this is to make sure that block generators cann=
ot feasibly attack the coin, such as by proof-of-work.
Short options are much too useful otherwise to the block generators, as it =
allows them to hedge against drops in market price, and keeps them operatin=
g rather than reducing the security of the coin, thus short options will in=
evitably arise.

> >>>=C2=A0But your proposal of being non-linear on the size of the stake m=
eans that if you have 51% of the coins, if you put them in a single stake U=
TXO you potentially get 99.999% of the blocks, which is ***much worse***.
>
> Not at all, I forgot to tell you that in modern=C2=A0PoS protocols like P=
oS v3.0 staking deposits have to wait many blocks after creating a block to=
 be able to create another block.
>
> With my additional rule every staker is incentivized to put their staking=
 deposit in a single address to avoid a strong penalty in their staking wei=
ght, and having their coins together they can't avoid the wait time with th=
e=C2=A0"stake in many addresses" trick =F0=9F=99=82

*facepalm*

Let's suppose there are two big whales in your coin.
Each of them owns 50% of the total staked value.
Let's say "wait many blocks" parameter is 100 blocks.

One whale puts all his coin in a single UTXO.
The other has distributed his stake in 100,000 different UTXOs.

The honest single-UTXO whale gets a block, because his stake dominates over=
 all others.
Then he gets banned from signing blocks for 100 blocks.
During this ban, the other whale gets every block, as his only competitor i=
s banned.
In addition, banning one of its 100,000 UTXOs is not much reducing his effe=
ctive stake-weight.
So the honest single-UTXO whale gets 1 block (and its rewards) while the on=
e who distributed his coins to 100,000 different UTXOs gets 100 blocks.

You have just let someone who could *just barely* 51% attack without those =
rules, 99% attack *with* those rules.

If you had added neither of the two new rules "non-linear stake weights" an=
d "ban for many blocks", you would have gotten both of them at 50% control =
only, which while concerning, is not as bad as a 99% attack.

Now suppose the one with the 99% control performs a censorship attack.
After a week (1008 blocks) the community rallies and hardforks, burning the=
 UTXOs that performed censorship.
However, only about 998 UTXOs of the censoring staker is known (from the 99=
% of blocks it generated in that period), which is less than 1% of the 100,=
000 UTXOs he actually owns, and thus still controls a significant stake eve=
n past the hardfork, letting it perform further censorship attacks.

You should stop adding even more rules at this point.

An experienced engineer will stop at this point, delete all his or her file=
s related to the current design (or move them to some archive space, some e=
ngineers are compulsive archivists), then regenerate the design from princi=
ples up.

A rule-of-thumb in any security design is that, when you add something to p=
rotect against some attack, you probably just added an attack vector that i=
s the inverse of the attack you were protecting against.
Thus, adding more rules is rarely the optimal thing to do.

You added two rules, one fixing the original attack (splitting your stake) =
but inviting the opposite attack (merging your stake), then added another r=
ule to fix the second attack (merging your stake), bringing back the origin=
al attack (splitting your stake), except worse.
This is the other rule-of-thumb in any design: adding more things usually j=
ust makes things worse.

>
> >>>=C2=A0We hope to see you back soon after having learned your lesson.
>
> Thx=C2=A0=F0=9F=99=82

You are welcome.

>
> Just an additional question: do you have an estimation of the energy wast=
e of PoW if Bitcoin price rises a lot, like one million dollars or more? Be=
cause if it's proportional to the price, it could be like 100 times the cur=
rent energy waste.

Yes.

0.

This is because we expect market forces to move miners towards efficiency, =
thus they will not waste energy, only spend exactly enough to maintain the =
security of the coin.

We already know that miners are setting up mines at locations where energy =
is being wasted (e.g. oil well gas flares, putting up solar panels instead =
of just letting sunshine pointlessly heat up their roofs, etc.), and channe=
ling the wasted energy into productive activity.
This is the opposite of becoming more energy-wasteful.
Thus does the invisible hand of the free market abide.



Regards,
ZmnSCPxj