On Tuesday, January 29, 2019 6:06 PM, James MacWhyte <keatonat...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
