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.

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

Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg

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

> You keep referring to 148 coinbase coins, what is the rationale behind this? > Why would you prefer using 148 coinbases over legacy coinbases for this > purpose? OK, maybe "post-UASF coinbase coins" is a better term? I just wanted to make it clear that this refers to coins that come from

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

You keep referring to 148 coinbase coins, what is the rationale behind this? Why would you prefer using 148 coinbases over legacy coinbases for this purpose? Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks

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

> CPFP can be used by an attacker to get your original txn into the 148 chain. *err, my bad that's unlikely to happen, if I remember correctly CPFP can only be done by the person you're sending the coins to. Coin-mixing seems the better option of the two, but shouldn't the BIP148 folks wait

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

> CoinJoin works as a method of both improving fungibility and mixing with > coinbase transactions. My understanding is that the two situations are quite different. Unlike mixing to coin-split, CoinJoin doesn't create a high demand exclusively for coinbase transactions. However, of the

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

> Replay is a solved problem. Point to this solved problem? Your "solution" here is not a solution: https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3

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

Hey Greg, It wasn't my intention to insult anyone (a bit defensive?). Maybe this is yet another example of a recurring criticism of Core: that core doesn't community these issues very well to journalists / reports / media / community outside of this list. Because outside of this list it's

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

On Tue, Jun 06, 2017 at 03:39:28PM -0700, Tao Effect via bitcoin-dev wrote: > - Mixing with 148 coinbase txns destroys fungibility. CoinJoin works as a method of both improving fungibility and mixing with coinbase transactions. You probably don't need to do anything clever to split a coin

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

On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote: > I believe the severity of replay attacks is going unvoiced and is not > understood within the bitcoin community because of their lack of > experience with them. Replay is a solved problem. It can be improved on and made

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

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 community because of their lack of experience > with them. Please don't insult our

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

[bitcoin-dev] SegWit activation proposal with 2MB Hard Fork by next Block Halving on 2020

*Proposal*: Verify whether 50% Tx mined from SegWit activation block to block 63 are SegWit Tx. If yes, increase legacy max block size to 2MB and SegWit max block size to 8MB. *Implementation*: This proposal either needs to be implemented in next release of Bitcoin Core or require SegWit