From: rhavar@protonmail•com
To: James MacWhyte <keatonatron@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
Date: Wed, 30 Jan 2019 02:46:47 +0000 [thread overview]
Message-ID: <rw6S6-g_a3GdPaJ1pspzBCAVxromSSYzw_jQhgsZ9VmWPLxfMG-DB_ne2VhMvAkpppbc20mwXXyYjUmy1ifVHHfDXGUTnZdI87omk8T6gV4=@protonmail.com> (raw)
In-Reply-To: <CAH+Axy68O76GjjKtdzwOQBS0bQauoPXJEYnrztSfYzVNDSbcNw@mail.gmail.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 --]
next prev parent reply other threads:[~2019-01-30 2:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 20:24 rhavar
2018-09-10 12:30 ` Sjors Provoost
2018-09-10 15:49 ` rhavar
2019-01-25 14:47 ` Adam Gibson
2019-01-27 7:36 ` rhavar
2019-01-27 12:20 ` Adam Gibson
2019-01-27 19:24 ` rhavar
2019-01-27 19:42 ` James MacWhyte
2019-01-27 22:11 ` rhavar
2019-01-30 2:06 ` James MacWhyte
2019-01-30 2:46 ` rhavar [this message]
2019-01-30 20:58 ` James MacWhyte
2019-01-28 4:14 ` ZmnSCPxj
2019-01-28 13:19 ` Adam Gibson
2019-01-30 8:34 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='rw6S6-g_a3GdPaJ1pspzBCAVxromSSYzw_jQhgsZ9VmWPLxfMG-DB_ne2VhMvAkpppbc20mwXXyYjUmy1ifVHHfDXGUTnZdI87omk8T6gV4=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=keatonatron@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox