Bitcoin Forum

Hey guys I'm interested in getting people's thoughts on this.

- see all addresses, including change

- see which addresses are linked together (does recursive expansion of address linkages)

- select which address(es) to send from, rather than letting the client to chose for you

http://www.youtube.com/watch?v=TA_O6Boi7Xo

So what can you do about this? If you don’t have any Bitcoin yet then you can just make sure to use separate wallets for addresses you don’t want being mixed together.

That’s why I’ve made a patch to the official client which allows you to send from _only_ a single specific address.

I’ve added a ‘Send From Address’ tab to the main interface. It actually contains information which was impossible to get from the client before. That is, every address in your wallet and the balance thereof. This includes addresses which were created for the change of your outgoing transactions.

I've repatched my changes onto v0.3.24rc1, see here: https://github.com/coderrr/bitcoin/commit/b32016a314bcbb15c97f14c733a8f49d43c5e8b2

I'll release new builds once the official v0.3.24 is released

I hadn't seen it before. It looks neat. I worry about UI complexity though. This is definitely a power user feature.

http://mtgoxlive.com/downloads/bitcoin-v0.3.24+coderrr-v2-linux64.tar.bz2

Can this get into the main release as an "advanced" option selection?

just finished the windows build: http://mtgoxlive.com/downloads/bitcoin-v0.3.24+coderrr-v2-win32.zip

Yes, welcome to bitcoin ;P

Yes, welcome to bitcoin ;P

Your client knows which part of the transaction is the change because you own the key for that address.

From the outside you have a 50/50 chance AT WORST assuming you're looking at a tx from an official bitcoin client.  My guess is most of the time you have a much better chance at guessing which part of the transaction is the change than 50/50.  For example, on a transaction where the payment is 1 BTC and the change is 2.0291 BTC, it's pretty obvious which part is the change.  I haven't done too much research on how often change amts are obvious but I just decided to be conservative and assume they're always identifiable.

WARNING!

This transaction will reveal to

ShadyDude:

That you own 957 BTC minus the 2 you're currently sending to them, and that you received 955.5 of them from RichMistress on June 2, 2011 at 11:38 AM (for extra effect, assume her identity is public knowledge because you know she reuses addresses with multiple people ;)), and 1.5 from address 1B... on May 1, 2011 at 4:56 PM.

RichMistress:

That you're sending 2 BTC to address 1M... right now, and that you received 1.5 from address 1B... on May 1, 2011 at 4:56 PM.

Wife: 

That you're sending 2 BTC to address 1M... right now, and that you received 955.5 BTC from RichMistress on July 12, 2011 at 11:38 AM.

If this is too revealing, then use the Send To Address tab to manually select the addresses to send from.

Does this patch give any sort of warning if bitcoin isn't being used through a proxy?

I worry that a user will be REALLY careful keeping all their addresses separated so their ordinary transactions are separate from their fund-the-oppositition transactions, and then will get busted by the Secret Police who were eavesdropping on their bitcoin IP traffic at their ISP.

why conflate the two issues?

Does this patch give any sort of warning if bitcoin isn't being used through a proxy?

Because to non-technical users, "privacy" is a single feature, not a series of separate technical issues.

Could you also compile a 32-bit Linux binary?

I see what you're saying although I don't think that's really a fair criticism of the patch.  Obtaining any really high level of anonymity is a very complex endeavor that no patch alone will get you.

That's just excellent work. I'm surprised it generated so little buzz and isn't adopted into the official client until now.

On a separate note, Suggester suggests a Redistribute coins button, an option which moves all your funds to a chosen number of new wallets with the desired proportion of your current coins assigned for each. A user would then be able to consolidate his wealth from all his, say, 17 addresses into just 3 new ones, with the first one containing 49% of his coins, the second one 26%, and the third 25% (he will be able to assign those %'s arbitrarily using a simple interface). Similarly, he might want to break up his single wallet into, say, 4 different wallets, using them for 4 different purposes. When the transactions clear after 10 minutes, it'll be harder for anyone to prove that this user still owns the coins previously associated with his identity.

For the suggestion to be practical for anonymity purposes though, I strongly recommend another adjustable option where the user chooses how much time to assign for the whole operation. For example, choosing "63.2 hours" would move random chunks of the coins into their new distribution over that period of time (the client would have to be connected for the whole duration). That would make plausible deniability much stronger because you usually don't have 17 people simultaneously sending all their coins to 3 new addresses! If done correctly, it will be virtually impossible after that for anyone to prove that he still owns the coins. We're essentially simulating a change-of-ownership.

This can all be currently done using windows explorer and separate wallet files, but it'll be a big pain in the butt.

I really need this patch! Is it available for version 0.4.0?

It doesn't seem to be in the standard client (0.4.0) yet. Why not? Sure, advertising it as an anonymity feature might give false expectations, but the same is true for the current client, since Bitcoin already has an anonymity reputation. This feature is not sufficient for complete anonymity, but it is a necessary (IMHO) component of a anonymous set-up, and as such it is a useful addition to the client. Sure, it adds complexity to the user interface (I haven't seen it yet), but this can easily be an 'optional' feature (and disabled by default), can't it?

Besides, I need it for a completely different reason: I want to manage several separated accounts, for an open source software development 'bounty' system (e.g., 'if you want to have this feature, send BTC to that address'). I want others to be able to see how much has been donated so far (or even how much they can receive if they implement the requested feature), so I don't want to accidentally spend bitcoins from the donation address.

TLDR: this patch allows you to:
- see all addresses, including change
- see which addresses are linked together (does recursive expansion of address linkages)
- select which address(es) to send from, rather than letting the client to chose for you

Because to non-technical users, "privacy" is a single feature, not a series of separate technical issues.

I updated the code for 0.4 but never released builds since I didn't perceive any demand for them.  The code is now updated for the 0.5 qt gui so once 0.5 is officially released I'll release builds with my patch as well.

It's possible https://www.bitaddress.org  could be useful for you to create separate accounts which you won't accidentally spend.

I updated the code for 0.4 but never released builds since I didn't perceive any demand for them.  The code is now updated for the 0.5 qt gui so once 0.5 is officially released I'll release builds with my patch as well.

I'd prefer that approach, since I don't really trust arbitrary websites. It might secretly remember the private keys of the generated addresses and its operators might decide to cash out as soon as a certain amount of money is stored on addresses generated by them.

I don't need builds; please give me an URL for the source code of the version 0.4 patch. I'll give your code a quick security review (so hopefully it won't be too large) and then I'll compile my own client.

My github bitcoin fork: https://github.com/coderrr/bitcoin/tree/v0.3.24%2Bcoderrr
The commits with the changes: https://github.com/coderrr/bitcoin/commit/74411bec8438431e92a1ad0fd78495f3d742473d https://github.com/coderrr/bitcoin/commit/9376bcbaf7796f7fcf5e7f9976d3d42917507c63

Any chance of a windows build of 0.5 with the patch?

+1

I have to say that having read this, I am very disappointed. The anonymity available in bitcoin comes done to this: with special tools, a specialist will be able to violate the anonymity of anyone using the standard client. Shouldn't this be fixed at the protocol level? Perhaps by exchange of bitcoin amounts with random clients, these transactions might disguise legitimate transactions breaking the chain of address dependency.  This is not 'what it says on the box'!

Its true that eves-dropping is an issue, but its another issue, and in particular it requires action beforehand, while the blockchain is a permanent record, so can be analysed years afterwards to prove that I was sending money to more than one hot_lady!  (or whatever!)

Eves-dropping is an issue, but its not a reason for lack of action on this issue, Gavin, how could you imply such a thing? It sounds like an excuse for inaction.

While I really applaud the work of coderr and the Bitcoin authors, anonymity is a part of Bitcoins promise, this post makes it clear to me that for now at least, the past blockchain can be forensically analysed to reveal far more information than a casual user would expect. We need to see how we can deliver on this promise.

from my last reply on this thread

+1 - it's not just for anonymity, it's also a look under the hood at addresses, which helps when explaining how bitcoin works.

Can I "empty" several of my addresses to single, already existing, MY OWN address?

I am getting "Error: Transaction creation failed".

Can it be "not enough money on all specified addresses to take a required fee from it" problem?

yes, most likely the tx needs the 0.0005 fee, so transfer the total amount minus that fee and it should be fine

Question -- how do I specify multiple source addresses for sending BTC?

Can we have this rebased against 0.6?

Thanks.

(even though it's probably CTRL-click, for the sake of completeness...)

Settings - options - display
check that Display advanced anonymity features is ticked
click OK

There should be a new tab between address book and export

http://img11.imageshack.us/img11/8144/bitccoincoderrtab.jpg


Go to Send coins and look at the bottom where it says send from:
http://img27.imageshack.us/img27/2192/bitccoincoderrsendclear.jpg


Click anonymity

http://img141.imageshack.us/img141/6568/bitccoincoderranontab.jpg

click the address you want to send from, and it will highlight in blue.
CTRL-click to add more addresses.

go to Send coins, at the bottom you will see the selected address(es). You can delete or add addresses directly here, each address separated with a ; (semi-colon)
http://img714.imageshack.us/img714/8092/bitccoincoderrsendaddre.jpg


if there is insufficient funds in the selected addresses it will error and you will need to reduce the amount or  use another tab.

CTRL-clicking all addresses is equivalent to having none selected. ie the client will use up to all of the addresses that contain balances to calculate.

Don't forget that there is a tx fee for EACH address used, not one combined fee.

marked

Am i right in saying that this feature will not be supported by the official client?

merged into 0.5.3

code:
https://github.com/coderrr/bitcoin/tree/v0.5.3+coderrr

linux64 and win32 downloads:
https://github.com/coderrr/bitcoin/downloads

If you're on WINDOWS please use the new 0.5.3.1 build which has the patch for the recent vulnerability.

https://github.com/coderrr/bitcoin/downloads

If you use a previous version on WINDOWS you are in danger of being hacked and getting your wallet stolen.

works for me..check if u enabled it in settings of the qt client..isn`t called anonymity anymore..something with coinxxxx..:)

Coin Control is included in today's next-test release (https://bitcointalk.org/index.php?topic=73945.0). Please give it a try!

As has been mentioned before and I mentioned in here recently (but got ignored), just going to address level is insufficient.
Selecting the source for a txn should be to transaction level.

next-test (https://bitcointalk.org/index.php?topic=73945.0) should be compatible with 0.6.0, and has Coin Control

Is this still being developed?

Please, could we get 0.6.2 with this "Coin control" merged in?

The latest next-test is secure.

Can't wait for it to be merged in the mainline client!

Ente

Can't wait for it to be merged in the mainline client!

... and fixed so you can specify transactions, not just addresses.

is it not possible to achieve the same with coin control and a separate address for every transaction?

a feature that sets the transfer amount to all coins in the selected address minus fee would be nice. currently it's a pita to empty an address.

?

As has been mentioned before and I mentioned in here recently (but got ignored), just going to address level is insufficient.
Selecting the source for a txn should be to transaction level.

See the raw transaction API (https://gist.github.com/2839617) I've been working on, and please help try to break it-- it needs more testing.

The main motivation is to move forward with multisignature transactions, but it also lets you have complete control over the source(s) for a transaction.

It seems that knowing the fee in advance is beyond bitcoin.

This an issue that has been ignored or argued not possible for a VERY long time, every time it comes up, since there are some variables in the calculation that change over time I imagine is the excuse.

... what's that old timers term ... 2 phase commit ... not used much these days ...

So for the average joe's wallet that might want to use this to choose transactions or addresses, it's no good since you have to have done this from the start and always remember to do it that way?

My point being that your saying that this is only of use to people who have anonymity issues, rather than also for those who wish to have control over certain transactions
i.e. going one more level is as far as is possible with selecting sources for a transaction - and why not allow that? Why stop early?

See the raw transaction API (https://gist.github.com/2839617) I've been working on, and please help try to break it-- it needs more testing.

The main motivation is to move forward with multisignature transactions, but it also lets you have complete control over the source(s) for a transaction.

However, as mentioned above, the issue of fees is still outstanding - which does relate VERY closely to this.

This looks interesting - just one question after reading this document (as the word "change" does not appear in it at all) - will it be also possible to specify the *change* address with such "raw transactions" (in perhaps the sendrawtx command itself)?

This interests me.  Not the anonymity aspect, but the fine grain control per address.  I prefer this to opening and closing multiple wallets, which feels like a clumsy approach.

If you use the raw transaction API then you're responsible for saying exactly where all of the outputs go.  If you create a raw transaction with a 50 BTC input and a 2 BTC output then that is a no-change, 48 BTC fee transaction.  If you don't intend the 48 BTC to go to miners, then you need to specify where the change goes by adding another output.

I this the current multi-wallet plan allows for having multiple open concurrently.

I never understood why the fee calculation has to bee so complicated...  age of coins - wtf why?

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Your question answered many of my questions regarding transactions, forwarding, fees and DOS.
Thank you.

Ente

This is a great explanation. I'm going to put this on the wiki.

EDIT: Or not. I've forgotten my wiki password. I guess I'll do it later :P

Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF...

P.S. Just my 0.02 btc, nevermind :)

Actually i remember reading somewhere that this will be implemented in 0.7.
Am I wrong ?

No (...)

I don't think anyone has said it yet, so I'll just point out that this feature is available in the electrum client - you can prioritize addresses that you received at for a payment.  In particular, if you prioritize an address that received more than you're sending, you can be sure that only that address is used for the payment.

No, since the author and subsequent maintainer have both abandoned it, there is nobody to address the problems still left unresolved. Until that happens, it will not likely be merged. For the time being, I am keeping it minimally up to date for my next-test branches.

Good luck Luke-jr.

However, I think you are probably thrashing a dead horse since both Gavin A. and Jeff G. have indicated they will defend bitcoin's current level of traceability.

However, I think you are probably thrashing a dead horse since both Gavin A. and Jeff G. have indicated they will defend bitcoin's current level of traceability.

Good luck Luke-jr.

However, I think you are probably thrashing a dead horse since both Gavin A. and Jeff G. have indicated they will defend bitcoin's current level of traceability.

Good luck Luke-jr.

However, I think you are probably thrashing a dead horse since both Gavin A. and Jeff G. have indicated they will defend bitcoin's current level of traceability.

Gavin, if we, those who are interested in this function, provide our interest by donations to you or other developer, is there a chance that you will make this patch happen sooner?

Any updates on the topic ? Is anybody working on it ?

Certainly I doubt it will ever be a feature that Gavin's grandmother will be asking for. :)

* WKWTAD people = People Who Know What They Are Doing

And those people can't use the raw tx API (even with the help of brainwallet.org)?

Even if that is possible, it will be far more convenient (and less time consuming) if it would be integrated in the mainline client.

Well I am pretty sure I will be playing around with the raw tx stuff soon (probably using brainwallet.org to make it easier). So hopefully I'll have something positive to report about using it down the track. :)

i hope they will update it, or someone pick it up since this is really important!

Live in hope, die in despair! ---

It will never happen. The developers want BTC to get mainstream acceptance. The major issue that Governments and institutions have is the perceived anonymous nature of the BTC system. Therefore the developers will not countenance the idea of increased anonymity, perceived or otherwise.

Live in hope, die in despair! ---

It will never happen. The developers want BTC to get mainstream acceptance. The major issue that Governments and institutions have is the perceived anonymous nature of the BTC system. Therefore the developers will not countenance the idea of increased anonymity, perceived or otherwise.

Forget the word anonymous, it has all sorts of negative implications.

What we want is privacy, and privacy in our transactions is what we are talking about here. We obviously have to do it ourselves.
Therefore start a Topic, find an Escrow holder, start a Bounty for a viable but entirely separate Privacy patch to be developed.

Who is interested??

Establish an Escrow and I pledge 10BTC

You would basically have to write an advanced script or a frontend for bitcoind which would use this feature.

Anyway, it's complicated, not everybody has time for this and you don't have certanity that you did it properly. I would probably write my own script if that was easy enough.

What the fuck is wrong with you?  What makes you bring this kind of shit here?

The reason this isn't included in the main client is because it is hard to maintain, and provides very little real benefit in reality.  This has been discussed at length in (https://bitcointalk.org/index.php?topic=24784.msg359697#msg359697) this (https://bitcointalk.org/index.php?topic=24784.msg364599#msg364599) very (https://bitcointalk.org/index.php?topic=24784.msg651265#msg651265) thread (https://bitcointalk.org/index.php?topic=24784.msg1015494#msg1015494).  By all means, please, please! find someone to take charge of this.  But take your bullshit conspiracy theories elsewhere, none of the devs are excluding this to gain favor with "the man".



In answer to your question :-

“What the fuck is wrong with you?  What makes you bring this kind of shit here?”

This is what makes me bring this shit here!
http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf

Then I can see you have already seen it but others may not have. So here it is
https://bitcointalk.org/index.php?topic=121271.0

It's very interesting that you immediately take it that I inferred conspiracy and defend your perception abusively. Makes one wonder exactly why a perceived inference of conspiracy would elicit such a abusive response from Bitcoin Foundation-Life Member.

In short what I attempted to convey was. Viewed realistically there is no benefit to BTC as a entity in increasing the level of anonymity. In fact it may be detrimental because the level of anonymity is already a major issue with Regulators. Don't take my word for it on the anonymity issue, read the ECB document, ECB is concerned, all the Central Banks will have exactly the same opinion. It is not a conspiracy, it is common sense. It is called not making matters worse!
I don't for one minute think that the developers are as inept as you seem willing to portray. If they saw it as a beneficial priority, they would develop a solution that was maintainable and offered better privacy. It seems it is simply not a priority. Why is it not a priority? see the paragraph above.
This topic currently has ~13886 views it is about the fourth most viewed topic on this Alternative Clients board. That indicates that this is a matter of concern for many. I would guess that once more people read the recent ECB document and start to fully understand the possible implications there will be a great deal more concern.

Now, as for “the man” as you so quaintly put it, “the man” may be unable to shut BTC down in a single stroke but “the man” can make it so God-damn long term difficult that BTC will become nonviable.
Don't try to tell me the developers are not watching “the man” According to the ECB document Gavin Andresen has an “invite” from the CIA to brief them regarding BTC. But if you say so, no, no, the developers are not watching “the man”  This is the Core Developer “invited” to brief the CIA.

Now, get real, if you are going to deny something, you have to make it at least plausible.

This is what makes me bring this shit here!
http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf

Then I can see you have already seen it but others may not have. So here it is
https://bitcointalk.org/index.php?topic=121271.0

It's very interesting that you immediately take it that I inferred conspiracy and defend your perception abusively. Makes one wonder exactly why a perceived inference of conspiracy would elicit such a abusive response from Bitcoin Foundation-Life Member.

In short what I attempted to convey was. Viewed realistically there is no benefit to BTC as a entity in increasing the level of anonymity. In fact it may be detrimental because the level of anonymity is already a major issue with Regulators. Don't take my word for it on the anonymity issue, read the ECB document, ECB is concerned, all the Central Banks will have exactly the same opinion. It is not a conspiracy, it is common sense. It is called not making matters worse!
I don't for one minute think that the developers are as inept as you seem willing to portray. If they saw it as a beneficial priority, they would develop a solution that was maintainable and offered better privacy. It seems it is simply not a priority. Why is it not a priority? see the paragraph above.
This topic currently has ~13886 views it is about the fourth most viewed topic on this Alternative Clients board. That indicates that this is a matter of concern for many. I would guess that once more people read the recent ECB document and start to fully understand the possible implications there will be a great deal more concern.

Now, as for “the man” as you so quaintly put it, “the man” may be unable to shut BTC down in a single stroke but “the man” can make it so God-damn long term difficult that BTC will become nonviable.
Don't try to tell me the developers are not watching “the man” According to the ECB document Gavin Andresen has an “invite” from the CIA to brief them regarding BTC. But if you say so, no, no, the developers are not watching “the man”  This is the Core Developer “invited” to brief the CIA.

Now, get real, if you are going to deny something, you have to make it at least plausible.

holy shit totally paranoid and talking stuff without proof for it? wheres the troll flag :P anyway, ignored and b2t.

@flatfly:
electrum client is someway about trust, trust is bad!

@all:
ppl who need this dont really need it per GUI, a patch for bitcoind should be fine for everyone i guess?

For the more technically savvy the raw tx API (perhaps with help from brainwallet.org) reduces the priority of this feature a lot (as you have been able to do everything you want as far as controlling your coins since 0.7 was released).

For the less technically competent I guess the question is really whether the UI can be made easy enough to make the feature worthwhile implementing (if it's not easily understood then there is probably little point in doing more work on this). Note that I haven't actually tested the patch so have no idea how intuitive the UI is.

Certainly I doubt it will ever be a feature that Gavin's grandmother will be asking for. :)

This patch ... provides very little privacy

SPV does not mean verifying transactions. It means verifying the block headers and their proof of work, and verifying that the claimed transactions do in fact belong to the blocks. It does require some trust, in particular it relies on the majority of mining power creating valid blocks, but indeed far less than just randomly trusting a central server.

@CIYAM Pty. Ltd.
if its so easy, why arnt u creating a little wrapper (best in C so u can directly patch bitcoind with it :P) for it? Altough i have to say i didnt check this function out yet, maybe its really that easy.

Actually, if people really want to increase privacy, it's better to do more linkage... I believe it was coingenuity (if not him, copumpkin) who proposed a group of p2p nodes building a collective transaction with all their inputs and outputs combined and everyone signing it. This not only saves space in the blockchain and other nice benefits like that, it also means the assumption that all sources are the same is broken and improves privacy.