Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A685723 for ; Wed, 15 Jun 2016 17:08:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43BCA230 for ; Wed, 15 Jun 2016 17:08:34 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id u64so38460488vkf.3 for ; Wed, 15 Jun 2016 10:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V1W/4JCtPoashPlFhDjYZwBQf9caoSkx1NYHZX8MMic=; b=g0yYR6NdojhJ6BAJWEQlPGBT/8vHVX5dgUoPf8K5mFetWxXPvdBXg1ut+EmZFxAteL U3AWBRfDv536DPusar+w4o8A/vxyu9PtQQ6T5T0+893pHXLeL9kVposuRJDLVuV18Jcx /eHfoW3da49pFPIWPFaxn/WtenqUEOlKbpVXnj03XtHoslRnm/9J5vcAQkwyLOegPb94 hKhPCct86yGlh+7EWQxYRGwrjgkUscdNFCwJQrer6qWymcvk6wm+jtqZgA5v0MX7HVMM CDCPGy+EV29ax+BQP4KVM2pO23tinEPDLnt56WSYxu5SzpBkGRIu9msYbz6J3ehwwQFj JM/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V1W/4JCtPoashPlFhDjYZwBQf9caoSkx1NYHZX8MMic=; b=d2qiDTQfexRFeKukVx9Kldft7zqorn/z048J8V+5fIPosXRVVkMEBqKJqJbasxqfDq Qi5gV0ew2lgyfgdSYxYia/8AvFoe+LI8V/AOilU33uCrRvJen2U+Ey2F6eXdWvmEwY4c nCpC3sNu+qy1eeFi8Zq1mihtKrwUNIOuK3A+xZ6JYZ7P2dLppe7Oey8g1POsR05knV4K oYfhI/rMUV5jvV7a081bE6bQuiZGcEYC9oeEreCEtDgSW9Lhk9+McJN9Dm3K1ACCdsGU z3mvxI0EbK4a36e8sOrT805Egj8kc/Aapr2jcUUc+0A/pYHHRiDBWtOLP402TRyhH2nU IhiQ== X-Gm-Message-State: ALyK8tIzTzyqpKquSi3cohMU/9nVsFdDYFezlOMGd2qseRlET2bne1FLRY+taoOEY0ZiDBQMZvgFPXX7KR1QStIT X-Received: by 10.31.47.85 with SMTP id v82mr11270200vkv.140.1466010513469; Wed, 15 Jun 2016 10:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.103 with HTTP; Wed, 15 Jun 2016 10:08:13 -0700 (PDT) In-Reply-To: References: <5760259B.7040409@mycelium.com> <57612D67.9080007@gmail.com> <576133A7.6070004@mycelium.com> From: "Russell O'Connor" Date: Wed, 15 Jun 2016 13:08:13 -0400 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1143ff38e497430535542bc4 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:08:35 -0000 --001a1143ff38e497430535542bc4 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Indeed, and you can go even further. When there are multiple "sending" > outputs, pick one at random, and mimic it for the change output. This means > that if you have a P2PKH and 3 P2SH sends, you'll have 25% chance for a > P2PKH change output, and 75% chance for a P2SH output. > This isn't quite perfect because if there is only 1 P2PKH output and you know the person is using the above algorithm then you know the P2PKH output isn't the change. I don't know what the perfect method is. My guess is that it is to let p be the probability that a P2PKH output is produced over the entire network and to pick P2PKH for your change output with probability p (and similarly for other output types). On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Jun 15, 2016 12:53, "Daniel Weigl via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > That would be a big privacy leak, imo. As soon as both outputs are > spent, its visible > > which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as a > consequence > > you leak which output was the change and which one the actual sent output > > > > So, i'd suggest to even make it a requirement for "normal" > send-to-single-address transactions > > to always use the same output type for the change output (if the wallet > is able to recognize it) > > Indeed, and you can go even further. When there are multiple "sending" > outputs, pick one at random, and mimic it for the change output. This means > that if you have a P2PKH and 3 P2SH sends, you'll have 25% chance for a > P2PKH change output, and 75% chance for a P2SH output. > > You can go even further of course, if you want privacy that remains after > those sends get spent. In that case, you also need to match the template of > the redeemscript/witnessscript. For example, if the send you are mimicking > is a 2-of-3, the change output should also use 2-of-3. > > -- > Pieter > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1143ff38e497430535542bc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Indeed, and yo= u can go even further. When there are multiple "sending" outputs,= pick one at random, and mimic it for the change output. This means that if= you have a P2PKH and 3 P2SH sends, you'll have 25% chance for a P2PKH = change output, and 75% chance for a P2SH output.

=
This isn't quite perfect because if there is= only 1 P2PKH output and you know the person is using the above algorithm t= hen you know the P2PKH output isn't the change.

I don't know what the perfect method is.=C2=A0 My gues= s is that it is to let p be the probability that a P2PKH output is produced= over the entire network and to pick P2PKH for your change output with prob= ability p (and similarly for other output types).

On Wed, Jun 15, 2016 = at 7:00 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev= @lists.linuxfoundation.org> wrote:


On Jun 15, 2016 12:53, "Daniel Weigl via bitcoin-dev" <bitcoin= -dev@lists.linuxfoundation.org> wrote:
>
> That would be a big privacy leak, imo. As soon as both outputs are spe= nt, its visible
> which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as = a consequence
> you leak which output was the change and which one the actual sent out= put
>
> So, i'd suggest to even make it a requirement for "normal&quo= t; send-to-single-address transactions
> to always use the same output type for the change output (if the walle= t is able to recognize it)

Indeed, and you can go even further. When there are m= ultiple "sending" outputs, pick one at random, and mimic it for t= he change output. This means that if you have a P2PKH and 3 P2SH sends, you= 'll have 25% chance for a P2PKH change output, and 75% chance for a P2S= H output.

You can go even further of course, if you want privacy that = remains after those sends get spent. In that case, you also need to match t= he template of the redeemscript/witnessscript. For example, if the send you= are mimicking is a 2-of-3, the change output should also use 2-of-3.

--
Pieter


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1143ff38e497430535542bc4--