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?
-------- 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 <aj@erisian.com.au>
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 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