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 8F4EE1A19 for ; Sun, 27 Jan 2019 19:24:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E48883A for ; Sun, 27 Jan 2019 19:24:16 +0000 (UTC) Date: Sun, 27 Jan 2019 19:24:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1548617054; bh=KvkiKRhc8Ux5BoUUPYMkZ/iqGIu2FwpIh81ob/fKk9M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Pr7SVOMHguKYlytZu9t0ltAeAz1slgliFlZZCRfV+WDN+3wyBnuYBY9M9qzh3O9y3 gHiavFStsK/gPz581SYdRNgGg9u2GOQOpRqgdrbdGh7pTn7zRvxQN39sfbdGLN5Niq tzbhX4T1NAT7W34efsEtPO+eq9xTDdVgj8b//ntA= To: Adam Gibson From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: In-Reply-To: <2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@gmail.com> References: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com> <2cd4fe6d-c0ca-5ae7-4107-38e1609743a8@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 22:06:37 +0000 Cc: Bitcoin Protocol Discussion 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:24:18 -0000 > 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. Correct on both points. I meant to say "giving a (txid:vout:privkey)" to a = person as means of payment. > So I think the limiting factor is in fact creating a standard that a reas= onable 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") The problem with BtcPayServer (and a lot of similar software), is that it's= not very unsuitable for any sender/receiver coinjoin due to it not having = its own wallet. As I understand the basic architecture is just a fancy wrap= per around bip32 address generation and monitoring the payment to those add= resses. This means that adding support is not only a large code change, but= it also entails a substantial change for merchants (you can't just have yo= ur payments flow into your trezor, but need to run a hot wallet) But I strongly believe that bustapay is good enough _right now_ for BtcPayS= erver integration (which I'd happily contribute myself, if it wasn't for my= unfamiliarity of the project and c#) > 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. Adding backwards-compatible versioning at a later stage would be pretty tri= vial through either the URL or HTTP header (e.g version=3D2) and if break= ing backwards compatible is desirable it can also easily been done (e.g. bu= mp the bip21 or send an incompatible request/response). I don't see this as= a problem at all, and I'm not rejecting it long-term, I just don't think i= t's particularly helpful to bikeshed now, when adoption is pretty much zero= . > 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. Oh wow. had no idea. I saw the part about the receiver spamming the sender = with a bunch of transactions, where only 1 of them are real and thought "ew= ww" and "came up" with the idea of a "template transaction" instead. I was = always wondering why no one came up it, but now it makes sense. The transac= tion-spam stage was just an _additional_ layer of protection. Ok, now I feel like an idiot =3D) Thanks for letting me know. > 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. I think it's interesting, but I don't think it particularly matters. Avoidi= ng UIH1 I think is pretty much irrelevant, as it'll likely just confuse any= analysis into thinking the payment is the reverse of what it actually is. = And wallets already don't care about violating UIH2(as a way to do implicit= consolidation). If 30% of tx's are violating it, you can be pretty sure it= means the _vast majority_ of wallets run coin selection in such a way that= can violation UIH2. Most wallets use a coin selection algorithm that you = can approximate with: while !enoughMoney { inputs +=3D getAnotherInput(); } and don't run a final pass that would prune superfluous inputs. Even coins= ayer (shill alert) which I believe runs the most advanced coin selection al= gorithms, will routinely and intentionally violate UIH2 when it's ideal (e.= g. most classic case: when `consolidationFeeRate >=3D minFeeRate`). I'm not trying to dismiss your analysis, as I find it interesting. I'm just= against increasing the cognitive burden on implementations by mentioning a= ll this stuff, when the truth is it (barely) matters. If wallets routinely= avoided UIH2 and making a UIH2 payment would "out" the transaction as much= more likely to be a bustapay, then I'd definitely reconsider and provide a= basic suggestion into how to try avoid it. And like I said, I also think there's much more important things that go in= to "picking a contributed input" than just this. > 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. My intention was that wallets create a transaction exactly like they normal= ly would do, and use that as the template transaction. The only time I want= ed to be prescriptive was when it would increase the implementation complex= ity (e.g. being non-segwit compatible is a pain in the ass. So I'd rather j= ust be "pure segwit only" transactions). But something like locktime makes = no difference as long as the transaction is mempool eligible, so I'd rather= just wallets do what they do anyway. Although I think there should be a separate discussion on improving the uni= formity of bitcoin transactions in general. The current state of affairs is= really atrocious. --- P.S. I know I come across as obstinate, but it's not really so. If you can = come up with an alternative to bustapay with some traction, I'd love to get= behind it and deprecate bustapay in favor of it. I just am pretty happy wi= th the state of bustapay and it's status a sort of "MVP of pay2endpoint", a= nd unless the argument is in the form: "We'd love to support it, but in ord= er to do so we'd need X" I'm probably going to disagree.