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

> 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 

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
bitcoin-dev mailing list

Reply via email to