Multiple dust payments

[Atrax]

Hi all,

I'm trying the to find the best, scalable solution for the following situation:
a) An unlimited number of people should get a Bitcoin wallet address.
b) The payments they should get on this address may be small and paid to them on a weekly base.

What would be the smartest way to do this? Make one payment to several addresses? Use a sidechain solution? If so: Which one?

Suggestions - with questions - are highly welcome

[1713957873]

1713957873

[1713957873]

1713957873

[achow101]

You should batch your payments and send to multiple addresses at the same time. This will reduce your transaction fees and reduce the amount of transactions that you will need to create.

Once the lightning network is up and running (and that could take a while) you should use that as it will reduce your transaction fees even further and reduce the number of onchain transactions that you will need to make.

[HCP]

Is it absolutely necessary that you need to use bitcoins? Have you considered using an altcoin network to achieve your goal?

At the current time, the transaction fees on the BTC network are at the highest they have been. bitcoinfees.21.co is suggesting that the "best" fee at the moment is 200 satoshis/byte. This leads to a fee of 45,200 satoshis for the median transaction size of 226 bytes.  If you send 1000 transactions at that cost, you're going to be paying something like 0.4 btc just in fees!

If you are only sending small dust payments, your fees may far outweigh the amounts you are actually sending! 

Compare that with say, the DOGE network... You can send transactions with a 1 DOGE fee (currently worth ~30 satoshis)... although larger transactions will incur multiple doge fees, the difference in cost between DOGE and BTC is massive.  1000 transactions would only be 30,000 satoshis worth in fees...

Granted, if you did this, your end users would then have "altcoin" instead of BTC... but there are plenty of coin exchanges and services like shapeshift that will enable them to convert back to BTC if they want.

[Atrax]

You should batch your payments and send to multiple addresses at the same time. This will reduce your transaction fees and reduce the amount of transactions that you will need to create.

Once the lightning network is up and running (and that could take a while) you should use that as it will reduce your transaction fees even further and reduce the number of onchain transactions that you will need to make.

The LN definitively is something I am eager to finally use - until then, batch payments seem to be the only solution. Even if the fees will be relatively high...

[Qartada]

Is it absolutely necessary that you need to use bitcoins? Have you considered using an altcoin network to achieve your goal?

At the current time, the transaction fees on the BTC network are at the highest they have been. bitcoinfees.21.co is suggesting that the "best" fee at the moment is 200 satoshis/byte. This leads to a fee of 45,200 satoshis for the median transaction size of 226 bytes.  If you send 1000 transactions at that cost, you're going to be paying something like 0.4 btc just in fees!

If you are only sending small dust payments, your fees may far outweigh the amounts you are actually sending! 

Compare that with say, the DOGE network... You can send transactions with a 1 DOGE fee (currently worth ~30 satoshis)... although larger transactions will incur multiple doge fees, the difference in cost between DOGE and BTC is massive.  1000 transactions would only be 30,000 satoshis worth in fees...

Granted, if you did this, your end users would then have "altcoin" instead of BTC... but there are plenty of coin exchanges and services like shapeshift that will enable them to convert back to BTC if they want.

You don't need to do this, batch payments are quite a different concept in which you send many to many different addresses at once in one transaction, thus dramatically reducing your fees for the transaction.  On Electrum, for example, you can do "send to many" which is quite convenient for the user.

You forget that while you say it's easy for them to convert it to Bitcoin, when you're talking about dust payments the effort of converting their altcoin to Bitcoin, especially the first time, would massively outweigh the actual value of the payment, so it would be pointless.

Unfortunately there's no way for OP to reduce his fees to an extent at which they would be insignificant, but hopefully the LN might help with that in the future if it's ever implemented.  That might take a long time though.

[HCP]

You don't need to do this, batch payments are quite a different concept in which you send many to many different addresses at once in one transaction, thus dramatically reducing your fees for the transaction.  On Electrum, for example, you can do "send to many" which is quite convenient for the user.

I had thought that batch payments would still require effectively (or near enough to) the same number of input and output scripts, resulting in similar amounts of data needed for the transaction. That is to say, instead of a lot of small (data size) transactions, you're sending one giant (data size) transaction, but the total bytes would be roughly the same.

