On Thu, Sep 3, 2015 at 6:23 PM, Jorge Timón 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 argume
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
wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.
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
h
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. Introduci
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
s
On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik 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 bus
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 i
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
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, wrote:
> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>
>> Schemes proposing to pay with difficulty /
On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
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.
Ca
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
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 ch
12 matches
Mail list logo
