Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B20FB5A for ; Tue, 6 Jun 2017 23:27:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D256518F for ; Tue, 6 Jun 2017 23:27:36 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 96C1810AFB5; Tue, 6 Jun 2017 16:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=GqRKDp3SXdITeCJ/B 3gU+tggwI0=; b=SHz/JVyHA57ZtHTVTy8gwf5Ne/tZCQxrpDNMKAPFBb0E40M2x jhQ6z02ufd8mH7ONr9dNXAD+dF7eDwyw/YhWE3RHPN+0b4QKtuRZ2Mrvj+SVeKLm 4CNx6K15JiflLDmJpywRaViNjZgcqHyhS8+gh3XYVkEjcdQIhVBzhXqpMw= Received: from [192.168.42.64] (184-23-255-227.fiber.dynamic.sonic.net [184.23.255.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 3490910AFB0; Tue, 6 Jun 2017 16:27:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CF850FAB-DC79-488D-A410-14268AC28F21"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: <20170606232015.GA11830@erisian.com.au> Date: Tue, 6 Jun 2017 16:27:33 -0700 X-Mao-Original-Outgoing-Id: 518484453.534158-100fe2ecc5c47234e8b72f1760e3bdb5 Message-Id: <38DDC3A2-2727-477E-A6FF-7638842AAB03@taoeffect.com> References: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com> <20170606232015.GA11830@erisian.com.au> To: Anthony Towns X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 06 Jun 2017 23:31:20 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:27:37 -0000 --Apple-Mail=_CF850FAB-DC79-488D-A410-14268AC28F21 Content-Type: multipart/alternative; boundary="Apple-Mail=_0CD83101-2A35-4251-9FD6-8A17DA62C4EE" --Apple-Mail=_0CD83101-2A35-4251-9FD6-8A17DA62C4EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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: >=20 > On Tue, Jun 06, 2017 at 03:39:28PM -0700, Tao Effect via bitcoin-dev = wrote: >> - Mixing with 148 coinbase txns destroys fungibility. >=20 > CoinJoin works as a method of both improving fungibility and mixing = with > coinbase transactions. >=20 > 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. >=20 > (also, no double-n in untenable) >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_0CD83101-2A35-4251-9FD6-8A17DA62C4EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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 = <bitcoin-dev@lists.linuxfoundation.org> 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<= /a>

= --Apple-Mail=_0CD83101-2A35-4251-9FD6-8A17DA62C4EE-- --Apple-Mail=_CF850FAB-DC79-488D-A410-14268AC28F21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZNzplAAoJEOxnICvpCVJHWV0QAIVJxZ17xhVy4ZcjzDSjOC7S udAhzsoSZs0fud63+T+TSEECTlQkPYptdffuBjHHnTL1U3s+cjmdUSAYoANwl98d mPFaUKS0Eth0DQNKp4om1hh7CAB5YIItcaXKeKbu/ZssucQlTgYpayRA9NQ9mfXl EWfjfd7FxY6MkBcQKdvGEzR8vqIQXoIBvaeM7xRubYzdAkBikWTeLRmYybIDp6G0 kGSxwkZneuyGH0eL18ZE0E2DlkLrfLXZJV5VyHPmzbydW8H6MJ22Zts4B+Y8BUus D6A/qSoTNyhGSHhvqz21HEQ74F2ujHuM75JVfFvmH1viDjHt0FwiYmDs/AiL7Av2 4zi7mQCofeplVm7gc+7+0Sq3th09WrtKi+zkjDDX8YNsk7dWRt7iSDl9r3c1WYhb Hd5vEh8NpPJvSdXF1qqovKDf3OWBvuKhG7k78eoiOQ3WiQWRPLG/WyW48TVUaKSO JWij4rK7roeH822pLeSFJshtiU6sDmqbluDqlljhNuEJ/wgy60lhYpTEliv1LXVj rwptGHGY/4qrgBahfILlNPTG1viq5VwGkvkBPu3t2asV2WyvSowQ5eBYFUBlCQAg j8S5p1LSAJw6QAL2kHNKXv00k2nlmBmvVAUxJvYs0ZzrZ7T7CP0dNFq9P4IWORI6 6qddPtGplB088gu07jA9 =Ao9g -----END PGP SIGNATURE----- --Apple-Mail=_CF850FAB-DC79-488D-A410-14268AC28F21--