* [bitcoin-dev] block size - pay with difficulty
@ 2015-09-03 4:05 Jeff Garzik
2015-09-03 4:55 ` jl2012
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Jeff Garzik @ 2015-09-03 4:05 UTC (permalink / raw)
To: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Schemes proposing to pay with difficulty / hashpower to change block size
should be avoided. The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as you can
get it online. Introducing the concepts of (a) requiring out-of-band
collusion to change block size and/or (b) requiring miners to have idle
hashpower on hand to change block size are both unrealistic and potentially
corrosive. That potentially makes the block size - and therefore fee
market - too close, too sensitive to the wild vagaries of the mining chip
market.
Pay-to-future-miner has neutral, forward looking incentives worth
researching.
[-- Attachment #2: Type: text/html, Size: 743 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 4:05 [bitcoin-dev] block size - pay with difficulty Jeff Garzik
@ 2015-09-03 4:55 ` jl2012
2015-09-03 14:18 ` Jeff Garzik
2015-09-03 6:57 ` Gregory Maxwell
2015-09-03 18:23 ` Tom Harding
2 siblings, 1 reply; 12+ messages in thread
From: jl2012 @ 2015-09-03 4:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin development mailing list
Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
> Schemes proposing to pay with difficulty / hashpower to change block
> size should be avoided. The miners incentive has always been fairly
> straightforward - it is rational to deploy new hashpower as soon as
> you can get it online. Introducing the concepts of (a) requiring
> out-of-band collusion to change block size and/or (b) requiring miners
> to have idle hashpower on hand to change block size are both
> unrealistic and potentially corrosive. That potentially makes the
> block size - and therefore fee market - too close, too sensitive to
> the wild vagaries of the mining chip market.
>
> Pay-to-future-miner has neutral, forward looking incentives worth
> researching.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Ref:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
I explained here why pay with difficulty is bad for everyone: miners and
users, and described the use of OP_CLTV for pay-to-future-miner
However, a general problem of pay-to-increase-block-size scheme is it
indirectly sets a minimal tx fee, which could be difficult and
arbitrary, and is against competition
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 4:05 [bitcoin-dev] block size - pay with difficulty Jeff Garzik
2015-09-03 4:55 ` jl2012
@ 2015-09-03 6:57 ` Gregory Maxwell
2015-09-03 14:31 ` Jeff Garzik
2015-09-03 18:23 ` Tom Harding
2 siblings, 1 reply; 12+ messages in thread
From: Gregory Maxwell @ 2015-09-03 6:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin development mailing list
On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> (b) requiring miners to have idle
> hashpower on hand to change block size are both unrealistic and potentially
I really cannot figure out how you could characterize pay with
difficty has in any way involving idle hashpower.
Can you walk me through this?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 4:55 ` jl2012
@ 2015-09-03 14:18 ` Jeff Garzik
2015-09-03 18:24 ` jl2012
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2015-09-03 14:18 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
Thanks for the link. I readily admit only having given pay-to-future-miner
a little bit of thought. Not convinced it sets a minimal tx fee in all
cases.
On Thu, Sep 3, 2015 at 12:55 AM, <jl2012@xbt•hk> wrote:
> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>
>> Schemes proposing to pay with difficulty / hashpower to change block
>> size should be avoided. The miners incentive has always been fairly
>> straightforward - it is rational to deploy new hashpower as soon as
>> you can get it online. Introducing the concepts of (a) requiring
>> out-of-band collusion to change block size and/or (b) requiring miners
>> to have idle hashpower on hand to change block size are both
>> unrealistic and potentially corrosive. That potentially makes the
>> block size - and therefore fee market - too close, too sensitive to
>> the wild vagaries of the mining chip market.
>>
>> Pay-to-future-miner has neutral, forward looking incentives worth
>> researching.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> Ref:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>
> I explained here why pay with difficulty is bad for everyone: miners and
> users, and described the use of OP_CLTV for pay-to-future-miner
>
> However, a general problem of pay-to-increase-block-size scheme is it
> indirectly sets a minimal tx fee, which could be difficult and arbitrary,
> and is against competition
>
>
>
[-- Attachment #2: Type: text/html, Size: 2416 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 6:57 ` Gregory Maxwell
@ 2015-09-03 14:31 ` Jeff Garzik
2015-09-03 14:40 ` Jeff Garzik
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2015-09-03 14:31 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
paying with difficulty requires some amount of collusion ('a')
Any miner paying with a higher difficulty either needs idle hashpower, or
self-increase their own difficulty at the possible *opportunity cost* of
losing an entire block's income to another miner who doesn't care about
changing the block size. The potential loss does not economically
compensate for size increase gains in most cases, when you consider the
variability of blocks (they come in bursts and pauses) and the fee income
that would be associated.
Miners have more to lose paying with diff than they gain -- unless the
entire network colludes out-of-band with ~90% certainty, by collectively
agreeing to increase the block period by collectively agreeing with
pay-with-diff until the globally desired block size is reached. At that
level of collusion, we can create far more simple schemes to increase block
size.
Pay-with-diff will either not get used, or lead to radical short term block
size (and thus fee) volatility. It is complex & difficult for all players
to reason, and a Rational game theory choice can be to avoid
paying-for-diff even when the network desperately needs an upgrade.
On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > (b) requiring miners to have idle
> > hashpower on hand to change block size are both unrealistic and
> potentially
>
> I really cannot figure out how you could characterize pay with
> difficty has in any way involving idle hashpower.
>
> Can you walk me through this?
>
[-- Attachment #2: Type: text/html, Size: 2321 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 14:31 ` Jeff Garzik
@ 2015-09-03 14:40 ` Jeff Garzik
2015-09-03 17:57 ` Gregory Maxwell
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Garzik @ 2015-09-03 14:40 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
Expanding on pay-with-diff and volatility (closing comment),
Users and miners will have significant difficulty creating and/or
predicting a stable block size (and fee environment) with pay-with-diff
across the months. The ability of businesses to plan is low. Chaos and
unpredictability are bad in general for markets and systems. Thus the
binary conclusion of "not get used" or "volatility"
On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <jgarzik@gmail•com> wrote:
> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
> paying with difficulty requires some amount of collusion ('a')
>
> Any miner paying with a higher difficulty either needs idle hashpower, or
> self-increase their own difficulty at the possible *opportunity cost* of
> losing an entire block's income to another miner who doesn't care about
> changing the block size. The potential loss does not economically
> compensate for size increase gains in most cases, when you consider the
> variability of blocks (they come in bursts and pauses) and the fee income
> that would be associated.
>
> Miners have more to lose paying with diff than they gain -- unless the
> entire network colludes out-of-band with ~90% certainty, by collectively
> agreeing to increase the block period by collectively agreeing with
> pay-with-diff until the globally desired block size is reached. At that
> level of collusion, we can create far more simple schemes to increase block
> size.
>
> Pay-with-diff will either not get used, or lead to radical short term
> block size (and thus fee) volatility. It is complex & difficult for all
> players to reason, and a Rational game theory choice can be to avoid
> paying-for-diff even when the network desperately needs an upgrade.
>
>
>
>
>
>
> On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell@gmail•com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> > (b) requiring miners to have idle
>> > hashpower on hand to change block size are both unrealistic and
>> potentially
>>
>> I really cannot figure out how you could characterize pay with
>> difficty has in any way involving idle hashpower.
>>
>> Can you walk me through this?
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3260 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 14:40 ` Jeff Garzik
@ 2015-09-03 17:57 ` Gregory Maxwell
2015-09-03 18:23 ` Jorge Timón
0 siblings, 1 reply; 12+ messages in thread
From: Gregory Maxwell @ 2015-09-03 17:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin development mailing list
On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
> Expanding on pay-with-diff and volatility (closing comment),
>
> Users and miners will have significant difficulty creating and/or predicting
> a stable block size (and fee environment) with pay-with-diff across the
> months. The ability of businesses to plan is low. Chaos and
> unpredictability are bad in general for markets and systems. Thus the
> binary conclusion of "not get used" or "volatility"
Sorry, I'm still not following. I agree that predictability is important.
I don't follow where unpredictability is coming from here. Most (all?)
of the difficulty based adjustments had small limits on the difficulty
change that wouldn't have substantially changed the interblock times
relative to orphaning.
> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then paying with difficulty requires some amount of collusion ('a')
> Any miner paying with a higher difficulty either needs idle hashpower, or self-increase their own difficulty at the possible opportunity cost of losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for size increase gains in most cases, when you consider the variability of blocks (they come in bursts and pauses) and the fee income that would be associated
What the schemes propose is blocksize that increases fast with
difficulty over a narrow window. The result is that your odds of
producing a block are slightly reduced but the block you produce if
you do is more profitable: but only if there is a good supply of
transactions which pay real fees compariable to the ones you're
already taking. The same trade-off exists at the moment with respect
to orphaning risk and miners still produce large blocks, producing a
larger block means a greater chance you're not successful (due to
orphaning) but you have a greater utility. The orphing mediated risk
is fragile and can be traded off for centeralization advantage or by
miners bypassing validation, issues which at least so far we have no
reason to believe exist for size mediated schemes.
As you know, mining is not a race (ignoring edge effects with
orphaning/propagation time). Increasing difficulty does not put you at
an expected return disavantage compared to other miners so long as the
income increases at least proportionally (otherwise pooling with low
diff shares would be an astronomically losing proposition :)!).
Pay-for-size schemes have been successfully used in some altcoins
without the effects you're suggesting.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 4:05 [bitcoin-dev] block size - pay with difficulty Jeff Garzik
2015-09-03 4:55 ` jl2012
2015-09-03 6:57 ` Gregory Maxwell
@ 2015-09-03 18:23 ` Tom Harding
2 siblings, 0 replies; 12+ messages in thread
From: Tom Harding @ 2015-09-03 18:23 UTC (permalink / raw)
To: bitcoin-dev
On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote:
> Schemes proposing to pay with difficulty / hashpower to change block
> size should be avoided. The miners incentive has always been fairly
> straightforward - it is rational to deploy new hashpower as soon as
> you can get it online. Introducing the concepts of (a) requiring
> out-of-band collusion to change block size and/or (b) requiring miners
> to have idle hashpower on hand to change block size are both
> unrealistic and potentially corrosive. That potentially makes the
> block size - and therefore fee market - too close, too sensitive to
> the wild vagaries of the mining chip market.
>
> Pay-to-future-miner has neutral, forward looking incentives worth
> researching.
>
Another market dependency is even more direct.
Blocksize that can be bought with either difficulty or bitcoin has
incentives whose strength (though not direction) is subject to the
exchange rate. Hence those incentives are subject to the whims of fiat
holders, who can push the exchange rate around.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 17:57 ` Gregory Maxwell
@ 2015-09-03 18:23 ` Jorge Timón
2015-09-03 18:28 ` Btc Drak
2015-09-03 19:17 ` Gregory Maxwell
0 siblings, 2 replies; 12+ messages in thread
From: Jorge Timón @ 2015-09-03 18:23 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin development mailing list
Greg, I believe Jeff is focusing on BtcDrak's proposal (
https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
increased nBits are used to vote for the block size to raise
permanently ( or until it gets voted down).
His arguments don't seem to apply to your original proposal (where the
size is only increased for that block).
On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
>> Expanding on pay-with-diff and volatility (closing comment),
>>
>> Users and miners will have significant difficulty creating and/or predicting
>> a stable block size (and fee environment) with pay-with-diff across the
>> months. The ability of businesses to plan is low. Chaos and
>> unpredictability are bad in general for markets and systems. Thus the
>> binary conclusion of "not get used" or "volatility"
>
> Sorry, I'm still not following. I agree that predictability is important.
>
> I don't follow where unpredictability is coming from here. Most (all?)
> of the difficulty based adjustments had small limits on the difficulty
> change that wouldn't have substantially changed the interblock times
> relative to orphaning.
>
>> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then paying with difficulty requires some amount of collusion ('a')
>> Any miner paying with a higher difficulty either needs idle hashpower, or self-increase their own difficulty at the possible opportunity cost of losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for size increase gains in most cases, when you consider the variability of blocks (they come in bursts and pauses) and the fee income that would be associated
>
> What the schemes propose is blocksize that increases fast with
> difficulty over a narrow window. The result is that your odds of
> producing a block are slightly reduced but the block you produce if
> you do is more profitable: but only if there is a good supply of
> transactions which pay real fees compariable to the ones you're
> already taking. The same trade-off exists at the moment with respect
> to orphaning risk and miners still produce large blocks, producing a
> larger block means a greater chance you're not successful (due to
> orphaning) but you have a greater utility. The orphing mediated risk
> is fragile and can be traded off for centeralization advantage or by
> miners bypassing validation, issues which at least so far we have no
> reason to believe exist for size mediated schemes.
>
> As you know, mining is not a race (ignoring edge effects with
> orphaning/propagation time). Increasing difficulty does not put you at
> an expected return disavantage compared to other miners so long as the
> income increases at least proportionally (otherwise pooling with low
> diff shares would be an astronomically losing proposition :)!).
>
> Pay-for-size schemes have been successfully used in some altcoins
> without the effects you're suggesting.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 14:18 ` Jeff Garzik
@ 2015-09-03 18:24 ` jl2012
0 siblings, 0 replies; 12+ messages in thread
From: jl2012 @ 2015-09-03 18:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin development mailing list
Assuming that:
1. The current block size is 1MB
2. The block reward for a full block is 25.5BTC including tx fee
3. Miner is required to pay x% of reward penalty if he is trying to
increase the size of the next block by x%
If a miner wants to increase the block size by 1 byte, the block size
has to increase by 0.0001%, and the penalty will be 0.0000255BTC/byte.
For a typical 230byte tx that'd be 0.005865BTC, or 1.35USD at current
rate. This is the effective minimum tx fee.
Jeff Garzik 於 2015-09-03 10:18 寫到:
> Thanks for the link. I readily admit only having given
> pay-to-future-miner a little bit of thought. Not convinced it sets a
> minimal tx fee in all cases.
>
> On Thu, Sep 3, 2015 at 12:55 AM, <jl2012@xbt•hk> wrote:
>
>> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>>
>>> Schemes proposing to pay with difficulty / hashpower to change
>>> block
>>> size should be avoided. The miners incentive has always been
>>> fairly
>>> straightforward - it is rational to deploy new hashpower as soon
>>> as
>>> you can get it online. Introducing the concepts of (a) requiring
>>> out-of-band collusion to change block size and/or (b) requiring
>>> miners
>>> to have idle hashpower on hand to change block size are both
>>> unrealistic and potentially corrosive. That potentially makes
>>> the
>>> block size - and therefore fee market - too close, too sensitive
>>> to
>>> the wild vagaries of the mining chip market.
>>>
>>> Pay-to-future-miner has neutral, forward looking incentives worth
>>> researching.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> [1]
>>
>> Ref:
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>> [2]
>>
>> I explained here why pay with difficulty is bad for everyone:
>> miners and users, and described the use of OP_CLTV for
>> pay-to-future-miner
>>
>> However, a general problem of pay-to-increase-block-size scheme is
>> it indirectly sets a minimal tx fee, which could be difficult and
>> arbitrary, and is against competition
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 18:23 ` Jorge Timón
@ 2015-09-03 18:28 ` Btc Drak
2015-09-03 19:17 ` Gregory Maxwell
1 sibling, 0 replies; 12+ messages in thread
From: Btc Drak @ 2015-09-03 18:28 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin development mailing list
Maybe Jeff can clarify but my communications with him seemed to imply
he didn't think any kind of difficulty penalty scheme is workable. I
strongly dispute that assertion.
On Thu, Sep 3, 2015 at 7:23 PM, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).
>
>
> On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
>>> Expanding on pay-with-diff and volatility (closing comment),
>>>
>>> Users and miners will have significant difficulty creating and/or predicting
>>> a stable block size (and fee environment) with pay-with-diff across the
>>> months. The ability of businesses to plan is low. Chaos and
>>> unpredictability are bad in general for markets and systems. Thus the
>>> binary conclusion of "not get used" or "volatility"
>>
>> Sorry, I'm still not following. I agree that predictability is important.
>>
>> I don't follow where unpredictability is coming from here. Most (all?)
>> of the difficulty based adjustments had small limits on the difficulty
>> change that wouldn't have substantially changed the interblock times
>> relative to orphaning.
>>
>>> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then paying with difficulty requires some amount of collusion ('a')
>>> Any miner paying with a higher difficulty either needs idle hashpower, or self-increase their own difficulty at the possible opportunity cost of losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for size increase gains in most cases, when you consider the variability of blocks (they come in bursts and pauses) and the fee income that would be associated
>>
>> What the schemes propose is blocksize that increases fast with
>> difficulty over a narrow window. The result is that your odds of
>> producing a block are slightly reduced but the block you produce if
>> you do is more profitable: but only if there is a good supply of
>> transactions which pay real fees compariable to the ones you're
>> already taking. The same trade-off exists at the moment with respect
>> to orphaning risk and miners still produce large blocks, producing a
>> larger block means a greater chance you're not successful (due to
>> orphaning) but you have a greater utility. The orphing mediated risk
>> is fragile and can be traded off for centeralization advantage or by
>> miners bypassing validation, issues which at least so far we have no
>> reason to believe exist for size mediated schemes.
>>
>> As you know, mining is not a race (ignoring edge effects with
>> orphaning/propagation time). Increasing difficulty does not put you at
>> an expected return disavantage compared to other miners so long as the
>> income increases at least proportionally (otherwise pooling with low
>> diff shares would be an astronomically losing proposition :)!).
>>
>> Pay-for-size schemes have been successfully used in some altcoins
>> without the effects you're suggesting.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] block size - pay with difficulty
2015-09-03 18:23 ` Jorge Timón
2015-09-03 18:28 ` Btc Drak
@ 2015-09-03 19:17 ` Gregory Maxwell
1 sibling, 0 replies; 12+ messages in thread
From: Gregory Maxwell @ 2015-09-03 19:17 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin development mailing list
On Thu, Sep 3, 2015 at 6:23 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).
Ah, that would clarify things for me me.
Please everyone try to speak specifically enough to catch details like that.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-09-03 19:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-03 4:05 [bitcoin-dev] block size - pay with difficulty Jeff Garzik
2015-09-03 4:55 ` jl2012
2015-09-03 14:18 ` Jeff Garzik
2015-09-03 18:24 ` jl2012
2015-09-03 6:57 ` Gregory Maxwell
2015-09-03 14:31 ` Jeff Garzik
2015-09-03 14:40 ` Jeff Garzik
2015-09-03 17:57 ` Gregory Maxwell
2015-09-03 18:23 ` Jorge Timón
2015-09-03 18:28 ` Btc Drak
2015-09-03 19:17 ` Gregory Maxwell
2015-09-03 18:23 ` Tom Harding
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox