I hope the answers given by Pavel earlier are able to answer your questions? Do ask additional questions that might not have been answered yet.

I am the CTO of Bluzelle Networks. We have launched a MSB-licensed gateway out of Canada, and are quite interested in running an INR gateway for India.

Would love to re-start this conversation and find more information on what is necessary to do this.

Possibly the most important question is around licensing -- do any of you have a proper license to do this, and if not, are you in the process of acquiring one? Do you know specifically what is required to run a gateway in India?

On another note, Ripple in itself IS decentralized. It comes down to how it is actually implemented, but the design is a decentralized one. Ripple is a protocol, not a currency. It happens to have a native currency called XRP that is pre-mined but comparing Ripple to Bitcoin directly is not quite accurate.

Even with a mixer, the bitcoin address that the payment was sent to is still fixed. If it is for a porn site, now everyone knows what BTC addresses have made payments to a porn site. They may not know what the porn site did with the proceeds, but in this context, how important is that?

It is a bit odd. Bitcoin Forum has a field for "Bitcoin Address". I don't actually have a "Bitcoin Address", do I?

Makes me wonder. In general, if I want anonymity, there is no way for me to advertise an address of mine. I know that sounds obvious, but if I wanted to receive payments, someone would have to goto my site and ask me for one.

What is the main reason my second scenario is not ideal? Is it the re-use of the payment address because now, that can be tracked and reduces anonymity? Or are there any other reasons? What about any increased risks?

So here are a few questions...

Blockchain lets you send BTC to someone, obviously. It has the option of "any address" vs selecting a specific address from a list.

1. Is it reasonable to assume that if I select a specific address, it will limit what I can send to the sum of all the unspent inputs sent to that specific address?

2. Or is there more magic to this? Like say if I don't have enough on that specific address's own unspent inputs (but do from other addresses), it first sends the necessary unspent inputs from those others to the selected one, and then sends from the selected one to my intended recipient, sending the change to whereever I designate?

3. What would "any address" mean? Does it simply mean use any of the unspent inputs from any of the keypairs I have the private key for? So in theory, the "sender" could be a bunch of different addresses I have the private key for?

MOST importantly...

4. If I am building out a service where I want to receive BTC from my customers, what is best practice for this? Give each of them a unique and unchanging BTC address to make payments to? Does this violate the principle then that BTC addresses are not to be re-used? I am trying to avoid burdening my customers with the need to goto my site each time they want to make a payment to me to request a new BTC address to pay me with. I am also trying to avoid a related burden then of having to store all the keypair information for all the BTC addresses of all my customers.

The ideal scenario would have been that I have ONE BTC address that ALL BTC payments from ALL customers come to. I own the private key for this address. This would require me to look at the sending address of payment to know who sent it. BAD idea. The sending address is not deterministic.

Less ideal scenario is I have ONE BTC address for EACH customer. So Bob has his deposit address with me. Alice has own own. I own the private keys for these. So now, I can infer that if a payment comes into Bob's deposit address, I credit Bob. Etc. I am making no assumptions on Bob's sending address. But Bob's deposit address is now fixed. A BTC address is being re-used.

Least preferable scenario is everytime Bob wants to send me BTC, he can login to my site, as for a new BTC address, and pay to that address. He could technically pay more than once to the same address but the point here is Bob can keep getting new BTC address to pay me with. I have to now remember all of Bob's deposit addresses on the backend.

Thoughts? I am I right about these three scenarios?

Actually, I did read it. A while ago. I will give it another go. Thanks for the quick response.

It could be, but the keypairs are very small, and several thousand addresses would only take up a couple Mb tops. With current technology, and the current growth, this will never become a problem.

I suppose that once a keypair has 0 BTC left as unspent inputs, we could discard it from the "environment"? Thereby keeping the "environment" lean?

Still, it means we have a Blockchain that grows like mad. Over time, every BTC address ever used by ever user since genesis is in there. There is no real way to "compress" or trim this Blockchain if a person's "balance" it determined as a result of their transaction trail.

A new keypair is not generated for each send. Bitcoin core sends your funds from one or more of the addresses you own, and the remainder from the address goes to a newly generated address as the change. It will try to involve as few inputs as possible in order to create your transaction.

So indeed the recipient now knows who paid me. And who paid me now knows who I paid?

Why even bother with a new change address? It is still tied back to the receiving keypair. So no anonymity gained here...

Bob can send his bitcoin to a mixer. The mixer service allows Bob to send multiple payments, one from each of his addresses, to them and then he can withdraw his bitcoin from the service when all of his Bitcoin has been sent there. The withdrawal takes Bitcoin from addresses that he did not send to and sends that to another newly generated address owned by Bob, thus anonymizing his Bitcoin. Alice will only know that the Bitcoin she sent Bob went to another address, but she will have lost her trail on Bob. Carol will only know that he funded his address from other addresses, but tracing those, she will be tracing Bob's payments.

If Bob does not use a mixer, then Carol can see the addresses she is being paid from, and Alice can see where the Bitcoin is being sent. If Bob also sends from many of his addresses, then both Carol and Alice will know what addresses Bob has.
[/quote]

Well, I heard about mixers. But this is now a value added service on top of Bitcoin and Bob has to trust the mixer to not decide to vanish at that point in time and walk away with whatever is in the "bowl" at that time, right?

