Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2018-09-10 Thread Ryan Havar via bitcoin-dev
Thanks Sjors,
It's nice to get hear feedback like that, it'll help make me clear some stuff 
up. Right now I've been working on getting a reference client for both sending 
and receiving, while juggling some stuff in real life.

But here is the evolving document:
https://github.com/RHavar/bips/blob/master/bip-bustapay.mediawiki

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

Not that I'm aware of. However from what I've seen of chainalysis, it's eerily 
accurate. I've seen it cluster wallets that it really shouldn't have been able 
to do. (address-reuse is actually the biggest culprit here, we really need to 
working on reducing stopping this with stuff like bip32 based address books, 
wallet warnings on reused addresses, etc.). As for false positives of 
block-chain analysis, under normal circumstances it probably shouldn't suffer 
any. Although it was pretty easy to confuse it with specially crafted coinjoin 
transactions, although a few months later seemed to realize and decluster the 
wallets again.

> In addition to mixers, custodial wallets and exchanges also contribute to 
> breaking this heuristic

Well, kind of I guess. From a block-chain analysis point of view you'd be 
trying to figure out the transaction was to/from coinbase, rather than 
"coinbase on behalf of client XYZ". I guess the former is better than the 
later, but I think it'd be preferable if no one knew all together.

> Using PSBT?

I've got this feedback a lot, and I think it's definitely the way to go in the 
future. But at the moment compatibility and libraries are just not there that 
I'd like to stick with raw transactions for now.

> The use of HTTPS kind of forces sender and recipient to use a 3rd party 
> service, even though this could done bilaterally.

I don't really understand this point. I just used https as an example, as I 
suspect that's what every merchant will want to use. I don't really mean to 
specify the protocol though, if the client/server support  it (e.g. onion)  
then it should be fine.

> I assume the transaction in step (1) is some sort of collateral to insure 
> they’re not just trying to extract private information from you?

It's not really designed as a sort of collateral, but as a way to prevent 
someone costlessly learning about one of your inputs. The cost is that of 
spending a utxo. An attacker can always trivially double spend the "template 
transaction" because from the network's point of view the "template 
transaction" will come after an alternate (say, non-rbf) spend.  But in 
practice I don't think this is a problem, because it still imposes a cost on 
the attacker.

> In what ways could it be abused?

I just want to make it clear that senders can't blindly sign a transaction 
without verifying it. The most important thing to verify is the output 
amounts/addresses -- but I will make it more explicit.

Thanks once again for your feedback

-Ryan

‐‐‐ Original Message ‐‐‐
On Monday, 10 September 2018 05:30, Sjors Provoost  wrote:

>> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev 
>>  het volgende geschreven:
>>
>> ==Motivation==
>>
>> 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’s a single entity signing multiple 
> inputs, that entity doesn’t represent a single owner of the funds. As with 
> mixers, exchanges and custodial wallets can sometimes be spotted as well, but 
> we don’t know what percentage is missed.
>
> Breaking this heuristic at scale would be good, but do we know to what degree 
> it’s 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.
>
>> ==Specification==
>>
>> 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”.
>
> Using PSBT?
>
>> This transaction must not be propagated on the bitcoin network.
>
> This can’t be guaranteed, and even after step 5 a reorg could cause it to get 
> confirmed. It’s useful to explain why this doesn’t matter.
>
>> Step 2. Sender gives the 

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2018-09-10 Thread Sjors Provoost via bitcoin-dev

> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev 
>  het volgende geschreven:
> 
> ==Motivation==
> 
> 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’s a single entity signing multiple 
inputs, that entity doesn’t represent a single owner of the funds. As with 
mixers, exchanges and custodial wallets can sometimes be spotted as well, but 
we don’t know what percentage is missed.

Breaking this heuristic at scale would be good, but do we know to what degree 
it’s 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.

> ==Specification==
> 
> 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”.

Using PSBT?

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

This can’t be guaranteed, and even after step 5 a reorg could cause it to get 
confirmed. It’s useful to explain why this doesn’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=https://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’s 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’s temporary reachability issue.

Adding a (onion) URL to the the payment request also makes gradual adoption 
easier, because recipients don’t 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’re 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’ing 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’s 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’t 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


signature.asc
Description: