Topic: How faster transactions can be implemented (Read 742 times)

Besides the fact that this claim is false, a 'gigameg' doesn't mean anything regarding an internet network. It literally means 'billion million'. You're saying: which is only possible through a billion million internet network.

All? milliseconds? It's unlikely since there are many factor which affect verification time. Check this snipped answer by Pieter Wuille.


It's not wrong answer, but what OP means is increasing transaction speed (as in getting confirmed) by modifying Bitcoin protocol/node implementation.

There are several ways to speed up the bitcoin transaction and i will list them below:

- Replace-by-Fee (RBF (for transactions sent by you)To implement RBF you need to use a wallet thats upports this functionality
- Child Pays for Parent (CPFP)
- Transaction accelerators

if you need more info be welcome to reply to me to try to help you little bit more.

Then besides a very low latency network, thanks to our fictitious, perfect gigameg internet available to all, add our fictitious, cheap, high-grade institutional hardware network of full nodes. All post-IBD validation is processed within milli-seconds.

I'm afraid that won't solve the real issue either. Bitcoin blocks are not like a video that you just stream, they have to be validated which requires expensive computation work followed by database updates, which is the actual bottlenecks.

The solution? A low latency cryptocurrency network, which is only possible through a gigameg internet network that could download and upload gigamegs of data within seconds that’s available for everyone. If Bitcoin can’t have something like this, the Core Developers must adapt with what’s available, and they are doing a very good job.

Yeah. The reason for short block times would be to pay for stuff in person. If you're paying online you're not gonna care if it takes 10 seconds or 1 hour to confirm. But in person, anything more than a handful of seconds is too long, so even if the blocktime were 20 seconds that'd be a very long time to wait jus to get the first confirmation.

So reducing blocktime for this purpose is basically pointless. For in person transactions you need something that has finality within seconds. That's where L2 solutions like LN come in. There's no point in using L1 for that sort of stuff. Just like you're not gonna wire money or even write a check these days while in the line at the grocery store, you're gonna use one of the higher up networks like a credit card.

Bitcoin has exactly the tradeoff we need for a robust monetary system. Security on L1, that is still useful for moving money around and buying things online (assuming the fee isn't too high), and efficiency on L2 for buying stuff in person or just making every day transactions.

The fact that usually you can see a transaction hit the mempool in a few seconds or so is good enough for getting confirmation that your transaction is being processed, if we're talking about just making sure it went through (sort of like when a credit card tx says confirmed).

It might be trivial for a software program to perform the calculation, but the runtime will be slower calculating to infinity versus calculating the chances of x -1 not happening.

To demonstrate, I created two simple functions:
def to_inf():
    count = 0
    for x in range(100):
        count +=1
def sub_3x():
    count = 0
    for x in range(3):
        count -=1

I ran some test on both to see how fast they execute:
%timeit to_inf()
4.64 µs ± 67.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
%timeit sub_3x()
512 ns ± 4.11 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

I could create functions that calculate a poisson probability until the probability is zero, and that calculates all probabilities of x-1 down to 0, and the outcome would be the same (the later would have a quicker runtime)

If you are doing it by hand, then sure, that way is easier, but working out the upper distribution to infinity is a trivial task for any calculator or piece of software. Here, I've put the necessary equation in to Wolfram Alpha so you can play around with numbers yourself. Just adjust the upper and lower bounds (the ∞ and 0 above and below the capital sigma respectively) as desired. The output is a percentage chance.

https://www.wolframalpha.com/input/?i2d=true&i=Sum%5BDivide%5BPower%5Be%2C-1%5D%2Cn%21%5D%2C%7Bn%2C0%2C%E2%88%9E%7D%5D*100

The chances of not finding n blocks within one block interval is the same as 1 - chances of finding n or more blocks within one block interval.

If you need a precise chance of 'x or more' occurrences happening, it is probably better to calculate the chances of x -1 or less occurrences not happening. 

Essentially yes, if you want to do it manually.

What you really want to do is to use the summation function, denoted by capital sigma (Σ). Difficult to print it out properly in BBCode, but essentially the formula would be:

f(n,Λ) = Σ (Λⁿ * e^-Λ / n!)

Your bounds would be between 0 and n for the lower distribution (so finding n or fewer blocks), and between n and infinity for the upper distribution (so finding n or more blocks). Or alternatively change the bounds to any arbitrary numbers to find the chance of finding that number of blocks. For example, the chance of finding either 1 or 2 blocks in 10 minutes is 55.18%.

If I am not mistaken, to calculate the chances of x or more events over an interval when y events are expected, you can do one of two things:
If x is sufficiently small, you can plug (x - 1) and y into the Poisson formula, note the resulting probability, repeat with x being decreased by an additional 1, noting the result, and repeating until you note the result after x = 0. The sum of the probabilities subtracted from one is the resulting probability.

For larger x values, you can plug x and y into the Poisson formula, note the resulting probability, repeat with x being increased until x is 4 standard deviations away from y (for Poisson distributions, one standard deviation is the square root of the expected value, or y in my example), and the sum will be within 0.1% of the actual probability, or you can continue until 5 standard deviations from y, and the sum of the resulting probabilities will be within 0.00006% of the actual probability.

It is drawing the plot of the gamma function, which is undefined for non-positive integers and tends to infinity for these values, and so the graph of e^-1 / n! is zero at these values (since the infinity term is the denominator).

Correct. You will always have a higher chance of finding "x or more" blocks than you will of finding "exactly x" blocks. 2 blocks in 10 minutes is 18.39%, but 2 or more blocks in 10 minutes is 26.42%. 3 blocks in 10 minutes is 6.13%, but 3 or more blocks in 10 minutes in 8.03%.

If it isn't defined, then why did Desmos draw it? 

So, it's all a matter of assumption. We just compare the final result; when we divide Λ with 5 to understand the probability in monero, what we actually do is divide the presumed 10 with 5 to get 2.

May I conclude that the P of the exact number of blocks is not greater than the P of the at least number of blocks?

The exact block interval itself isn't relevant. What is relevant is how many blocks you would expect to find within the time frame you are interested in, which is what Λ is. So if you are considering blocks found within 10 minutes, then Λ = 1 for bitcoin since you would expect to find 1 block within those 10 minutes on average. If you were considering monero, which has a block time of 2 minutes, then for a 10 minute interval Λ would equal 5.

If you wanted to examine bitcoin over an hour, then Λ = 6. Over a day, Λ = 144. Over a minute, Λ = 0.1.

Yes, your results are all correct. You've entered the incorrect exponent of 1 in your last two equations, but it is irrelevant to the final result. Note that as above, this equation is for finding that exact number of blocks in the time frame specified, and not at least that number of blocks.

Graphing negative numbers on the x axis here makes no sense, since n! is not defined for negative numbers. Here is the same graph over a much more zoomed in and relevant axis:

Oh, there's an n that defines the exact number of blocks you may find while you expect to find Λ number of blocks in 10 minutes. Question: Does that apply to any block interval? Would it be the same whether it was 10 or 20 minutes? I don't see it being part of the equation anywhere.

So, let's play with it. If I wanted to see my result, I'd take:
P = Λⁿ * e^-Λ / n!   --->  P = 1² * e^-1 / 2   --->  P = 18.39%

For 3 blocks within 10 minutes, it'd be:
P = Λⁿ * e^-Λ / n!   --->  P = 1³ * e^-1 / 6   --->  P = 6.13%

For 4 blocks within 10 minutes, it'd be:
P = Λⁿ * e^-Λ / n!   --->  P = 1⁴ * e^-1 / 24   --->  P = 1.53%

For 5 blocks:
P = Λⁿ * e^-Λ / n!   --->  P = 1⁴ * e^-1 / 120   --->  P = 0.306%

And finally for 6 blocks:
P = Λⁿ * e^-Λ / n!   --->  P = 1⁴ * e^-1 / 720   --->  P = 0.051%

So, 0.051%. That's what is considered improbable to happen.

---

This is truly interesting, I concede. I'd like to make the probability viewable graphically.


Skipping anything prior 0, we can observe how abruptly improbable it becomes for the network to generate stale blocks. Question, is this true only if we assume there are no attackers and everyone mines honestly?

LN is far superior to a hypothetical coin with a one-minute block time that has the security of bitcoin. Provided there is an available route, a transaction will be completed nearly instantly. Further, a transaction completed on LN will have the security of 6+ confirmations as of the second it is completed.

If there is some reason why using LN is not feasible, there are ways for a business to make waiting potentially 3-5 minutes not a negative customer experience, while not giving up security. A business can do this by engineering their process such that the customer will send a payment with sufficient time before the business would be able to provide the product to the customer.

I ran some tests, and you're right. I stand corrected.

You can play around with the numbers here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.html. This page is essentially the equations from the whitepaper put in to action.

6 was chosen as a trade off between speed and security. In reality it's a continuum of how likely an attacker might be able to reverse x confirmations, not a case of "5 is unsafe, but 6 is safe". As you can see from the whitepaper and the calculator I linked, if someone has a significant (but less than 51%) percentage of the hashrate, then even 6 confirmations might not be safe. If you want an attacker with 40% of the hashrate to have a less than 0.1% chance of reversing a transaction, then you need to wait for 89 confirmations, for example. However, given the huge amount of hash power the bitcoin network now has, I would accept 3 for a lot of things, as do many exchanges and services.

No, it's not that simple. The simplified equation I gave only holds when you are looking at not finding a block at all, because in that case n = 0 and you can cancel out most of the terms. To work out any other number of blocks, you would need to go back to the original equation that I have quoted from myself above, and make n = 2. So if you wanted to see how likely it would be to find 2 blocks in 10 minutes, given that you would ordinarily expect to find 1 block in 10 minutes, you would set n = 2 and Λ = 1.

P = Λⁿ * e^-Λ / n!
P = 1² * e^-1 / 2!
P = 1 * e^-1 / 2
P = e^-1 / 2
P = 18.39%

Note that this is the value to find exactly 2 blocks in 10 minutes. If you wanted to find 2 or more blocks in 10 minutes, then the math becomes much more complicated, but would give a probability of 26.42%.

Oh, so that's what the seventh page of the whitepaper is about... Finally.

In Bitcoin, the block interval is 10 minutes. This means that the probability for a block to be found within the next 10 minutes is 1 - e^-1 = 63.2%. I'm trying to understand why the 6 confirmations are considered safe as long as honest nodes control most of the computational power, but here's something I don't get.

Given that Λ is the number of blocks and 1 - e^-Λ the probability of finding Λ blocks within the next 10 minutes, don't we increase our chances as long as Λ increases?

For instance, generating 2 blocks within the next 10 minutes would have probability of 1 - e^-Λ = 86.5% which is greater than 63.2%. Shouldn't it drop off exponentially since generating 1 block instead of 2 blocks within the next 10 minutes is more probable?

This is not accurate. Mining is a Poisson process, which is memoryless. It doesn't matter if it has been 1 second or 1 hour since the last block; the average amount of time to the next block is always the same (1 minute in your example). With a 1 minute block time, the chance of mining a block in the next 30 seconds is 39.3%, not 50%.

As I've mentioned, bitcoin mining is a Poisson process, which can be modeled mathematically. See my previous post regarding this here:


As I've done here, instead of using lambda to equal the expected number of blocks you would find, you turn it in to the time frame you are interested in divided by the average block time, which gives you the same result. If I'm interested in not finding a block in 10 minutes, then the equation is e^(-600/600), which is e^-1. If I'm interested in not finding a block in 30 seconds when the block time is one minute, the equation is e^(-30/60), which is e^-0.5.