Comparative confirmation security of different alt block chains

[Lolcust]

Hello!

As it is widely (maybe ) known, there are numerous alt blockchains now, with different target block  rate.

Since yours truly has given "life" to a blockchain with a particularly short block rate (a block per 15 seconds, doing remarkably nice so far), a discussion has started as to how exactly, from mathematical perspective, does security of a "single confirmation" compare between two blockchains with different target block rate.

Assume two blockchains with exactly same total network performance  
Assume that one of them (A) has a "target" block generation rate of one block per ten minutes, and another (B) has a target block generation rate of one block per 100 minutes (for ease of calculation)

Assume each chain has an attacker with 30% of overall total hashrate  of attacker's respective network.

Each attacker is trying to pull a double-spend against a transaction per classic "gambler's ruin" scenario in his respective network.

Which attacker would have an easier time ? (or, to put it differently, which network has "more security" to its single confirmation and how does one go about comparing it?)

Thank you very much.

[1715096517]

1715096517

[1715096517]

1715096517

[1715096517]

1715096517

[1715096517]

1715096517

[1715096517]

1715096517

[2112]

Oh, I wrote my answer down in the wild west of "Alternate Cryptocurrencies" forum.

https://bitcointalk.org/index.php?topic=42417.msg528330#msg528330

I presume not many readers of this forum go down to that demilitarized zone, so I'm copy-pasting it here.

I'm not an expert, but I used to eat lunches with some experts. Here's the main difference between Satoshi's approach and yours:

Satoshi made an assumption of type "assume a spherical cow in a vacuum", or in his case "assume that the interblock period is long enough to consider the underlying network observable." In other words he can neglect the inter-node transmission time and consider the time to be a discrete interblock periods.

You made an assumption of type "assume a fat cow on a muddy field", or in your case "assume that the interblock period is as short as a decent computer can squeeze them through a decent home-style Internet pipe." In other words you cannot neglect network observability, your inter-node transmission time is on the same order as a TCP/IP timeout and a BGP route flap. Thus the time in your security model cannot be discretized to just interblock period. You have to consider other cases, eg. your node is getting flapped between two competing versions of the block-chain that are producing blocks on the even/odd half-periods.

Now, from reading your previous posts I can tell that you posses both skill and attitude to solve this type of problems. Perhaps Geist Gold requires a "block-chain flap dampening patch" the same way as BGP protocol required "route flap dampening"?

Anyway, the true expert would answer: "Do you want me to write a research grant proposal?"

[theymos]

Maybe someone with a better knowledge of probability will prove me wrong, but this is my understanding:

To replace 6 blocks, you need to make the same number of blocks that the network makes over a period of time and then re-do the blocks you want to replace. So currently with Bitcoin it'd be 12.5 Thash/s to match the network plus a fixed (7,500,000,000,000,000 * 6) hashes to replace the last 6 blocks.

If Bitcoin had a larger block interval, you'd have the same 12.5 Thash/s to match the network, but replacing the last blocks would take many more hashes. So confirmations would represent more work and be somewhat more valuable.

[Lolcust]

Maybe someone with a better knowledge of probability will prove me wrong, but this is my understanding:

To replace 6 blocks, you need to make the same number of blocks that the network makes over a period of time and then re-do the blocks you want to replace. So currently with Bitcoin it'd be 12.5 Thash/s to match the network plus a fixed (7,500,000,000,000,000 * 6) hashes to replace the last 6 blocks.

If Bitcoin had a larger block interval, you'd have the same 12.5 Thash/s to match the network, but replacing the last blocks would take many more hashes. So confirmations would represent more work and be somewhat more valuable.

So, basically, in terms of "confirmation values", confirmations that are longer are more valuable in situations where an attacker has exceeded 51% (The "match the network" part) and is about to retroactively edit past blocks ?

Hm, that's not verily nice, but at least if you're right, that 6 confirmations in Bitcoin and 6 confirmations in say Solidcoin or Geist confer the same "amount of security" (I know it's a poor choice of words) as long as attacker has not matched/exceeded the network (which was the scenario presented).

Oh, I wrote my answer down in the wild west of "Alternate Cryptocurrencies" forum.

https://bitcointalk.org/index.php?topic=42417.msg528330#msg528330

I presume not many readers of this forum go down to that demilitarized zone, so I'm copy-pasting it here.

I'm not an expert, but I used to eat lunches with some experts. Here's the main difference between Satoshi's approach and yours:

Satoshi made an assumption of type "assume a spherical cow in a vacuum", or in his case "assume that the interblock period is long enough to consider the underlying network observable." In other words he can neglect the inter-node transmission time and consider the time to be a discrete interblock periods.

You made an assumption of type "assume a fat cow on a muddy field", or in your case "assume that the interblock period is as short as a decent computer can squeeze them through a decent home-style Internet pipe." In other words you cannot neglect network observability, your inter-node transmission time is on the same order as a TCP/IP timeout and a BGP route flap. Thus the time in your security model cannot be discretized to just interblock period. You have to consider other cases, eg. your node is getting flapped between two competing versions of the block-chain that are producing blocks on the even/odd half-periods.

Now, from reading your previous posts I can tell that you posses both skill and attitude to solve this type of problems. Perhaps Geist Gold requires a "block-chain flap dampening patch" the same way as BGP protocol required "route flap dampening"?

Anyway, the true expert would answer: "Do you want me to write a research grant proposal?"

Oh, holly-molly, now we have two competing forum threads of different lengths

Anyways, this particular question pertains to the issue of whether two networks with different block rates (including two networks with different block rates that are well within the "known safe" window", as in my hypothetical scenario above)

Methinks it would be best if this thread was left to the discussion of statistic peculiarities pertaining to "two networks with different blockrate in a vacuum, which has "more security per validation" against attacker with less-than-51% of network", and continue the fascinating discussion of possible effects of time-sensitive aspects of low-level internet protocols and associated research grants (which I sadly can only pay in GeistGeld or Belorussian Roubles, and I strongly advise taking any cryptocoin over Belorussian Rouble ) in the main GG thread (everyone is invited, BTW)

[theymos]

So, basically, in terms of "confirmation values", confirmations that are longer are more valuable in situations where an attacker has exceeded 51% (The "match the network" part) and is about to retroactively edit past blocks ?

It also works for attackers that have less than 50%. I gave average values. It's possible for an attacker to get lucky and solve enough blocks to match the network even with less than 50%.

I don't think there's any advantage to longer confirmations if the attacker is only trying to maintain control and is not replacing historical blocks.

[Lolcust]

So, basically, in terms of "confirmation values", confirmations that are longer are more valuable in situations where an attacker has exceeded 51% (The "match the network" part) and is about to retroactively edit past blocks ?

It also works for attackers that have less than 50%. I gave average values. It's possible for an attacker to get lucky and solve enough blocks to match the network even with less than 50%.

I don't think there's any advantage to longer confirmations if the attacker is only trying to maintain control and is not replacing historical blocks.

I think I see what you're getting at.

In case of maintaining control (the "gambler's ruin" scenario, as outlined in Satoshi's paper), the lower complexity of a block is offset by  much narrower timeframe you have to solve them and feed them to the net.

In case of overwriting historical blocks, the "timeframe consideration" works differently since the block is, well, historical, is that correct interpretation of what you are saying ?

P.S.:
Isn't "replacing historical blocks" exclusively a 51-er thing since you need to be able to at least match the production rate of the "good nodes" in order to be able to take a stab at replacing the previous block and not having your rewrite overrun by the output of "good nodes" ?