public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail•com>
To: Isidor Zeuner <cryptocurrencies@quidecco•de>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] determining change addresses using the least significant digits
Date: Fri, 6 Feb 2015 18:21:09 +0000	[thread overview]
Message-ID: <CAAS2fgQyecwuiXxYxzF4bmYCVvcQnBa97LYXYu-Gf3rVNs5VJw@mail.gmail.com> (raw)
In-Reply-To: <20150204142323.DEC4BE2DCDE@quidecco.de>

On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
<cryptocurrencies@quidecco•de> wrote:
> Hi there,
>
> traditionally, the Bitcoin client strives to hide which output
> addresses are change addresses going back to the payer. However,
> especially with today's dynamically calculated miner fees, this
> may often be ineffective:
>
> A user sending a payment using the Bitcoin client will usually enter
> the payment amount only up to the number of digits which are
> considered to be significant enough. So, the least significant digits
> will often be zero for the payment. With dynamically calculated miner
> fees, this will often not be the case for the change amount, making it
> easy for an observer to classify the output addresses.
>
> 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.

Sending someone too much can really play hell with their accounting.
Unless you know they're okay with it, I wouldn't suggest it.

I often randomly round up the output when I'm paying to a depository
account... and I've thought that would be a useful feature to have,
but I dunno how to usefully present a UI for "pay at least X but
you're allowed to round-up up to 0.01 BTC more".


Another strategy is this: create two change outputs, with uniform
probablity make one equal to your payment amount (which is also nice
because if your payment amount models future payment amount the change
will be usefully sized) or split your change evenly.



      parent reply	other threads:[~2015-02-06 18:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 14:23 Isidor Zeuner
2015-02-06  1:17 ` Peter Todd
2015-02-06  3:16 ` Justus Ranvier
2015-02-06  4:08   ` [Bitcoin-development] [SPAM] " Luke Dashjr
2015-02-06 10:11 ` [Bitcoin-development] " Wladimir
2015-02-06 15:08   ` Jeff Garzik
2015-02-06 17:50     ` Justus Ranvier
2015-02-06 18:21 ` Gregory Maxwell [this message]

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=CAAS2fgQyecwuiXxYxzF4bmYCVvcQnBa97LYXYu-Gf3rVNs5VJw@mail.gmail.com \
    --to=gmaxwell@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=cryptocurrencies@quidecco$(echo .)de \
    /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