Topic: Bitcoin Payment Processing (Read 698 times)

Thanks Danny, your response was very helpful and appreciated.  I will try this when I'm ready to launch and I'll be sure to contact you so you know what I'm doing.  Thanks again. 
 

Mining pools are businesses.  They operate for the purpose of generating profits.  If you can convince a mining pool that it would be in their best interests to include your transactions in their blocks, then they will.

All very good comments, thank you all.  Do you really thing mining pools would pick me up if they could see it was to their advantage?

Can you maintain an "account" on your system for the users?

Then you can wait until their account builds up to several dollars (or tens of dollars, or hundreds of dollars) and let them withdraw the larger amount with a single transaction.

If you can do something like that you'll make a HUGE difference in fees paid as a percentage of funds moved.

Sending $100 worth of bitcoin with a single transaction that has 1 input and 2 outputs will have the exact same fee as sending $1 worth of bitcoins with a single transaction that has 1 input and 2 outputs.  However, it will save you 99 times that fee since you won't need to send the other 99 one dollar transactions.

This wont help. You would need to mine and process your own transactions. Will be definitely to expensive.
Bitcoin is not a good solution for nanopayments at the moment. Better check out some other cryptocurrencies till the blocksize-problem is solved. Once the blocksize-probkem is solved and/or the lightning network is implemented nanotransactions through Bitcoin wont be a problem - but no one knows when (or even if) the blocksize problem will be solved

Being a ful node has no effect on the creation of transactions at all.

The network is not able to tell if a transaction initially came from a full node or not.

Transactions have a size:

The more inputs that you need to include to provide value to your transaction, the larger the transaction is (approximately 148 bytes per input).

The more outputs that your transaction uses to distribute that value, the larger the transaction is (approximately 34 bytes per output).

Every transaction has a certain amount of data that is required regardless of the number of inputs or outputs (approximately 10 bytes per transaction).

So, if you want to create a smaller transaction you either need to use less inputs, or you need to generate less outputs.

The fees are considered on a fee-per-byte basis.  So if fast confirmation requires 0.00000112 BTC per byte, and you have a 208 byte transaction, the necessary fee will be at least 0.00023296 BTC.

You can create a transaction with a smaller fee if you want to, but the miners can simply ignore your transaction and confirm one that pays them more money per byte (meaning it will take longer for your transaction to confirm).

If you can't make your transactions any smaller, then your only other option is to find ways to get miners to include your cheap transactions.  One way to do this is to keep track of what the average fee is on transactions on the network and only send your transactions at times when the average is lower.

Another way would be to convince mining pools to sign contracts with you to prioritize your transactions (of course they'll only do this if they see a benefit for them, if you aren't going to give them more money, then what incentive are you able to provide?).

Another option would be to run your own mining pool and confirm your own transactions.  Of course, if you pool isn't profitable, then you are still paying the extra cost.  You're just paying it in the form of equipment and electricity instead of transaction fees. If your pool is profitable, then you are STILL paying the extra cost, you are just paying it in the form of reduced pool profits (since your pool is skipping the high fee transactions in order to include your cheaper ones).

There isn't a lot of room for magic here.  Blocks are 1 megabyte in size.  Transaction have a size in bytes, and miners (and mining pools) are businesses that are trying to maximize their profits.  If a miner is going to choose a transaction for the block they are working on, they don't have any good reason to choose a transaction that will pay them less per byte instead of another transaction that pays more.

Thanks Kolloh.  I was hoping there would be another solution and certainly a greater response.  What about if I became a full node and sent and received my own transactions? 

Besides grouping the transactions into a single transaction, I'm not sure if they are really any other magic ways of lower the amount of fees a transactions will require. Its depends on the number of inputs and the size of the transaction so reducing both of those where possible will lower your fees.

I'm looking for an individual that has an advanced knowledge of bitcoin payment processes both incoming and outgoing.  I'm fully aware of what Coinbase, bitpay, and blockchain.info have to offer and that is not what I'm looking for.  I want to figure out the most cost effective and expedient way to send $1 in bitcoin to people without getting killed by fees.  This would include bundling transactions and any other magic someone can come up with.  I'm willing to pay for this service if you can help me.  Drop me a line to discuss.