Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-29 Thread Adam Gibson via bitcoin-dev
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] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-27 Thread Adam Gibson via bitcoin-dev
ut 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 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/experimen

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2019-01-26 Thread Adam Gibson via bitcoin-dev
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