path: root/cb/c53437670b7f954c5053596febaf9cb4726e3e

Return-Path: <nadahalli@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18683C0733
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Jul 2020 12:39:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 06B768B109
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Jul 2020 12:39:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bhLrQzJgG7m1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Jul 2020 12:39:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com
 [209.85.216.53])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 960C58B100
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Jul 2020 12:39:47 +0000 (UTC)
Received: by mail-pj1-f53.google.com with SMTP id k5so2913825pjg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 02 Jul 2020 05:39:47 -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; bh=hGXay054trJXozytVBO9Q/dG6D81T9uuLFVg04YxTAM=;
 b=BNmdaRm+KR5kXLWj/e5MO7jQaqONpY7G2P2bfgckqI1ukytA+y7SL2x0RPFcCBPsiP
 7+4xMfx5+fYtNQCmPmIPD0qNOcDCTXRE8ANPhbvpi4vQBCBtrusmQOkGCu+UZBUi5dry
 Cx8osTN+Py9gmuyTDiEQ12U+SrsPGBujUo7BSHQd+qtmhDVlIOnxl/n3IFrFMF34kwKz
 iF4OfXXLgvE+5TyrSYzRT7kZyH4jn5TqlF6cyrsnyMThrMmDTfsViG8VqGcIuLcWN1h2
 O2QwMmBgCiUgQrCOp2tPmJiq+BO0MrYaGBp4DnDo+mg4s1zZNttJRf+ABdJyaWdW2clg
 aFdg==
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;
 bh=hGXay054trJXozytVBO9Q/dG6D81T9uuLFVg04YxTAM=;
 b=LSTUBd/OYuixkqfbPBZpIPFPkOFUosnHs92AtazSSqedmK3D/Ki7yJwLtKNLHuOAUc
 ly02K0caKCVRwgB7LjvkQMD/SgErLKKFQv2VBjyO/TkfaVqerAV5+jCERYzWnF9CK6bz
 PIOBdXZFURIS2NfIjto9bnd5jtKdrMqq5cdvO7BUruFeKZsWP5CihhP2EoIHNctcAJOz
 mRXERaToMe8SWSepnYVYYEwMBvwBLfgJoisUxDz/EqKxU0Yap6Y53eKR+jIMrLIfQRI5
 QM1VXOKw+XRhBGYTB7lHF1y3de49GXKyZNIfM+Gc9EQ6K3gOmrMV9/VRvBxVy7UG3crW
 2dGw==
X-Gm-Message-State: AOAM530GuGD1Q1tyLVyMGOM5LrVUIaBFlGBo0aFs3MD+I0xZ6uxFxRYt
 b9kU8GPGEardvDG3UE1bEoyYwug8UJbwc00Gw8A=
X-Google-Smtp-Source: ABdhPJzA7vKNI+KF+NdwVGsO3cdAKFaZvgwAB9iugN2zHxLLpp/0rr0Ig22cwyIXn7jBrD153ZoFooS2if9dwgXaDGE=
X-Received: by 2002:a17:90a:2681:: with SMTP id
 m1mr16114062pje.204.1593693587095; 
 Thu, 02 Jul 2020 05:39:47 -0700 (PDT)
MIME-Version: 1.0
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
 <20200628121517.f3l2mjcy7x4566v3@ganymede>
 <WYQRrIi65yvBWc9qsqCxHWadrMFtYPh2wI-IzVS15FBTFmpIXqHwj5yrj3Igpr-9sKygWsH4DkI_maWcULKKQb51Xp_xZBvKuPF_HmCvqb4=@protonmail.com>
 <CAAifmATmQSUUsEbouVYTNNMu-BT8vQiGvh3jwLNK4CUB11s7mg@mail.gmail.com>
 <Fh70O0CqbkbLaOUEqRzIG3MOOZi_tYz69xRDPlIlF5tgTIPdYF9LyeoJjypo-agN9-WkuoXJD896R6CQygTozeHA_CFULp3k7007PioaDrs=@protonmail.com>
