From: Mark Friedenbach <mark@friedenbach•org>
To: Thomas Voegtlin <thomasv@electrum•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Date: Sun, 10 May 2015 15:31:46 -0700 [thread overview]
Message-ID: <CAOG=w-uZBGaprOV2ztYYNtiOSgxTpRUn_8zKTsNSkGAL1N1=nA@mail.gmail.com> (raw)
In-Reply-To: <554FD237.2020009@electrum.org>
[-- Attachment #1: Type: text/plain, Size: 3633 bytes --]
I'm on my phone today so I'm somewhat constrained in my reply, but the key
takeaway is that the proposal is a mechanism for miners to trade subsidy
for the increased fees of a larger block. Necessarily it only makes sense
to do so when the marginal fee per KB exceeds the subsidy fee per KB. It
correspondingly makes sense to use a smaller block size if fees are less
than subsidy, but note that fees are not uniform and as the block shrinks
the marginal fee rate goes up..
Limits on both the relative and absolute amount a miner can trade subsidy
for block size prevent incentive edge cases as well as prevent a sharp
shock to the current fee-poor economy (by disallowing adjustment below 1MB).
Also the identity transform was used only for didactic purposes. I fully
expect there to be other, more interesting functions to use.
On May 10, 2015 3:03 PM, "Thomas Voegtlin" <thomasv@electrum•org> wrote:
> Le 08/05/2015 22:33, Mark Friedenbach a écrit :
>
> > * For each block, the miner is allowed to select a different difficulty
> > (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
> > and this miner-selected difficulty is used for the proof of work check.
> In
> > addition to adjusting the hashcash target, selecting a different
> difficulty
> > also raises or lowers the maximum block size for that block by a function
> > of the difference in difficulty. So increasing the difficulty of the
> block
> > by an additional 25% raises the block limit for that block from 100% of
> the
> > current limit to 125%, and lowering the difficulty by 10% would also
> lower
> > the maximum block size for that block from 100% to 90% of the current
> > limit. For simplicity I will assume a linear identity transform as the
> > function, but a quadratic or other function with compounding marginal
> cost
> > may be preferred.
> >
>
> Sorry but I fail to see how a linear identity transform between block
> size and difficulty would work.
>
> The miner's reward for finding a block is the sum of subsidy and fees:
>
> R = S + F
>
> The probability that the miner will find a block over a time interval is
> inversely proportional to the difficulty D:
>
> P = K / D
>
> where K is a constant that depends on the miner's hashrate. The expected
> reward of the miner is:
>
> E = P * R
>
> Consider that the miner chooses a new difficulty:
>
> D' = D(1 + x).
>
> With a linear identity transform between block size and difficulty, the
> miner will be allowed to collect fees from a block of size: S'=S(1+x)
>
> In the best case, collected will be proportional to block size:
>
> F' = F(1+x)
>
> Thus we get:
>
> E' = P' * R' = K/(D(1+x)) * (S + F(1+x))
>
> E' = E - x/(1+x) * S * K / D
>
> So with this linear identity transform, increasing block size never
> increases the miners gain. As long as the subsidy exists, the best
> strategy for miners is to reduce block size (i.e. to choose x<0).
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4357 bytes --]
next prev parent reply other threads:[~2015-05-10 22:31 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 7:20 Matt Whitlock
2015-05-08 10:15 ` Mike Hearn
2015-05-08 10:30 ` Clément Elbaz
2015-05-08 12:32 ` Joel Joonatan Kaartinen
2015-05-08 12:48 ` Matt Whitlock
2015-05-08 13:24 ` Matt Whitlock
2015-05-08 12:48 ` Gavin Andresen
2015-05-08 16:51 ` Peter Todd
2015-05-08 22:36 ` Joel Joonatan Kaartinen
2015-05-09 18:30 ` Peter Todd
2015-05-08 15:57 ` Alex Mizrahi
2015-05-08 16:55 ` Bryan Bishop
2015-05-08 20:33 ` Mark Friedenbach
2015-05-08 22:43 ` Aaron Voisine
2015-05-08 22:45 ` Mark Friedenbach
2015-05-08 23:15 ` Aaron Voisine
2015-05-08 23:58 ` Mark Friedenbach
2015-05-09 3:36 ` Gregory Maxwell
2015-05-09 11:58 ` Gavin Andresen
2015-05-09 13:49 ` Tier Nolan
2015-05-10 17:36 ` Owen Gunden
2015-05-10 18:10 ` Mark Friedenbach
2015-05-10 21:21 ` Gavin Andresen
2015-05-10 21:33 ` Gregory Maxwell
2015-05-10 21:56 ` Rob Golding
2015-05-13 10:43 ` Tier Nolan
2015-05-16 0:22 ` Rusty Russell
2015-05-16 11:09 ` Tier Nolan
2015-05-18 1:42 ` Rusty Russell
2015-05-19 8:59 ` Tier Nolan
2015-05-10 21:48 ` Thomas Voegtlin
2015-05-10 22:31 ` Mark Friedenbach [this message]
2015-05-10 23:11 ` Thomas Voegtlin
2015-05-28 15:53 ` Gavin Andresen
2015-05-28 17:05 ` Mike Hearn
2015-05-28 17:19 ` Gavin Andresen
2015-05-28 17:34 ` Mike Hearn
2015-05-28 18:23 ` Gavin Andresen
2015-05-29 11:26 ` Mike Hearn
2015-05-29 11:42 ` Tier Nolan
2015-05-29 11:57 ` Mike Hearn
2015-05-29 12:39 ` Gavin Andresen
2015-05-29 14:00 ` insecurity
2015-05-29 14:15 ` Braun Brelin
2015-05-29 14:09 ` Tier Nolan
2015-05-29 14:20 ` Gavin Andresen
2015-05-29 14:22 ` Mike Hearn
2015-05-29 14:21 ` Mike Hearn
2015-05-29 14:22 ` Tier Nolan
2015-05-29 16:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-29 18:28 ` Tier Nolan
2015-05-29 17:53 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Admin Istrator
2015-05-30 9:03 ` Aaron Voisine
2015-06-01 11:30 ` Ricardo Filipe
2015-06-01 11:46 ` Marcel Jamin
2015-05-29 18:47 ` Bryan Cheng
2015-05-30 1:36 ` Cameron Garnham
2015-05-28 17:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-28 17:59 ` Pieter Wuille
2015-05-28 18:21 ` Gavin Andresen
2015-05-28 17:50 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Peter Todd
2015-05-28 17:14 ` Thomas Voegtlin
2015-05-28 17:34 ` Pieter Wuille
2015-05-29 17:45 ` Aaron Voisine
2015-05-08 14:57 Steven Pine
2015-05-09 0:13 Raystonn
[not found] <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
2015-05-28 16:30 ` Steven Pine
[not found] ` <CABsx9T03aNRC5DRbR06nNtsiBdJAcQsGAHvbCOe3pnuRpdvq5w@mail.gmail.com>
2015-05-28 18:25 ` Steven Pine
2015-05-28 18:31 ` Gavin Andresen
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='CAOG=w-uZBGaprOV2ztYYNtiOSgxTpRUn_8zKTsNSkGAL1N1=nA@mail.gmail.com' \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=thomasv@electrum$(echo .)org \
/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