determining change addresses using the least significant digits
8 messages, 4 to 6 Feb 2015. Started by Isidor Zeuner.
Justus Ranvier (2), Isidor Zeuner, Peter Todd, Luke Dashjr, Wladimir J. van der Laan, Jeff Garzik, Greg Maxwell
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.
Any thoughts?
Best regards,
Isidor
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote:
Quoted text (19 lines)
> 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. > > Any thoughts?
Have you looked at Armory? IIRC they do this kind of stuff.
On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
Quoted text (18 lines)
> 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.
Another possible approach is to randomize the number of change outputs from transaction to transaction.
Doing this, it would be possible to make change outputs that mimic real spends (low number of s.d.)
- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
Quoted text (25 lines)
> On 02/04/2015 02:23 PM, Isidor Zeuner 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. > > Another possible approach is to randomize the number of change outputs > from transaction to transaction. > > Doing this, it would be possible to make change outputs that mimic > real spends (low number of s.d.)
This uses more data.
Why not just round change down (effectively rounding fee up)?
Luke
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner <cryptocurrencies@quidecco•de> wrote:
Quoted text (5 lines)
> 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
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 <laanwj@gmail•com> wrote:
Quoted text (33 lines)
> On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner > <cryptocurrencies@quidecco•de> 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 >
On 02/06/2015 03:08 PM, Jeff Garzik wrote:
Quoted text (3 lines)
> Yes. You can certainly add additional inputs and outputs -- and as > such you can increase privacy and defrag your wallet at the same > time.
A lot could be done to make regular spends resemble CoinJoin transactions and vice verse.
- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner <cryptocurrencies@quidecco•de> wrote:
Quoted text (17 lines)
> 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.