Send to many addresses FROM a certain address

[loquitus_of_borg]

Hello folks.

I am getting a bit frustrated with the standard bitcoin command line client (bitcoind).

I have been building a service where I want incoming payments to always go to a certain well-advertised and known and unchanging address X. I want to be able to also send out money to one or more addresses from X. In the local wallet, I manage not only address X, but also Y and Z.

Using sendmany allows me to specify one or more destination addresses and amounts for each, which is great. It even lets me specify the sending account (not sending address). So let's say address X was in account A, address Y was in account B, and address Z was in account C. So I thought I could send from X by specifying A as the account to send from using sendmany.

This is not the case. The bitcoin client will use some algorithm I do not really understand to send money from any of the X, Y, or Z accounts. This is absolutely not what I want to do.

I tried a patched version of the client, as per: https://github.com/coderrr/bitcoin/tree/v0.5.3%2Bcoderrr. I downloaded the binaries for linux and ran the command line daemon but it does not get the blockchain. I had figured this would resolve the issue. It did not.

So what options do I have then?

[CIYAM]

Accounts are not addresses - so you simply cannot think of address X *belonging* to account A (the accounts in bitcoin are confusing to many).

If you want to control the UTXO's being used (the "froms" and note they will often be many) then you are either going to have to use the "Coin Control" version (and not the "coderr" one as it's obsolete) or start coding "raw transactions".

[loquitus_of_borg]

Thanks for the reply.

So I figured that there is some confusion on what an account is, and that specifying an account does not necessarily dictate what address is actually being used.

Where do I get this "Coin Control" version? Is it an official release or a patch of some kind, and is it well "supported"?

I definitely want to stay away from going with raw transactions.

Please advise.

Accounts are not addresses - so you simply cannot think of address X *belonging* to account A (the accounts in bitcoin are confusing to many).

If you want to control the UTXO's being used (the "froms" and note they will often be many) then you are either going to have to use the "Coin Control" version (and not the "coderr" one as it's obsolete) or start coding "raw transactions".

[CIYAM]

Where do I get this "Coin Control" version? Is it an official release or a patch of some kind, and is it well "supported"?

The version of "coin control" you'd want to be using is by "cozz" and you can find a link to binaries and source in the OP here: https://bitcointalk.org/index.php?topic=144331.0 (it is not part of the official bitcoin-qt client *yet*).

[gmaxwell]

I have been building a service where I want incoming payments to always go to a certain well-advertised and known and unchanging address X.

This is _strongly_ discouraged. If you do this you will not be able to tell which of multiple parties concurrently paying you is paying you, you will degrade privacy for your own service and other users of Bitcoin as well. You may be subject to blocking by hostile parties, it's just generally a bad plan.

The account functionality is purely local bookkeeping— like categories in a checkbook. It doesn't influence the transactions the system creates. It was created for a particular niche usecase (shared webwallets) and it's not even particularly useful for that case.  It's generally discouraged to use accounts for anything important.

[CIYAM]

This is _strongly_ discouraged.

Indeed - I didn't read the OP carefully enough - you really should be generating a separate address for every payment being made.

[loquitus_of_borg]

Hmm...

So if I wanted to have a general address for people to send money to me for donations, services, or whatever else it is I am doing, you are saying I should not do this, and therefore making a certain address known as being the one to pay me on is essentially not to be done?

If so, then how do I do this? What if I wanted to (just a silly example) print t-shirts or put an ad out on the newspaper or a tv commercial saying pay to this address for some purpose -- you are saying this should not be done?

This is _strongly_ discouraged.

Indeed - I didn't read the OP carefully enough - you really should be generating a separate address for every payment being made.

[CIYAM]

If so, then how do I do this? What if I wanted to (just a silly example) print t-shirts or put an ad out on the newspaper or a tv commercial saying pay to this address for some purpose -- you are saying this should not be done?

Perhaps just think about this from your own side - how do you know who has paid if all payments are made to the same address?

[loquitus_of_borg]

I can look at the incoming transaction and figure out its inputs, can't I? I then know who the sending address is. If I had a mapping (internally) from the sender address to some business service or product I need to sell to them, then I can validate at this point that the payment was made from them.

There could be multiple inputs, I realize, and that is a challenge in itself, but each incoming TX has this info.

On my original question then -- there is no effective way then to advertise a service and tell people to pay to that service.

And what about something like SatoshiDice? They have published vanity addresses. Lots of companies are doing vanity addresses to receive payments. Are these all at odds then with "best practices"?

Just wondering what the best way to go here is. I am trying to establish a service where the pay-to address is not constantly changing.

If so, then how do I do this? What if I wanted to (just a silly example) print t-shirts or put an ad out on the newspaper or a tv commercial saying pay to this address for some purpose -- you are saying this should not be done?

Perhaps just think about this from your own side - how do you know who has paid if all payments are made to the same address?

[CIYAM]

I can look at the incoming transaction and figure out its inputs, can't I?

How is that going to help when the customer themselves have no idea what addresses their own UTXO's came from?

