From: "Warren Togami Jr." <wtogami@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fee smoothing
Date: Wed, 27 Jan 2016 15:11:04 -0800 [thread overview]
Message-ID: <CAEz79Pq7AEmSfDZr0jc0JjdeH9asyGXXhJGMXc43OHJcj8Vrsw@mail.gmail.com> (raw)
In-Reply-To: <CAMuv0Z1yo7-zzj75nXFf9kJNJfmxOoxqHMpDmmNM9uQzFKZ_xQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
On Wed, Jan 27, 2016 at 2:12 AM, Luzius Meisser <luzius.meisser@gmail•com>
wrote:
> I agree that flex cap is promising. However, for it to be a viable
> long-term solution, it must not depend on significant block subsidies
> to work as the block subsidy will become less and less relevant over
> time
There is another variant of the Flex Cap approach that allows miners to pay
with a slightly higher difficulty target instead of deferring a portion of
subsidy to later blocks. I think the HK presentation was about the subsidy
deferral variant because of miner feedback that they preferred that
approach.
Myself and a few other developers think proposals like BIP100 where the
block size is subject to a vote by the miners is suboptimal because this
type of vote is costless. You were astute in recognizing in your post it's
a good thing to somehow align the global marginal cost with the miner's
incentive. I feel a costless vote is not great because it aligns only to
the miner's marginal cost, and not the marginal cost to the entire flood
network. Flex Cap is superior as "vote" mechanism as there is an actual
cost associated, allowing block size to grow with actual demand.
Warren
[-- Attachment #2: Type: text/html, Size: 1672 bytes --]
next prev parent reply other threads:[~2016-01-27 23:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 17:42 Luzius Meisser
2016-01-27 2:45 ` Warren Togami Jr.
2016-01-27 10:12 ` Luzius Meisser
2016-01-27 23:11 ` Warren Togami Jr. [this message]
2016-01-28 20:16 ` Luzius Meisser
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=CAEz79Pq7AEmSfDZr0jc0JjdeH9asyGXXhJGMXc43OHJcj8Vrsw@mail.gmail.com \
--to=wtogami@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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