From: rhavar@protonmail•com
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
Date: Thu, 30 Aug 2018 20:24:58 +0000 [thread overview]
Message-ID: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5416 bytes --]
I've just finished writing an implementing of this, and extremely happy with how it turned out. So I'd like to go and try go down the path of more formally describing it and getting some comments and ultimately encourage its wide-spread use.
==Abstract==
The way bitcoin transactions are overwhelming used is known to leak more
information than desirable. This has lead to fungibility concerns in bitcoin
and a raise of unreasonably effective blockchain analysis.
Bustapay proposes a simple, practical way to bust these assumptions to immediate
benefit of the sender and recievers. Furthermore it does so in such a way that
helps recievers avoid utxo bloat, a constant problem for bitcoin merchants.
==Copyright==
This BIP is in the public domain.
==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).
Bustapay requires no changes to bitcoin and creates bitcoin transactions that are
indistinguishable from normal ones.
It is worth noting that this specification has been intentionally kept as simple
as possible to encourage adoption. There are almost an endless amount of extensions
possible but the harder the implementation of clients/server the less likely it
will ever be done. Should bustapay enjoy widespread adoption, a "v2" specification
will be created with desired extensions.
==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". This transaction must not be propagated on the bitcoin network.
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.
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.
Step 4. Receiver validates, re-signs, and propagates on the bitcoin network
The receiver is responsible in making sure the "partial transaction" returned by the sender was changed correctly (it should assume the connection has been MITM'd and act accordingly), resign its original inputs and propagates this transaction over the bitcoin network. The client must be aware that the server can reorder inputs and outputs.
Step 5. Receiver observes the finalized transaction on the bitcoin network
Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout will propagate the original "template transaction" to ensure the payment happens and function a strong anti-DoS mechanism.
=== Implementation Notes ===
For anyone wanting to implement bustapay payments, here are some notes for receivers:
* A transaction can easily be checked if it's suitable for the mempool with testmempoolaccept in bitcoin core 0.17
* Tracking transactions by txid is precarious. To keep your sanity make sure all inputs are segwit. But remember segwit does not prevent txid malleability unless you validate the transaction. So really make sure you're using testmempoolaccept at the very least
* 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
* You will need to keep a mapping of which utxos people have showed you and which you revealed. So if you see them again, you can reveal the same one of your own
* Check if the transaction was already sorted according to BIP69, if so ensure the result stays that way. Otherwise probably just shuffle the inputs/outpus
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.
* The sender should be aware the original "template transaction" may be propagated at any time, and in fact can intentionally be
done so for the purpose of RBF as it should have a slightly higher fee rate.
== Credits ==
The idea is obviously based upon Dr. Maxwell's seminal CoinJoin proposal, and reduced scope inspired by a simplification of the "pay 2 endpoint" (now offline) blog post by blockstream.
-Ryan
[-- Attachment #2: Type: text/html, Size: 6789 bytes --]
next reply other threads:[~2018-08-30 20:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 20:24 rhavar [this message]
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
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='TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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