From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36231183B for ; 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 ; 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 , Bitcoin Protocol Discussion From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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