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 B

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

I don't know what you mean by "render the replay threat moot." If you don't have replay protection, replay is always a threat. A very serious one. -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Jun 6, 2017, at 5:19 PM, Kekcoin

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message S

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

> Please read my email more carefully; the replay threat would be moot because > there would be no alternative chain to replay the TX on, In order to *get to that point*, you need >51%. Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

I was merely describing that the only failure mode of using "post-split coinbases from the legacy chain" as seedcoins for cointainting purposes would be a resolution of the coinsplit, thereby rendering the cointainting redundant, therefore this would be an entirely safe approach to cointainting,

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

While this isn't an unreasonable proposal, it will orphan blocks from any miner who isn't running it (or BIP148) by Aug 1, right? That seems rather rushed for a non-backwards-compatible SF, especially since in practice, miners are unlikely to deploy it until it comes bundled with some version of t

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 wi

[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama. First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list, th

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > wrote: > > I believe the severity of replay attacks is going unvoiced and is not > > understood within the bitcoin commun

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. O

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

Nick, > Please don't spread misinformation. Whatever you think of the DAO hard fork, > it's a simple fact that the Ethereum ledger was not edited. This sort of email is unhelpful to this conversation, and it certainly doesn't help with the perception that Ethereum is nothing but a bunch of hypo

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 "If

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 i

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

On Wed, Jun 7, 2017 at 5:27 PM Tao Effect wrote: > Nick, > > Please don't spread misinformation. Whatever you think of the DAO hard > fork, it's a simple fact that the Ethereum ledger was not edited. > > > This sort of email is unhelpful to this conversation, and it certainly > doesn't help with

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 i

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 wrote: > You're mis

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, much better than a -

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

On Thu, Jun 1, 2017 at 7:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote: > Hi y'all, > > Alex Akselrod and I would like to propose a new light client BIP for > consideration: >* https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki I see the inner loop of construction and l

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 majorit

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 depl

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 again. > > I missed

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 t

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, no

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 requ

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

On Wed, Jun 7, 2017 at 4:50 PM, Jared Lee Richardson wrote: > Could this risk mitigation measure be an optional flag? And if so, > could it+BIP91 signal on a different bit than bit4? It's fairly trivial for miners to signal for BIP91 on bit4 or a different bit at the same time as the code is triv

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 n

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 hashpower profitability

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 consens

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 statement is misleading.

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 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 >> chain then the hi

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 signa