From: Eric Lombrozo <elombrozo@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
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 09:38:33 -0800 [thread overview]
Message-ID: <EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com> (raw)
In-Reply-To: <CABm2gDp4ac=E+T-FT=ZQPnW_ao2GdF1QOg8tROYoV=QKypQS1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
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: 2628 bytes --]
next prev parent reply other threads:[~2015-12-26 17:38 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-19 18:42 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 [this message]
2015-12-26 18:01 ` Jorge Timón
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=EC9193E8-DEC6-413F-A9AC-903E26E51824@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
--cc=nbvfour@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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