Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 800BB1A24 for ; Sun, 27 Jan 2019 19:42:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6C425D3 for ; Sun, 27 Jan 2019 19:42:17 +0000 (UTC) Received: by mail-wm1-f49.google.com with SMTP id p6so11571171wmc.1 for ; Sun, 27 Jan 2019 11:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=azJeI+cHfWn5jSio2XGrw/mCjhJsK52gY3ks3TxInYk=; b=FG2OeAtsn9zQFUqFm/6EMMKLJ/mk6kWM6jJPIEB8VwUEpi/WLSht2uiZQmcgC8j9TH TKhVURF9ssdXW4RFkFJKPYaKAAkyB+a0DzqTX1P/JwV7unRBu23IC6IoQgeS1MMK7vLJ 513TCYdJZ9RhO6EUtXEKqi9HL69/hRQgI7th2K1qujYnDJTuab+5eT5bhQWYAYPUFv+8 GlKeC9VVkOfqz9MaBTWSDs+5af0Efo+bYeHIsLE13HVg6l/bhP5vkkFKHrR+4mC3T0H8 3/8H33Gmyq5t6HsPOSzn4R0FBHZVMiIDPo8RMxvhfjbG2RnxaWvvy0TYkb1Vyd9T6W4r PvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=azJeI+cHfWn5jSio2XGrw/mCjhJsK52gY3ks3TxInYk=; b=i7DDlq7n0ze/0xzo7TUgPgRRe5ba5+WSXj88HJwpBOuAu9JnEoHTM9G7gGw7QZflon IFIYY+IyBbtkACpgQ9LexnnazgP6L73ufp1L5jjbfRwkKliJuqc0CJzifznIGWzCa62s VZJGEM9fpQfI3708P/NzScOMoW3tVjw8NfKwV/FN4JP8LSI1tAKp6SXbag3awQBNXmzK uLyl+Gwj8+r1Cj4ttuveJrjeKgDWAK1c6abFR9ieefNcDU8HchwOe4IhT+ZhAPrtm2vx NCxQTnoa0hMy3uqI0QnoSG+jZomZGTJUmx+03Svxo85LCBOeS1RR8M8Q9mLEU+W/tp13 NvbA== X-Gm-Message-State: AJcUukf0y5JJ9Gvv5uhqRpCLIrd9fuzQO86eJAqXtDYCm+9c40o1foLE zFXdEHKpyvRXE2ie0ruQFuZi/X79Yjyc67LY426jYg== X-Google-Smtp-Source: ALg8bN6fhgzBV6OEkFbI7ZjZXKPd32ncxi98Y74XrdKywU9gp5lM2ddPPyuzpInYwX5HviHqun+M4kliUfxoUxu+gv4= X-Received: by 2002:a1c:bbd6:: with SMTP id l205mr13528345wmf.97.1548618135604; Sun, 27 Jan 2019 11:42:15 -0800 (PST) MIME-Version: 1.0 References: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com> <2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@gmail.com> In-Reply-To: <2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@gmail.com> From: James MacWhyte Date: Sun, 27 Jan 2019 11:42:03 -0800 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000dd9274058075c13c" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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 22:06:37 +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 19:42:21 -0000 --000000000000dd9274058075c13c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why does the template transaction need to be signed in step one and passed back and forth so many times? What is wrong with: 1. Sender creates unsigned tx with their relevant inputs and outputs. This tx is passed to receiver. 2. Receiver adds their relevant inputs and outputs and signs their portion before returning the tx to sender. 3. Sender confirms their inputs and outputs have not been modified, and signs the remainder of the tx before broadcasting it (or sending it to the recipient if you want to follow the payment protocol spec). James On Sun, Jan 27, 2019, 08:45 Adam Gibson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org wrote: > > > On 27. 01. 19 8:36, rhavar@protonmail.com wrote: > > 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 > feeling. > > > > I very much agree =3D) I really think anything that (silently) breaks t= he > assumption of common ownership of transaction inputs offers outsized > benefits for the whole ecosystem. > > > > One other idea I have is (way) better support for moving utxo's betwee= n > wallets. The least controversial use case is moving funds between wallets > you own. Like I might want to move *specific* utxo's from/to my joinmarke= t > wallet, but not create a (privacy losing / expensive) transaction. Both > core and joinmarket fail at this at a practical point of view. > > (tangential, but yes coin control in JM is an obviously necessary > feature and will be done, I just don't have time). > > > > > Like imho it'd be pretty cool having a standardized format for > (txid:vout:privatekey) with wallets showing it as "External UTXO" and > preferentially spending 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. > > Is there a missing word. "by giving a person.."? Not actually sure what > you're getting at here but I suspect it's again tangential to this BIP > discussion. > > > > > --- > > > > 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 > changes. > > > > 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 getti= ng > 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 system that is still practical. > > You know, there's considerable evidence to the contrary, I'd argue: this > idea *has* been implemented already three times: by yourself, by myself > and by Samourai. And in fully incompatible ways :) So I think the > limiting factor is in fact creating a standard that a reasonable number > of people could agree with (and I like operational definitions, so > subjective as it is, I like the goal of "good/clear enough that it could > be incorporated into something like BtcPayServer") > > > > > For instance I like PSBT and it's nice in theory. I actually had an > original implementation using it, which is how I found some bugs in the > core and golang version of PSBT). But in practice it's hugely overkill an= d > significantly increases the implementation complexity complexity and is > poorly supported. 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 other contexts). > > But this relates back to my first "generic" point that you haven't > addressed here - protocol versioning and the possibility of more than > one option. Perhaps more realistic (debatable): have the current version > be non-PSBT but with a plan to have a version bump with PSBT in future. > Stuff like that. It seems crazy to actually long term reject it. > > > > > Anyway, a big motivation for me even writing it as a BIP was to > formalize my little anti-DOS trick of privately creating a "template > transaction" which can just be dumped on the network as punishment. So if > nothing else, hopefully I'll have demonstrated it's a pretty practical wa= y > of doing things. > > > > I don't want to be that guy, but this was a central part of the proposal > that came of the meetup last summer and is in Haywood's blogpost. I mean > if you came up it with separately, then cool :) But I was there, that > was established immediately as the right way of doing this to avoid a > trivial attack. > What might have confused you is all that stuff about multiple candidates > and even ZKP approaches - those were just extra ideas about making it > really secure at large scale; but those ideas don't quite meet the goal > (for various reasons); well, arguably. The basic anti-DOS of an initial > non-coinjoin was sorta central. > (Also I'm noting you didn't respond to my critique of your "always use > the same contributions" defence; I mean, probably that's fine, it was > only really saying it isn't perfect. Was just curious to hear > your/others thoughts on it). > > > -- > > > > Also your analysis on "Unnecessary Input Heuristic" is pretty cool, but > I also don't like telling people to "avoid the UIH2" without providing th= e > actual algo they should use. But really I think it's better off in a sort > of article "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 currently just heavily biases tainted inputs (e.g. ones > associated with address reuse). > > > > Good point about algo. > I wrote my best effort at a procedure here: > > https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomm= ent-2799709 > > I asked for comments on it but got none back so far (gists are terrible > for this unfortunately, perhaps I'll have more luck on the list). > > I would argue that this issue *should* be mentioned on the BIP. A *huge* > part of what makes PayJoin/BustaPay of interest is the steganographic > feature, if you don't pay attention to this then it doesn't look like a > payment (caveat.-->). > The counterargument is Laurent's statistics which I previously linked, > suggesting that maybe 30% of txs violate this anyway, today. I'm not > sure about that, will need more analysis; Core's SRD algo may be one > reason, but anyway ... better to make things look like payments. > > It doesn't hurt to prompt an implementer to do this; whether it's > feasible in that specific wallet situation or not is up to them; whether > they want to go hog wild and control percentages of UIH1 and UIH2 and > whatnot is there business, or they can totally ignore it - but without > it being mentioned in the BIP, they may not even think of it. > > A last point, you also don't see value in being more explicit about > simple things like transaction version and locktime? Even if you think > these things should *not* be controlled, e.g. the protocol should allow > either transaction version, then it'd be better to explicitly say so. > > > > > > -Ryan > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= l Message =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-dev@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 virt= ue > >> of steganographic hiding means only minimal uptake is still enormously > >> interesting and worth pursuing; that's my current feeling. I've offere= d > >> 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 BTCPayServe= r, > >> 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 th= en > >> 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), th= is > >> must be implemented by multiple wallets to be useful, the > communication > >> protocol will need versioning (for example i have in my > >> simple/experimental Joinmarket PayJoin that sender sends min and m= ax > >> supported version and receiver responds with a chosen protocol > version > >> so we can update). I do understand that as a client-server model c= an > >> 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 > for > >> 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 i= s > 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 > correctly > >> observe, it is not yet implemented in the majority of wallets and > >> libraries. One way round that is to make it optional (possibly > combined > >> with above point about versioning). Note that for example you were > >> observing the necessity to check the sequence number was unchanged= ; > that > >> would be encapsulated by checking equality of PSBT Input > objects/fields. > >> While one can make such software architecture arguments, the reall= y > >> fundamental point is the need for standards for x-wallet > compatibility. > >> > >> - Version, Locktime: Perhaps this is not needed; in a peer to peer > >> wallet scenario I think there might be logic in trying to get cove= r > >> traffic of (Core, Electrum, others), say, by using > >> last-block-locktime-mostly, as they do. Version should be 2 and > sequence > >> is a function of your suggestion to use BIP125. Worth noting that > BIP125 > >> is not currently widely used on the network, though (see > >> https://p2sh.info/dashboard/db/replace-by-fee?orgId=3D1). For this > reason > >> 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#gistcomm= ent-2796539 > >> and some data here > >> > https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomm= ent-2800791 > >> (whole comment thread may be of interest) - note this UIH name is > afaik > >> 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 pi= ck > >> an input set where one input is larger than any output, most won't= , > and > >> some in particular never will. So I think the text here should > indicate > >> that *the receiver's contributed input(s) SHOULD be chosen to avoi= d > >> triggering the UIH2 heuristic where possible, so that the final > payjoin > >> 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 necessar= y > to > >> 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 = the > >> > >> 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 i= ts > >> 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 t= o > >> 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 p= er > >> 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, howeve= r > >> > >> they are circumstances where adding more than a single input can be > useful. > >> > >> 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 th= e > >> value in your approach, but it might end up with a re-attempted paymen= t > >> 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 u= se > >> 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 su= m > >> 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 shou= ld > >> 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 n= ot > >> 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 hap= py > >>> 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 > 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 t= o > >>> 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. > >>> =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 a= re > >>> 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 kep= t > >>> 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. > >>> =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 > it > >>> to could be specified with a bip21 encoded address. Such as > >>> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=3D > 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 nee= ds > >>> to return this "partial transaction" back to the receiver to sign. Th= is > >>> is returned as a hex-encoded raw transaction a response to the origin= al > >>> 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 paymen= t > >>> for the sent amount (as opposed to the amount that it looks like on t= he > >>> network). If the receiver does not see the finalized transaction afte= r > a > >>> timeout will propagate the original "template transaction" to ensure > the > >>> 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 note= s > >>> 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, i= f > 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 validat= ed > >>> that no unexpected changes have been made to the transaction. > >>> > >>> - The sender should be aware the original "template transaction" ma= y > 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. > >>> > >>> > >>> =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 > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000dd9274058075c13c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why does the template transaction need to be signed = in step one and passed back and forth so many times? What is wrong with:
1. Sender creates unsigned tx wi= th their relevant inputs and outputs. This tx is passed to receiver.
<= div dir=3D"auto">
2. Receiver adds their relevan= t inputs and outputs and signs their portion before returning the tx to sen= der.

3. Sender confirms = their inputs and outputs have not been modified, and signs the remainder of= the tx before broadcasting it (or sending it to the recipient if you want = to follow the payment protocol spec).

Jame= s

On Sun, Jan 27, 2019, = 08:45 Adam Gibson via bitcoin-dev <bitcoin-dev@lists.= linuxfoundation.org wrote:


On 27. 01. 19 8:36, rhavar@protonmail.com wrote:
> 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<= br> >> is still enormously interesting and worth pursuing; that's my = current feeling.
>
> I very much agree =3D) I really think anything that (silently) breaks = the assumption of common ownership of transaction inputs offers outsized be= nefits for the whole ecosystem.
>
> One other idea I have=C2=A0 is (way) better support for moving utxo= 9;s between wallets. The least controversial use case is moving funds betwe= en wallets you own. Like I might want to move *specific* utxo's from/to= my joinmarket wallet, but not create a (privacy losing / expensive) transa= ction. Both core and joinmarket fail at this at a practical point of view.<= br>
(tangential, but yes coin control in JM is an obviously necessary
feature and will be done, I just don't have time).

>
> Like imho it'd be pretty cool having a standardized format for (tx= id:vout:privatekey) with wallets showing it as "External UTXO" an= d preferentially spending it (and wallet not automatically importing any ot= her 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&#= 39;s not generally useful (for obvious reasons), but there's a lot of c= ases I think it's super cool.

Is there a missing word. "by giving a person.."? Not actually sur= e what
you're getting at here but I suspect it's again tangential to this = BIP
discussion.

>
> ---
>
> 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 c= hanges.
>
> 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 gettin= g people to implement it. I made multiple implementations of bustapay from = both the sending/receiving end, so I could try develop the easiest to imple= ment system that is still practical.

You know, there's considerable evidence to the contrary, I'd argue:= this
idea *has* been implemented already three times: by yourself, by myself
and by Samourai. And in fully incompatible ways :) So I think the
limiting factor is in fact creating a standard that a reasonable number
of people could agree with (and I like operational definitions, so
subjective as it is, I like the goal of "good/clear enough that it cou= ld
be incorporated into something like BtcPayServer")

>
> For instance I like PSBT and it's nice in theory. I actually had a= n original implementation using it, which is how I found some bugs in the c= ore and golang version of PSBT). But in practice it's hugely overkill a= nd significantly increases the implementation complexity complexity and is = poorly supported. Switching to just a raw transaction actually made everyth= ing easier. (And that's not to criticise PSBT, I would definitely want = to use it in other contexts).

But this relates back to my first "generic" point that you haven&= #39;t
addressed here - protocol versioning and the possibility of more than
one option. Perhaps more realistic (debatable): have the current version be non-PSBT but with a plan to have a version bump with PSBT in future.
Stuff like that. It seems crazy to actually long term reject it.

>
> Anyway, a big motivation for me even writing it as a BIP was to formal= ize my little anti-DOS trick of privately creating a "template transac= tion" which can just be dumped on the network as punishment. So if not= hing else, hopefully I'll have demonstrated it's a pretty practical= way of doing things.
>

I don't want to be that guy, but this was a central part of the proposa= l
that came of the meetup last summer and is in Haywood's blogpost. I mea= n
if you came up it with separately, then cool :) But I was there, that
was established immediately as the right way of doing this to avoid a
trivial attack.
What might have confused you is all that stuff about multiple candidates and even ZKP approaches - those were just extra ideas about making it
really secure at large scale; but those ideas don't quite meet the goal=
(for various reasons); well, arguably. The basic anti-DOS of an initial
non-coinjoin was sorta central.
(Also I'm noting you didn't respond to my critique of your "al= ways use
the same contributions" defence; I mean, probably that's fine, it = was
only really saying it isn't perfect. Was just curious to hear
your/others thoughts on it).

> --
>
> Also your analysis on "Unnecessary Input Heuristic" is prett= y cool, but I also don't like telling people to "avoid the UIH2&qu= ot; without providing the actual algo they should use. But really I think i= t's better off in a sort of article "how to pick contributed input= s" or something, as while it's nice it's not a huge deal and t= here's a lot of debatable tradeoffs that can/should be used. For instan= ce the implementation I wrote for bustabit.com currentl= y just heavily biases tainted inputs (e.g. ones associated with address reu= se).
>

Good point about algo.
I wrote my best effort at a procedure here:
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gist= comment-2799709

I asked for comments on it but got none back so far (gists are terrible
for this unfortunately, perhaps I'll have more luck on the list).

I would argue that this issue *should* be mentioned on the BIP. A *huge* part of what makes PayJoin/BustaPay of interest is the steganographic
feature, if you don't pay attention to this then it doesn't look li= ke a
payment (caveat.-->).
The counterargument is Laurent's statistics which I previously linked,<= br> suggesting that maybe 30% of txs violate this anyway, today. I'm not sure about that, will need more analysis; Core's SRD algo may be one reason, but anyway ... better to make things look like payments.

It doesn't hurt to prompt an implementer to do this; whether it's feasible in that specific wallet situation or not is up to them; whether they want to go hog wild and control percentages of UIH1 and UIH2 and
whatnot is there business, or they can totally ignore it - but without
it being mentioned in the BIP, they may not even think of it.

A last point, you also don't see value in being more explicit about
simple things like transaction version and locktime? Even if you think
these things should *not* be controlled, e.g. the protocol should allow
either transaction version, then it'd be better to explicitly say so. >
>
> -Ryan
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin= al Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<= br> > On Friday, January 25, 2019 6:47 AM, Adam Gibson via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer n= oreferrer" target=3D"_blank">bitcoin-dev@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 enormo= usly
>> interesting and worth pursuing; that's my current feeling. I&#= 39;ve offered
>> more detailed thoughts in my blog post[1] (def not required readin= g here).
>>
>> Both Joinmarket and Samourai have started implementing this kind o= f
>> transaction. And while that's interesting experimentally, some= kind of
>> cross-wallet standard would be helpful, albeit there some differen= ces
>> between that and the merchant/centralized service use-case.
>>
>> We might imagine as a concrete goal for this BIP to create somethi= ng
>> that would be acceptable for inclusion into a project like BTCPayS= erver,
>> so that it could be used in a realistic use case by smaller bitcoi= n
>> accepting merchants.
>>
>> Comments to the BIP[2] as follows, with generic comments first, an= d then
>> specific comments for existing points in the BIP:
>>
>> [1] https://joinmarket.me/blog= /blog/payjoin
>> [2] htt= ps://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
>>
>> -=C2=A0 =C2=A0Protocol versioning. Since inevitably (even if only = merchants), this
>>=C2=A0 =C2=A0 =C2=A0must be implemented by multiple wallets to be u= seful, the communication
>>=C2=A0 =C2=A0 =C2=A0protocol will need versioning (for example i ha= ve in my
>>=C2=A0 =C2=A0 =C2=A0simple/experimental Joinmarket PayJoin that sen= der sends min and max
>>=C2=A0 =C2=A0 =C2=A0supported version and receiver responds with a = chosen protocol version
>>=C2=A0 =C2=A0 =C2=A0so we can update). I do understand that as a cl= ient-server model can
>>=C2=A0 =C2=A0 =C2=A0apply here, we can ditch a lot of the complexit= ies around network/p2p
>>=C2=A0 =C2=A0 =C2=A0interaction, but this much at least seems neces= sary.
>>
>> -=C2=A0 =C2=A0Although it has its logic, I don't think "B= ustapay" is a good name for
>>=C2=A0 =C2=A0 =C2=A0this protocol. I prefer "PayJoin" whi= ch is neutral sounding and
>>=C2=A0 =C2=A0 =C2=A0self-descriptive. Needless to say this is not a= hill I intend to die on.
>>
>> -=C2=A0 =C2=A0PSBT/BIP174. I realise this has already been discuss= ed, but this is a
>>=C2=A0 =C2=A0 =C2=A0good example of what this standardisation was d= esigned for, so I'd be
>>=C2=A0 =C2=A0 =C2=A0against not including it, even given the realit= y that, as you correctly
>>=C2=A0 =C2=A0 =C2=A0observe, it is not yet implemented in the major= ity of wallets and
>>=C2=A0 =C2=A0 =C2=A0libraries. One way round that is to make it opt= ional (possibly combined
>>=C2=A0 =C2=A0 =C2=A0with above point about versioning). Note that f= or example you were
>>=C2=A0 =C2=A0 =C2=A0observing the necessity to check the sequence n= umber was unchanged; that
>>=C2=A0 =C2=A0 =C2=A0would be encapsulated by checking equality of P= SBT Input objects/fields.
>>=C2=A0 =C2=A0 =C2=A0While one can make such software architecture a= rguments, the really
>>=C2=A0 =C2=A0 =C2=A0fundamental point is the need for standards for= x-wallet compatibility.
>>
>> -=C2=A0 =C2=A0Version, Locktime: Perhaps this is not needed; in a = peer to peer
>>=C2=A0 =C2=A0 =C2=A0wallet scenario I think there might be logic in= trying to get cover
>>=C2=A0 =C2=A0 =C2=A0traffic of (Core, Electrum, others), say, by us= ing
>>=C2=A0 =C2=A0 =C2=A0last-block-locktime-mostly, as they do. Version= should be 2 and sequence
>>=C2=A0 =C2=A0 =C2=A0is a function of your suggestion to use BIP125.= Worth noting that BIP125
>>=C2=A0 =C2=A0 =C2=A0is not currently widely used on the network, th= ough (see
>>=C2=A0 =C2=A0 =C2=A0https://p2sh.info/dashboard/db/replace-by-fee?orgId=3D1). For this= reason
>>=C2=A0 =C2=A0 =C2=A0it should perhaps be explicitly only optional.<= br> >>
>> -=C2=A0 =C2=A0Avoidance of non-payment "Unnecessary Input Heu= ristic" (1, 2). For
>>=C2=A0 =C2=A0 =C2=A0reference, see the definition here
>>=C2=A0 =C2=A0 =C2=A0https://gist.github.com/AdamISZ/4551b9477= 89d3216bacfcb7af25e029e#gistcomment-2796539
>>=C2=A0 =C2=A0 =C2=A0and some data here
>>=C2=A0 =C2=A0 =C2=A0https://gist.github.com/AdamISZ/4551b9477= 89d3216bacfcb7af25e029e#gistcomment-2800791
>>=C2=A0 =C2=A0 =C2=A0(whole comment thread may be of interest) - not= e this UIH name is afaik
>>=C2=A0 =C2=A0 =C2=A0Chris Belcher's invention, it seems useful = as a categorisation.
>>=C2=A0 =C2=A0 =C2=A0So, it seems that UIH2 is more important to avo= id; while some more
>>=C2=A0 =C2=A0 =C2=A0sophisticated wallet coin selection algorithms = may occasionally pick
>>=C2=A0 =C2=A0 =C2=A0an input set where one input is larger than any= output, most won't, and
>>=C2=A0 =C2=A0 =C2=A0some in particular never will. So I think the t= ext here should indicate
>>=C2=A0 =C2=A0 =C2=A0that *the receiver's contributed input(s) S= HOULD be chosen to avoid
>>=C2=A0 =C2=A0 =C2=A0triggering the UIH2 heuristic where possible, s= o that the final payjoin
>>=C2=A0 =C2=A0 =C2=A0transaction is maximally plausible as an ordina= ry payment" or similar.
>>=C2=A0 =C2=A0 =C2=A0UIH1 is a nice-to-have (meaning the plausibilit= y extends to two
>>=C2=A0 =C2=A0 =C2=A0different (both wrong) payment amounts, but it = may not be necessary to
>>=C2=A0 =C2=A0 =C2=A0mention it in the BIP.
>>
>>=C2=A0 =C2=A0 =C2=A0Specific comments
>>=C2=A0 =C2=A0 =C2=A0=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 prop= agates on the
>>
>> bitcoin network=3D=3D=3D=3D
>>
>> I believe this should say "Sender" not Receiver. Also fo= r the next
>> sentence, s/receiver/sender/:
>>
>>>> The receiver MUST validate the ''partial transacti= on'' was changed
>>
>> correctly and non-maliciously (to allow using potentially untruste= d
>> 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 "recei= ver gives
>> sender other inputs belonging to sender to unwittingly sign (descr= ibed
>> below), should be highlighted here, perhaps with the phrase "= re-sign its
>> ORIGINAL inputs" (only!)".
>>
>>>> When the sender is creating a "template transaction&q= uot; it is done
>>
>> almost identically to creating a normal send, with the exception t= hat
>> only segwit inputs may be used. The sender is also encouraged to u= se a
>> slightly more aggressive feerate than usual as well as BIP125 (Opt= -in
>> Full Replace-by-Fee Signaling), but neither is strictly required.<= br> >>
>> "slightly more aggressive feerate than usual" - this I u= nderstand 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 be= low)
>> 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 transactio= n (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<= br> >> (non-error) response indicating that it will broadcast the templat= e tx
>> in this case?
>>
>>>> Its generally advised to only add a single contributed inp= ut, however
>>
>> they are circumstances where adding more than a single input can b= e useful.
>>
>> 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&q= uot;). I guess
>> it's because of your approach to fees. I'd prefer not to c= reate 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 in= puts
>> 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 contribute= d input
>> utxos, but (2) how should this be updated if you need to spend the=
>> contribution mentioned in (1)? Ironically use of payjoin exacerbat= es
>> 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 se= e the
>> value in your approach, but it might end up with a re-attempted pa= yment
>> being rejected. Certainly the more complex suggested solutions com= ing
>> out of the summer 2018 coinjoin workshop aren't as practical a= s this,
>> and may be overkill for small merchants/receivers.
>>
>>>> It is strongly preferable that the receiver makes an effor= t 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 cann= ot 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 us= age of
>> multi-type-input transactions), which is a very different thing th= an 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 gener= ally will
>>
>> want to adjust the output that pays himself by increasing it by th= e sum
>> of the contributed input amounts (minus any fees he wants to
>> contribute). However the only strict requirement is that the recei= ver
>> must never add or remove inputs, and must not ever decrease any >> output amount.
>>
>> "must never add or remove inputs" - did you mean "m= ust never remove
>> inputs"? he surely has to add one! Or, perhaps you mean he mu= st 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 disag= reed with this
>> but it is a better option than the one I currently chose in Joinma= rket
>> 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 you= r
>> 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 chang= e.
>>
>> 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 ex= tremely 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 ulti= mately
>>> encourage its wide-spread use.
>>> =3D=3DAbstract=3D=3D
>>> The way bitcoin transactions are overwhelming used is known to= leak more
>>> information than desirable. This has lead to fungibility conce= rns in bitcoin
>>> and a raise of unreasonably effective blockchain analysis.
>>> Bustapay proposes a simple, practical way to bust these assump= tions 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 bitco= in merchants.
>>> =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 who= se goal is to
>>> undermine
>>> bitcoin's fungiblity has been to assume all inputs of a tr= ansaction 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 tr= ansactions
>>> that are
>>> indistinguishable from normal ones.
>>> It is worth noting that this specification has been intentiona= lly 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 t= he 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 receiv= er
>>> This transaction must be fully valid, signed and all inputs mu= st use
>>> segwit. This transaction is known as the "template transa= ction". This
>>> transaction must not be propagated on the bitcoin network.
>>> Step 2. Sender gives the "template transaction" to t= he 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=3Dhttps://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 parti= ally
>>> 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 invalid= ate the
>>> "template transaction"'s original input signatur= es, so the sender needs
>>> to return this "partial transaction" back to the rec= eiver 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 bi= tcoin network
>>> The receiver is responsible in making sure the "partial t= ransaction"
>>> returned by the sender was changed correctly (it should assume= the
>>> connection has been MITM'd and act accordingly), resign it= s original
>>> inputs and propagates this transaction over the bitcoin networ= k. The
>>> client must be aware that the server can reorder inputs and ou= tputs.
>>> Step 5. Receiver observes the finalized transaction on the bit= coin network
>>> Once the receiver has seen the finalized transactions on the n= etwork
>>> (and has enough confirmations) it can process it like a normal= payment
>>> for the sent amount (as opposed to the amount that it looks li= ke on the
>>> network). If the receiver does not see the finalized transacti= on after a
>>> timeout will propagate the original "template transaction= " to ensure the
>>> 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 so= me notes
>>> for receivers:
>>>
>>> -=C2=A0 =C2=A0A transaction can easily be checked if it's = suitable for the mempool
>>>=C2=A0 =C2=A0 =C2=A0with testmempoolaccept in bitcoin core 0.17=
>>>
>>> -=C2=A0 =C2=A0Tracking transactions by txid is precarious. To = keep your sanity make
>>>=C2=A0 =C2=A0 =C2=A0sure all inputs are segwit. But remember se= gwit does not prevent txid
>>>=C2=A0 =C2=A0 =C2=A0malleability unless you validate the transa= ction. So really make sure
>>>=C2=A0 =C2=A0 =C2=A0you're using testmempoolaccept at the v= ery least
>>>
>>> -=C2=A0 =C2=A0Bustapay could be abused by a malicious party to= query if you own a
>>>=C2=A0 =C2=A0 =C2=A0deposit address or not. So never accept a b= ustapay transaction that pays
>>>=C2=A0 =C2=A0 =C2=A0an already used deposit address
>>>
>>> -=C2=A0 =C2=A0You will need to keep a mapping of which utxos p= eople have showed you
>>>=C2=A0 =C2=A0 =C2=A0and which you revealed. So if you see them = again, you can reveal the
>>>=C2=A0 =C2=A0 =C2=A0same one of your own
>>>
>>> -=C2=A0 =C2=A0Check if the transaction was already sorted acco= rding to BIP69, if so
>>>=C2=A0 =C2=A0 =C2=A0ensure the result stays that way. Otherwise= probably just shuffle the
>>>=C2=A0 =C2=A0 =C2=A0inputs/outpus
>>>
>>>
>>> Notes for sending applications:
>>>
>>> -=C2=A0 =C2=A0The HTTP response must not be trusted. It should= be fully validated
>>>=C2=A0 =C2=A0 =C2=A0that no unexpected changes have been made t= o the transaction.
>>>
>>> -=C2=A0 =C2=A0The sender should be aware the original "te= mplate transaction" may be
>>>=C2=A0 =C2=A0 =C2=A0propagated at any time, and in fact can int= entionally be
>>>=C2=A0 =C2=A0 =C2=A0=C2=A0 done so for the purpose of RBF as it= should have a slightly higher fee
>>>=C2=A0 =C2=A0 =C2=A0rate.
>>>
>>>
>>> =3D=3D Credits =3D=3D
>>> The idea is obviously based upon Dr. Maxwell's seminal Coi= nJoin
>>> proposal, and reduced scope inspired by a simplification of th= e "pay 2
>>> endpoint" (now offline) blog post by blockstream.
>>> -Ryan
>>>
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundat= ion.org
>>> htt= ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.or= g
>> https:/= /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
--000000000000dd9274058075c13c--