(i.e. your customer would then have exactly the same problem as you are stating as they can't control their "from" address either)

On my original question then -- there is no effective way then to advertise a service and tell people to pay to that service.

You just advertise without a payment address (do most people advertise a bank account # currently?). Payment is normally at least a "click here to purchase" link.

And what about something like SatoshiDice? They have published vanity addresses. Lots of companies are doing vanity addresses to receive payments. Are these all at odds then with "best practices"?

Don't look at SD for an example of "best practice" (and especially the blockchain spamming "signal" payments). Also understand SD doesn't *have* a product or a service that is is selling - it's just a gambling website (or is that what you are setting up also?).

Just wondering what the best way to go here is. I am trying to establish a service where the pay-to address is not constantly changing.

I am not sure what is the problem with creating a new pay-to address for each tx - surely you can store them in a DB to know what each is for?

[loquitus_of_borg]

I can look at the incoming transaction and figure out its inputs, can't I?

How is that going to help when the customer themselves have no idea what addresses their own UTXO's came from?

(i.e. your customer would then have exactly the same problem as you are stating as they can't control their "from" address either)

On my original question then -- there is no effective way then to advertise a service and tell people to pay to that service.

You just advertise without a payment address (do most people advertise a bank account # currently?). Payment is normally at least a "click here to purchase" link.

And what about something like SatoshiDice? They have published vanity addresses. Lots of companies are doing vanity addresses to receive payments. Are these all at odds then with "best practices"?

Don't look at SD for an example of "best practice" (and especially the blockchain spamming "signal" payments). Also understand SD doesn't *have* a product or a service that is is selling - it's just a gambling website (or is that what you are setting up also?).

Just wondering what the best way to go here is. I am trying to establish a service where the pay-to address is not constantly changing.

I am not sure what is the problem with creating a new pay-to address for each tx - surely you can store them in a DB to know what each is for?

That's assuming a point and click (or touch interface). What if I want to have people store my service in a directory or just copy and paste or possibly (not likely) memorize the address? Having that extra level of indirection where you need to click someplace to then get directed to the right "payment address" is possible but a hindrance. Imagine for example those 1900 numbers... you call the number and they get paid 1.99 a minute. They can advertise that. Nice and simple. Not that I am suggesting that's what I am doing here.

Not suggesting that everything or even most of what SD does is right.  I am not saying that's what I am setting up either, but having a fixed payment address in this case is of value.

[CIYAM]

That's assuming a point and click (or touch interface). What if I want to have people store my service in a directory or just copy and paste or possibly (not likely) memorize the address? Having that extra level of indirection where you need to click someplace to then get directed to the right "payment address" is possible but a hindrance. Imagine for example those 1900 numbers... you call the number and they get paid 1.99 a minute. They can advertise that. Nice and simple. Not that I am suggesting that's what I am doing here.

I am struggling to work out how you are going to know who has paid for your product/service (unless it is just a gambling website similar to SD in which case just say so).

The point here being that if you can't work out who has paid for what then how could you possibly deliver it to them?

[loquitus_of_borg]

I have been playing with electrum. It has commands like payto and payfrom where you can specify the "from" address. What's that all about?

I can look at the incoming transaction and figure out its inputs, can't I?

How is that going to help when the customer themselves have no idea what addresses their own UTXO's came from?

(i.e. your customer would then have exactly the same problem as you are stating as they can't control their "from" address either)

On my original question then -- there is no effective way then to advertise a service and tell people to pay to that service.

You just advertise without a payment address (do most people advertise a bank account # currently?). Payment is normally at least a "click here to purchase" link.

And what about something like SatoshiDice? They have published vanity addresses. Lots of companies are doing vanity addresses to receive payments. Are these all at odds then with "best practices"?

Don't look at SD for an example of "best practice" (and especially the blockchain spamming "signal" payments). Also understand SD doesn't *have* a product or a service that is is selling - it's just a gambling website (or is that what you are setting up also?).

Just wondering what the best way to go here is. I am trying to establish a service where the pay-to address is not constantly changing.

I am not sure what is the problem with creating a new pay-to address for each tx - surely you can store them in a DB to know what each is for?

[CIYAM]

I have been playing with electrum. It has commands like payto and payfrom where you can specify the "from" address. What's that all about?

For a start I don't use Electrum and quite likely most of your potential "buyers" don't either and for a second you need to really read up on what UTXO's are to fully understand that there is no "from address".

The only way you could make a tx "appear" to have a "from" address would be to use only one UTXO or multiple UTXOs that were all outputs to the *same* address (something no user should ever do in the first place if they care about their own privacy).

Your idea is now looking like a "nightmare" for your potential customers - not only do they have to use a certain client but also apparently they have to get rid of any chance of anonymity in order to use your service.

I think it's pretty clear that you aren't going to find any customers with this approach - maybe time to rethink what you are hoping to achieve.

[danneu]

The difference between bitcoin and a $1.99/min phone-call is that your phone number is already linked to you through a central service. Your bank account is attached to it.

And if you're using a prepaid phone or a burner, then you can't call 1-900 numbers and our analogy is back to square one.

So when you say this:

I can look at the incoming transaction and figure out its inputs, can't I? I then know who the sending address is. If I had a mapping (internally) from the sender address to some business service or product I need to sell to them, then I can validate at this point that the payment was made from them.

It sounds like you're expressing some sort of "reverse address lookup", but I'm not convinced that you actually want that.

On my original question then -- there is no effective way then to advertise a service and tell people to pay to that service.

No, your original question was "I'm building <X> because [I think] it's how to solve <Y>. Help." Yet you only seem interested validating your assumptions instead of reconsidering them.

The bottom line is that, in the examples you mention, you'd control some sort of rendezvous point for your customers.

A simple example would be a form on a checkout page where they type in their shipping address and it generates a unique bitcoin address for them to pay to. Any time a form is submitted, you insert into your database (A) the user info, (B) the bitcoin keys that you'll start watching, and (C) the order so you know how to fulfill. From there you could let them generate a username and password just like every other ecommerce website.

Having that extra level of indirection where you need to click someplace to then get directed to the right "payment address" is possible but a hindrance.

It's no different than having to actually go to amazon.com to buy their products, or click a google result to go to a website, or type in buyhatsforcats.com from a newspaper ad to buy your cat a hat.

Anyways, the best way to get help is to outline exactly what you actually want because that's the critical info that this thread is missing.