I had forgotten to take into account the saving that can be made from the "fixed" 10 bytes in a transaction. Given that a transaction has a size that is "approximately" (and I know this isn't entirely accurate) [181bytes*Inputs + 34bytes*Outputs + 10 bytes], I guess the 10 byte saving per "batched" transaction will add up if you combine 100 transactions in one. That is an effective saving of 990 bytes... which at fees of ~150sats/byte starts to add up pretty quickly... around 0.15 BTC! 

[achow101]

You don't need to do this, batch payments are quite a different concept in which you send many to many different addresses at once in one transaction, thus dramatically reducing your fees for the transaction.  On Electrum, for example, you can do "send to many" which is quite convenient for the user.

I had thought that batch payments would still require effectively (or near enough to) the same number of input and output scripts, resulting in similar amounts of data needed for the transaction. That is to say, instead of a lot of small (data size) transactions, you're sending one giant (data size) transaction, but the total bytes would be roughly the same.

I had forgotten to take into account the saving that can be made from the "fixed" 10 bytes in a transaction. Given that a transaction has a size that is "approximately" (and I know this isn't entirely accurate) [181bytes*Inputs + 34bytes*Outputs + 10 bytes], I guess the 10 byte saving per "batched" transaction will add up if you combine 100 transactions in one. That is an effective saving of 990 bytes... which at fees of ~150sats/byte starts to add up pretty quickly... around 0.15 BTC! 

It's not just that overhead. With individual payments, each transaction will have create a change output, and that change output is likely to be spent from for the next payment, which both leads to extra outputs and long unconfirmed transaction chains. Doing batched payments completely removes the need for a change output for each actual payment and reduces the risks related to long unconfirmed transaction chains.

[Atrax]

So batch payments seem to be the way to go. However, this creates some questions to which some may already have found an answer:

A business plan is - of course - always very optimistic... so I have started with some few clients. They will get some Satoshi on your wallet address every week. There will be a minimum amount before you can withdraw this.

If there are only 5000 clients, this shouldn't be a problem. But what if there would be a million clients - in this case, I assume, it would make sense to use multiple wallets - not only for security reasons, but also for not cloaking the network with one huge transaction. Or do I get this wrong?

Another question is: Has anybody experience how many clients would be ideal to include in one batch payment? Is it more depending on the amount of the payments or the number of payments in the batch?

[achow101]

So batch payments seem to be the way to go. However, this creates some questions to which some may already have found an answer:

A business plan is - of course - always very optimistic... so I have started with some few clients. They will get some Satoshi on your wallet address every week. There will be a minimum amount before you can withdraw this.

If there are only 5000 clients, this shouldn't be a problem. But what if there would be a million clients - in this case, I assume, it would make sense to use multiple wallets - not only for security reasons, but also for not cloaking the network with one huge transaction. Or do I get this wrong?

Large transactions take a long time to verify and propagate, so there is a point where you should use multiple batch payments instead of one gigantic one.

Another question is: Has anybody experience how many clients would be ideal to include in one batch payment? Is it more depending on the amount of the payments or the number of payments in the batch?

It is entirely dependent on the number of payments you make in a transaction, not the amount. The only time the amount matters is if you have an output that is below the dust threshold.

[Atrax]

It is entirely dependent on the number of payments you make in a transaction, not the amount. The only time the amount matters is if you have an output that is below the dust threshold.

Ah, okay. Any suggestion on what the *perfect* number would be?

[DannyHamilton]

. . . Given that a transaction has a size that is "approximately" (and I know this isn't entirely accurate) [181bytes*Inputs + 34bytes*Outputs + 10 bytes] . . .

That's actually quite accurate if you are using the old uncompressed key addresses (inputs in that case are between 179 and 181 bytes).

If you've received all of the bitcoins that you are spending at compressed key addresses, then the size is between 147 and 149 bytes per input instead of 181 bytes.  Save yourself 32 bytes per input.

[HCP]

It's not just that overhead. With individual payments, each transaction will have create a change output, and that change output is likely to be spent from for the next payment, which both leads to extra outputs and long unconfirmed transaction chains. Doing batched payments completely removes the need for a change output for each actual payment and reduces the risks related to long unconfirmed transaction chains.

Oh right, I see what you're saying, unless you were to wait for each transaction to confirm before sending the next one, you would end up with with a massive chain of unconfirmed transactions due to the change addresses from previous (unconfirmed) transactions being used in subsequent transactions. 

Whereas with "n" batches, you would end up with, at worst, "n" change addresses... and obviously no long chain, as you're likely to be sending maybe 2 or 3 transactions at most...

That's actually quite accurate if you are using the old uncompressed key addresses (inputs in that case are between 179 and 181 bytes).

If you've received all of the bitcoins that you are spending at compressed key addresses, then the size is between 147 and 149 bytes per input instead of 181 bytes.  Save yourself 32 bytes per input.

That is quite a substantial saving... and probably explains why a lot of my calculations have been out by a few bytes and satoshis here and there   Thanks Danny, as usual your knowledge on the finer points of Bitcoin mechanics is on point. Cheers for the updated information, I will need to check the wallets/addresses that I have so I can use the correct values in the future to make things a bit more accurate.

[iDice_io]

Have you considered using very low transaction fees with batch transactions, and then using ViaBTC's transaction accelerator?