The Lightning Network Reality Check

[Lauda]

The fact you've said it multiple times doesn't make it true. 

It does, because it is a fact. The validation time is quadratic. It does not make my claim invalid just because:
A) You don't understand the issue.
B) You don't know how to create this transaction yourself.

[BlindMayorBitcorn]

The fact you've said it multiple times doesn't make it true. 

It does, because it is a fact. The validation time is quadratic. It does not make my claim invalid just because:
A) You don't understand the issue.
B) You don't know how to create this transaction yourself.

One likely scenario is that the requirements on the nodes will increase due to the natural emergence of Bitcoin on the market. If this happens more people will depend on Bitcoin and be devoted to Bitcoin. Even with both the introduction of light clients and the price kicking our teeth in for the last three years, we still have 5648 nodes running. I think people confuse "real decentralization" with running a full node being some kind of a human right. It's not.

[jonald_fyookball]

This seems to be a controversial point. I believe even Adam Back thinks 2MB blocks are safe. I’d have to find the sauce tho...

Why do you say they are not safe?

Because it is possible to construct a transaction that takes too long to validate (10 minutes any more).

Can you link to some paper or something?

I've never heard this claim before and would like more information on what
you're talking about.

If Adam Back thinks 2MB are safe, then I agree with the good Mayor and would
say that it is in fact controversial at least.

[xyzzy099]

This seems to be a controversial point. I believe even Adam Back thinks 2MB blocks are safe. I’d have to find the sauce tho...

Why do you say they are not safe?

Because it is possible to construct a transaction that takes too long to validate (10 minutes any more).

Can you link to some paper or something?

I've never heard this claim before and would like more information on what
you're talking about.

https://www.reddit.com/r/Bitcoin/comments/3yulwv/any_examples_of_the_10_minute_script_thats_a/

[Lauda]

Can you link to some paper or something?

I've never heard this claim before and would like more information on what
you're talking about.

The validation time is quadratic. You can find information about this yourself easily or you can watch the first scaling workshop. The first thing that comes into mind is this post on reddit. The piece of information is also mentioned on Bitcoin.org, under

[jonald_fyookball]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

[xyzzy099]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

The problem is that every node on the network - not even just miners - will be validating that transaction, regardless of whether it ever actually ends up being in a mined block.  It is a valid transaction, which will be broadcast to all nodes.  And an attacker could broadcast many such transactions.

[BlindMayorBitcorn]

This seems to be a controversial point. I believe even Adam Back thinks 2MB blocks are safe. I’d have to find the sauce tho...

Why do you say they are not safe?

Because it is possible to construct a transaction that takes too long to validate (10 minutes any more).

Can you link to some paper or something?

I've never heard this claim before and would like more information on what
you're talking about.

If Adam Back thinks 2MB are safe, then I agree with the good Mayor and would
say that it is in fact controversial at least.

It isn’t just Adam. There are a few Core developers (including Jeff and Gavin) behind a hard fork to 2MB. BitFury, the biggest western mining pool is behind it; quite a few economic players with a lot at stake are equally convinced Lauda is wrong.

[jonald_fyookball]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

The problem is that every node on the network - not even just miners - will be validating that transaction, regardless of whether it ever actually ends up being in a mined block.  It is a valid transaction, which will be broadcast to all nodes.  And an attacker could broadcast many such transactions.

I'm not sure that is a sufficient reason to have/keep a blocksize limit at the protocol level.  Why can't problematic transactions should be rejected by nodes, for example, by a simple timeout mechanism?

[xyzzy099]

This seems to be a controversial point. I believe even Adam Back thinks 2MB blocks are safe. I’d have to find the sauce tho...

Why do you say they are not safe?

Because it is possible to construct a transaction that takes too long to validate (10 minutes any more).

Can you link to some paper or something?

I've never heard this claim before and would like more information on what
you're talking about.

If Adam Back thinks 2MB are safe, then I agree with the good Mayor and would
say that it is in fact controversial at least.

It isn’t just Adam. There are a few Core developers (including Jeff and Gavin) behind a hard fork to 2MB. BitFury, the biggest western mining pool is behind it; quite a few economic players with a lot at stake are equally convinced Lauda is wrong.

I should add that larger block capacity via SegWit does not make the script problem any worse, because the max 'witness-less' blocksize would still be 1MB, so the largest possible script would still be 1MB.

[Lauda]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

Unlikely.  They would have to do double work.  If the miner who mined the 11 minute-to-validate-block mines another one before the rest of the miners have mined *two* blocks, he wins. So you may do a 51% attack with much less than 51% of the hashrate. SPV miners will probably build on top of the block as well, after fetching just the header and not validating the entire block (or even downloading it). The miner who mined the block obviously know it is valid.

It isn’t just Adam. There are a few Core developers (including Jeff and Gavin) behind a hard fork to 2MB. BitFury, the biggest western mining pool is behind it; quite a few economic players with a lot at stake are equally convinced Lauda is wrong.

