Single vs many receiving addresses for a business application

[quantumentangled]

Consider a business that has 1000s of customers, considering the high cost of bitcoin transactions these days, would it be better to have just a single destination address to receive bitcoin transactions ( edit: payments ) at, rather than issuing 1000s of unique addresses which is then swiped to a single address later?

The payment can be matched with the user by asking the user to input their sending address before sending (edit: via an UI and storing it in a DB). I would like to understand what the downsides are for such an approach? would you trust the service and provide your bitcoin address?

edit: I understand that the current recommendation one is to use one unique receiving address per user and do a reverse lookup. However I would like to learn what could go wrong with other approaches and why we shouldn't use it.

[1714919861]

1714919861

[1714919861]

1714919861

[1714919861]

1714919861

[1714919861]

1714919861

[1714919861]

1714919861

[nullius]

Consider a business that has 1000s of customers, considering the high cost of bitcoin transactions these days, would it be better to have just a single destination address to receive bitcoin transactions ( edit: payments ) at, rather than issuing 1000s of unique addresses which is then swiped to a single address later?

The payment can be matched with the user by asking the user to input their sending address before sending (edit: via an UI and storing it in a DB). I would like to understand what the downsides are for such an approach? would you trust the service and provide your bitcoin address?

edit: I understand that the current recommendation one is to use one unique receiving address per user and do a reverse lookup. However I would like to learn what could go wrong with other approaches and why we shouldn't use it.

In Bitcoin, there is no such thing as a “from” address.  Any system based on such a design will drop money on the floor.

What you need is a forthcoming new feature:  Schnorr signatures.  This will allow one signature to cover all your inputs:

It will also improve privacy, which I think is certainly a concern when inevitably coin-merging all your customers’ payments.

Unfortunately, it’s not here yet.  Meanwhile, yes, fees are quite problematic for your use case.  I hope that at least you’re using Segwit addresses like the one in my signature; if you’re not, then each of those extra public keys and signatures in your spends is quadruple-weighted in the fees you need to pay.  For a typical consumer transaction, that’s a big waste; for your use case, the difference will be obscene.  Signatures and public keys are relatively large, in measure of bytes; and when you are spending the proceeds from many receiving addresses, of course, you need one of each.

If I heard you correctly want to know if it nice for a business owner to have multiple bitcoin address link to one account. The answer is most business owner use one account and every business owner that use multi address link to one account is definitely trying to evade tax issue.

This makes no sense whatsoever.  The standard industry “best practice” recommendation is to use one receiving address for each transaction.  You’re spouting nonsense.

[DannyHamilton]

This makes no sense whatsoever.  The standard industry “best practice” recommendation is to use one receiving address for each transaction.  You’re spouting nonsense.

I've found it's best not to waste time responding to nonsense in technical sub-forums from users with signature ads.

Instead I just click the "Report to Moderator" link and type:

sig ad nonsense in technical subforum

The moderators do a pretty good job of deleting all those nonsense posts once they are reported and cleaning up the thread.

issuing 1000s of unique addresses which is then swiped to a single address later?

Why would you sweep the funds to a single address?  Just leave them where they are until you need to spend them.

The payment can be matched with the user by asking the user to input their sending address before sending (edit: via an UI and storing it in a DB).

There's no such thing as a sending address.

I assume you mean to ask them to list one or more of the addresses where they received the funds that they are spending?  You do understand that in the case of a bitcoin account (such as with Coinbase or any exchange) the user doesn't know what funds the account provider will spend or what address the account provider received those funds at, don't you?

I would like to understand what the downsides are for such an approach?

It's a horrible idea.

Funds will be lost. Users will be frustrated and angry.

would you trust the service and provide your bitcoin address?

A service that makes such a horrible technical decision would not get any business from me.  If they can't get something as simple as that correct, then I'm not going to trust them to provide a quality product or service.

[kola25]

 

[quantumentangled]

In Bitcoin, there is no such thing as a “from” address.  Any system based on such a design will drop money on the floor.

What you need is a forthcoming new feature: image removed.  This will allow one signature to cover all your inputs:

