From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CEB7CCA for ; Mon, 10 Sep 2018 12:30:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A68B782 for ; Mon, 10 Sep 2018 12:30:50 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C41B9416; Mon, 10 Sep 2018 08:30:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 10 Sep 2018 08:30:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=b0YDDkevd9VJhw+CYY178Z7IyrEYDFbGNtI+t6A4ofI=; b=Ct8Nz/Hy qBUrOqMesQvP6jH247cHb9yzSqz/bfcvInmeHxbypOYfYgOUUP1GCmvDszUeHTam Q75IELhv23eSs69Y9RBgiJTq+aSwNnCEZjJopLtf/8MEOW9nhrwBtFzsSkjLFk4N 6A06pauXDOXDwSUfqRhpyQcVjeaqrRcUlVaTiFMaAQsAv4rM+u4eroQr1xNbjRub Wj1rk8iL6Hvgc9Wacj6c+7U/PqCKVRbBRBGjIa/kYCzdmYAmZkgauo/adpEO4HWF VVdhxdRoLvns+qTr0wI7uAUpaoiLrKzlVcGX4EKfusq/gtvQ2P+VKQoh7+ndEAjr WavZslhtvc0mvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=b0YDDkevd9VJhw+CYY178Z7IyrEYD FbGNtI+t6A4ofI=; b=sNJrjntWuLqh3jQXZ4+GcqYizzwTSiQgFG2PP+AZ/KN4n dugQ9kvQAqO1rQ/SJDA879dv8iUeKIMB9BPksmv+MW8MuDuEBAlrfVUAEsJGBiD6 MubVIhGRzMlLdos4fOl5Uf3l/WC14jDfpJQlNrGyVs65V4fKtwK7Zkuy5dx//Bjl NT8XOh6DK1xScQ8drINgi43CdZHziyClyFFNl33gei2RCbDMoNsuQcpU1kDCiWaK qHlIjFlh6AdvOj5uUhlzRV0o/j02ZbyII+F66jtHx8dbSX29PGiMDEqaK6CAXwwy hg45UpO5AeLKPkqkVhnyI5IeBCmkX2/VyFxoSZwlg== X-ME-Proxy: X-ME-Sender: Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id F2912E408D; Mon, 10 Sep 2018 08:30:47 -0400 (EDT) From: Sjors Provoost Content-Type: multipart/signed; boundary="Apple-Mail=_35E0A336-43BB-4270-8B25-FDEBE5AD051A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 10 Sep 2018 14:30:46 +0200 References: To: Bitcoin Protocol Discussion , Rhavar In-Reply-To: Message-Id: <82F5C582-1B93-44CF-B5AA-A93AAEA32AB2@sprovoost.nl> X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Mon, 10 Sep 2018 13:38:20 +0000 Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol 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: Mon, 10 Sep 2018 12:30:51 -0000 --Apple-Mail=_35E0A336-43BB-4270-8B25-FDEBE5AD051A Content-Type: multipart/alternative; boundary="Apple-Mail=_48127117-8F35-4700-ADFA-F388148ACF8B" --Apple-Mail=_48127117-8F35-4700-ADFA-F388148ACF8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev = het volgende geschreven: >=20 > =3D=3DMotivation=3D=3D >=20 > One of the most powerful heuristic's employed by those whose goal is = to undermine > bitcoin's fungiblity has been to assume all inputs of a transaction = are signed by > a single party. In the few cases this assumption does not hold, it is = generally > readibly recognizable (e.g. traditional coinjoins have a very obvious = structure, > or multisig outputs are most frequently validated onchain). In addition to mixers, custodial wallets and exchanges also contribute = to breaking this heuristic; even though there=E2=80=99s a single entity = signing multiple inputs, that entity doesn=E2=80=99t represent a single = owner of the funds. As with mixers, exchanges and custodial wallets can = sometimes be spotted as well, but we don=E2=80=99t know what percentage = is missed. Breaking this heuristic at scale would be good, but do we know to what = degree it=E2=80=99s already broken? Is there any empirical research = measuring its accuracy and false positive rate? > Should bustapay enjoy widespread adoption, a "v2" specification > will be created with desired extensions. I would not put future promises in a BIP. Rather, explain how extension = might work. > =3D=3DSpecification=3D=3D >=20 > A bustapay payment is made from a sender to a receiver. >=20 > Step 1. Sender creates a bitcoin transaction paying the receiver >=20 > This transaction must be fully valid, signed and all inputs must use = segwit. This transaction is known as the "template transaction=E2=80=9D. Using PSBT? > This transaction must not be propagated on the bitcoin network. This can=E2=80=99t be guaranteed, and even after step 5 a reorg could = cause it to get confirmed. It=E2=80=99s useful to explain why this = doesn=E2=80=99t matter. >=20 > Step 2. Sender gives the "template transaction" to the receiver >=20 > This would generally be done as an HTTP POST. > The exact URL to submit it to could be specified with a bip21 encoded = address. Such as = bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=3Dhttps://bp.bustabit= .com/submit and the HTTP body should be = the raw transaction hex encoded as text. This seems too detailed. If you want to specify the message protocol, = maybe that can have it=E2=80=99s own section where you list each of the = messages, the URL, parameters and encoding. Then you can keep this = overview section shorter. The use of HTTPS kind of forces sender and recipient to use a 3rd party = service, even though this could done bilaterally. What if the payment = request contained a (single-use) Onion URL an expiration date? The = recipient would have to keep a hidden service up until the expiration = date, though the sender could try again if there=E2=80=99s temporary = reachability issue. Adding a (onion) URL to the the payment request also makes gradual = adoption easier, because recipients don=E2=80=99t need to worry if = senders support this protocol. > Step 3. Receiver processes the transaction and returns a partially = signed coinjoin >=20 > The receiver validates the transaction is valid, pays himself and is = eligible for propation. The receiver then adds one of his own inputs = (known as the "contributed input") and increase the output that pays = himself by the contributed input amount. Doing so will invalidate the = "template transaction"'s original input signatures, so the sender needs = to return this "partial transaction" back to the receiver to sign. This = is returned as a hex-encoded raw transaction a response to the original = HTTP POST request. > * Bustapay could be abused by a malicious party to query if you own a = deposit address or not. So never accept a bustapay transaction that pays = an already used deposit address Indeed, once the recipient adds funds, they reveal more about themselves = to the sender then they would otherwise. I think that needs more = elaboration. I assume the transaction in step (1) is some sort of collateral to = insure they=E2=80=99re not just trying to extract private information = from you? However if fees are low they could still double-spend it after = the recipient revealed their address, especially because the recipient = has no way of RBF=E2=80=99ing the original (though CPFP could help). = Perhaps require that the original transaction pays a fee based on the = expected size of the final transaction? >=20 > Notes for sending applications: >=20 > * The HTTP response must *not* be trusted. It should be fully = validated that no unexpected changes have been made to the transaction. Not trusting anything is obvious. :-) It=E2=80=99s better to explicitly = state what exactly needs to be verified (amounts, destinations, inputs, = etc), and maybe list a few obvious shenanigans to watch out for. A more general concern is that the sender can=E2=80=99t know for sure = the recipient really supports this protocol, so it should assume that = whatever information it pings to some API could be used maliciously. In = what ways could it be abused? Sjors --Apple-Mail=_48127117-8F35-4700-ADFA-F388148ACF8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Op 30 aug. 2018, om 22:24 heeft Ryan Havar = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende = geschreven:

