public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tejaswi Nadahalli <nadahalli@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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
Date: Thu, 2 Jul 2020 14:39:35 +0200	[thread overview]
Message-ID: <CAAifmAQR2=jSeHBH-GrVsGAOX-qDf-bpKSUJaWEYAdzkmNre4A@mail.gmail.com> (raw)
In-Reply-To: <Fh70O0CqbkbLaOUEqRzIG3MOOZi_tYz69xRDPlIlF5tgTIPdYF9LyeoJjypo-agN9-WkuoXJD896R6CQygTozeHA_CFULp3k7007PioaDrs=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 5935 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 6804 bytes --]

      parent reply	other threads:[~2020-07-02 12:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
2020-06-23  6:41 ` [bitcoin-dev] MAD-HTLC Stanga
2020-06-23  9:48   ` ZmnSCPxj
2020-06-23 12:47     ` Stanga
2020-06-23 13:18       ` Stanga
2020-06-25  1:38         ` ZmnSCPxj
2020-06-25  3:26           ` Nadav Ivgi
2020-06-25  4:04             ` ZmnSCPxj
2020-06-25  4:35               ` Nadav Ivgi
2020-06-25 13:12                 ` Bastien TEINTURIER
2020-06-28 16:41       ` David A. Harding
2020-07-04 21:05         ` ZmnSCPxj
2020-06-28 12:15   ` David A. Harding
2020-06-29 11:57     ` Tejaswi Nadahalli
2020-06-29 18:05     ` ZmnSCPxj
2020-06-30  6:28       ` Stanga
2020-06-30  6:45       ` Tejaswi Nadahalli
2020-07-01 16:58         ` ZmnSCPxj
2020-07-02 12:22           ` Tejaswi Nadahalli
2020-07-02 16:06             ` ZmnSCPxj
2020-07-03  9:43               ` Tejaswi Nadahalli
2020-07-03 10:16                 ` ZmnSCPxj
2020-07-03 10:44                   ` Tejaswi Nadahalli
     [not found]                     ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
2020-07-03 12:38                       ` ZmnSCPxj
     [not found]                         ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
2020-07-04 20:58                           ` ZmnSCPxj
2020-07-05  9:03                         ` Stanga
2020-07-06 11:13                       ` Tejaswi Nadahalli
2020-07-02 12:39           ` Tejaswi Nadahalli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAifmAQR2=jSeHBH-GrVsGAOX-qDf-bpKSUJaWEYAdzkmNre4A@mail.gmail.com' \
    --to=nadahalli@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=matany@campus.technion.ac.il \
    --cc=sitay@campus.technion.ac.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox