public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, nbvfour@gmail.com
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Sat, 26 Dec 2015 19:01:59 +0100	[thread overview]
Message-ID: <CABm2gDrkvsShE1Vbc9KVTTeFzjJJJrGj605pRxoOAWMwpMWn1w@mail.gmail.com> (raw)
In-Reply-To: <EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com>

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

The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:

> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, the
> difficulty is lowered so that if the second PoW difficulty were to be kept
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the same
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for these
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon@jtimon.cc>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops,
>> total pow per unit of time should also drop. Even if the inter-block time
>> is increased, it's not clear to me that the pow per block would necessarily
>> be higher.
>> What am I missing?
>>
>

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

  reply	other threads:[~2015-12-26 18:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-19 18:42 [bitcoin-dev] We need to fix the block withholding attack Peter Todd
2015-12-19 19:30 ` Bob McElrath
2015-12-19 20:03 ` jl2012
2015-12-20  3:34 ` Chris Priest
2015-12-20  3:36   ` Matt Corallo
2015-12-20  3:43     ` Chris Priest
2015-12-20  4:44       ` Peter Todd
2015-12-26  8:12         ` Multipool Admin
2015-12-27  4:10           ` Geir Harald Hansen
2015-12-28 19:12           ` Peter Todd
2015-12-28 19:30             ` Emin Gün Sirer
2015-12-28 19:35               ` Multipool Admin
2015-12-28 19:33             ` Multipool Admin
2015-12-28 20:26             ` Ivan Brightly
2015-12-29 18:59               ` Dave Scotese
2015-12-29 19:08                 ` Jonathan Toomim
2015-12-29 19:25                 ` Allen Piscitello
2015-12-29 21:51                   ` Dave Scotese
2015-12-20  3:40   ` jl2012
2015-12-20  3:47     ` Chris Priest
2015-12-20  4:24       ` jl2012
2015-12-20  5:12         ` Emin Gün Sirer
2015-12-20  7:39           ` Chris Priest
2015-12-20  7:56             ` Emin Gün Sirer
2015-12-20  8:30               ` Natanael
2015-12-20 11:38           ` Tier Nolan
2015-12-20 12:42             ` Natanael
2015-12-20 15:30               ` Tier Nolan
2015-12-20 13:28           ` Peter Todd
2015-12-20 17:00             ` Emin Gün Sirer
2015-12-21 11:39               ` Jannes Faber
2015-12-25 11:15                 ` Ittay
2015-12-25 12:00                   ` Jonathan Toomim
2015-12-25 12:02                   ` benevolent
2015-12-25 16:11                   ` Jannes Faber
2015-12-26  0:38               ` Geir Harald Hansen
2015-12-28 20:02               ` Peter Todd
2015-12-26  8:23             ` Eric Lombrozo
2015-12-26  8:26               ` Eric Lombrozo
2015-12-26 15:33               ` Jorge Timón
2015-12-26 17:38                 ` Eric Lombrozo
2015-12-26 18:01                   ` Jorge Timón [this message]
2015-12-26 16:09               ` Tier Nolan
2015-12-26 18:30                 ` Eric Lombrozo
2015-12-26 19:34                   ` Jorge Timón
2015-12-26 21:22               ` Jonathan Toomim
2015-12-27  4:33                 ` Emin Gün Sirer

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=CABm2gDrkvsShE1Vbc9KVTTeFzjJJJrGj605pRxoOAWMwpMWn1w@mail.gmail.com \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    --cc=nbvfour@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