From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJkX0-0004pH-G8 for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 15:09:18 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.214.171 as permitted sender) client-ip=209.85.214.171; envelope-from=jgarzik@bitpay.com; helo=mail-ob0-f171.google.com; Received: from mail-ob0-f171.google.com ([209.85.214.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJkWy-0000RT-Pm for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 15:09:18 +0000 Received: by mail-ob0-f171.google.com with SMTP id gq1so13685480obb.2 for ; Fri, 06 Feb 2015 07:09:11 -0800 (PST) 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:content-type; bh=QTcd/45q7bcmt7WTTPra9vHBIK0W8WUgTACLT1soJfA=; b=O5rGT8TNW6TG8yL8wn10oCtWCNq3rQr9VWD8TBTU+hKAveKeu1+tjHvpc0zVadCDpm vkmQzi5OygBbmykyF/0iLNNrFoaqmE35BvjfTE76o5OdXKLsdRbILz8/j23uyktclSG/ BCPGkRSlG/eBdcZ1JtdPmm7IWDnxxr97jKC1fNtcWFYGFhOvGqPwiPsiCpvA8T7VrqIW /Iie/rj0PPPEw73fm1MwHIcYG38B43FLDhECDQaB2fRcoioNhv28KqiWchPNunSO+76G P43YHpdViR/crTp+bZNcVAQtxgyczaJGVfdhRRuP0Odovo/rNom/h2pLl4XyxqGX79vh ssKw== X-Gm-Message-State: ALoCoQlU6l/9CSzkdgROlt/IjN3rmDVW2kZa4h8ZCCYBRQySl9Mhkzb0PwsoM0nUhJh3jmnsxc7S X-Received: by 10.202.192.11 with SMTP id q11mr2613028oif.41.1423235351226; Fri, 06 Feb 2015 07:09:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.219.10 with HTTP; Fri, 6 Feb 2015 07:08:50 -0800 (PST) In-Reply-To: References: <20150204142323.DEC4BE2DCDE@quidecco.de> From: Jeff Garzik Date: Fri, 6 Feb 2015 07:08:50 -0800 Message-ID: To: Wladimir Content-Type: multipart/alternative; boundary=001a113dd2768abe6d050e6ccd64 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YJkWy-0000RT-Pm Cc: Bitcoin Development Subject: Re: [Bitcoin-development] determining change addresses using the least significant digits X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:09:18 -0000 --001a113dd2768abe6d050e6ccd64 Content-Type: text/plain; charset=UTF-8 Yes. You can certainly add additional inputs and outputs -- and as such you can increase privacy and defrag your wallet at the same time. On Fri, Feb 6, 2015 at 2:11 AM, Wladimir wrote: > On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner > wrote: > > > A possible approach to handle this issue would be to add a randomized > > offset amount to the payment amount. This offset amount can be small > > in comparison to the payment amount. > > > > Any thoughts? > > Adding/subtracting a randomized offset amount is one way, but there > have also been more sophisticated ideas to obfuscate the amount, e.g. > by adding multiple change outputs or even distributing over multiple > transactions (potentially coinjoined for further privacy). > > Mike Hearn had some ideas regarding obfuscation of payment amounts, > which still make sense, and he wrote about them here: > https://medium.com/@octskyward/merge-avoidance-7f95a386692f > > Wladimir > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --001a113dd2768abe6d050e6ccd64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 You can certainly add additional inputs and out= puts -- and as such you can increase privacy and defrag your wallet at the = same time.


On Fri, Feb 6, 2015 at 2:11 AM, Wladimir &l= t;laanwj@gmail.com> wrote:
On W= ed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
<
cryptocurrencies@quidec= co.de> wrote:

> A possible approach to handle this issue would be to add a randomized<= br> > offset amount to the payment amount. This offset amount can be small > in comparison to the payment amount.
>
> Any thoughts?

Adding/subtracting a randomized offset amount is one way, but there<= br> have also been more sophisticated ideas to obfuscate the amount, e.g.
by adding multiple change outputs or even distributing over multiple
transactions (potentially coinjoined for further privacy).

Mike Hearn had some ideas regarding obfuscation of payment amounts,
which still make sense, and he wrote about them here:
https://medium.com/@octskyward/merge-avoidance-7f95a386692f<= /a>

Wladimir



--
=
Jeff Garzik
Bitcoin core developer and op= en source evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--001a113dd2768abe6d050e6ccd64--