public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	 Daniele Pinna <daniele.pinna@gmail.com>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
Date: Sun, 11 Dec 2016 10:21:01 +0100	[thread overview]
Message-ID: <CALqxMTGHBhyBMPfdUid_W9tYafk5pGbKPP6LTdQbCmbAHLSURQ@mail.gmail.com> (raw)
In-Reply-To: <CAEgR2PEuZBZqUJ-qehBpk8dL8U-F5z9mZAn-UuRwUXiUSOcXRQ@mail.gmail.com>

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

Well I think empirical game-theory observed on the network involves more
types of strategy than honest vs dishonest.  At least 4, maybe 5 types of
strategy and I would argue lumping the strategies together results in
incorrect game theory conclusions and predictions.

A) altruistic players (protocol following by principle to be good network
citizens, will forgo incremental profits to aid network health) eg aim to
decentralize hashrate, will mine stuck transactions for free, run pools
with zero fee, put more effort into custom spam filtering, tend to be power
users, or long term invested etc.

B) honest players (protocol following but non-altruistic or just
lazy/asleep run default software, but still leaving some dishonest profit
untaken). Eg reject spy mining, but no charitable actions, will not
retaliate in kind to semi-honest zero sum attacks that reduce their profits.

C) semi-honest (will violate protocol if their attack can be plausibly
deniable or argued to be not hugely damaging to network security). Eg spy
mining, centralised pools increasing other miners orphan rates.

D) rational players (will violate the protocol for profit: will not overtly
steal from users via double spends, but anything short particularly
disadvantaging other miners even if it results in centralisation is treated
as fair game) eg selfish mining. Would increase block size by filling with
pay to self transactions, if it increased orphans for others.

E) dishonest players (aka hyper-rational: will actually steal from users
probabilistically if possible, not as worried about detection). Eg double
spend and probabilistic double spends (against onchain gambling games).
Would DDoS competing pools.

In part the strategies depend on investment horizon, it is long term
rational for altruistic behavior to forgo incremental short term profit to
improve user experience.  Hyper-rational to buy votes in a "ends justify
means" mentality though fortunately most network players are not dishonest.

So called meta-incentive (unwillingness to risk hurting bitcoin due to
intended long term ho dling coins or ASICs) can also explain bias towards
honest or altruistic strategies.

Renting too much hashrate is risky as it can avoid the meta-incentive and
increase rational or dishonest strategies.

In particular re differentiating from 51% attack so long as > 50% are
semi-honest, honest or altruistic it won't happen.  It would seem actually
that > 66-75% are because we have not seen selfish mining on the network.
Though I think conveniently slow block publication by some players in the
60% spy mining semi-honest cartel was seen for a while, the claim has been
it was short-lived and due to technical issue.

It would be interesting to try to categorise and estimate the network %
engaging in each strategy.  I think the information is mostly known.

Adam

On Dec 11, 2016 03:22, "Daniele Pinna via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> How is the adverse scenario you describe different from a plain old 51%
> attack? Each proposed protocol change  where 51% or more  of the network
> can potentially game the rules and break the system should be considered
> just as acceptable/unacceptable as another.
>
> There comes a point where some form of basic honesty must be assumed on
> behalf of participants benefiting from the system working properly and
> reliably.
>
> Afterall, what magic line of code prohibits all miners from simultaneously
> turning all their equipment off...  just because?
>
> Maybe this 'one':
>
> "As long as a majority of CPU power is controlled by nodes that are not
> cooperating to attack the network, they'll generate the longest chain and
> outpace attackers. The network itself requires minimal structure."
>
> Is there such a thing as an unrecognizable 51% attack?  One where the
> remaining 49% get dragged in against their will?
>
> Daniele
>
> On Dec 10, 2016 6:39 PM, "Pieter Wuille" <pieter.wuille@gmail.com> wrote:
>
>> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> We have models for estimating the probability that a block is orphaned
>>> given average network bandwidth and block size.
>>>
>>> The question is, do we have objective measures of these two quantities?
>>> Couldn't we target an orphan_rate < max_rate?
>>>
>>
>> Models can predict orphan rate given block size and network/hashrate
>> topology, but you can't control the topology (and things like FIBRE hide
>> the effect of block size on this as well). The result is that if you're
>> purely optimizing for minimal orphan rate, you can end up with a single
>> (conglomerate of) pools producing all the blocks. Such a setup has no
>> propagation delay at all, and as a result can always achieve 0 orphans.
>>
>> Cheers,
>>
>> --
>> Pieter
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  parent reply	other threads:[~2016-12-11  9:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
     [not found] ` <CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
     [not found]   ` <CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
     [not found]     ` <CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
     [not found]       ` <CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
     [not found]         ` <CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
     [not found]           ` <CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
2016-12-10 12:23             ` [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75) Daniele Pinna
2016-12-10 17:39               ` Pieter Wuille
2016-12-11  3:17                 ` Daniele Pinna
2016-12-11  5:29                   ` Eric Voskuil
2016-12-11  9:21                   ` Adam Back [this message]
2016-12-05 15:27 t. khan
2016-12-10 10:44 ` s7r
2016-12-10 12:05   ` Hampus Sjöberg
2016-12-11  0:26   ` t. khan
2016-12-11  0:40     ` James Hilliard
2016-12-11  1:07       ` Bram Cohen
2016-12-11 17:11     ` s7r
2016-12-11 19:55       ` t. khan
2016-12-11 20:31         ` James Hilliard
2016-12-11 21:40           ` t. khan
2016-12-11 21:53             ` Bram Cohen
2016-12-11 21:55             ` James Hilliard
2016-12-11 22:30               ` t. khan
2016-12-11 20:38       ` Andrew Johnson
2016-12-11 23:22         ` s7r
2016-12-18 21:53           ` James MacWhyte
2016-12-19  1:42             ` Tom Harding
2016-12-10 23:12 ` Bram Cohen
2016-12-11  0:52   ` t. khan

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=CALqxMTGHBhyBMPfdUid_W9tYafk5pGbKPP6LTdQbCmbAHLSURQ@mail.gmail.com \
    --to=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=daniele.pinna@gmail.com \
    /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