=3D=3DMotivation=3D=3D
One of the most powerful heuristic's = employed by those whose goal is to undermine
bitcoin's fungiblity has been to assume all inputs of a = transaction are signed by
a single = party. In the few cases this assumption does not hold, it is = generally
readibly recognizable = (e.g. traditional coinjoins have a very obvious structure,
or multisig outputs are most frequently = validated onchain).

In addition to mixers, custodial wallets and = exchanges also contribute to breaking this heuristic; even though = there=E2=80=99s a single entity signing multiple inputs, that entity = doesn=E2=80=99t represent a single owner of the funds. As with mixers, = exchanges and custodial wallets can sometimes be spotted as well, but we = don=E2=80=99t know what percentage is missed.

Breaking this heuristic at scale would be good, = but do we know to what degree it=E2=80=99s already broken? Is there any = empirical research measuring its accuracy and false positive = rate?

Should bustapay enjoy = widespread adoption, a "v2" specification
will be = created with desired extensions.

I = would not put future promises in a BIP. Rather, explain how extension = might work.

=3D=3DSpecification=3D=3D

A = bustapay payment is made from a sender to a receiver.

Step= 1. Sender creates a bitcoin transaction paying the receiver

This= transaction must be fully valid, signed and all inputs must use segwit. = This transaction is known as the "template = transaction=E2=80=9D.

Using PSBT?

This = transaction must not be propagated on the bitcoin network.

This = can=E2=80=99t be guaranteed, and even after step 5 a reorg could cause = it to get confirmed. It=E2=80=99s useful to explain why this doesn=E2=80=99= t matter. 


