Thanks for all the comments.
I plan to address the feedback and work on an implementation next week.
On Tue, May 26, 2015 at 6:48 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
Hello everyone,
here is a proposal for how to coordinate future soft-forking consensus
changes:
Agreed, there is no need to misuse the version field as well. There is more
than enough variability you could roll in the merkle tree including and
excluding transactions, and the scriptSig of the coinbase transaction,
which also influences the merkle root.
I have a fundamental dislike of
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a start-line. The definition would then
be something like
BIP 105
Start block: 325000
End block: 35
Activation: 750 of 1000
On Wed, May 27, 2015 at 11:15 AM, Peter Todd p...@petertodd.org wrote:
The median time mechanism is basically a way for hashing power to show
what time they think it is. Equally, the nVersion soft-fork mechanism is
a way for hashing power to show what features they want to support.
Fair
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote:
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The median time mechanism is basically a way for hashing power to show
what time they think it is.
On May 27, 2015 11:35 AM, Tier Nolan tier.no...@gmail.com wrote:
Was the intention to change the 95% rule. You need 750 of the last 1000
to activate and then must wait at least 1000 for implication?
You need 75% to start applying it, 95% to start rejecting blocks that don't
apply it.
There is absolutely no reason to do this.
Any reasonable micro-controller can build merkle tree roots
significantly faster than is necessary.
1 Th/s walks the nonce range once every 4.3ms.
The largest valid merkle trees are 14 nodes high.
That translates to 28 SHA256 ops per 4.3ms or 6511
I like the idea but I think we should leave at least 16 bits of the
version fixed as an extra-nonce.
If we don't then miners may use them as a nonce anyway, and mess with
the soft-fork voting system.
My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102
Best regards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015/5/26 21:48, Pieter Wuille wrote:
here is a proposal for how to coordinate future soft-forking
consensus changes:
https://gist.github.com/sipa/bf69659f43e763540550
It supports multiple parallel changes, as well as changes that get
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
Feel free to comment. As the gist does not support notifying participants
of new comments, I would suggest using the mailing list instead.
I suggest adding a section describing how this interacts with and changes GBT.
Currently, the
It would also help to see the actual code changes required, which I'm sure
will be much shorter than the explanation itself.
On May 27, 2015 5:47 AM, Luke Dashjr l...@dashjr.org wrote:
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
Feel free to comment. As the gist does not support
11 matches
Mail list logo
