public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt•hk
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] block size - pay with difficulty
Date: Thu, 03 Sep 2015 14:24:26 -0400	[thread overview]
Message-ID: <9b65f18ed100177a0f887c0a31f3f0b8@xbt.hk> (raw)
In-Reply-To: <CADm_WcbudZs6_bYfDkQ2XgqvPEMRN4ONnmz45Wz45E06bpGOrQ@mail.gmail.com>

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



  reply	other threads:[~2015-09-03 18:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03  4:05 Jeff Garzik
2015-09-03  4:55 ` jl2012
2015-09-03 14:18   ` Jeff Garzik
2015-09-03 18:24     ` jl2012 [this message]
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

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=9b65f18ed100177a0f887c0a31f3f0b8@xbt.hk \
    --to=jl2012@xbt$(echo .)hk \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jgarzik@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