In-Reply-To: <Fh70O0CqbkbLaOUEqRzIG3MOOZi_tYz69xRDPlIlF5tgTIPdYF9LyeoJjypo-agN9-WkuoXJD896R6CQygTozeHA_CFULp3k7007PioaDrs=@protonmail.com>
From: Tejaswi Nadahalli <nadahalli@gmail.com>
Date: Thu, 2 Jul 2020 14:39:35 +0200
Message-ID: <CAAifmAQR2=jSeHBH-GrVsGAOX-qDf-bpKSUJaWEYAdzkmNre4A@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000023c2da05a974b40a"
X-Mailman-Approved-At: Thu, 02 Jul 2020 13:29:09 +0000
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Jul 2020 12:39:49 -0000

--00000000000023c2da05a974b40a
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Another analysis, similar but a little off-tangent to yours, would be to
> consider miners as a breeding group with various strategies, and see which
> one is able to gain more utilons (with which it creates more miners) and
> outbreed the other miners.
>
> This models the fact that miners can use their earnings to reinvest into
> their mining operations and increase their mining hashrate, and the amount
> they can reinvest is proportional to their earnings.
> A miner that "gives birth" to a child miner with the same strategy is, in
> the so-called "real world", simply a miner that has earned enough and
> reinvested those earnings to double the hashrate of their business (which,
> logically speaking, would use the same strategy throughout the entire
> business).
>
> Let us start with a population of 4 miners, 3 of which follow the
> non-myopic strategy, and the remaining following the myopic strategy.
> Let us postulate that all miners have the same unit hashrate.
> Thus, this starting population is 75% non-myopic, 25% myopic.
>
> If there exists a timelocked bribe, then if non-myopic miner is chosen at
> a block, it will have to sacrifice the Alice fee minus whatever lesser
> transaction fee it can replace in its block.
> If the Alice transaction is successfully delayed until the Bob transaction
> is valid, then the non-myopic miners can get the Bob transaction confirmed.
>
> However, even in the case that the Alice transaction is delayed, the
> myopic miner still has its 25% chance --- equal to the 25% chance of the
> three non-myopic miners --- to confirm the Bob transaction and earn the
> increased bribe that Bob offers.
>
> Thus, the non-myopic miners can end up sacrificing fee earnings, and in
> the end the myopic miner still has the 25% chance to get the Bob
> transaction fee later when it becomes valid.
> So the non-myopic miners do not impose any loss on myopic miners.
>
> On the other hand, if the non-myopic miners sacrificed their chances to
> include the Alice transaction in the hope of getting the later 25% chance
> to get the Bob higher-fee timelocked transaction, and then the myopic miner
> gets the next block, the myopic miner gets the Alice transaction confirmed
> and the 25% chance to get the Bob higher fee is lost by the non-myopic
> miners.
> Thus, the myopic miner is able to impose costs on their non-myopic
> competitors.
>
> So even if by chance for the entire locktime, only the non-myopic miners
> are selected, the myopic miner still retains its 25% chance of getting the
> block at locktime + 1 and confirming and earning the bigger Bob fee.
>
> Thus, we expect that the myopic miner will earn more than 25% of subsidies
> and fees than the non-myopic miners, in such a mixed environment.
>

This is exactly our analysis, and is covered in section 2.5 of our paper.
We formalize the ideas a bit more, and are able to relate the values of
Alice-fee, Bob-bribe, timelock, and miner's hashpower percentage. We go a
bit further into #reckless territory as well - reducing the timelock value
to super low values. That's in Algorithm #1 of our paper, and is a bit more
involved.


>
> We can then consider that the myopic miner, being able to earn more, is
> able to increase its progeny (i.e. expand its mining business and inspire
> new miners to follow its strategy towards success) faster than the
> non-myopic miners.
>
> We can thus conclude that the myopic miners will eventually dominate over
> the breeding population and drive the non-myopic miners to near-extinction.
>