I'm not wrong though, constructing such a transaction is possible. It is either 2 MB or SegWit right now, because both would result in an 'effective block size' of 4 MB which is definitely not safe (in addition to lack of consensus in regards to it).

[xyzzy099]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

The problem is that every node on the network - not even just miners - will be validating that transaction, regardless of whether it ever actually ends up being in a mined block.  It is a valid transaction, which will be broadcast to all nodes.  And an attacker could broadcast many such transactions.

I'm not sure that is a sufficient reason to have/keep a blocksize limit at the protocol level.  Why can't problematic transactions should be rejected by nodes, for example, by a simple timeout mechanism?

My understanding is that there is going to be a limit on the number of sigops a scipt can require that will fix this problem, but I don't know when it's coming.  It's not in 0.12.

[jonald_fyookball]

Thanks for the info.  I did not know about this.

Skimming over the comments... I wonder what's your rebuttal to this:

There's a pretty significant flaw in reasoning here: The other miners will be busy mining away on blocks that don't contain this hypothetical 11-minute transaction, so they'll likely surpass the chain that has it in the time it takes to verify it and build another on top... It is far more likely that the monster block would just get orphaned if it took that long to verify.

The problem is that every node on the network - not even just miners - will be validating that transaction, regardless of whether it ever actually ends up being in a mined block.  It is a valid transaction, which will be broadcast to all nodes.  And an attacker could broadcast many such transactions.

I'm not sure that is a sufficient reason to have/keep a blocksize limit at the protocol level.  Why can't problematic transactions should be rejected by nodes, for example, by a simple timeout mechanism?

My understanding is that there is going to be a limit on the number of sigops a scipt can require that will fix this problem, but I don't know when it's coming.  It's not in 0.12.

Why would core include it if they're not going to raise the limit anyway? Makes sense.

[xyzzy099]

Why would core include it if they're not going to raise the limit anyway? Makes sense.

Maybe they are planning to raise it eventually?

[Lauda]

Why would core include it if they're not going to raise the limit anyway? Makes sense.

It will be included (or it might be merged already, I'm not sure). In addition to this there is a BIP (143) that solves the validation time being quadratic, so that the time becomes O(n).

Why would core include it if they're not going to raise the limit anyway? Makes sense.

Maybe they are planning to raise it eventually?

It is highly likely that it will eventually be raised (probably after IBLT and similar improvements).

[jonald_fyookball]

Why would core include it if they're not going to raise the limit anyway? Makes sense.

Maybe they are planning to raise it eventually?

I'm sure they are.  Obviously "eventually" doesn't seem to be a palatable time frame
for many, which is why there is contention.

[BlindMayorBitcorn]

I guess we slid off-topic again. Sorry.

Here's a good read:

I’m sorry, engineers of Bitcoin, but you’re wrong with your fears that a larger block will break Bitcoin.  You’re doing what Donald Knuth told you not to do – premature optimization.  We have no hard data that indicates a 2MB block will be a significant issue with block propagation or centralization. 

[sickpig]

2 MB blocks are dangerous at the moment because a transaction could be created that would take too long to validate (10 minutes or more).

https://github.com/bitcoin/bitcoin/commit/97e5b55c6fabf5deb57be13bdd8f8b9c90d21570

[BlindMayorBitcorn]

It isn’t just Adam. There are a few Core developers (including Jeff and Gavin) behind a hard fork to 2MB. BitFury, the biggest western mining pool is behind it; quite a few economic players with a lot at stake are equally convinced Lauda is wrong.

I'm not wrong though [...] It is either 2 MB or SegWit right now, because both would result in an 'effective block size' of 4 MB which is definitely not safe.

You sure?

https://botbot.me/freenode/bitcoin-core-dev/2016-01-20/?msg=58304091&page=2

I think consensus has been reached that 2MB is tolerable.

[Preclus]

you can send unconfirmed transactions over email, sure. i don't think you can meaningfully/usefully send them over the dogecoin blockchain; if you did, it would just be putting data on the dogecoin blockchain not making use of its coins/crypto per se

My initial post referencing dogecoin was had an incorrect example and was confusing so I deleted it and replaced it with one that was clearer (within a minute). What you appear to be saying is that if I email someone a bitcoin transaction, for example "I'm paying you 1 bitcoin", that is the same as an actual bitcoin transaction. Even though there is nothing that happens on the blockchain.

If that is the case, then a transaction in dogecoin is also a bitcoin transaction if the two parties agree that the dogecoin transaction represents (is a proxy for) bitcoin.

With the LN, your transactions are not bitcoins, they are a proxy for bitcoins. Once off-chain, the transactions are supposedly pegged to the value of bitcoins but there is no 100% enforced and direct connection. The fact that both parties locked something in the bitcoin network is immaterial. The subsequent transactions are off-chain, no different from alt-coin transactions between parties.