MultiBit and address reuse

[jtoomim]

I've made a few transactions with MultiBit, and I'm pretty happy with it overall. However, I've observed that it tends to accumulate bitcoin in one address, which it reuses over and over again. For privacy and anonymity, I would prefer it if MultiBit created a new address to use to receive the change from each transaction instead of reusing one and making it easy for the IRS and ex-girlfriends to stalk my every financial move. Does anybody know anything about this? Was this behavior the result of a conscious decision? Is there any compelling reason for the address reuse that I don't know about?

To illustrate this issue, let's say I have 3 addresses (A, B, and C) initially, each with a different amount of coins:

A: 1.0 BTC
B: 1.5 BTC
C: 2.0 BTC

Let's say I want to send 2.1 BTC to address X. When I do this in Multibit, the transaction it generates ends up looking something like this:

Inputs:
A: 1.0 BTC
B: 1.5 BTC
Outputs:
X: 2.1 BTC
A: 0.3999 BTC
Fees:
0.0001 BTC

I would prefer that MultiBit instead created an address D for the change. Why doesn't it?

(I'm not sure if it would prefer address C or A as the change output address. I haven't observed any trades that would disambiguate yet.)

[jtoomim]

This is an example of the kind of behavior that I don't like, taken from an address which is NOT mine:

https://blockchain.info/address/1MoB9poJFaa6Amzcybgmj3XFkW22XYipxc

Here is the kind of behavior I do like:

https://blockchain.info/address/1Dz7MHCZ3gHVqKRtUuP9RFipsdH5c61Gms

Edit: 1MoB9.... is a better example than 1GC6ucWxo5stow6U8A1gUaptK77n7E6FhQ

[jtoomim]

If for nothing else, MultiBit shouldn't reuse addresses like this because the Eligius mining pool will deprioritize your transactions, and other pools might do the same.

https://bitcointalk.org/index.php?topic=334316.0

I happen to agree with Luke Jr's motivation for this, and think that Yifu's CoinValidation is an awful idea. For the average Bitcoin wallet user, they just want their transactions to go through quickly, and that means that Luke Jr and his mining minions have largely forced users' hands.

[Mike Hearn]

All SPV clients (bitcoinj based) have this behaviour. The reason is that there's no equivalent of the bitcoin-qt key pool, so every time you add an address, you have to make a new backup.

I've started work on integrating HD wallets, but it's a big job and will take a while. Once that work is done bitcoinj will stop reusing addresses, at least on desktop class machines, and MultiBit will pick up that behaviour automatically.

[PenAndPaper]

If for nothing else, MultiBit shouldn't reuse addresses like this because the Eligius mining pool will deprioritize your transactions, and other pools might do the same.

https://bitcointalk.org/index.php?topic=334316.0

I happen to agree with Luke Jr's motivation for this, and think that Yifu's CoinValidation is an awful idea. For the average Bitcoin wallet user, they just want their transactions to go through quickly, and that means that Luke Jr and his mining minions have largely forced users' hands.

There isn't any other pool that agrees to that. Actually there are some that expressed clearly that they are not going to implement such a change.
It's not going to happen.

[jimmydorry]

Great! Been worried about this for a while.

In the meantime is it possible to implement an option to remove addresses and specify where remaining coins go?

[JWU42]

In the meantime is it possible to implement an option to remove addresses and specify where remaining coins go?

This would be great - similar to what blockchain offers (defining a change address)...

[empoweoqwj]

All SPV clients (bitcoinj based) have this behaviour. The reason is that there's no equivalent of the bitcoin-qt key pool, so every time you add an address, you have to make a new backup.

I've started work on integrating HD wallets, but it's a big job and will take a while. Once that work is done bitcoinj will stop reusing addresses, at least on desktop class machines, and MultiBit will pick up that behaviour automatically.

I thought with Electrum it would restore *all* keys, however many there are (as long as they weren't imported keys), from the 12 word "seed"?

[Abdussamad]

All SPV clients (bitcoinj based) have this behaviour. The reason is that there's no equivalent of the bitcoin-qt key pool, so every time you add an address, you have to make a new backup.

I've started work on integrating HD wallets, but it's a big job and will take a while. Once that work is done bitcoinj will stop reusing addresses, at least on desktop class machines, and MultiBit will pick up that behaviour automatically.

I thought with Electrum it would restore *all* keys, however many there are (as long as they weren't imported keys), from the 12 word "seed"?

Electrum does not use bitcoinj. It is based on python libraries. Electrum uses a separate deterministic sequence for change addresses. It's very nice actually.

[empoweoqwj]

All SPV clients (bitcoinj based) have this behaviour. The reason is that there's no equivalent of the bitcoin-qt key pool, so every time you add an address, you have to make a new backup.

I've started work on integrating HD wallets, but it's a big job and will take a while. Once that work is done bitcoinj will stop reusing addresses, at least on desktop class machines, and MultiBit will pick up that behaviour automatically.

I thought with Electrum it would restore *all* keys, however many there are (as long as they weren't imported keys), from the 12 word "seed"?

Electrum does not use bitcoinj. It is based on python libraries. Electrum uses a separate deterministic sequence for change addresses. It's very nice actually.

Thanks for clearing that up Abdussamad. I was getting worried Electrum wouldn't restore change addresses. I agree, Electrum *is* very nice.