path: root/4b/5619c521d6f63b54d363b539f382e2ec314fcf

Return-Path: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 36231183B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Jan 2019 07:37:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F303F13A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Jan 2019 07:37:08 +0000 (UTC)
Date: Sun, 27 Jan 2019 07:36:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1548574624;
	bh=pB8dBmL2n0UqPqpLmE5+pIwLznzJwQtymXxY2p4aEts=;
	h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
	From;
	b=mHaro4+yhM7QSrY3JBg7Gv/uRDfTNZBduhj6R4FBwWeatZJNyfp5u5fXXoJV3xWHP
	PS0x+jLWzIOMTQnhw05sIPgyVWfsCc2C7kbPBae11xPq8cGYekvWZ9zoFWPL34l/af
	PmB65Q90pKKZk957tLC7B+Ksowq3aKu99n/4x+bI=
To: Adam Gibson <ekaggata@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com>
In-Reply-To: <e15c5dd7-6fe1-b253-e129-aeae6493acd1@gmail.com>
References: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com>
	<e15c5dd7-6fe1-b253-e129-aeae6493acd1@gmail.com>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 27 Jan 2019 16:43:56 +0000
Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver
	coinjoin protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jan 2019 07:37:11 -0000

Thanks Adam,

I have fixed the mistakes you have pointed out: https://github.com/bitcoin/=
bips/pull/754

Thanks for the detailed look!

> but its virtue of steganographic hiding means only minimal uptake
> is still enormously interesting and worth pursuing; that's my current fee=
ling.

I very much agree =3D) I really think anything that (silently) breaks the a=
ssumption of common ownership of transaction inputs offers outsized benefit=
s for the whole ecosystem.

One other idea I have  is (way) better support for moving utxo's between wa=
llets. The least controversial use case is moving funds between wallets you=
 own. Like I might want to move *specific* utxo's from/to my joinmarket wal=
let, but not create a (privacy losing / expensive) transaction. Both core a=
nd joinmarket fail at this at a practical point of view.

Like imho it'd be pretty cool having a standardized format for (txid:vout:p=
rivatekey) with wallets showing it as "External UTXO" and preferentially sp=
ending it (and wallet not automatically importing any other utxo from that =
address).

Taken a bit further (this is the part which everyone hates) you could send =
someone money (or withdraw it from a service) by giving a person. It's not =
generally useful (for obvious reasons), but there's a lot of cases I think =
it's super cool.

---

Getting back on topic, without trying to do a point-by-point reply, I agree=
 with pretty much everything you said but I am reluctant to make any change=
s.

I don't meant to be obtuse or anything, but I strongly believe the limiting=
 factor to adoption to all these protocols is actually just getting people =
to implement it. I made multiple implementations of bustapay from both the =
sending/receiving end, so I could try develop the easiest to implement syst=
em that is still practical.

For instance I like PSBT and it's nice in theory. I actually had an origina=
l implementation using it, which is how I found some bugs in the core and g=
olang version of PSBT). But in practice it's hugely overkill and significan=
tly increases the implementation complexity complexity and is poorly suppor=
ted. Switching to just a raw transaction actually made everything easier. (=
And that's not to criticise PSBT, I would definitely want to use it in othe=
r contexts).

Anyway, a big motivation for me even writing it as a BIP was to formalize m=
y little anti-DOS trick of privately creating a "template transaction" whic=
h can just be dumped on the network as punishment. So if nothing else, hope=
fully I'll have demonstrated it's a pretty practical way of doing things.

--

Also your analysis on "Unnecessary Input Heuristic" is pretty cool, but I a=
lso don't like telling people to "avoid the UIH2" without providing the act=
ual algo they should use. But really I think it's better off in a sort of a=
rticle "how to pick contributed inputs" or something, as while it's nice it=
's not a huge deal and there's a lot of debatable tradeoffs that can/should=
 be used. For instance the implementation I wrote for bustabit.com currentl=
y just heavily biases tainted inputs (e.g. ones associated with address reu=
se).



-Ryan

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, January 25, 2019 6:47 AM, Adam Gibson via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