This is an interesting direction that we chose to not look at. Like the
MAD-HTLC authors, we assume a constant hash-rate distribution across time,
which is obviously not a great assumption. It might work in the local
context of an HTLC's timelock, but in our approach, we are also interested
in *weak* miners, and finding them across 1000's of blocks might get tricky.


> It is helpful to remember that rationality is about success *in the
> universe you exist in*.
> While miners may step back and consider that, ***if*** all of them were to
> use non-myopic strategy, they would all earn more, the fact of the matter
> is that each miner works for themselves, and themselves alone, in a highly
> competitive environment.
> Thus, even though they know *all of them* will benefit if they use the
> non-myopic strategy, they cannot be sure, unless they are all perfectly
> synchronized mind-clones of each other, that the other miners will rather
> be selfish and mine for themselves, even if in the end every miner earns
> less
> The standard for success is to earn more *than your competitors*, not
> ensure that *every* miner earns more.
>
> Fortunately, since miners are running a business, this competition leads
> to better services to the the customers of the mining business, a known
> phenomenon of the free market, yay free market greed is good.
> The user Alice is a customer of the mining business.
> Alice gets, as a side effect of this competitiveness of miners (which
> leads to miners adopting myopic strategies in order to gain an edge over
> non-myopic miners), improved security of their HTLCs without requiring
> slashable fidelity bonds or such-like that MAD-HTLC proposes.
>

Yes. And in the context of Lightning, both Alice and Bob need to have
fidelity bonds, which triples the already bad channel-lockin cost.


> Using this model, it seems to me that non-myopic miners can only maintain
> hold over the blockchain if all miners agree to use non-myopic strategy.
> This is basically all miners forming a cartel / monopoly, which we know is
> detrimental to customers of the monopoly, and is the reason why we prefer
> decentralization.
>

If miners form a cartel and get to 51%, we are all doomed anyway.

Thanks for the detailed reply. And apologies for splitting my email into
two parts.

--00000000000023c2da05a974b40a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj &=
lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&g=
t; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Another analysis, similar but a little off-tangent to =
yours, would be to consider miners as a breeding group with various strateg=
ies, and see which one is able to gain more utilons (with which it creates =
more miners) and outbreed the other miners.<br>
<br>
This models the fact that miners can use their earnings to reinvest into th=
eir mining operations and increase their mining hashrate, and the amount th=
ey can reinvest is proportional to their earnings.<br>
A miner that &quot;gives birth&quot; to a child miner with the same strateg=
y is, in the so-called &quot;real world&quot;, simply a miner that has earn=
ed enough and reinvested those earnings to double the hashrate of their bus=
iness (which, logically speaking, would use the same strategy throughout th=
e entire business).<br>
<br>
Let us start with a population of 4 miners, 3 of which follow the non-myopi=
c strategy, and the remaining following the myopic strategy.<br>
Let us postulate that all miners have the same unit hashrate.<br>
Thus, this starting population is 75% non-myopic, 25% myopic.<br>
<br>
If there exists a timelocked bribe, then if non-myopic miner is chosen at a=
 block, it will have to sacrifice the Alice fee minus whatever lesser trans=
action fee it can replace in its block.<br>
If the Alice transaction is successfully delayed until the Bob transaction =
is valid, then the non-myopic miners can get the Bob transaction confirmed.=
<br>
<br>
However, even in the case that the Alice transaction is delayed, the myopic=
 miner still has its 25% chance --- equal to the 25% chance of the three no=
n-myopic miners --- to confirm the Bob transaction and earn the increased b=
ribe that Bob offers.<br>
<br>
Thus, the non-myopic miners can end up sacrificing fee earnings, and in the=
 end the myopic miner still has the 25% chance to get the Bob transaction f=
