Greg,
I'd like to ask you to assign a BIP number to this proposal and open
another round of discussion.
There is now a reference implementation available as pull request #5102
(https://github.com/bitcoin/bitcoin/pull/5102).
It introduces a new version number (3) to properly distinguish the
If changing the structure of the block header, wouldnt you also need to
increment the version number to 3?
No, in this case I don't think so. Incrementing the version number has
two purposes:
1. inform old clients that something new is going on
2. be able to phase out old version numbers and
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs. Especially because in future we should make unknown versions a
validation rule, so we can easily trigger hard forks.
If this change was
On Sun, Apr 27, 2014 at 02:38:06AM -0700, Mark Friedenbach wrote:
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining
On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs.
The purpose of the proposal is to change the protocol spec, not to
ignore it.
I'd like to put the following draft of a BIP up for discussion.
Timo
# Abstract
There are incentives for miners to find cheap, non-standard ways to generate
new work, which are not necessarily in the best interest of the protocol.
In order to reduce these incentives this proposal re-assigns 2
On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
I'd like to put the following draft of a BIP up for discussion.
Timo
# Abstract
There are incentives for miners to find cheap, non-standard ways to
generate new work, which are not necessarily in the best interest of the
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining space of the 4 bytes as your extra nonce.
That would allow
8 matches
Mail list logo