Overall then, all the people who paid me for a certain "group" of BTC will know all the people I paid that BTC out to, and vice versa. I can create "islands" of privacy so that each time I am paid, I have a new keypair that has nothing to do with the existing ones, but now all the people who get paid by the BTC on this new island know who paid me on the same island.

Furthermore, if I need to make a big payment in BTC, I will likely have to combine the BTC from many different islands. Now, all those people who were on all those islands know about each other, as well as the guy I making the big payment to. Is this accurate?

@DannyHamilton

Thanks for the wonderful response. I think it clears up much.

I understand now that when I "login" to see my wallet, what I am logging into is really a semantic that has nothing at all to do with Bitcoin. I am logging into an environment that now has access to all the private/public key pairs that "belong" to me. The pairs that involve unspent inputs are important since these contain BTC that have value and I could spend.

Whenever I want to receive BTC from some arbitrary user Bob, I do not at any point tell Bob ANYTHING about my existing public keys that I hold the private key for (where the public key is effectively a BTC address). What I do instead is generate a NEW key pair, keeping the private key stored only in this secure environment I just logged into (how this is implemented is not relevant -- could be stored in the cloud or on my local hard drive or whatever), and give Bob the BTC address corresponding to the public key from this pair. Bob makes the payment, not knowing anything about what other pairs I hold nor any unspent inputs among them.

Now, once I have received that BTC from Bob, I have another pair that I manage that has unspent inputs.

Some questions:

1. Is the above accurate?
2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.
3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).
4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

Hi.

I am trying to build a service where I provide my users the ability to deposit bitcoin into a hosted wallet of sorts. So obviously, they need to be given a bitcoin address to send the coins to.

A couple options I thought of:

- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.

- Provide one bitcoin address for everyone to deposit to and look at the sender bitcoin address. But now each user on my system is constrained to register a single bitcoin address with me so I can recognize their deposits. I could now look at the sender's address in the tx, right? I know this might sound obvious but I am a bit confused about unspent inputs from the sending address. Namely, if address A receives bitcoin from a bunch of different senders and then A wants to send to B, as far as B is concerned, all those payments came from A as the sender right?

Are there any other options that are cleaner than these? Any errors in my assumptions?

It is a matter of opinion if it is spamming. You can argue it both ways. Frankly, miners can always choose to reject your TX if they want to, based on what fee you provide. So ultimately, the miners could just process such TX's with a high enough fee that justifies it. Sort of alleviates a mass-spam issue and now, people are paying to store data.

Interesting!

I tried and got the following:

Trying to send...
array(3) {
  ["result"]=>
  string(64) ""
  ["error"]=>
  NULL
  ["id"]=>
  string(1) "1"
}
Response = 0

replaces what appears to be a hex string that is the same length as a tx hash.

What does this mean?

Also, when you say it could take a while, do you mean the confirmation time?

This is neat!

I thought someone would eventually do this.

Do you know how to send out OP_RETURN tx's? I have been looking into these, and while I can construct them, I can't find a way to send them to the network.

Given we know this tx did get relayed, if we want to send out OP_RETURN tx's, is there a way to do so? I have figured out how to construct such a message properly, but it seems to be impossible so far to send it out, as expected. The typical "entry points" to send the raw tx (such as blockchain.info's push or bitcoind's sendrawtransaction) tend to fail. The latter fails client-side, I think and does not even bother talking to the network.

Perhaps the IP of the node that relayed this example tx successfully is a miner that does accept such tx's?

I have been able to create an OP_RETURN tx.

I probably don't understand this as well as you do (obviously), so pardon some of the obviousness of my question.

I realize opcode 0x6a is what refers to OP_RETURN. I noticed this in the HEX for some of the TX's already on the blockchain that have OP_RETURN output scripts. It seems (if I get it right) that it is something like 0x6a

Not too sure what you meant when you said to put the opcode 0x6a in front of the script followed by the length prefix.

Since the bitcoind client does not let you specify output scripts (per my knowledge) when creating a raw transaction, I am going with the idea that I have to take the output of createrawtransaction, and modify it to additionally include OP_RETURN somehow.

What approach were you referring to?

My understanding is are being considered because people are resorting to creating unspendable UXTO's to "embed" data. This would pollute the blockchain and is not something that can be stopped, so since we can't stop it, let's at least provide a cleaner way to do it, albeit we would prefer it not be done at all.

Is this sort of the point and why this won't be a feature that will be easily provided?

Problem is, it is still way easier to do the former than it is to use OP_RETURN, from how I understand things, so unless you make it at least reasonably as easy/hard to use OP_RETURN as it is to do the former, it is sort of pointless.

But more generally, how do you even specify your own output scripts? What if you want to something fancier than just sending BTC to one or more recipients using the already-supported script operarations. How would you even do that? Is the reference bitcoin client not meant to support this?

Is this something that can't be done yet (unless using a 0.9 release candidate)?

I know that people have already sent out TX's that specify OP_RETURN in the output scripts, but I can't seem to see how to do this. I apologize if I should have put this in a different forum -- not sure.

Thanks.

Their code is broken, quite simply.

Some of us have actually tried to fix the code and get this crappy thing to work. No go.

And if you were able to, bravo! That don't make it sensible to ship a piece of crap most people can't use.