ee later when it becomes valid.<br>
So the non-myopic miners do not impose any loss on myopic miners.<br>
<br>
On the other hand, if the non-myopic miners sacrificed their chances to inc=
lude the Alice transaction in the hope of getting the later 25% chance to g=
et the Bob higher-fee timelocked transaction, and then the myopic miner get=
s the next block, the myopic miner gets the Alice transaction confirmed and=
 the 25% chance to get the Bob higher fee is lost by the non-myopic miners.=
<br>
Thus, the myopic miner is able to impose costs on their non-myopic competit=
ors.<br>
<br>
So even if by chance for the entire locktime, only the non-myopic miners ar=
e selected, the myopic miner still retains its 25% chance of getting the bl=
ock at locktime + 1 and confirming and earning the bigger Bob fee.<br>
<br>
Thus, we expect that the myopic miner will earn more than 25% of subsidies =
and fees than the non-myopic miners, in such a mixed environment.<br></bloc=
kquote><div><br></div><div>This is exactly our analysis, and is covered in =
section 2.5 of our paper. We formalize the ideas a bit more, and are able t=
o relate the values of Alice-fee, Bob-bribe, timelock, and miner&#39;s hash=
power percentage. We go a bit further into #reckless territory as well - re=
ducing the timelock value to super low values. That&#39;s in Algorithm #1 o=
f our paper, and is a bit more involved.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
<br>
We can then consider that the myopic miner, being able to earn more, is abl=
e to increase its progeny (i.e. expand its mining business and inspire new =
miners to follow its strategy towards success) faster than the non-myopic m=
iners.<br>
<br>
We can thus conclude that the myopic miners will eventually dominate over t=
he breeding population and drive the non-myopic miners to near-extinction.<=
br></blockquote><div><br></div><div>This is an interesting direction that w=
e chose to not look at. Like the MAD-HTLC authors, we assume a constant has=
h-rate distribution across time, which is obviously not a great assumption.=
 It might work in the local context of an HTLC&#39;s timelock, but in our a=
pproach, we are also interested in *weak* miners, and finding them across 1=
000&#39;s of blocks might get tricky.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">It is helpful to remember that rationali=
ty is about success *in the universe you exist in*.<br>
While miners may step back and consider that, ***if*** all of them were to =
use non-myopic strategy, they would all earn more, the fact of the matter i=
s that each miner works for themselves, and themselves alone, in a highly c=
ompetitive environment.<br>
Thus, even though they know *all of them* will benefit if they use the non-=
myopic strategy, they cannot be sure, unless they are all perfectly synchro=
nized mind-clones of each other, that the other miners will rather be selfi=
sh and mine for themselves, even if in the end every miner earns less<br>
The standard for success is to earn more *than your competitors*, not ensur=
e that *every* miner earns more.<br>
<br>
Fortunately, since miners are running a business, this competition leads to=
 better services to the the customers of the mining business, a known pheno=
menon of the free market, yay free market greed is good.<br>
The user Alice is a customer of the mining business.<br>
Alice gets, as a side effect of this competitiveness of miners (which leads=
 to miners adopting myopic strategies in order to gain an edge over non-myo=
pic miners), improved security of their HTLCs without requiring slashable f=
idelity bonds or such-like that MAD-HTLC proposes.<br></blockquote><div><br=
></div><div>Yes. And in the context of Lightning, both Alice and Bob need t=
o have fidelity bonds, which triples the already bad channel-lockin cost.=
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
Using this model, it seems to me that non-myopic miners can only maintain h=
old over the blockchain if all miners agree to use non-myopic strategy.<br>
This is basically all miners forming a cartel / monopoly, which we know is =
detrimental to customers of the monopoly, and is the reason why we prefer d=
ecentralization.<br></blockquote><div><br></div><div>If miners form a carte=
l and get to 51%, we are all doomed anyway.</div><div><br></div><div>Thanks=
 for the detailed reply. And apologies for splitting my email into two part=
s.</div></div></div>

--00000000000023c2da05a974b40a--