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

[rhavar@protonmail.com]

[-- Attachment #1: Type: text/plain, Size: 2816 bytes --]

On Tuesday, January 29, 2019 6:06 PM, James MacWhyte <keatonatron@gmail.com> wrote:

> I'm not convinced this is a valid concern, at least not valid enough to add extra complications to the process.

Signing a transaction is something a wallet needs to be able to do anyway AND at the final-step. And actually a signed transaction is _simpler_ because it's more standard and way format to send and validate.

> The sender could still refuse to sign the final transaction after they see the recipient's in-/outputs; "show me yours and I'll show you mine" isn't much of a spy deterrent, and nothing here prevents a DOS attack.

If the sender refuses to sign the final transaction, the receiver just propagates the template transaction which pays the receiver! So it's a pretty weak attack.

The only real attack is that the sender could double-spend the template-transaction before it's propagated, but the cost of doing this isn't free, as at the very least you need to pay the transaction fees of creating a double spend. It's not an amazingly good defence, but it's good enough that it's unlikely to get abused (and an attacker would only learn a single utxo of the receiver) .

> As an implementor, I would suggest keeping the protocol as simple as possible. By dropping the signing in the first step, the recipient doesn't need to maintain the ability to lookup and verify unspent outputs.

Being able to verify a transaction tends to be pretty simple in practice.  (e.g. `testmempoolaccept` in bitcoin core's wallet) but if it's really hard for a receiver to do, it can easily just not do it... (and assume the template transaction is valid even if it's not).

But I suspect this actually complicates the job for the receiver, because now you have to deal with transaction malleability as they can now give you an invalid transaction, you sign it  and then they malleate into a valid transaction with a different txid. So if you're tracking the transaction by txid, you'll get really confused...).

> It also would enforce the increased privacy, which the sender obviously wants if they are going down this path

I guess that's a valid concern. A sender might want to make a payment, but *only* if it can be done via a bustapay, while the current spec doesn't support that.

But there's no way that justifies removing the protection for receivers. Without some _basic_ protection, every company that takes bustapayments will just get constantly attacked by a simple costless `wget` that leaks their wallet utxos...

The only viable way I can see, would be the sender pays the first part of his invoice in lightning. And then pays the rest with a bustapay. Now the anti-spy thing is the fact the first part of the invoice was already paid.

But with so many moving parts, no one is ever going to implement that :P

[-- Attachment #2: Type: text/html, Size: 3733 bytes --]