> Ryan and list,
> I want to add some commentary to this (BIP79) to see if we can get
> further in standardizing this idea.
>
> When I first mulled it over I thought it too impractical, but its virtue
> of steganographic hiding means only minimal uptake is still enormously
> interesting and worth pursuing; that's my current feeling. I've offered
> more detailed thoughts in my blog post[1] (def not required reading here)=
.
>
> Both Joinmarket and Samourai have started implementing this kind of
> transaction. And while that's interesting experimentally, some kind of
> cross-wallet standard would be helpful, albeit there some differences
> between that and the merchant/centralized service use-case.
>
> We might imagine as a concrete goal for this BIP to create something
> that would be acceptable for inclusion into a project like BTCPayServer,
> so that it could be used in a realistic use case by smaller bitcoin
> accepting merchants.
>
> Comments to the BIP[2] as follows, with generic comments first, and then
> specific comments for existing points in the BIP:
>
> [1] https://joinmarket.me/blog/blog/payjoin
> [2] https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki
>
> Generic comments
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> -   Protocol versioning. Since inevitably (even if only merchants), this
>     must be implemented by multiple wallets to be useful, the communicati=
on
>     protocol will need versioning (for example i have in my
>     simple/experimental Joinmarket PayJoin that sender sends min and max
>     supported version and receiver responds with a chosen protocol versio=
n
>     so we can update). I do understand that as a client-server model can
>     apply here, we can ditch a lot of the complexities around network/p2p
>     interaction, but this much at least seems necessary.
>
> -   Although it has its logic, I don't think "Bustapay" is a good name fo=
r
>     this protocol. I prefer "PayJoin" which is neutral sounding and
>     self-descriptive. Needless to say this is not a hill I intend to die =
on.
>
> -   PSBT/BIP174. I realise this has already been discussed, but this is a
>     good example of what this standardisation was designed for, so I'd be
>     against not including it, even given the reality that, as you correct=
ly
>     observe, it is not yet implemented in the majority of wallets and
>     libraries. One way round that is to make it optional (possibly combin=
ed
>     with above point about versioning). Note that for example you were
>     observing the necessity to check the sequence number was unchanged; t=
hat
>     would be encapsulated by checking equality of PSBT Input objects/fiel=
ds.
>     While one can make such software architecture arguments, the really
>     fundamental point is the need for standards for x-wallet compatibilit=
y.
>
> -   Version, Locktime: Perhaps this is not needed; in a peer to peer
>     wallet scenario I think there might be logic in trying to get cover
>     traffic of (Core, Electrum, others), say, by using
>     last-block-locktime-mostly, as they do. Version should be 2 and seque=
nce
>     is a function of your suggestion to use BIP125. Worth noting that BIP=
125
>     is not currently widely used on the network, though (see
>     https://p2sh.info/dashboard/db/replace-by-fee?orgId=3D1). For this re=
ason
>     it should perhaps be explicitly only optional.
>
> -   Avoidance of non-payment "Unnecessary Input Heuristic" (1, 2). For
>     reference, see the definition here
>     https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gist=
comment-2796539
>     and some data here
>     https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gist=
comment-2800791
>     (whole comment thread may be of interest) - note this UIH name is afa=
ik
>     Chris Belcher's invention, it seems useful as a categorisation.
>     So, it seems that UIH2 is more important to avoid; while some more
>     sophisticated wallet coin selection algorithms may occasionally pick
>     an input set where one input is larger than any output, most won't, a=
nd
>     some in particular never will. So I think the text here should indica=
te
>     that *the receiver's contributed input(s) SHOULD be chosen to avoid
>     triggering the UIH2 heuristic where possible, so that the final payjo=
in
>     transaction is maximally plausible as an ordinary payment" or similar=
.
>     UIH1 is a nice-to-have (meaning the plausibility extends to two
>     different (both wrong) payment amounts, but it may not be necessary t=
o
>     mention it in the BIP.
>
>     Specific comments
>     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> > > =3D=3D=3D=3DStep 4. Receiver validates, re-signs, and propagates on t=
he
>
> bitcoin network=3D=3D=3D=3D
>
> I believe this should say "Sender" not Receiver. Also for the next
> sentence, s/receiver/sender/:
>
> > > The receiver MUST validate the ''partial transaction'' was changed
>
> correctly and non-maliciously (to allow using potentially untrusted
> communication channels), re-sign its original inputs and propagate the
> final transaction over the bitcoin network.
>
> Your very correct highlighting of the attack vector of "receiver gives
> sender other inputs belonging to sender to unwittingly sign (described
> below), should be highlighted here, perhaps with the phrase "re-sign its
> ORIGINAL inputs" (only!)".
>
> > > When the sender is creating a "template transaction" it is done
>
> almost identically to creating a normal send, with the exception that
> only segwit inputs may be used. The sender is also encouraged to use a
> slightly more aggressive feerate than usual as well as BIP125 (Opt-in
> Full Replace-by-Fee Signaling), but neither is strictly required.
>
> "slightly more aggressive feerate than usual" - this I understand is to
> make up for receiver contributed utxo, OK.
>
> "only segwit inputs" - it certainly makes things simpler. One can work
> with non-segwit inputs but especially considering (as mentioned below)
> we really ought to "MUST" the part about matching input types, I tend to
> agree that non-segwit should be disallowed.
>
> > > The receiver must add at least one input to the transaction (the
>
> "contributed inputs"). If the receiver has no inputs, it should use a
> 500 internal server error, so the client can send the transaction as per
> normal (or try again later).
>
> Would it not be much simpler for the server to return a different
> (non-error) response indicating that it will broadcast the template tx
> in this case?
>
> > > Its generally advised to only add a single contributed input, however
>
> they are circumstances where adding more than a single input can be usefu=
l.
>
> I don't see a good reason to advise the use of only 1 input? (but this
> will also connect with the above generic comment about "UIH"). I guess
> it's because of your approach to fees. I'd prefer not to create a
> limitation here.
>
> > > To prevent an attack where a receiver is continually sent variations
>
> of the same transaction to enumerate the receivers utxo set, it is
> essential that the receiver always returns the same contributed inputs
> when it's seen the same inputs.
>
> This is an approach to avoiding this problem which has the virtue of
> simplicity, but it seems a little problematic. (1) You must keep a
> mapping of proposed payment utxos to one's proposed contributed input
> utxos, but (2) how should this be updated if you need to spend the
> contribution mentioned in (1)? Ironically use of payjoin exacerbates
> this issue, because it results in a smaller number of utxos being held
> by the receiver at any one time :) All this considered, I still see the
> value in your approach, but it might end up with a re-attempted payment
> being rejected. Certainly the more complex suggested solutions coming
> out of the summer 2018 coinjoin workshop aren't as practical as this,
> and may be overkill for small merchants/receivers.
>
> > > It is strongly preferable that the receiver makes an effort to pick a
>
> contributed input of the same type as the other transaction inputs if
> possible.
>
> I have also thought about this and you could reasonably argue this
> should be a MUST section in the BIP, that is, if the receiver cannot use
> inputs of the same type, he should fall back to the template
> transaction. A mixed-input payjoin/coinjoin is essentially
> near-perfectly identifiable as such (there is almost zero other usage of
> multi-type-input transactions), which is a very different thing than a
> non-identifiable payjoin transaction. That may or may not be OK to the
> sender. This is debatable though, for sure.
>
> > > After adding inputs to the transaction, the receiver generally will
>
> want to adjust the output that pays himself by increasing it by the sum
> of the contributed input amounts (minus any fees he wants to
> contribute). However the only strict requirement is that the receiver
> must never add or remove inputs, and must not ever decrease any
> output amount.
>
> "must never add or remove inputs" - did you mean "must never remove
> inputs"? he surely has to add one! Or, perhaps you mean he must not
> alter the list of inputs provided by the sender (in which case it should
> be clarified).
>
> "must not decrease any output amount" - I initally disagreed with this
> but it is a better option than the one I currently chose in Joinmarket
> payjoin (sender pays all fee as long as receiver utxos are not too
> much). So this means that the receiver either consciously chooses to not
> increase the fee, meaning the fee rate may be a bit low (hence your
> earlier comment about being generous, got it), or contributes via the
> payout amount. I guess the latter might break merchant software
> expecting to have amount output fixed and fees determined by change.
>
> Regards,
> Adam Gibson/waxwing
>
> On 30. 08. 18 22:24, Ryan Havar via bitcoin-dev wrote:
>
> > 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.
> > =3D=3DAbstract=3D=3D
> > The way bitcoin transactions are overwhelming used is known to leak mor=
e
> > information than desirable. This has lead to fungibility concerns in bi=
tcoin
> > 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 mercha=
nts.
> > =3D=3DCopyright=3D=3D
> > This BIP is in the public domain.
> > =3D=3DMotivation=3D=3D
> > 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 transaction=
s
> > 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 o=
f
> > 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.
> > =3D=3DSpecification=3D=3D
> > 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 i=
t
> > to could be specified with a bip21 encoded address. Such as
> > bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=3Dhttps://bp.busta=
bit.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 net=
work
> > 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 netw=
ork
> > 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 th=
e
> > payment happens and function a strong anti-DoS mechanism.
> > =3D=3D=3D Implementation Notes =3D=3D=3D
> > 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 mempoo=
l
> >     with testmempoolaccept in bitcoin core 0.17
> >
> > -   Tracking transactions by txid is precarious. To keep your sanity ma=
ke
> >     sure all inputs are segwit. But remember segwit does not prevent tx=
id
> >     malleability unless you validate the transaction. So really make su=
re
> >     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 y=
ou
> >     and which you revealed. So if you see them again, you can reveal th=
e
> >     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 t=
he
> >     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
> >     =C2=A0 done so for the purpose of RBF as it should have a slightly =
higher fee
> >     rate.
> >
> >
> > =3D=3D Credits =3D=3D
> > 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
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev