Bitcoin Forum
May 03, 2024, 02:51:38 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Single vs many receiving addresses for a business application on: December 22, 2017, 11:01:32 AM

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:


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 )?
2  Bitcoin / Development & Technical Discussion / Single vs many receiving addresses for a business application on: December 21, 2017, 08:42:49 PM
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.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!