Yes, 75% seems fine - given that there is a already a wide deployment of
segwit enforcing nodes
This implementation is 100% compatible with a "UASF movement" since, if
triggered, it essentially turns all supporting miners into equivalent
BIP148 enforcers. This should allay any fears that this wo
I would be fine with that, since segwit is widely deployed on the
network already a lower activation threshold should be safe.
On Wed, May 24, 2017 at 12:02 PM, Wang Chun <1240...@gmail.com> wrote:
> I think we should go for 75%, same Litecoin. As I have said before, 95%
> threshold is too high e
I think we should go for 75%, same Litecoin. As I have said before, 95%
threshold is too high even for unconventional soft forks.
> 在 2017年5月24日，04:58，Andrew Chow via bitcoin-dev
> 写道：
>
> Ah. I see now. It wasn't very clear to me that that is what will happen.
>
> Also, shouldn't the timeout
Ah. I see now. It wasn't very clear to me that that is what will happen.
Also, shouldn't the timeout date be set for before the BIP141 timeout?
Otherwise this could lock in but not have enough time for Segwit to be
locked in.
On 5/23/2017 4:42 PM, James Hilliard wrote:
> That is incorrect, it is
That is incorrect, it is compatible with the current segwit
implementation because it triggers a mandatory signalling period that
will activate segwit on existing nodes.
On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
wrote:
> Hi James,
>
> From what I understand, this proposal is in
Hi James,
>From what I understand, this proposal is incompatible with the current
segwit implementation with regards to the NODE_WITNESS service bit. I
believe it could cause network partitioning if the service bit is not
changed.
Andrew
On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrot
good an idea here due to the
fairly short deployment timeline.
>
> Under the assumption that this is indeed compatible with the terms of the
> Silbert agreement, we can presume the involved miners are willing to trust
> eachother more than usual so such a short lock-in period should be
&
e
Silbert agreement, we can presume the involved miners are willing to trust
eachother more than usual so such a short lock-in period should be acceptable.
Original Message ----
Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
segwit deployment
Local Time:
Seems like it would work fine. But why would we expect 80pct to signal for
the exact same implementation - when we can't get 40pct.
It will be contingent on some HF code that allows him to continue using
asicboost, or is too aggressive, or some other unreasonable request.
On May 22, 2017 6:4
Given the overwhelming support for SegWit across the ecosystem of businesses
and users, this seems reasonable to me.
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev
wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal i
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
The goal here is to minimize chain split risk and network disruption
while ma
11 matches
Mail list logo
