* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-04 14:23 [Bitcoin-development] determining change addresses using the least significant digits Isidor Zeuner
@ 2015-02-06 1:17 ` Peter Todd
2015-02-06 3:16 ` Justus Ranvier
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Peter Todd @ 2015-02-06 1:17 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
On Wed, Feb 04, 2015 at 03:23:23PM +0100, 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.
>
> Any thoughts?
Have you looked at Armory? IIRC they do this kind of stuff.
--
'peter'[:-1]@petertodd.org
0000000000000000165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-04 14:23 [Bitcoin-development] determining change addresses using the least significant digits 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 18:21 ` Gregory Maxwell
3 siblings, 1 reply; 8+ messages in thread
From: Justus Ranvier @ 2015-02-06 3:16 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.)
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU1DH9AAoJECpf2nDq2eYjt2gP/3gpojJey2URkWWk0sg9dpHU
OsD37TCbrwUaS/K8UMKsuc45FSJU/EeYpaVz9r1Ifm/IeaFYPIX0tEm17n3hkcAG
QPmt/xAZn9GVyPWYKjmVDmx574pqiJLeZh8bP788sZsGc4Gk7NNJniVGLtsmvFCb
ZOtwS8v7UuJZx6awydrpNhw/+SsQn9Xdb8fcLqmFKWDpG2Mlrv+ds34NMlGbfO2r
PqCMw1Y12J0HXLisOCGQNZNdG9mVjKw3MP0GGjUlOM+ibrrorqoO5Ifo2RGuElgw
LZkzzDzg6kO8iuNOV7Jg1lz5WftRjgLRSCcMq4V+793zGJW9BeISeDcKQ2ZlWMXB
Hu83m4vCYOJeECdKGWlhyTmKNNHshsiPz3SBDLxP8uR80UkS3waDIXwLxGX9Pa63
uleaZ2qHQ/0UdC9opN3Snn33M701dHNJH9iXfhf/MVnUZ0FjzsLXaJ0F0208ZxCX
qGCAv5y1ijrDlCLTvakZJRIruXgxNPqtErzP9GtgXeGeDc8tRv00WiM9Olpu0EXd
yjhAZGydcE3Ec2cNo+teWjeDt4Ga4OYDb7i08eegaDuj5MCDcDtlgfwNjdKbre1x
S7pKKDn8V03/WST1x9fWjM04NxeSjJ0yRjOAxkLV/mlDX6lQEYJL/W+MJLvpOnTC
LtZrkSmSTJ7ZR0tMgpAe
=8EVe
-----END PGP SIGNATURE-----
[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bitcoin-development] [SPAM] Re: determining change addresses using the least significant digits
2015-02-06 3:16 ` Justus Ranvier
@ 2015-02-06 4:08 ` Luke Dashjr
0 siblings, 0 replies; 8+ messages in thread
From: Luke Dashjr @ 2015-02-06 4:08 UTC (permalink / raw)
To: bitcoin-development; +Cc: Justus Ranvier
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-04 14:23 [Bitcoin-development] determining change addresses using the least significant digits Isidor Zeuner
2015-02-06 1:17 ` Peter Todd
2015-02-06 3:16 ` Justus Ranvier
@ 2015-02-06 10:11 ` Wladimir
2015-02-06 15:08 ` Jeff Garzik
2015-02-06 18:21 ` Gregory Maxwell
3 siblings, 1 reply; 8+ messages in thread
From: Wladimir @ 2015-02-06 10:11 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-06 10:11 ` [Bitcoin-development] " Wladimir
@ 2015-02-06 15:08 ` Jeff Garzik
2015-02-06 17:50 ` Justus Ranvier
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Garzik @ 2015-02-06 15:08 UTC (permalink / raw)
To: Wladimir; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
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:
> 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
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
[-- Attachment #2: Type: text/html, Size: 2785 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-06 15:08 ` Jeff Garzik
@ 2015-02-06 17:50 ` Justus Ranvier
0 siblings, 0 replies; 8+ messages in thread
From: Justus Ranvier @ 2015-02-06 17:50 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/06/2015 03:08 PM, Jeff Garzik wrote:
> 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
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU1P7iAAoJECpf2nDq2eYjeXwQAJGdVdYta5CddfL+xyFNG2+l
RMxkSABfgWQF6mDus6ul+EhRhOYEveuuukbK2ibcnY2U4H9ecb8Gttno9+Wi0YfM
zcu1Wt/j5cJyUFjO9owZO5gse5mTCt+1njgNIGMlXHHbFEHc5OavXEgkvh8YcL/j
E8Kk4YNM5Ovp47vh1ihkB4Zo+ihu5oMuY4vbBO7So4BIe8KaSLOTsOAccT17bWGo
jtd6KdjfqsLSjhQoVtuQAsx9AGUS+jfjBRWSnwkeAdd4G4BE87/7DCdYnczFKhds
kVwnHODA0+5dwEwZ/ChipKVzAVLVZ2a7BXUenax70P1QgfG8WwL0tueoKviRBLfc
6Xa80GHGo84qeGEkiste1qnG4XZWwi6pnTSTwP1f5CtVvGvfYRysHsMCm82Mr7vA
pwrQULv6fkhI63xB+kfcXBPr0WIVrilVrEtGcypzIbPbQgRQ6k3Wg66zLoQTc8vA
w2pOZYrEU1Rmfiv27/MLdvSuWzR0kF+nidwCBxUYBuKAA4K0Y8GBH0FApp9JmCEo
LXIY4RU3sCCbP3C1qloN8k99q8+CDTwrZpzi2zi3r0zRorg/1tTXqavicE9KPC2j
ymk+eFFJhqG51o/d6irzA5R+hK/T2JatDhneEwTBetsrbXq0D9jiN3+KB+vME0wf
KJhXhGbElNyz7eA4EOMt
=zcqb
-----END PGP SIGNATURE-----
[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] determining change addresses using the least significant digits
2015-02-04 14:23 [Bitcoin-development] determining change addresses using the least significant digits Isidor Zeuner
` (2 preceding siblings ...)
2015-02-06 10:11 ` [Bitcoin-development] " Wladimir
@ 2015-02-06 18:21 ` Gregory Maxwell
3 siblings, 0 replies; 8+ messages in thread
From: Gregory Maxwell @ 2015-02-06 18:21 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
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.
^ permalink raw reply [flat|nested] 8+ messages in thread