segwit subsidy and multi-sender (coinjoin) transactions

segwit subsidy and multi-sender (coinjoin) transactions
2016-05-03  2:05 ` Peter Todd
  
From: Kristov Atlas @ 2016-04-29 18:22 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Has anyone thought about the effects of the 75% Segregated Witness subsidy
on CoinJoin transactions and CoinJoin-like transactions? Better yet, has
anyone collected data or come up with a methodology for the collection of
data?

From this link: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

"Segwit improves the situation here by making signature data, which does
not impact the UTXO set size, cost 75% less than data that does impact the
UTXO set size. This is expected to encourage users to favour the use of
transactions that minimise impact on the UTXO set in order to minimise
fees, and to encourage developers to design smart contracts and new
features in a way that will also minimise the impact on the UTXO set."

My expectation from the above is that this will serve as a financial
disincentive against CoinJoin transactions. However, if people have
evidence otherwise, I'd like to hear it.

I noticed jl2012 objected to this characterization here, but has not yet
provided evidence:
https://www.reddit.com/r/Bitcoin/comments/4gyhsj/what_are_the_impacts_of_segwits_75_fee_discount/d2lvxmw

A sample of the 16 transaction id's posted in the JoinMarket thread on
BitcoinTalk shows an average ratio of 1.38 or outputs to inputs:

https://docs.google.com/spreadsheets/d/1p9jZYXxX1HDtKCxTy79Zj5PrQaF20mxbD7BAuz0KC8s/edit?usp=sharing

As we know, a "traditional" CoinJoin transaction creates roughly 2x UTXOs
for everyone 1 it consumes -- 1 spend and 1 change -- unless address reuse
comes into play.

Please refrain from bringing up Schnorr signatures in your reply, since
they are not on any immediate roadmap.

Thanks,
Kristov

[-- Attachment #2: Type: text/html, Size: 2255 bytes --]

 permalink raw reply	[|nested]
From: Gregory Maxwell @ 2016-05-01 16:21 UTC (permalink / raw)
  To: Bitcoin Dev

On Fri, Apr 29, 2016 at 6:22 PM, Kristov Atlas via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Has anyone thought about the effects of the 75% Segregated Witness subsidy
> on CoinJoin transactions and CoinJoin-like transactions?

Yes.

> My expectation from the above is that this will serve as a financial
> disincentive against CoinJoin transactions.

This does not appear to be the case.

Coinjoin doesn't necessitate any particular behavior that is relevant
here -- normal transactions spend a coin and create a payment of an
externally specified amount and change; CoinJoins are not special
in this regard.

Users may sometimes split up their outputs in an effort to improve
privacy, which would have the "more outputs" effect you're describing,
but more outputs in and of itself would not increase costs under segwit:

The total cost to a user for creating an output paying themselves is both
the cost of the creation and the cost of eventually spending it.

Segwit's cost calculation improvements shifts some relative cost from
spending to creation, but in these cases same user is paying both.

-- unless you want to assume the user is going to create it and never
spend it.  In which case, ... they have other issues than transaction
fees.  And in that case these outputs are creating a perpetual cost on
the system, it's prudent that the user creating the additional load
take on that cost.

> A sample of the 16 transaction id's posted in the JoinMarket thread on
> BitcoinTalk shows an average ratio of 1.38 or outputs to inputs
[...]
> As we know, a "traditional" CoinJoin transaction creates roughly 2x UTXOs
> for everyone 1 it consumes

It's odd to state something like that as fact immediately after a providing
figure that disproves it...

Although for self-sends the output to input ratio doesn't matter for total
costs (as I described above), you're missing the important bit of context:
where are other transactions. In block 409711 (current height of my
txindex node on my laptop), I see an average of 1.4647 outputs per input.
This figure is all over the map in different blocks, however.

> Please refrain from bringing up Schnorr signatures in your reply, since
> they are not on any immediate roadmap.

Schnorr signatures for Bitcoin have been in the works for  years, and are
one of the first proposed uses of the segwit versioning.

[Comments like this last one from you make it hard to see your message
 as a good-faith inquiry: Schnorr multisignature signature aggregates
 would make CoinJoins massively less expensive, ... that you'd demand
 that your dismissal of it be the final word on the subject leaves
 the impression that you're intentionally calling for a misleading
 presentation of the trade-offs -- there doesn't appear to be a
 disincentive here, but if there were it would be far beyond eliminated
 by a planned use of segwit versioning.]


 permalink raw reply	[|nested]
2016-04-29 18:22 [bitcoin-dev] segwit subsidy and multi-sender (coinjoin) transactions Kristov Atlas

  
From: Peter Todd @ 2016-05-03  2:05 UTC ( / )
  To: Kristov Atlas;  Bitcoin Dev



On Fri, Apr 29, 2016 at 02:22:32PM -0400, Kristov Atlas via bitcoin-dev wrote:
> A sample of the 16 transaction id's posted in the JoinMarket thread on
> BitcoinTalk shows an average ratio of 1.38 or outputs to inputs:
> 
> https://docs.google.com/spreadsheets/d/1p9jZYXxX1HDtKCxTy79Zj5PrQaF20mxbD7BAuz0KC8s/edit?usp=sharing
> 
> As we know, a "traditional" CoinJoin transaction creates roughly 2x UTXOs
> for everyone 1 it consumes -- 1 spend and 1 change -- unless address reuse
> comes into play.

Note how this is obviously an unsustainable situation - at some point that
change needs to be combined again, or you're throwing away money in the form of
UTXO's that aren't ever getting spent.

Meanwhile, if you put it another way the segwit discount is an obvious
advantage for coinjoin: by making spending UTXO's cheaper, we can recover those
funds that would otherwise get lost to dust, becoming ever more difficult to
spend.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org