https://cdn-images-1.medium.com/max/1600/1*L3NV1otCXEB0Y-fmPJNWkg.png

It will also improve privacy, which I think is certainly a concern when inevitably coin-merging all your customers’ payments.

Unfortunately, it’s not here yet.  Meanwhile, yes, fees are quite problematic for your use case.  I hope that at least you’re using Segwit addresses like the one in my signature; if you’re not, then each of those extra public keys and signatures in your spends is quadruple-weighted in the fees you need to pay.  For a typical consumer transaction, that’s a big waste; for your use case, the difference will be obscene.  Signatures and public keys are relatively large, in measure of bytes; and when you are spending the proceeds from many receiving addresses, of course, you need one of each.

Thanks for this, really appreciate the response, will look up schnorr-signature-aggregation and hope it gets implemented soon. I meant to say last used address, as DannyHamilton mentioned that's a bad idea.

The plan is to use segwit addresses as they have lower costs as you say.

From a organization point of view accountability would take precedence over privacy, but since customer addresses are involved it is worth paying those transaction prices ( and ensuring customer privacy ) and just consider that as the cost of doing business.

Why would you sweep the funds to a single address?  Just leave them where they are until you need to spend them.

There's no such thing as a sending address.

I assume you mean to ask them to list one or more of the addresses where they received the funds that they are spending?  You do understand that in the case of a bitcoin account (such as with Coinbase or any exchange) the user doesn't know what funds the account provider will spend or what address the account provider received those funds at, don't you?

Thanks for taking the time to respond to the query, I meant to say last used address, you are right on the exchange accounts, missed that when posting the question.

The plan is to use an unique address per transaction using Trezor ( HD wallets ), have a watch only node, create raw transactions and the sign them offline with Trezor using APIs and broadcast them using sendrawtransaction as is the recommended practice.

This is more of out of curiosity than anything else. Say BTC has to be moved around frequently are there ways to minimize the cost if using different receiving addresses ( other than using segwit addresses, with reasonable ETA.. say 1 - 3 weeks )?

[DannyHamilton]

ways to minimize the cost if using different receiving addresses

The fact that you keep saying this makes me think that you are misunderstanding something.

If you receive 5 payments to a single address, OR you receive those same 5 payments to 5 different addresses, it doesn't matter when it comes to transaction costs.  Either way you still have 5 outputs.  Spending those 5 outputs will cost the same in fees either way.  You can't reduce the number of outputs by re-using an address.  You can't save on transaction fees by re-using an address.

That being said.  You can monitor the average transaction fees on the network and the blockchain (or use a service that does this for you).  Then, when the average fee per byte needed for fast confirmation is low, you can create transactions that spend many of your unspent outputs, and that create a single higher value new output. That way, you are only paying the transaction fee on all those outputs when it is cheap to do so.  Then later when the fees are higher, you'll have just a single output to spend (which will reduce the size of your transaction.

Other things you can do to reduce costs are:

Batch up your transactions.  Instead of sending immediately, you can wait until you have a few places you need to send to.  Then you can create a single transaction that has multiple outputs.  Each output only increases the transaction size by 34 bytes, whereas a whole new transaction would require 10 bytes of overhead plus, potentially, additional inputs.

Try to choose inputs such that the sum of their value is very close to the sum of the value of the outputs plus the necessary transaction fee.  If you can avoid the need to create change outputs, then you will reduce the size of both the current transaction (since you'll have one less output in the transaction) AND a future transaction (since there will never be a future transaction that needs to spend that additional change output).

Use SegWit addresses when receiving.

Use Lightning Network as soon as it is available (start learning about it now, so you are ready when it is available).

Increase the amount that you are charging your customers to cover some of the costs associated with transactions.

Provide your customers with an account on your system so that they can send a single large payment to you. Then they can spend from that account multiple times until all the funds have been used up. Each spend from an account can be instant. It won't need confirmations, and it won't create transactions or outputs in the bitcoin system.

Offer incentives and find other ways to encourage your customers to send fewer larger payments instead of many smaller payments.