1) Batch payments
You get a lot of withdrawal requests? Instead of paying each out separately, save up to 80% in fees by batching multiple payments into one transaction. It also makes UTXO management much easier!
2) Consolidate deposits
You're still getting tons of deposits and have to perform withdrawals. By funding withdrawals only with bigger UTXOs and consolidating smaller UTXOs at a lower feerate than your withdrawal transactions, you can save a ton of fees. 3/
3) Split consolidation by UTXO value
The least valuable UTXOs get consolidated at the lowest feerate with biggest delay or paused altogether. Consolidations of more valuable UTXOs get distinct higher feerates to prioritise what provides the most liquid funds for operation. 4/
4) Switch to using native segwit internally
Even if you're not ready to switch to native segwit addresses generally, you can save fees and blockspace by using native segwit addresses when sending to yourself, i.e. for change or consolidations. Less fees, less blockspace! 5/
5) Avoid change outputs
By picking input sets that match the sum of recipient amounts, you:
• get smaller transactions
• don't have extra funds in flight via unconfirmed change
• create fewer UTXOs that need to be spend later
6/
6) Switch to native segwit deposit addresses
Funds received to native segwit addresses incur significantly less blockweight for their inputs. You can even economically incentive deposits to native segwit addresses and still save money! Segwit is out 3.5 years. It's time! 7/
7) Mind ancestry of unconfirmed inputs
If you end up building chains of unconfirmed txs, you'll have a bad time in the current mempool conditions. Stuck transactions, inability to CPFP, or even locked up wallet balance. You don't want to be this:
8) Implement RBF
Other than CPFP, RBF allows you to replace stuck transactions with a higher feerate version without using extra blockspace. You can even add additional recipients to the replacement tx. It's a big lift though, because payments need to be tracked differently. 9/
9) Lightning Deposits and Withdrawals
LN can be leveraged to increase transaction throughput by magnitudes with little on-chain footprint:
. It's also a big lift, but one that should be on your roadmap. 10/
10) Need advice?
Ping me, happy to chat with you about your specific situation. We can bounce ideas around, figure out some accessible operational improvements.
Especially happy to assist member companies of @bitcoinoptech.
11/11
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@CryptoStorm3@ChartsBtc Each transaction offers miners a small amount of bitcoins to incentivize confirmation. Blocks are limited to 4M weight units, so miners cannot include everything that is waiting. Naturally, they choose the transactions that pay the highest fee per weight unit to maximize revenue.
@CryptoStorm3@ChartsBtc Since a block is limited in size, and the block interval self-regulates to be roughly constant, the throughput of transaction data is limited.
OTOH, the amount of transactions that get submitted to the network is flexible.
@CryptoStorm3@ChartsBtc Especially, when the price makes big swings, people get excited and want to participate in the market. As a precept in Bitcoin is to be your own bank and control your funds directly, a lot of people do not keep funds on their exchange accounts but in their own wallets.
Mempool depth is still on the rise with all fee bands growing.
If we were headed into a major fee event, the #btc ecosystem would be much better prepared than in 2017. Native segwit is on the verge of wide adoption, opt-in RBF is right there for anyone that wants thrifty quick confirmations, LN maturity is coming along nicely, which…
… could at least serve as a valve for some smaller payments even when Wumbo seems a bit daunting still.
If you aren't working on all of these, you might want to consider to.
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt Alright, so our threat model is a widespread effort to change the protocol rules with support of a majority hashing attack. Presumably this is incompatible with existing network rules as enforced by fully validating nodes, but compatible with thin clients.
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt a) A vast majority of FN oppose this protocol change. Attackers are banned by their peers, blocks don't propagate, most thin clients never see the blocks. Affected scrutinizing thin client discovers changed rules when first valid block is found, if it has at least 1 honest peer.
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt b) Significant count of FN support protocol change. FN topology decouples, some Scrutinizing Thin Clients (STC) are eclipsed by attack. STC will at the latest fully validate the first block that includes any transaction that concerns them. 1) Discovers invalid block if rule...
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt Maybe I'm missing something, but current thin client implementations either rely on a trusted server or connect to multiple nodes. So, you'd not only need to be served a fake block, but also get verification by other nodes to follow it. That means you need to be sybilled.
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt BIP157 done right would first gather multiple filter fingerprints and compare them, then download the full filter if they agree. If they disagree, the would need to be back-off validation procedures. I don't see why such a validation couldn't include parsing the full block.
@giacomozucco@CarstenBKK@BlueDelta0@StopAndDecrypt Obviously, a thin client doesn't have the full UTXO set, but many other rules could be checked on a single block. This would significantly reduce the attack surface and susceptibility to accepting chain tips with protocol changes.
A Hash-Timelocked-Contract is a conditional payment on a LN channel with two possible outcomes: Either the recipient provides the pre-image corresponding to the Lightning invoice that is being paid and takes the funds, or after the lock times out, the sender takes back the funds.
External Tweet loading...
If nothing shows, it may have been deleted
by @bradmillscan view original on Twitter
Ah submarine swap is an on-chain payment that purchases a LN payment: The sender locks funds into a conditional script, where either the swap provider can spend the funds by providing a pre-image, thus proving to have paid the LN invoice, or sender can take it back themselves.
One of the exciting things is that submarine swaps can be created on most cryptocurrencies, even ones that are not compatible with LN directly. This way you can for example offer to pay some forkcoin to get a LN invoice on the Bitcoin LN paid by ANY swap provider trustlessly.