Jorge Timón 於 2015-08-30 14:56 寫到:
On Sun, Aug 30, 2015 at 7:13 PM, wrote:
This is based on the assumption that miners would always like to use
up the
last byte of the available block size. However, this is just not true:
1. The 6 year blockchain history has shown that most miners have a
so
On Sun, Aug 30, 2015 at 7:13 PM, wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum w
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/201
My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote
I am quite skeptical about any pay-to-increase proposal because it is
difficult to predict the game dynamics and determine the right amount of
penalty. But anyway, here is my response to your revised proposal:
1. I agree with you that there should be a cap in the rate of change,
and also the m
In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
wan
On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
wrote:
> Ah, then my mistake. It seemed so similar to an idea that was proposed
> before on this mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>
> that my mind just filled in the gaps.
We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2.
On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear
Ah, then my mistake. It seemed so similar to an idea that was proposed
before on this mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
that my mind just filled in the gaps. I concur -- having miners -- or any
group -- vote on block size is not an intrinsic
On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
I realize now that this is not what Greg Maxwell proposed (aka
flexcap): this is just miner's voting on block size
On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective action
> problem. If a miner votes for an increase and nobody else does, the
> b
On Sat, Aug 29, 2015 at 1:36 AM, Btc Drak via bitcoin-dev
wrote:
> On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock
> wrote:
>> However, this proposal currently fails to answer a very important question:
>>
>> • What is the mechanism for activation of the new consensus rule? It is when
>> a cert
On Aug 28, 2015 7:38 PM, "Mark Friedenbach" wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward,
But that's not what this proposal does. They have to pay the difficulty penalty
merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit
block *immediately* by paying a difficulty penalty. Then we can simply take
On Fri, Aug 28, 2015 at 11:24 PM, Gavin wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the miner
> 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is
It is in their individual interests when the larger block that is allowed
for them grants them more fees.
On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size
On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock wrote:
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when
> a certain percentage of the blocks mined in a 2016-block retargeting period
> co
When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalt
With this proposal, how much would it cost a miner to include an 'extra'
500-byte transaction if the average block size is 900K and it costs the miner
20BTC in electricity/capital/etc to mine a block?
If my understanding of the proposal is correct, it is:
500/90 * 20 = 0.1 BTC
... Or $
This is the best proposal I've seen yet. Allow me to summarize:
• It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their
block-size votes.
• It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to
predict future market needs versus future technological ca
I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2]
https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_
Interesting.
Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.
With that figured, then your voting proposal could be triggered by a moving
day block average which takes
You said:
> There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase
From this, my understanding is that you are operating on the principle
that "the optimum blocksize" is related to "popularity/use of Bitcoin".
It seems that
I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determinat
26 matches
Mail list logo
