Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
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
Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
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 > 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 inevi
Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
ZmnSCPxj, thanks, responses inline. On 28. 01. 19 5:14, ZmnSCPxj wrote: > Good morning Ryan and Adam, > >> [UIH2 snipped] > > Perhaps I am being naive, but I seem, the B2EP and similar do not need to > worry about UIH2. > > From the github discussion: > >> "UIH2": one input is larger than any output. > . > I.e. there exists an input, for all outputs, input > output > To avoid this, we should ensure that, for all inputs, there exists an output, > input < output. > > From the proposal BIP: > >> 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. > > Suppose the original transaction avoids the UIH2 (i.e. for all inputs, there > exists an output, input < output). > The single added input will also avoid the UIH2, since the contributed output > value is added to the receiver output, thereby ensuring that contributed > input < output. > Yes, I had noted this (see link below). > Suppose the original transaction does not avoid the UIH2. > The receiver adding their own contributed input would then have a chance that > the addition on the output will now cause the final transaction to avoid the > UIH2, since the sum of the receiver amount and the contributed input may now > exceed the largest sender input. (Just to note (see link below) what I'm sure you're aware of but a reader might forget: if the change output that the sender provided is larger than the payment amount, the above won't happen). > But since there are more transactions that avoid the UIH2 than not avoid > UIH2, the increased probability of now avoiding the UIH2 will lead to a > greater anonymity set (especially for the sender, whose coin selection > algorithm might have a consistent bias that makes it create transactions that > trigger UIH2). > > So it seems to me that the simple solution, i.e. sender uses standard coin > selection algorithms already in use today, and receiver does not do any UIH2 > checks at all, would be an improvement in both privacy and implementation > simplicity. > > Regards, > ZmnSCPxj > Really good point, and I think your argument is reasonable, if not watertight. (Just in case you missed it I tried to outline an algo to let the receiver avoid UIH2 on best effort basis here: https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2799709). Although I ~ sorta agree, there is a slight counterargument: receiver is adding utxos, so in the absence of any transaction inspection you're creating a different distribution than one gets from existing wallet selection algos. For example: Note that the most likely/desirable/considered use case may be a merchant use case (after all, who receives coins most frequently? in theory, people selling stuff), and it is highly plausible that they might concentrate larger and larger sums into utxo(s) via use of PayJoin. Completely mismatched input sizes could be a problem, it's debatable, and it's also debatable whether it can be avoided, but what I don't quite buy is that this issue can just be ignored. And I'm reminded that a related point is made by belcher in the gist comment thread iirc (after we discussed it on IRC): over time a "PayJoin-only" merchant doing the simplest thing - using a single utxo over and over again, will concentrate more and more funds into it, and inevitably violating UIH2 in an increasingly dramatic fashion (contributing a 100BTC utxo to a 0.1BTC payment etc.). Suggesting it's better if there's a mix of payjoin/non-payjoin. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
reposted due to wrong email address: I'd just like to repeat something I said years ago but is undoubtedly lost now: > > ### Today's low cost for sybil attacks > > A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a > Market for Anonymity.” (2016).] calculates the requirement of such a > sybil attack in 2016 to be just 32,000 USD. According to the paper such > an attack would succeed 90% of the time and the investment is > recoverable afterwards so that figure for the requirement isn't even a > true cost. > > JoinMarket has been improved since 2016 and more makers have joined, so > the true requirement is perhaps 2x or 3x higher today, but it is still > relatively low. > > Even with future improvements like fixing issue #693 [2] the requirement > of a sybil attack would probably only rise another 2x. > I criticised this point from the Moser paper at the time, in particular because it was the headline grabbing result and in my opinion was only half the truth, at best: The $32K figure came from the assumption that swamping the bottom of the order book (in other words, making lots of bots offering prices lower than all the other bots) would lead to taking most of the join volume. At the time, this was true and false to some extent: it was true that the default order choosing algorithm was exponentially weighted to lower fees. But it was also true even then that Takers could simply manually choose any counterparty bots they liked (-P). Also at the time I complained that it was trivial to implement other order choosing algorithms, in particular I advocated (for its simplicity) "choose randomly under a user specified maximum fee", and indeed since the paper we have implemented that algorithm and it's now the default. Note that this algorithm is the crudest variant of what was loosely called "quantization" in this discussion between belcher and gmaxwell on the topic some years ago: https://github.com/JoinMarket-Org/joinmarket/issues/14#issuecomment-143509788 To me the crucial point is that the Taker's price sensitivity should not be too large, although of course it cannot be zero! So independent of changes in the makeup of the users of Joinmarket, that analysis from 2016 was in my opinion a bit skewed at the time, and completely wrong today. None of this is a critique of the fidelity bonds idea, since the Sybil threat is real in any case (see issue 693 as mentioned), but price-based Sybilling is less effective than it seems based on that. I'll continue my thoughts on fidelity bonds, for what they're worth, in the active thread: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/371 (for those not in the know, Joinmarket-Org/joinmarket-clientserver is the active repo, not Joinmarket-Org/joinmarket). Adam Gibson / waxwing / AdamISZ On Thu, Jul 25, 2019 at 3:18 PM Chris Belcher via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > JoinMarket[1] can be sybil attacked today at relatively low cost which > can destroy its privacy. Bitcoins can be sacrificed with burner outputs > and time-locked addresses (also called fidelity bonds), and this can be > used to greatly improve JoinMarket's resistance to sybil attacks. > > With real-world data and realistic assumptions we calculate that under > such a fidelity bond system an adversary would need to lock up > 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner > addresses to have a good chance of sybil attacking the system if it were > added to JoinMarket. > > This increased resistance to sybil attacks would most likely cause > coinjoin fees to rise. I think the added cost is worth it for the > greatly improved privacy, because today miner fees are the biggest cost > to JoinMarket takers not coinjoin fees which are very low. Users should > definitely share their opinion on fees after reading the document. > > ## Introduction > > JoinMarket creates a market for coinjoins, allowing anyone to create > equal-amount coinjoins for any amount they want at any time they want. > In return they pay a fee for the liquidity made available to them. The > project has existed since 2015 and has probably created hundreds of > thousands of coinjoins since then. Today there is available liquidity > for creating coinjoins with amounts up to about 400 btc per coinjoin > output. > > ### Sybil attacks > > JoinMarket, like many other schemes where participants are free to > anonymously enter, can be targetted by sybil attacks. In JoinMarket this > would work by an attacker running lots of maker bots which attempt to be > all the makers in every coinjoin. If successful the attacker would have > enough information unmix every coinjoin. > > One way to solve the problem of sybil attacks is centralization. For > example coinjoins could be constructed on a centralized server. Then > random anonymous participants cant sybil attack because they can't > control the coinjoin construction, but this comes at the cost that the > server
Re: [bitcoin-dev] Question regarding Confidential Transactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In case it helps: The elements alpha sidechain uses a different address format, which includes an ECDH pubkey used for creating an ECDH shared secret. That shared secret is used to seed a RFC6979 prng, which allows both sides to generate the blinding factors used in the rangeproof. So the situation is: both sides can generate the blinding factors, but also the fake signatures used in the rangeproof (the basic idea there is to have N signatures in a ring, but only one of them real; the rest are forged and can be (must be) entirely random numbers. I say 'basic' because the Borromean sig design is to link together several rings, not just one). This allows the sender to embed the amount into one of those fake signatures (usually the last one) using xor, with certain formatting details. It would be possible to not bother to embed the amount in this way; the receiver, knowing the stream of fake/real signatures (again - because he knows the seed for the prng), could simply observe which ones are real and therefore know the digits of the amount. But if he did it this way, it would not be possible to embed any other data into the range proof (such as: auditing related information) using xor as above. I did some detailed explanation/investigation of this in sections 3.3 and 3.4 of https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf ; with apologies for any errors, it was just an investigation I did last summer. On 02/10/2016 06:39 PM, Jeremy Papp via bitcoin-dev wrote: > On 2/10/2016 5:53 AM, Henning Kopp wrote: >> Hi Jeremy, >> >>> My understanding of the paper is that the blinding factor would >>> be included in the extra data which is incorporated into the >>> ring signatures used in the range proof. >> Yep, that is a possibility. The blinding factor could be >> encrypted with the public key of the receiver. Thus it is only >> visible for the receiver who can then check that the correct >> amount has been sent. > ECC doesn't work like RSA; you can't encrypt directly with a > public key. That's why you generate a shared secret between sender > and receiver. See also, ECDH. (Basically, if (m, M = m*G) is your > private/public key pair, and (n, N = n*G) is your recipient's > private public key pair, you can both generate shared secret S = > m*N = n*M = m*n*G without revealing your private keys to each > other, and without revealing the secret to anyone else as long as > they don't know either private key. You then use S as the basis for > the key to some symmetric algorithm.) >>> you'd transmit it then, though in any case, since using it >>> will pretty much require segwit, adding extraneous data isn't >>> much of a problem. In both cases, I imagine the blinding >>> factor would be protected from outside examination via some >>> form of shared secret generation... Although that would require >>> the sender to know the recipient's unhashed public key; I don't >>> know of any shared secret schemes that will work on hashed >>> keys. >> Here you lost me. Why do we need to create a shared secret? Is >> this shared secret used as the blinding factor? Also I think the >> sender knows the unhashed public key of the receiver. The only >> reason not to include it in the transaction script is that an >> external observer is unable to see the receiver directly in the >> blockchain. > Normal Bitcoin transactions are made to the hash of a public key > because once the public key is known, it becomes easier to break it > if we ever develop quantum computers. That's why it's recommended > that you only spend from a particular address once (if possible) > since its only in spending that you are required to reveal your > public key. Since you can't do a shared secret with a public key > hash, AFAIK, you'd have to know the public key of your recipient to > be able to do ECDH. > > Jeremy Papp ___ > bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWv1/8AAoJELOuCfHpoxl6dV8H/AvlEUebgKBAZdSdIEDKm0m0 pSXNWH62v327YdJ2wFqPCB2zG9HKXP76XhCGx39PEEvBmAFAoD6URAWPk8o03kTo aJZUeRB7wLqIALuUub/0JzAJwcxZtTIhYu3ygfyZZuvpomG8yXlERwfjB+BcCXnm D7TJ2qOyq3X3uaneb/OnUEvDxOrl9zAp9q7CUnFQB2xagCRnHyGNcrWaH43RmpHl Eima6eonQUR4AAcIUu0CKSRjgM6q46bMbXTFt9I4XeqQxsMB5Gfe9Ggk15TNRoUm ENVaJnPL4qlJqODSrO9R4xrurVCcp7HVeR9B5aztFQszVNxhMoZtFlyn5U3J0gY= =+I00 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
