Re: [bitcoin-dev] User Activated Soft Fork Split Protection

On Wed, Jun 7, 2017 at 8:01 PM, Jared Lee Richardson wrote: >> If you're looking for hard numbers at this point you aren't likely to >> find them because not everything is easy to measure directly. > > There's quite a few hard numbers that are available that are of varying

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> If you're looking for hard numbers at this point you aren't likely to > find them because not everything is easy to measure directly. There's quite a few hard numbers that are available that are of varying use. Mining commitments are a major one because of the stalled chain problem. Node

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

On Wed, Jun 7, 2017 at 7:20 PM, Jared Lee Richardson wrote: >> Not really, there are a few relatively simple techniques such as RBF >> which can be leveraged to get confirmations on on-side before double >> spending on another. Once a transaction is confirmed on the non-BIP148

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> Not really, there are a few relatively simple techniques such as RBF > which can be leveraged to get confirmations on on-side before double > spending on another. Once a transaction is confirmed on the non-BIP148 > chain then the high fee transactions can be made on only the BIP148 > side of the

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

On Wed, Jun 7, 2017 at 6:43 PM, Jared Lee Richardson wrote: >> BIP148 however is a consensus change that can >> be rectified if it gets more work, this would act as an additional >> incentive for mine the BIP148 side since there would be no wipeout >> risk there. > > This

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> BIP148 however is a consensus change that can > be rectified if it gets more work, this would act as an additional > incentive for mine the BIP148 side since there would be no wipeout > risk there. This statement is misleading. Wipeout risks don't apply to any consensus changes; It is a

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

On Wed, Jun 7, 2017 at 5:53 PM, Jared Lee Richardson wrote: >> There are 2 primary factors involved here, economic support and > hashpower either of which is enough to make a permanent chain split > unlikely, miners will mine whichever chain is most profitable(see > ETH/ETC

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> There are 2 primary factors involved here, economic support and hashpower either of which is enough to make a permanent chain split unlikely, miners will mine whichever chain is most profitable(see ETH/ETC hashpower profitability equilibrium for an example of how this works in practice) That's

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

Could this risk mitigation measure be an optional flag? And if so, could it+BIP91 signal on a different bit than bit4? The reason being, if for some reason the segwit2x activation cannot take place in time, it would be preferable for miners to have a more standard approach to activation that

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> Keep in mind that this is only temporary until segwit has locked in, after that happens it becomes optional for miners again. I missed that, that does effectively address that concern. It appears that BIP148 implements the same rule as would be required to prevent a later chainsplit as well,

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

I think this BIP represents a gamble, and the gamble may not be a good one. The gamble here is that if the segwit2x changes are rolled out on time, and if the signatories accept the bit4 + bit1 signaling proposals within BIP91, the launch will go smoother, as intended. But conversely, if either

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

Yes, this is the same as BIP148, there is no mandatory signalling after segwit is locked in. On Wed, Jun 7, 2017 at 4:43 PM, Jared Lee Richardson wrote: >> Keep in mind that this is only temporary until segwit has locked in, > after that happens it becomes optional for miners

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> This is, by far, the safest way for miners to quickly defend against a chain > split, much better than a -bip148 option. This allows miners to defend > themselves, with very little risk, since the defense is only activated if the > majority of miners do so. I would move for a very rapid

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

I don't really see how this would increase the likelihood of an extended chain split assuming BIP148 is going to have non-insignificant economic backing. This BIP is designed to provide a risk mitigation measure that miners can safely deploy. Since this BIP only activates with a clear miner

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

Keep in mind that this is only temporary until segwit has locked in, after that happens it becomes optional for miners again. On Wed, Jun 7, 2017 at 4:09 PM, Jared Lee Richardson wrote: >> This is, by far, the safest way for miners to quickly defend against a chain >> split,

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

I get it, a threshold could be put in place, but something like 33% would more accurately reflect the risks miners run. I'm not aware of a good signal to indicates someone is planning to run BIP148 and orphan a miner's blocks. On Wed, Jun 7, 2017 at 3:39 PM, Jacob Eliosoff

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

You're missing my point. "As soon as a simple majority supports it" - what is "it"? BIP148? Or "deferring to the miner consensus on BIP148"? It's the difference between supporting one side of a vote, vs supporting deferral to the outcome of the vote. Or if you mean, the safe thing for miners

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> But passing it off as the safest defense is bad faith. Without this option, a miner has to guess whether a split will be economically impacting. With this option, his miner will automatically switch to the chain least likely to get wiped out... as soon as a simple majority of miners supports

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

This is not the safest defense against a split. If 70% of miners run "splitprotection", and 0.1% run BIP148, there's no "safety"/"defense" reason for splitprotection to activate segwit. It should only do so if *BIP148* support (NB: not just segwit support!) >50%. The truly defensive logic is

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

This is, by far, the safest way for miners to quickly defend against a chain split, much better than a -bip148 option. This allows miners to defend themselves, with very little risk, since the defense is only activated if the majority of miners do so. I would move for a very rapid deployment.

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

See thread on replay attacks for why activating regardless of threshold is a bad idea [1]. BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more difficult for miners to hold together in opposition to Core. It gives Core more leverage in negotiations. If they don't activate

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

I think even 55% would probably work out fine simply due to incentive structures, once signalling is over 51% it's then clear to miners that non-signalling blocks will be orphaned and the rest will rapidly update to splitprotection/BIP148. The purpose of this BIP is to reduce chain split risk for

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

What is the probability that a 65% threshold is too low and can allow a "surprise miner attack", whereby miners are kept offline before the deadline, and brought online immediately after, creating potential havoc? (Nit: "simple majority" usually refers to >50%, I think, might cause confusion.)

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

This is a BIP8 style soft fork so mandatory signalling will be active after Aug 1st regardless. On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect wrote: > What is the probability that a 65% threshold is too low and can allow a > "surprise miner attack", whereby miners are kept

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

You need a majority of miners enforcing BIP148 upon BIP148 activation to prevent a split, not just a majority signalling segwit. This provides a miner coordination mechanism for BIP148 mandatory signalling enforcement. On Tue, Jun 6, 2017 at 8:11 PM, Karl Johan Alm

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

One thing about BIP148 activation that may be affected by this is the fact that segwit signalling non-BIP148 miners + BIP148 miners may hold majority hash power and prevent a chain split. With this SF, that will no longer be the case, right? Or am I completely confused on the subject? On Wed, Jun

[bitcoin-dev] User Activated Soft Fork Split Protection

Due to the proposed calendar(https://segwit2x.github.io/) for the SegWit2x agreement being too slow to activate SegWit mandatory signalling ahead of BIP148 using BIP91 I would like to propose another option that miners can use to prevent a chain split ahead of the Aug 1st BIP148 activation date.