Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 22034267 for ; Sun, 1 May 2016 16:21:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 742F3A6 for ; Sun, 1 May 2016 16:21:42 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id m64so12504085lfd.1 for ; Sun, 01 May 2016 09:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=6oTgxmmo2MVCRZxfhPYy2ca66r5PAVCx5fUVsrKbalM=; b=EACHSbMjYDRpiHglHGRWb6U5Vq9+8ANYXYxii8dUpfr6m8TMsnYaBkZjla2viBP3xl WZG1h9A7zhXYL+NlmnGR/+nHIy9bVAIjfZD8GAzCTKTdYCHTsy7nfMGZqD1D1vjmL7s7 q/YBc8XC8xEtrGNpEhaDFlNrJgz7NQeA+Y1NqbMqEsM5oKKrAaU2MRLr1YTmWU7Um97b KJtd9VJzvWy5S9BrMNCVuaHDVmDzvUiD9fAK70U56ChzPTn1N7ff5YWWSbGj+5947Yvp SkbfBJLKsHHoDQF67HeT0bdxhPAdFVPTQUq+YPrxZeqBtz0qJ6qo/6kAc6MTQFL1ou64 bC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=6oTgxmmo2MVCRZxfhPYy2ca66r5PAVCx5fUVsrKbalM=; b=i8vMx6HHSpAAKpeJOWS0dlC2xEUhT+/XiTSqFr5atTJ4NsZPA95yJUpl7WJOTKKOfe bP33KRkwAKt3QWos/LM+D0glHGkoBUpbPCE8qKN4UgmeRKLS7zFGMbpNVMZEiQ9NEByc lDItrbD3NT5/gkFIB8O93AfNjvslJtciD92QnL4k2LiHvPd5zV2sPnNDE2Z4VhiWx74P Rc5dEvA8yQsPjon/eaJ1fr2nVmLCer5QiOCydJt+chK2JUUv7WS2XFZuL7izq7y6iZTh Ne36vmINwy3n6GuAkcTeunbJv44cBN9Wd3JGhp6bN0YnZFLQh1dWavZASJcKk93Ktw35 w3ig== X-Gm-Message-State: AOPr4FXxdKy5lpDOvGVRIixIF3maZuvAv5QHn9D5e7uy/VSilMmo3Np+EOGGD++GhBMqNA9aDqUpdFkWXsbABQ== MIME-Version: 1.0 X-Received: by 10.25.125.212 with SMTP id y203mr11877625lfc.91.1462119700965; Sun, 01 May 2016 09:21:40 -0700 (PDT) Sender: gmaxwell@gmail.com Received: by 10.112.212.37 with HTTP; Sun, 1 May 2016 09:21:40 -0700 (PDT) Date: Sun, 1 May 2016 16:21:40 +0000 X-Google-Sender-Auth: 7JRA4NaGNftlFT2buHlIpCGFWV0 Message-ID: From: Gregory Maxwell To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 01 May 2016 16:27:38 +0000 Subject: [bitcoin-dev] segwit subsidy and multi-sender (coinjoin) transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 16:21:43 -0000 On Fri, Apr 29, 2016 at 6:22 PM, Kristov Atlas via bitcoin-dev 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.]