<p>As @chytrik already described, address reuse does not solve your problem for UTXO-based coins, each transaction output must be individually referenced regardless.</p>
<p>When your users deposit into your site, you want to give them separate addresses, so that you can track whose internal balance should be credited. After that, the funds are in your custody, though. Which means that you can and should manage your UXTO pool. A good start would be to regularly consolidate smaller amounts into larger UTXOs during off-peak hours when the feerates are low. You may find this article about <a href="https://blog.bitgo.com/utxo-management-for-enterprise-wallets-5357dad08dd1" rel="nofollow noreferrer">UTXO management for enterprise wallets</a> interesting.</p>
<p>Generally, Bitcoin on-chain payments don't lend themselves to fast micropayments—as you observed the fees are too big of a portion of the value. Bitcoin's response to that is the Lightning Network, an instant payment network leveraging multisignature based payment channels.</p>

CC BY-SA 4.0
2020-12-22T18:13:12.493Z
Thanks for your reply. **1)** Is the "time slot" proposal a viable solution for altcoins such as Ethereum which use the Account Model? **2)** The fee to transfer $2,500 to Vendor is approx. $376.37 (USD) (15% of the total) with a 60 min time frame according to [this site](https://btc.network/estimate). For a 400 min time frame cost is reduced to $78.50 (USD) (1.5% of total). The platform charges a 1.9% fee which would be eaten up by the high cost. Would you say this is the lowest fee I could expect to pay using the legacy BTC protocol (The API I'm using doesn't support Lighting Network) ?
S.O.S
CC BY-SA 4.0
2020-12-23T18:56:55.060Z
Bitcoin fees are not relative to the amount that is sent, but relative to the amount of blockspace a transaction occupies. If you can wait longer, you will eventually be able to get a transaction through at 5 sat/vB or lower. If you want to be really patient even at 1 sat/vB. For an average-sized transaction of 500 vB that translates to 500-2,500 satoshi of fees—at today's exchange rate less than a dollar. For questions about ethereum, I would suggest that you check out https://ethereum.stackexchange.com.
Murch
CC BY-SA 4.0
2021-01-14T17:22:20.990Z
A SE user (@Prayank) [commented on another question of mine](https://bitcoin.stackexchange.com/questions/101441/keeping-track-of-user-deposits-with-bitcoin/101443?noredirect=1#comment114912_101443)  "I can have one website, user login, all pay to same address but updated in my local database with user id and transaction id when payment is done" Would you agree to that statement? Is it possible to track user deposits using the transaction ID (TXID) if everyone on the site is sending to the same Bitcoin address? It doesn't make sense to me..
S.O.S
CC BY-SA 4.0
2021-01-14T17:38:05.297Z
While it is correct that every transaction has a unique id and therefore every unspent transaction output is uniquely identifiable, having everyone pay to the same address will introduce a lot of overhead with tracking who paid when. It will be _much_ easier to assign a new address for every payment process (or at least every customer). Generally, address reuse has a lot of disadvantages, and afaict no palpable advantages in Bitcoin.
Murch
CC BY-SA 4.0
2020-12-21T16:31:42.500Z
2020-12-23T19:02:41.513Z
2020-12-23T19:02:41.513Z
Murch
<blockquote>
<p>One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address</p>
</blockquote>
<p>This is definitely not a solution to the problem you've outlined. When creating a transaction, there is no difference between consolidating many payments that were made to the same address, and consolidating many payments that were made to unique addresses. Each payment you include will represent a single input to the transaction.</p>
<p>From the sounds of it, you are confusing the concept of an <a href="https://bitcoin.stackexchange.com/questions/49853/utxo-model-vs-account-balance-model">account based model for transactions, and a UTXO-based model for transactions</a> (which is what bitcoin employs).</p>

CC BY-SA 4.0
2020-12-29T16:38:00.590Z
Thanks. While the main questions is about BItcoin, would the time slot approach be a solution for Ethereum (account based model) type transactions?
S.O.S
CC BY-SA 4.0
2020-12-29T20:08:04.930Z
@S.O.S I don’t find Ethereum that interesting, so I am no expert in its operation, but I would guess that the ‘time slot approach’ is almost certainly not a good solution for any such situation, given the issue of many users potentially making concurrent deposits. (And the issue of delayed tx confirmation, etc)
chytrik
CC BY-SA 4.0
2020-12-21T08:44:22.833Z
2020-12-21T08:44:22.833Z
chytrik
<p>I’m building a cryptocurrency marketplace where users mainly buy and sell small ticket items (worth $10 - $50) using cryptocurrency. However, the &quot;miner fees&quot; are making it prohibitively expensive to run.</p>
<p><strong>SCENARIO:</strong></p>
<p>I have a marketplace of vendors and buyers where a user can be both a vendor and a buyer. A buyer must deposit funds in his account (top up account balance) before he can spend cryptocurrency on the platform. For every new user, we would generate a unique address so that any funds deposited to that address would be credited to that user. It makes it easy to know who to credit when we detect a deposit to a specific address. My main dilemma is regarding disbursements to the vendor and taking platform fee (see below).</p>
<p>After the buyer purchases an item (using account balance), the payment is held in escrow until the item is delivered to buyer. Once the item is delivered, the payment is “transferred” to the vendor minus a 1.9% “platform transaction fee” (which is paid to the platform owner). A vendor can withdraw his earnings at any time after paying a flat $5 withdrawal fee. Similarly, a buyer can withdraw his deposit (account balance) at any time for the same flat $5 fee. Keep in mind a withdrawal by a vendor typically includes payment received from hundreds of transactions (all which originate from numerous buyers and numerous addresses). It may also include a deposit the vendor himself made in order to top up his balance.</p>
<p>When a single order is complete (i.e, a product is delivered) it is obviously not viable to transfer payment from the buyer’s wallet to the vendor’s private wallet as this would incur a “mining fee” every time an order is placed on the site. Instead we would be relying on the <a href="https://bitcoin.stackexchange.com/a/67059/78451">internal ledger concept described in this reply</a>.</p>
<p>In short, based on the ledger concept, if a product sold for $25, we would “credit” the vendor with $25 worth of a specific type of cryptocurrency without actually broadcasting the transaction to the blockchain. Similarly, we would “deduct” the $25 of crypto from the buyers balance (using an internal database, without actually broadcasting anything to blockchain). Now let’s say a vendor completes 100 transaction * $25 when Bitcoin is worth $10,000 per BTC. So we would now owe the vendor $2,500 USD or 0.25 BTC (minus 1.9% platform fee).</p>
<p><strong>THE PROBLEM</strong></p>
<p>When the vendor chooses to withdraw his earnings, the 0.25 BTC would be originating from 100 different addresses (100 buyers) which will obviously lead to excessive miner fees. Similarly, since the site owner takes 1.9% fee for each transaction, if the site owner wanted to consolidate all of the little cryptocurrency earned from 100 addresses to 1 address it would entail a similar process (and the relative cost would be far greater for the platform owner).</p>
<p><strong>TIME SLOT APPROACH</strong></p>
<p>One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address. Of course, this makes it difficult to track who's who when making a deposit since everyone is sending to the same address. It is possible to dedicate address to a single user for a period of time (“time slot”) and then credit the user who has the dedicated “time slot” but this approach is not ideal since we would need to track which user had access to the address at a specific period of time. Furthermore, users may not remember that address allocation is time sensitive and may make deposits to that address at a future time under someone else’s “time slot”. It is also very confusing to the user and would still require dozens of unique addresses if the site has many users. However, in theory this would solve the primary issue since payment to vendor would be originating from a single address and any funds remaining in that address would go to the site owner as a platform fee.</p>
<p>Presumably, there are other solutions to this problem as there are many sites with similar functionality. What is the industry standard solution to this problem? What are some ways to tackle it? Any insight is highly appreciated.</p>
<p>Note: The marketplace will support deposits/withdrawals in Bitcoin, Ethereum, Bitcoin Cash, Ripple, Litecoin, USDC and USDT.</p>
<p>Note: I'm open to a native solution that relies on the blockchain client or a API solution from a reputable firm.</p>

CC BY-SA 4.0
2020-12-23T02:02:11.310Z
Please limit the scope of this question to Bitcoin. Other currencies are off-topic here.
Pieter Wuille
CC BY-SA 4.0
2020-12-23T02:04:06.523Z
@PieterWuille I thought that if the primary question relates to Bitcoin, I can include altcoins as secondary: _"Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin"_
S.O.S
CC BY-SA 4.0
2020-12-23T18:51:35.703Z
I understand that to cover questions for which the answer is the same as for Bitcoin.
Murch
<transactions><blockchain><transaction-fees><client><altcoin>
Strategies to Reduce High Transaction Fees in a Cryptocurrency Marketplace?
S.O.S
# Strategies to Reduce High Transaction Fees in a Cryptocurrency Marketplace?

(Asked by: username_0 on 2020-12-20)

I’m building a cryptocurrency marketplace where users mainly buy and sell small ticket items (worth $10 - $50) using cryptocurrency. However, the "miner fees" are making it prohibitively expensive to run.

**SCENARIO:**

I have a marketplace of vendors and buyers where a user can be both a vendor and a buyer. A buyer must deposit funds in his account (top up account balance) before he can spend cryptocurrency on the platform. For every new user, we would generate a unique address so that any funds deposited to that address would be credited to that user. It makes it easy to know who to credit when we detect a deposit to a specific address. My main dilemma is regarding disbursements to the vendor and taking platform fee (see below).

After the buyer purchases an item (using account balance), the payment is held in escrow until the item is delivered to buyer. Once the item is delivered, the payment is “transferred” to the vendor minus a 1.9% “platform transaction fee” (which is paid to the platform owner). A vendor can withdraw his earnings at any time after paying a flat $5 withdrawal fee. Similarly, a buyer can withdraw his deposit (account balance) at any time for the same flat $5 fee. Keep in mind a withdrawal by a vendor typically includes payment received from hundreds of transactions (all which originate from numerous buyers and numerous addresses). It may also include a deposit the vendor himself made in order to top up his balance.

When a single order is complete (i.e, a product is delivered) it is obviously not viable to transfer payment from the buyer’s wallet to the vendor’s private wallet as this would incur a “mining fee” every time an order is placed on the site. Instead we would be relying on the [internal ledger concept described in this reply](https://bitcoin.stackexchange.com/a/67059/78451).

In short, based on the ledger concept, if a product sold for $25, we would “credit” the vendor with $25 worth of a specific type of cryptocurrency without actually broadcasting the transaction to the blockchain. Similarly, we would “deduct” the $25 of crypto from the buyers balance (using an internal database, without actually broadcasting anything to blockchain). Now let’s say a vendor completes 100 transaction \* $25 when Bitcoin is worth $10,000 per BTC. So we would now owe the vendor $2,500 USD or 0.25 BTC (minus 1.9% platform fee).

**THE PROBLEM**

When the vendor chooses to withdraw his earnings, the 0.25 BTC would be originating from 100 different addresses (100 buyers) which will obviously lead to excessive miner fees. Similarly, since the site owner takes 1.9% fee for each transaction, if the site owner wanted to consolidate all of the little cryptocurrency earned from 100 addresses to 1 address it would entail a similar process (and the relative cost would be far greater for the platform owner).

**TIME SLOT APPROACH**

One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address. Of course, this makes it difficult to track who's who when making a deposit since everyone is sending to the same address. It is possible to dedicate address to a single user for a period of time (“time slot”) and then credit the user who has the dedicated “time slot” but this approach is not ideal since we would need to track which user had access to the address at a specific period of time. Furthermore, users may not remember that address allocation is time sensitive and may make deposits to that address at a future time under someone else’s “time slot”. It is also very confusing to the user and would still require dozens of unique addresses if the site has many users. However, in theory this would solve the primary issue since payment to vendor would be originating from a single address and any funds remaining in that address would go to the site owner as a platform fee.

Presumably, there are other solutions to this problem as there are many sites with similar functionality. What is the industry standard solution to this problem? What are some ways to tackle it? Any insight is highly appreciated.

Note: The marketplace will support deposits/withdrawals in Bitcoin, Ethereum, Bitcoin Cash, Ripple, Litecoin, USDC and USDT.

Note: I'm open to a native solution that relies on the blockchain client or a API solution from a reputable firm.

**Tags:** transactions, blockchain, transaction-fees, client, altcoin

> **Comments:**
> **username_1**: Please limit the scope of this question to Bitcoin. Other currencies are off-topic here.  
> **username_0**: @username_1 I thought that if the primary question relates to Bitcoin, I can include altcoins as secondary: _"Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin"_  
> **username_2**: I understand that to cover questions for which the answer is the same as for Bitcoin.  

---

## 2 answers

### Answer by username_2 on 2020-12-21. Score: 4

As @username_3 already described, address reuse does not solve your problem for UTXO-based coins, each transaction output must be individually referenced regardless.

When your users deposit into your site, you want to give them separate addresses, so that you can track whose internal balance should be credited. After that, the funds are in your custody, though. Which means that you can and should manage your UXTO pool. A good start would be to regularly consolidate smaller amounts into larger UTXOs during off-peak hours when the feerates are low. You may find this article about [UTXO management for enterprise wallets](https://blog.bitgo.com/utxo-management-for-enterprise-wallets-5357dad08dd1) interesting.

Generally, Bitcoin on-chain payments don't lend themselves to fast micropayments—as you observed the fees are too big of a portion of the value. Bitcoin's response to that is the Lightning Network, an instant payment network leveraging multisignature based payment channels.

> **Comments:**
> **username_0**: Thanks for your reply. **1)** Is the "time slot" proposal a viable solution for altcoins such as Ethereum which use the Account Model? **2)** The fee to transfer $2,500 to Vendor is approx. $376.37 (USD) (15% of the total) with a 60 min time frame according to [this site](https://btc.network/estimate). For a 400 min time frame cost is reduced to $78.50 (USD) (1.5% of total). The platform charges a 1.9% fee which would be eaten up by the high cost. Would you say this is the lowest fee I could expect to pay using the legacy BTC protocol (The API I'm using doesn't support Lighting Network) ?  
> **username_2**: Bitcoin fees are not relative to the amount that is sent, but relative to the amount of blockspace a transaction occupies. If you can wait longer, you will eventually be able to get a transaction through at 5 sat/vB or lower. If you want to be really patient even at 1 sat/vB. For an average-sized transaction of 500 vB that translates to 500-2,500 satoshi of fees—at today's exchange rate less than a dollar. For questions about ethereum, I would suggest that you check out https://ethereum.stackexchange.com.  
> **username_0**: A SE user (@Prayank) [commented on another question of mine](https://bitcoin.stackexchange.com/questions/101441/keeping-track-of-user-deposits-with-bitcoin/101443?noredirect=1#comment114912_101443)  "I can have one website, user login, all pay to same address but updated in my local database with user id and transaction id when payment is done" Would you agree to that statement? Is it possible to track user deposits using the transaction ID (TXID) if everyone on the site is sending to the same Bitcoin address? It doesn't make sense to me..  
> **username_2**: While it is correct that every transaction has a unique id and therefore every unspent transaction output is uniquely identifiable, having everyone pay to the same address will introduce a lot of overhead with tracking who paid when. It will be _much_ easier to assign a new address for every payment process (or at least every customer). Generally, address reuse has a lot of disadvantages, and afaict no palpable advantages in Bitcoin.  

---

### Answer by username_3 on 2020-12-21. Score: 3

> One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address

This is definitely not a solution to the problem you've outlined. When creating a transaction, there is no difference between consolidating many payments that were made to the same address, and consolidating many payments that were made to unique addresses. Each payment you include will represent a single input to the transaction.

From the sounds of it, you are confusing the concept of an [account based model for transactions, and a UTXO-based model for transactions](https://bitcoin.stackexchange.com/questions/49853/utxo-model-vs-account-balance-model) (which is what bitcoin employs).

> **Comments:**
> **username_0**: Thanks. While the main questions is about BItcoin, would the time slot approach be a solution for Ethereum (account based model) type transactions?  
> **username_3**: @username_0 I don’t find Ethereum that interesting, so I am no expert in its operation, but I would guess that the ‘time slot approach’ is almost certainly not a good solution for any such situation, given the issue of many users potentially making concurrent deposits. (And the issue of delayed tx confirmation, etc)  

---

