On 27. 01. 19 8:36, rha...@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 =) I really think anything that (silently) breaks the > 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 between > 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 joinmarket > 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 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 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 and > 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 way 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 the > 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#gistcomment-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 > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > 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 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 >> >> ================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== >> >> - Protocol versioning. Since inevitably (even if only merchants), this >> 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 max >> supported version and receiver responds with a chosen protocol version >> 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 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 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 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 really >> 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 cover >> 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=1). 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#gistcomment-2796539 >> and some data here >> >> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-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 pick >> 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 avoid >> 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 necessary to >> mention it in the BIP. >> >> Specific comments >> ================= >> >> >>>> ====Step 4. Receiver validates, re-signs, and propagates on the >> >> bitcoin network==== >> >> 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 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 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. >>> ==Abstract== >>> The way bitcoin transactions are overwhelming used is known to leak more >>> information than desirable. This has lead to fungibility concerns in bitcoin >>> and a raise of unreasonably effective blockchain analysis. >>> Bustapay proposes a simple, practical way to bust these assumptions to >>> immediate >>> benefit of the sender and recievers. Furthermore it does so in such a >>> way that >>> helps recievers avoid utxo bloat, a constant problem for bitcoin merchants. >>> ==Copyright== >>> This BIP is in the public domain. >>> ==Motivation== >>> One of the most powerful heuristic's employed by those whose goal is to >>> undermine >>> bitcoin's fungiblity has been to assume all inputs of a transaction are >>> signed by >>> a single party. In the few cases this assumption does not hold, it is >>> generally >>> readibly recognizable (e.g. traditional coinjoins have a very obvious >>> structure, >>> or multisig outputs are most frequently validated onchain). >>> Bustapay requires no changes to bitcoin and creates bitcoin transactions >>> that are >>> indistinguishable from normal ones. >>> It is worth noting that this specification has been intentionally kept >>> as simple >>> as possible to encourage adoption. There are almost an endless amount of >>> extensions >>> possible but the harder the implementation of clients/server the less >>> likely it >>> will ever be done. Should bustapay enjoy widespread adoption, a "v2" >>> specification >>> will be created with desired extensions. >>> ==Specification== >>> A bustapay payment is made from a sender to a receiver. >>> Step 1. Sender creates a bitcoin transaction paying the receiver >>> This transaction must be fully valid, signed and all inputs must use >>> segwit. This transaction is known as the "template transaction". This >>> transaction must not be propagated on the bitcoin network. >>> Step 2. Sender gives the "template transaction" to the receiver >>> This would generally be done as an HTTP POST. The exact URL to submit it >>> to could be specified with a bip21 encoded address. Such as >>> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit >>> and the HTTP body should be the raw transaction hex encoded as text. >>> Step 3. Receiver processes the transaction and returns a partially >>> signed coinjoin >>> The receiver validates the transaction is valid, pays himself and is >>> eligible for propation. The receiver then adds one of his own inputs >>> (known as the "contributed input") and increase the output that pays >>> himself by the contributed input amount. Doing so will invalidate the >>> "template transaction"'s original input signatures, so the sender needs >>> to return this "partial transaction" back to the receiver to sign. This >>> is returned as a hex-encoded raw transaction a response to the original >>> HTTP POST request. >>> Step 4. Receiver validates, re-signs, and propagates on the bitcoin network >>> The receiver is responsible in making sure the "partial transaction" >>> returned by the sender was changed correctly (it should assume the >>> connection has been MITM'd and act accordingly), resign its original >>> inputs and propagates this transaction over the bitcoin network. The >>> client must be aware that the server can reorder inputs and outputs. >>> Step 5. Receiver observes the finalized transaction on the bitcoin network >>> Once the receiver has seen the finalized transactions on the network >>> (and has enough confirmations) it can process it like a normal payment >>> for the sent amount (as opposed to the amount that it looks like on the >>> network). If the receiver does not see the finalized transaction after a >>> timeout will propagate the original "template transaction" to ensure the >>> payment happens and function a strong anti-DoS mechanism. >>> === Implementation Notes === >>> For anyone wanting to implement bustapay payments, here are some notes >>> for receivers: >>> >>> - A transaction can easily be checked if it's suitable for the mempool >>> with testmempoolaccept in bitcoin core 0.17 >>> >>> - Tracking transactions by txid is precarious. To keep your sanity make >>> sure all inputs are segwit. But remember segwit does not prevent txid >>> malleability unless you validate the transaction. So really make sure >>> you're using testmempoolaccept at the very least >>> >>> - Bustapay could be abused by a malicious party to query if you own a >>> deposit address or not. So never accept a bustapay transaction that pays >>> an already used deposit address >>> >>> - You will need to keep a mapping of which utxos people have showed you >>> and which you revealed. So if you see them again, you can reveal the >>> same one of your own >>> >>> - Check if the transaction was already sorted according to BIP69, if so >>> ensure the result stays that way. Otherwise probably just shuffle the >>> inputs/outpus >>> >>> >>> Notes for sending applications: >>> >>> - The HTTP response must not be trusted. It should be fully validated >>> that no unexpected changes have been made to the transaction. >>> >>> - The sender should be aware the original "template transaction" may be >>> propagated at any time, and in fact can intentionally be >>> done so for the purpose of RBF as it should have a slightly higher fee >>> rate. >>> >>> >>> == Credits == >>> The idea is obviously based upon Dr. Maxwell's seminal CoinJoin >>> proposal, and reduced scope inspired by a simplification of the "pay 2 >>> endpoint" (now offline) blog post by blockstream. >>> -Ryan >>> >>> 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
