public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kristov Atlas <kristovatlas.lists@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] segwit subsidy and multi-sender (coinjoin) transactions
Date: Fri, 29 Apr 2016 14:22:32 -0400	[thread overview]
Message-ID: <CAGH37S+5FAqHzOTE8H0E8HNb5cr1k06MqB2r3k92jqkc=eXWNg@mail.gmail.com> (raw)

[-- 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 --]

             reply	other threads:[~2016-04-29 18:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 18:22 Kristov Atlas [this message]
2016-05-03  2:05 ` Peter Todd
2016-05-01 16:21 Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGH37S+5FAqHzOTE8H0E8HNb5cr1k06MqB2r3k92jqkc=eXWNg@mail.gmail.com' \
    --to=kristovatlas.lists@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox