Actually, if you believe as I do that Bitcoin should remain fungible money and not eventually be reduced to a mere collectible then you should never reuse an address for any reason. Address reuse allows BTCIndia and others of his ilk to begin to and eventually attach identities to addresses. This strikes at the very core of what Bitcoin is or will become. In order to maintain and support the fungibility of Bitcoin:
Stop using vanity addresses
Always send change to a new address
Use a new address for each transaction
Even donations should be done through new addresses
All periodic payments should use BIP32
Coins should be mixed as often as possible, hopefully someday all transactions will be automatically mixed in every block
Avoid attaching identities to addresses
Topic: Is following possible with programming? (Read 1681 times)
A proper way for a merchant to receive BTC payment is to generate an address for each customer. It's a standard way and helps a lot for tracking who pays how much automatically. You could generate a BTC address when people login in and store that in the DB.
Please use one public address approach only as donation address.
Please use one public address approach only as donation address.
Wow, you guys replying are AMAZING. Impressed by the patience that many posters have here. 
Not only will most of us here not help you, we will be doing everything in our power to make it impossible for you to do this.
Seconded. If you're trying to link people's transactions without their active consent and cooperation, then you're working directly against their interests. Good people will be trying to stop you.
Good people will be trying to stop me?
If you see from my frame of mind then, I'd say bad people will be trying to stop me. I'm just working on some hypothetical concepts here, dude. You might be amazed to know that I got flunked on C++ three times.
You expect me to go against your community with these skills? I'm just being dreamer here. Chillax!
I think he meant good in the sense of "good at math and programming" or "better than you at math and programming" not good as in good and evil.
You do need to know that the idea of attaching identities to transactions is a direct attack on the concept of Bitcoin and in fact all public ledger systems. You cannot have both the ledger and the identities be public. Such a system would not ever be used by anybody. Would you use a system where who you are and how much you have and exactly how and where you spend all your money is totally public? I think not. One or the other has to be private: transactions and amounts are private but identities are public (current fiat money system) OR transactions and amounts are public but identities are private (Bitcoin and other public ledger systems).
The point is, someone will be wanting to stop you. Nobody really likes such harvesting of information without their consent, to some degree or another.
Not only will most of us here not help you, we will be doing everything in our power to make it impossible for you to do this.
Seconded. If you're trying to link people's transactions without their active consent and cooperation, then you're working directly against their interests. Good people will be trying to stop you.
Good people will be trying to stop me?
If you see from my frame of mind then, I'd say bad people will be trying to stop me. I'm just working on some hypothetical concepts here, dude. You might be amazed to know that I got flunked on C++ three times.
You expect me to go against your community with these skills? I'm just being dreamer here. Chillax!
Not only will most of us here not help you, we will be doing everything in our power to make it impossible for you to do this.
Seconded. If you're trying to link people's transactions without their active consent and cooperation, then you're working directly against their interests. Good people will be trying to stop you.
Not only will most of us here not help you, we will be doing everything in our power to make it impossible for you to do this.
It's a race, for sure.
The next generation of cryptocurrencies is going to have much harder anonymity.
Anoncoin is optimized for use by Tor -- in fact IIRC requires it. There is not and never will be linking via IP address there. StableCoin keeps talking about an 'automatic decentralized coin tumbling service' - which, if implemented, will make it impossible to link transactions via the blockchain. Several people are talking about 'decentralized exchanges', envisioning single commodity transactions having literally hundreds of buyers and sellers. Even without any efforts toward privacy, that'd make it pretty impossible to track the transactions of individuals by keeping track of which txouts belong to them. When somebody puts $10 into an exchange transaction with $1M of other buyers' money, and then that same transaction pays out to a thousand sellers? If you want to keep track of that somebody, he now has some small part of $1M worth of the exchange commodity, and you cannot know which part. If you're keeping track of the commodity, the person you're interested in now has 1 / 100K of the commodity that you can link to his money. If he then turns around and sells his $10 worth of commodity in the next exchange transaction, he gets his $10 back (more or less) but if you're trying to track it through the blockchain, the guy you're interested in now has $10, which is only one part in ten trillion linkable to the money you were trying to track.
And the next generation of snoops is going to take advantage of an increasingly rigged infrastructure to try to break it.
Lots and lots of crooks, plus various commercial enterprises and the intelligence and law enforcement agencies of various nations, will be trying to de-anonymize people, and as we've recently seen, the people whom we trust for privacy, can't be trusted. They can be bribed, they can be blackmailed, they can be served with subpeonas requiring them to reveal secrets and gag orders to prevent them from talking about it, they can succumb to extortion, they can owe far too much money to the mob, they can be tricked into buying bugged routers and switches, they can have electronic bugs planted in their buildings, they can have wayward employees walk out the door with a million people's private data on their thumb drives, they can be subject to MITM and Sybil attacks, they can even directly attack the security of their customers and try to install rootkits. They can be tricked into using "standards" that have backdoors built in, the people who know about the backdoors can be tricked into revealing them to crooks, and even nations that have privacy laws find it nearly impossible to prevent trades in customer data.
So... Just saying, the competition is stiff.
The next generation of cryptocurrencies is going to have much harder anonymity.
Anoncoin is optimized for use by Tor -- in fact IIRC requires it. There is not and never will be linking via IP address there. StableCoin keeps talking about an 'automatic decentralized coin tumbling service' - which, if implemented, will make it impossible to link transactions via the blockchain. Several people are talking about 'decentralized exchanges', envisioning single commodity transactions having literally hundreds of buyers and sellers. Even without any efforts toward privacy, that'd make it pretty impossible to track the transactions of individuals by keeping track of which txouts belong to them. When somebody puts $10 into an exchange transaction with $1M of other buyers' money, and then that same transaction pays out to a thousand sellers? If you want to keep track of that somebody, he now has some small part of $1M worth of the exchange commodity, and you cannot know which part. If you're keeping track of the commodity, the person you're interested in now has 1 / 100K of the commodity that you can link to his money. If he then turns around and sells his $10 worth of commodity in the next exchange transaction, he gets his $10 back (more or less) but if you're trying to track it through the blockchain, the guy you're interested in now has $10, which is only one part in ten trillion linkable to the money you were trying to track.
And the next generation of snoops is going to take advantage of an increasingly rigged infrastructure to try to break it.
Lots and lots of crooks, plus various commercial enterprises and the intelligence and law enforcement agencies of various nations, will be trying to de-anonymize people, and as we've recently seen, the people whom we trust for privacy, can't be trusted. They can be bribed, they can be blackmailed, they can be served with subpeonas requiring them to reveal secrets and gag orders to prevent them from talking about it, they can succumb to extortion, they can owe far too much money to the mob, they can be tricked into buying bugged routers and switches, they can have electronic bugs planted in their buildings, they can have wayward employees walk out the door with a million people's private data on their thumb drives, they can be subject to MITM and Sybil attacks, they can even directly attack the security of their customers and try to install rootkits. They can be tricked into using "standards" that have backdoors built in, the people who know about the backdoors can be tricked into revealing them to crooks, and even nations that have privacy laws find it nearly impossible to prevent trades in customer data.
So... Just saying, the competition is stiff.
Just saying, I don't want a service collecting information about me that way. Unless it's banking or something else official I completely randomize the details I give.
You want to stay anonymous and I don't want you too stay. You play your hands and I'll play mine.
Just saying, I don't want a service collecting information about me that way. Unless it's banking or something else official I completely randomize the details I give.
If you will never have as many as one hundred million customers, then you can use the decimals of the amount to identify which customer sent the whole bitcoins part of the value that was sent.
So for example when customer number 12345678 send a bitcoin, have them send 1.12345678 bitcoins.
Either have them send it from a wallet they control so you can send the "change" (0.12345678 bitcoins) back to the sending address, or have a "change address" for each customer in your database so you know where to send the change.
If you do want to use the memo field, go ahead and use a coin that has a memo field. But bitcoin has no memo field per se yet.
See however the work that is going on toward a payments layer that will carry extraneous information between merchant and customer and vice-versa...
-MarkM-
So for example when customer number 12345678 send a bitcoin, have them send 1.12345678 bitcoins.
Either have them send it from a wallet they control so you can send the "change" (0.12345678 bitcoins) back to the sending address, or have a "change address" for each customer in your database so you know where to send the change.
If you do want to use the memo field, go ahead and use a coin that has a memo field. But bitcoin has no memo field per se yet.
See however the work that is going on toward a payments layer that will carry extraneous information between merchant and customer and vice-versa...
-MarkM-
Beautiful thought!
I love your logic's! What if I'll be accepting 83 Satoshi from all of them? Y'all are not answering OP's question.
The issue is linking information. In principle, when a retailer gets a BTC payment from an unknown BTC address, and has no other information, he does not know who has sent it, so he cannot know which of his known accounts to credit.
In practice, if he knows the IP address of his customer, he can look at the IP address the BTC payment originated from and link the payment to the customer. But that's not 100% reliable because IP addresses change often. And you cannot do it after the fact; none of the IP details are recorded in the block chain, for example, so you have to be monitoring packets as they arrive to know where a BTC payment comes from.
But there is a way to do it 100% reliably with the customers' cooperation. Each bitcoin transaction has a message field, and if your customers are cooperating with your efforts to link their accounts to their payments, then they can just stick their account number in the message field to make sure that the merchant can credit the correct account.
The issue is linking information. In principle, when a retailer gets a BTC payment from an unknown BTC address, and has no other information, he does not know who has sent it, so he cannot know which of his known accounts to credit.
In practice, if he knows the IP address of his customer, he can look at the IP address the BTC payment originated from and link the payment to the customer. But that's not 100% reliable because IP addresses change often. And you cannot do it after the fact; none of the IP details are recorded in the block chain, for example, so you have to be monitoring packets as they arrive to know where a BTC payment comes from.
But there is a way to do it 100% reliably with the customers' cooperation. Each bitcoin transaction has a message field, and if your customers are cooperating with your efforts to link their accounts to their payments, then they can just stick their account number in the message field to make sure that the merchant can credit the correct account.
Thanks Cryddit! You seem to understand my problem perfectly. Here, I'm working on to trace a unknown wallet so that I can link anonymity with identity(Name, sex, age). People are not going to send me 1 BTC without reason.. but I've a plan. Actually, I'm not interested in 1 BTC. My interest is linking those information in fill up form to wallet address from which I'll be receiving. I dream to spy on their ledger and transaction. And for that thing, I need to link identity with anonymity. I can't tell them to write a note with transaction and even if I say, they're not gonna write it. This is my hurdle!
Attempting to use IP is a bad idea imo. What if Bobby registers from his home computer, but keeps his coins in an online wallet or on an exchange?
As many people have mentioned normally a service would generate multiple addresses, one (or more) for each depositor. If you do want to have only the one receiver address you could use transaction messages, e.g bobby attaches message containing 'bobby' to transaction. Although that restricts which coins you could use, as not all support messages, but its an option I guess.
As many people have mentioned normally a service would generate multiple addresses, one (or more) for each depositor. If you do want to have only the one receiver address you could use transaction messages, e.g bobby attaches message containing 'bobby' to transaction. Although that restricts which coins you could use, as not all support messages, but its an option I guess.
It seems, based on the image in the post, that there is a single address that everyone is sending to. Therefore, the solution of giving each user a unique address won't work.
It is possible to extract information and send customer to the bitcoin address checkout page. If three persons from different computers fills a form, and send the order, while they send the order, their order information should go straight ahead to database, and the order id should be generated and given to bitcoin checkout. So in that way, each order will get a unique order id, and each unique id should be sent to bitcoin checkout, so you can identify the payment.
If you will never have as many as one hundred million customers, then you can use the decimals of the amount to identify which customer sent the whole bitcoins part of the value that was sent.
So for example when customer number 12345678 send a bitcoin, have them send 1.12345678 bitcoins.
Either have them send it from a wallet they control so you can send the "change" (0.12345678 bitcoins) back to the sending address, or have a "change address" for each customer in your database so you know where to send the change.
If you do want to use the memo field, go ahead and use a coin that has a memo field. But bitcoin has no memo field per se yet.
See however the work that is going on toward a payments layer that will carry extraneous information between merchant and customer and vice-versa...
-MarkM-
So for example when customer number 12345678 send a bitcoin, have them send 1.12345678 bitcoins.
Either have them send it from a wallet they control so you can send the "change" (0.12345678 bitcoins) back to the sending address, or have a "change address" for each customer in your database so you know where to send the change.
If you do want to use the memo field, go ahead and use a coin that has a memo field. But bitcoin has no memo field per se yet.
See however the work that is going on toward a payments layer that will carry extraneous information between merchant and customer and vice-versa...
-MarkM-
The problem is you don't know the IP address of the person creating the transaction. Since transactions are relayed through the P2P network, chances are that you will see the transaction coming from the user's IP address. So you can't match the IP address you have stored with the IP address relaying the transaction.
Plus not everyone is running Bitcoin-qt on their computer. Some people use websites like blockchain.info, so the IP address initially relaying the transaction would be that of blockchain.info.
Bitcoin transactions don't include name, age, or sex, so it is not possible to match those.
So I don't see how this can work.
Plus not everyone is running Bitcoin-qt on their computer. Some people use websites like blockchain.info, so the IP address initially relaying the transaction would be that of blockchain.info.
Bitcoin transactions don't include name, age, or sex, so it is not possible to match those.
So I don't see how this can work.
Just give each customer a unique address for each transaction. In other words tread Bitcoin addresses just like invoice numbers and add these invoice numbers to the database information about each customer. That way you know exactly who paid what and when.
Hey, that works too, and doesn't even require customer cooperation. But it means you can't publish a merchant address in the normal way (ie, same address for everybody because you put it in a magazine ad or something).
Y'all are not answering OP's question.
The issue is linking information. In principle, when a retailer gets a BTC payment from an unknown BTC address, and has no other information, he does not know who has sent it, so he cannot know which of his known accounts to credit.
In practice, if he knows the IP address of his customer, he can look at the IP address the BTC payment originated from and link the payment to the customer. But that's not 100% reliable because IP addresses change often. And you cannot do it after the fact; none of the IP details are recorded in the block chain, for example, so you have to be monitoring packets as they arrive to know where a BTC payment comes from.
But there is a way to do it 100% reliably with the customers' cooperation. Each bitcoin transaction has a message field, and if your customers are cooperating with your efforts to link their accounts to their payments, then they can just stick their account number in the message field to make sure that the merchant can credit the correct account.
The issue is linking information. In principle, when a retailer gets a BTC payment from an unknown BTC address, and has no other information, he does not know who has sent it, so he cannot know which of his known accounts to credit.
In practice, if he knows the IP address of his customer, he can look at the IP address the BTC payment originated from and link the payment to the customer. But that's not 100% reliable because IP addresses change often. And you cannot do it after the fact; none of the IP details are recorded in the block chain, for example, so you have to be monitoring packets as they arrive to know where a BTC payment comes from.
But there is a way to do it 100% reliably with the customers' cooperation. Each bitcoin transaction has a message field, and if your customers are cooperating with your efforts to link their accounts to their payments, then they can just stick their account number in the message field to make sure that the merchant can credit the correct account.
Jump to: