18 May, 16 tweets, 7 min read
@Mario_Gibney 1/ Yeah, lemme try to draw it out. Let's assume it takes 6s for a block to reach other miners and compare 60s vs 600s block intervals for miners with 5% vs 30% of the hashrate. 6s is roughly the situation after Compact Blocks: dsn.kastel.kit.edu bitcoin/#propagation
@Mario_Gibney 2/ The propagation delay is both an advantage and disadvantage: it gives the author a headstart for the next block, but also gives time for a competing block to emerge which may oust the author's block. Let's assume half the remaining HR works on the competing block.
@Mario_Gibney 3/ We can calculate the chance of finding one or more blocks in a time interval by starting with 100% and deducting the chance of finding 0 blocks. The chance to find 0 blocks in a time frame where we'd expect Ξ» blocks is `p(0|Ξ») = exp(-Ξ»)*(Ξ»^0)/(0!) = exp(-Ξ»)*1/1 = exp(-Ξ»)`.
@Mario_Gibney 4/ Given a 600s block interval, we'd expect 0.01 blocks to be found in 6s by 100% of the hashrate, `0.05Γ0.01 = 0.0005` blocks to be found by the 5% miner, and 0.0030 blocks by the 30% miner.
@Mario_Gibney 5/ Given a 60s block interval, we'd expect 0.1 blocks to be found in 6s by 100% of the hashrate, `0.05Γ0.1 = 0.005` blocks to be found by the 5% miner, and 0.030 blocks by the 30% miner.
@Mario_Gibney 6/ As noted above, we'll simplify to expect half the remaining hashrate to work on a competing block whenever one is found. In case of the 5% miner this is 47.5% of the HR, and it's 35% for the 30% miner.
@Mario_Gibney 7/ The author wins either when they find another block during the headstart or when their collaborators find the next block, and loses when both a competing block is found and it sires the successor: `P_loss = (1-e^(-Ξ»_comp))Γcomp/2Γe^(-Ξ»_self)`
@Mario_Gibney 8/ (That's a simplification, because we don't cover the case where both sides find at least one block in the headstart time window, but the competitors find more blocks.βI think we can get away with it.)
@Mario_Gibney 9/ At 600s blocks for the small miner:
`P_loss = (1βe^(β0,0095))Γ0,475Γe^(β0,0005) = 0.0045`. I.e. the 5% miner mines at a handicap of 0.45% and has an effective HR of `5%Γ(1-0.0045)=4.98%`.
@Mario_Gibney 10/ At 600s blocks for the big miner:
`P_loss = (1βe^(β0,007))Γ0,35Γe^(β0,003) = 0.0024`.
I.e. the 30%-miner mines at a handicap of 0.24% and has an effective HR of `30%Γ(1-0.0024)=29.93%`.
@Mario_Gibney 11/ At 60s blocks for the small miner:
`P_loss = (1βe^(β0,095))Γ0,475Γe^(β0,005) = 0.043`.
I.e. the small 5%-miner mines at a handicap of 4.3% and has an effective HR of `5%Γ(1-0.043)=4.79%`.
@Mario_Gibney 12/ At 60s blocks for the big miner:
`P_loss = (1βe^(β0,07))Γ0,35Γe^(β0,03) = 0.023`.
I.e. the bigger 30%-miner mines at a handicap of just 2.3% and has an effective HR of `30%Γ(1-0.023)=29.3%`.
At the same handicap as the smaller miner it would be only 28.7%.
@Mario_Gibney 13/ We see that going from 600s blocks to 60s blocks, a 5%-miner goes from a 0.45% handicap to a 4.3% handicap, but a 30%-miner goes from a 0.24% handicap to a 2.3% handicap.
@Mario_Gibney 14/ Also, the stale block rate would increase from one every ~100 blocks to about one in every ~10 blocks; increasing hashrate not contributing to security, the chance of multi-block reorgs, and easing majority and selfish mining attacks.
@Mario_Gibney 15/15 In effect, an individual miner contributing to a 5%-pool would make about 0.2% more money by joining a 30%-pool at 600s blocks, but the same move would gain 2.1% more money at 60s blocks.
@Mario_Gibney Gonna run off for lunch before the first mathematician looking at my napkin math corrects me. π

The link in the first tweet was supposed to be dsn.kastel.kit.edu/bitcoin/#propaβ¦

β’ β’ β’

Missing some Tweet in this thread? You can try to force a refresh
γ

This Thread may be Removed Anytime!

Twitter may remove this content at anytime! Save it as PDF for later use!

# More from @murchandamus

19 Feb
Default mempools purging txs < 6.0 sat/vB.

Since a full mempool seems to be the new normal, at least temporarily. What can _businesses_ do to lower their operation costs?

The following is mostly picked from blog.bitgo.com/utxo-managemenβ¦ if you prefer long form.

#mempoolreport

1/
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!

bitcointechtalk.com/saving-up-to-8β¦ 2/
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/
24 Oct 20
@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.
22 Oct 20
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.
23 Mar 19
@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...
22 Mar 19
@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.
12 Jun 18
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.
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.