Step 2. Sender gives the "template transaction" to the = receiver

This would generally be done as an HTTP = POST.
The exact URL to submit it to could be = specified with a bip21 encoded address. Such as = bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=3Dhttps://bp.bustabit.com/submit and the HTTP body should = be the raw transaction hex encoded as text.

This seems too detailed. If you want to = specify the message protocol, maybe that can have it=E2=80=99s own = section where you list each of the messages, the URL, parameters and = encoding. Then you can keep this overview section shorter.

The use of HTTPS kind of forces sender and = recipient to use a 3rd party service, even though this could done = bilaterally. What if the payment request contained a (single-use) Onion = URL an expiration date? The recipient would have to keep a hidden = service up until the expiration date, though the sender could try again = if there=E2=80=99s temporary reachability issue.

Adding a (onion) URL to the the payment request = also makes gradual adoption easier, because recipients don=E2=80=99t = need to worry if senders support this protocol.

Step 3. Receiver processes the transaction = and returns a partially signed coinjoin

The receiver validates = the transaction is valid, pays himself and is eligible for propation. = The receiver then adds one of his own inputs (known as the "contributed = input") and increase the output that pays himself by the contributed = input amount. Doing so will invalidate the "template transaction"'s = original input signatures, so the sender needs to return this "partial = transaction" back to the receiver to sign. This is returned as a = hex-encoded raw transaction a response to the original HTTP POST = request.

* Bustapay could be abused by a malicious party to query if = you own a deposit address or not. So never accept a bustapay transaction = that pays an already used deposit = address

Indeed, = once the recipient adds funds, they reveal more about themselves to the = sender then they would otherwise. I think that needs more = elaboration.

I assume the transaction in = step (1) is some sort of collateral to insure they=E2=80=99re not just = trying to extract private information from you? However if fees are low = they could still double-spend it after the recipient revealed their = address, especially because the recipient has no way of RBF=E2=80=99ing = the original (though CPFP could help). Perhaps require that the original = transaction pays a fee based on the expected size of the final = transaction?


Notes for sending applications:

* The HTTP response must *not* be = trusted. It should be fully validated that no unexpected changes have = been made to the transaction.

Not = trusting anything is obvious. :-) It=E2=80=99s better to explicitly = state what exactly needs to be verified (amounts, destinations, inputs, = etc), and maybe list a few obvious shenanigans to watch out = for.

A more general concern is that = the sender can=E2=80=99t know for sure the recipient really supports = this protocol, so it should assume that whatever information it pings to = some API could be used maliciously. In what ways could it be = abused?

Sjors
= --Apple-Mail=_48127117-8F35-4700-ADFA-F388148ACF8B-- --Apple-Mail=_35E0A336-43BB-4270-8B25-FDEBE5AD051A 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----- iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAluWY/YACgkQV/+b28ww EAmizg//YrJjH+y2VprN2yObWtCfctE3NbCgIslkprtLZFF60mbAPw3HTeZLqZiR Vzeis3RKJL62M/eli5l+AL8O8cJrzSSWmS2zZKvjuuu192id07AACHrDPgsL+mMc DDXYgxrtslh8gfWdbgOvc36A2EZXbmwzTVLqkv7j3DMMNLyF23HvL+uPo8mlNP4m O5j446YXHB/Jj8JGWlluMn6rIJ/tQ988Gif0YQ1L8xK/f/mzwx6Hp9MJX2iKKXFN 05Aj6dHOMA/EXHU/Mkxki23oGUJoxh1TgOYtT2Lt4lrcqaZ2ecwuxBP6Stgsnwbr +QsKFvhQUqYbURDr5chtzwhclsqZthOOMe06I8Fywmg2UxA2J94kamWwp5I7K98o VRlw/6ebVyvDY9nps+GiF29BbBMrjYsTPBY335C/Qf3eR/GiWmTfAEmfksOjcpGP 2FmpbnVGVbls/GsUFWqCCCcY9zLMNjFarmZCjr9Lz4AOeXHQ022iL5q1A7RXdZKJ 2GloCXHsblkYtoNn+fRO1ctq6x5ZKIuJVhAO6Fw2/UksxxrImD3kcc63Zy1zX9Fa hByZ5uRLhDwGViKt+ZcB4a5v8RNNICBIdrjveUSrQb/XVFqgqq4kAXg0GR+2gKs0 MkCC31KavbWAwZWbW1aRclWTBKdkoiTMRoL2DorupnpS97CgjDM= =ukvu -----END PGP SIGNATURE----- --Apple-Mail=_35E0A336-43BB-4270-8B25-FDEBE5AD051A--