-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/24/2017 04:27 PM, Emin Gün Sirer wrote:
> Because there's no consensus on the contents of the mempool, this approach
> is unsafe and will lead to forks. It also opens a new attack vector where
> people can time the flood of new transactions wit
I think it is better not to use the coinbase, because it might collide
with other proposals, and because coinbase is not part of the block header.
I agree that a small set of standard threshold may be sufficient; a one
percent resolution is probably not needed. If we use 4 bits we can
encode 15 di
> However, my point is that the threshold should be [...] not fixed in the
> soft-fork proposal
My proposal makes it configurable (as well as window size, grace period etc.)
> I agree that coinbase space might be a limitation.
I still like the coinbase idea though - more than using up the BIP9
Hi Sancho,
I saw your proposal. However, my point is that the threshold should be
part of the signaling, and not fixed in the soft-fork proposal.
I agree that coinbase space might be a limitation.
To avoid this, I realize that the threshold could be encoded in the
version bits. We have 32 versio
Thomas,
I wonder if you've seen my proposal on how to make BIP9 more configurable:
https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
This could be extended with a coinbase signaling feature as you suggest.
This could include parameter information for forks which a
Disclaimer: I am fully supportive of Segregated Witness and its
activation by users through BIP148. However, I also believe that a
soft fork would be less risky if it was initially activated by miners,
before the date set in BIP148. This proposal is not intended to
replace UASF, but to mitigate the
