Techniques to reduce transaction fees - Revision history

Belcher: /* Consolidation */ Add link to CIOH page

2019-02-17T16:45:22Z

Consolidation: Add link to CIOH page

← Older revision		Revision as of 16:45, 17 February 2019
Line 162:		Line 162:
	[[File:Consolidation-savings.png\|center]]		[[File:Consolidation-savings.png\|center]]

	Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).		Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by [[Common-input-ownership heuristic\|making that connection in your consolidation transaction]] (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).

	See also:		See also:

Belcher: /* Patient spending */ Internal links are better as inline links rather than references

2019-02-15T19:56:02Z

Patient spending: Internal links are better as inline links rather than references

← Older revision		Revision as of 19:56, 15 February 2019
Line 194:		Line 194:
	''Very useful for non-urgent transactions. Not useful for urgent transactions''		''Very useful for non-urgent transactions. Not useful for urgent transactions''

	Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates\|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017~~<ref>[[Transaction_fees#The_market_for_block_space~~]]~~, Bitcoin Wiki, retrieved 2018-01-27</ref>~~. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.		Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the [[Transaction fees#feerates\|feerate]] necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as [[Transaction_fees#The_market_for_block_space\|fees on Sunday being on average 20% lower than fees on Friday in Q4 2017]]. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.

	[[File:Feerate-estimates.png\|center]]		[[File:Feerate-estimates.png\|center]]

Belcher: /* References */ Add to category scalability

2019-02-15T19:53:15Z

References: Add to category scalability

← Older revision		Revision as of 19:53, 15 February 2019
Line 332:		Line 332:

	[[Category:Instructional]]		[[Category:Instructional]]
			[[Category:Scalability]]

Belcher: /* Change avoidance */ Added anecdote of a bitcoin casino using change avoidance

2019-02-08T20:10:40Z

Change avoidance: Added anecdote of a bitcoin casino using change avoidance

← Older revision		Revision as of 20:10, 8 February 2019
Line 140:		Line 140:
	A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.		A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.

	To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement.		To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement. The number of ways n inputs choose m outputs combines grows exponentially<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015628.html</ref>, so if the organization has a decent number of outputs well under the value being paid then this method is very practical.

	The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.		The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html Transaction Merging (bip125 relaxation)], Rhavar, bitcoin-dev mailing list, 2018-01-22</ref> When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.

			For example in a notable bitcoin casino implementing this technique, when a player withdraws money they are given two options of ''Instant Send'' or ''Queued Send''. The latter option puts their withdrawal in a queue where it may or may not be included when changeless withdrawal transactions are calculated. A large amount of people prefer the queued send, as they can save money from the savings being passed onto them. The feature has a nice UX where the customer can see it's waiting, and can cancel it if it's taking too long.

	See also:		See also:

Belcher: /* Potential future improvements */ Add link to Off-Chain Transactions

2019-01-08T19:46:40Z

Potential future improvements: Add link to Off-Chain Transactions

← Older revision		Revision as of 19:46, 8 January 2019
Line 320:		Line 320:
	** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.		** '''Mempool-using fee estimation:''' a potential improvement in fee estimation that considers not just which transactions have been recently confirmed but also the queue of currently unconfirmed transactions.<ref name="mempool-fee-est-slides"/><ref name="mempool-fee-est-video"/> Does not require any protocol changes.

	* Offchain payments		* [[Off-Chain Transactions\|Offchain payments]]
	** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.		** '''Channel factories:''' (enforceable offchain payments) a potentially more efficient way to open payment channels such as those used by Lightning Network. Combined with signature aggregation (described above) this could reduce the cost of opening a payment channel by up to 96%.<ref>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]; Conrad Burchert, Christian Decker, and Roger Wattenhofer; retrieved 2018-01-27</ref> Does not require any [[consensus]] changes.
	** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.		** '''Chaumian banks:''' (unenforceable offchain payments) a trusted third party who controls bitcoins for a pool of Bitcoin users ([[custodial wallet]], AKA "Bitcoin bank") but who can't know which users own which bitcoins. This is accomplished using [[Chaum blinded signatures]].<ref>[https://medium.com/@nopara73/chaumian-e-cash-for-custodial-bitcoin-wallets-and-services-to-scale-bitcoin-8977d9a03064 Chaumian E-Cash For Custodial Bitcoin Wallets And Services To Scale Bitcoin], nopara73, Medium.com, 2017-12-22, retrieved 2018-01-27</ref> Combined with [[hardware security modules]], it could be made extremely difficult for banks to steal depositor funds.<ref>[https://bitcointalk.org/index.php?topic=146307.0 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments], Peter Todd, 2013-02-23, retrieved 2018-01-27</ref> Does not require any protocol changes.

Harding: /* Patient spending */ Remove fee estimation site that's already listed on linked page

2018-11-27T19:48:48Z

Patient spending: Remove fee estimation site that's already listed on linked page

← Older revision		Revision as of 19:48, 27 November 2018
Line 239:		Line 239:

	* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources		* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources
	* [https://bitcoinfees.net bitcoinfees.net] - Uses Bitcoin Core's "estimatesmartfee" method
	* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]		* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]

Peername: /* Patient spending */

2018-11-27T10:08:41Z

Patient spending

← Older revision		Revision as of 10:08, 27 November 2018
Line 239:		Line 239:

	* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources		* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources
	* [https://bitcoinfees.net] - Uses Bitcoin Core's "estimatesmartfee" method		* [https://bitcoinfees.net bitcoinfees.net] - Uses Bitcoin Core's "estimatesmartfee" method
	* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]		* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]

Peername: /* Patient spending */

2018-11-27T10:07:25Z

Patient spending

← Older revision		Revision as of 10:07, 27 November 2018
Line 239:		Line 239:

	* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources		* [https://p2sh.info/dashboard/db/fee-estimation P2SH.info] - Fee estimates from multiple sources
			* [https://bitcoinfees.net] - Uses Bitcoin Core's "estimatesmartfee" method
	* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]		* [[Transaction_fees#Fee_Plotting_Sites\|Other fee plotting sites]]

Belcher: /* Dynamic fee estimation */ Fix link

2018-11-24T22:08:51Z

Dynamic fee estimation: Fix link

← Older revision		Revision as of 22:08, 24 November 2018
Line 174:		Line 174:
	''Universally useful. Already widely deployed but still being improved as research and development continues''		''Universally useful. Already widely deployed but still being improved as research and development continues''

	Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in a [[~~fee~~ market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.		Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in the [[Transaction_fees#The_market_for_block_space\|block space market]]. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.

	[[File:Bitcoin-core-fee-selector.png\|thumb\|200px\|right\|Fee selector in Bitcoin Core 0.15.0]]		[[File:Bitcoin-core-fee-selector.png\|thumb\|200px\|right\|Fee selector in Bitcoin Core 0.15.0]]

Belcher: /* Native segwit */ Fix link

2018-11-24T22:07:32Z

Native segwit: Fix link

← Older revision		Revision as of 22:07, 24 November 2018
Line 125:		Line 125:
	To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.		To access these savings, you must use a wallet that supports generating native segwit addresses, called [[bech32]] addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.

	Once a wallet supports native segwit, it can begin using it immediately for any [[change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.		Once a wallet supports native segwit, it can begin using it immediately for any [[Change\|change outputs]] it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.

	See also:		See also: