Topic: One vs Many Addresses (Read 1409 times)

So, as usual, things takes more time than you think when developing. However, this is one of those ideas I just have to try.

Anyway, I'm actually trying to implement both ways. "One address" and "Generate unique addresses". Just to see how they compare. While testing this with one address, I noticed that sometimes I don't seem to get the sending address from first offset in the input. See my testing here:

http://api.blockcypher.com/v1/btc/test3/addrs/mggchBoqRNoT3beYCX4h2DMGtT2a6AaFFg

I've send a few testnet3 bitcoins to the mggchBoqRNoT3beYCX4h2DMGtT2a6AaFFg address, and if you look at the this transaction here: https://api.blockcypher.com/v1/btc/test3/txs/2e11ff66366592fdca419baef8873532594d85d80de5b3f714cbcc301eda3c20

I can grab the correct sending address from this input:

I get the sending address n295M4YJiumNFiTasqcHp5g7zr6BhD8G9L. All fine and dandy. This works for the other transactions as well, but when I look at this one: https://api.blockcypher.com/v1/btc/test3/txs/bd5d6f2a606f45be09c28744bc3b707bc885ee6f5ca0bd5e90ff54c0159b958c

The sending address is n4VQ5YdHf7hLQ2gWQYYrcxoE5B7nWuDFNF for some reason. And I have no idea why.

I only have these receiving (sending) addresses in the wallet:

mtPw16eSgDNojw5w7VEshLAk55nh8UCihZ
n295M4YJiumNFiTasqcHp5g7zr6BhD8G9L
msoZ1tjxth5Z6RDXKjPRTvES1QyGs2XkvR

So, as this seems tricky I'm now really leaning towards generating unique addresses instead. Anyone that can cast a light on this? If you look at the address here: https://live.blockcypher.com/btc-testnet/address/n4VQ5YdHf7hLQ2gWQYYrcxoE5B7nWuDFNF/ you can see it seems like the address just became some temporary receive and send address... Either way, it's confusing me.

I will continue working on "generate addresses" instead, as this "grabbing sending address" doesn't seem too reliable..

Seems the first option still has more votes... but from the feedback in the comments, I think I would go for #2 anyway. Hope that doesn't disappoint too much, unless you guys that voted for #1 can clarify why that option is better?

Isn't this good?

That's a lot less convoluted, though.

Yea, this is true.

Ok, now this is getting confusing.

Why not just do like this: I come to the site. I first input my address I want money send to. Next a deposit address is generated, or password first and then deposit address. With password, I essentially have an account, but I can't change the address money will be send to.

1 Main Address for Everybody would not work very well, there is bound to be a private key/password with a means to send coins to specific users. If so, would'nt that be putting all your coins in one hell of a basket? If you can implement 1 main address for everyone without risks, you would be filthy filthy rich   I would suggest unique addresses for each user, saves alot of auditing trouble and trouble should unfortunate events happen

You would assume all receiving addresses are compromised since an attacker would see them being sent to from your one BTC address, leaving only the username as a defense. Because of this, it's important users don't reuse usernames for this.

Let's say Malicious Marvin looks through transactions sent by your site's BTC address and knows 1Whatever is Bill. -So let's say Bill goes by DrunkonCoins on BTCTalk. There's a good chance Bill's going to re-use that username, so it's good to try getting them to choose a unique username (or generate one for them) or at least make them aware their username is effectively their password.

Ideally, you wouldn't use the public address as a username since the username itself should be a kind of password (and I just know someone's about to get up my ass over that ), so... disclaimer: I'm just putting that out there as one possibility out of many..... but a lot of sites post user's usernames, so... you know....

I really like this idea! +1 to you sir. I'm not sure what you mean with "Generate one for me" though. Also, what's interesting about this is that even if someone knew both, they can't do anything of importance, which I like very much! Which one of these can be public information?

If I want to be transparent I want to show both deposit and users receiving addresses (although I could in the account give an option to hide it). So, that would be public. Meaning "username" is more of a "password" and should not be public, right?

Cookies with addr and username alone could work (rec addr as "username," username as "password"). User enters withdraw address, user enters username ("Generate one for me" preferred), hashed together creates login token saved as cookie. User can provide receiving address and username for account recovery but cannot ever change the receiving address.

I'm not sure how you could implement #1 one way or the other with full confidence. You could perhaps prevent conflicts by generating a Bitcoin URI with a random string as the message. -Like bitcoin:1Whatever?amount=1&message=[UniqueHashHere]. If there's a dispute, just have the user relay the hash in the message until push messaging (or whatever They're calling it) is implemented. What are you doing, anyway?

My main goal with this was to do it how people prefer it. And, as easy as possible. But also secure. I know those don't go hand in hand, but still. Leaning towards #2 now however though, because it still enables me to be transparent which I would like to be.

It would probably be easiest to use #2 especially if you didn't want to bother with creating accounts or doing session management (and #1 is not recommended for both security and privacy reasons).

Thanks guys for quick feedback.

I guess I forgot to mention that the 2 first options is really setup to keep it simple with no accounts where users have to login and stuff.

With #3 I guess I need to setup some kind of account system too. With cookies, passwords and all that jazz. How does #3 work with #1 exactly? How would I best map the the transaction send address information to the users account return address?

This has quite a few benefits, a big one being that you can be pretty damn confident you aren't going to run into unauthorized use issues. Locking accounts to return addresses also eliminates a lot of the attraction to would-be thieves (though it doesn't directly impact the attraction to fuck around in your own tables for a bigger reward).

3. Get the user to provide a "return" address so then you don't need to try and work out where to send funds to (and works with either 1 or 2).

I like to use one address for everyone. It's easy to monitor. I know this is not how Satoshi envisioned it, it is convenient.

Hey folks,

I'm working on an idea which I plan of releasing in a week or so hopefully.

But, I'm having trouble deciding what method to use.

There are basically 2 ways you can do a bitcoin wallet payment solution.

1. Have one address which everybody sends to, and you use some magic to figure out what address the payment came from and you can send money back to.

This way the address is completely public and everybody can see what happens quite easily. However, there are restrictions as to what wallets people can send from. And might be a bit trickier to get working properly as I don't have much experience using this method myself, so I'm not sure how reliable it is to get users send addresses from the transaction information.

or

2. Create unique addresses for users to send to. Before doing this, you can just let the user specify which address that the user would like to get money to.

This is more of a controlled way to keep track of who payed what, and easy for users to specify where the money should come back. And, they can send from whatever wallet they want to. However, it's hard for anyone to see a total as one can do with the first one. I guess, one actually could just show all those addresses, and sum it up though.

What method do you guys prefer? First method is convenient, but again, you have to be careful with from where you send. And second is more controlled but less transparent (although one can make it more transparent by showing those addresses publicly as well).

Thanks,
Chillance