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 make BIP148 and BIP149 untennable Local Time: June 7, 2017 2:27 AM UTC Time: June 6, 2017 11:27 PM From: bitcoin-dev@lists.linuxfoundation.org To: Anthony Towns bitcoin-dev@lists.linuxfoundation.org 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 proposed methods, coin-mixing seems the better option, because it might be reasonably easy (I don't know) for exchanges to obtain 148 coinbase coins, and mix their coins with them, extending the coin-splitting capability beyond just miner coins and then using that to split incoming coins. That seems like the most reasonable approach I've heard so far. Whether exchanges would be willing to do that is a separate question. When it's confirmed on one chain, but not on the other, you can then "double-spend" on the lower hashrate chain with a higher fee, to end up with different coins on both chains. This method is time consuming and not guaranteed to work. CPFP can be used by an attacker to get your original txn into the 148 chain. (also, no double-n in untenable) Why thank you aj, you're so good at spelling. :-) Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 4:20 PM, Anthony Towns via bitcoin-dev wrote: 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 though: if you send a transaction with a standard fee it will get confirmed in a normal time on the higher hashrate chain, but won't confirm as quickly on the lower hashrate chain (precisely because transactions are valid on both chains, but blocks are found more slowly with the lower hashrate). When it's confirmed on one chain, but not on the other, you can then "double-spend" on the lower hashrate chain with a higher fee, to end up with different coins on both chains. (also, no double-n in untenable) Cheers, aj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev