It doesn't work that way ... the 2 are only related insomuch that increasing maxBlockSize to 2MB with segwit is even more dangerous in certain aspects and less in others vs simply changing the maxBlocksize to 4MB.

You just want a capacity of 28 TPS right away is all ... and there is nothing wrong with wanting more cake... I want more too.... but can we just hit the gym first before we load up on carbs?

1. You go into the airport and you are only allowed 1 bag that weighs a max of 100 pounds.  (1MB limit - current scheme)
2. You go into the airport and you are only allowed 1 bag that weighs a max of 200 pounds. (2MB hard fork - proposed scheme of classic)
3. You go into the airport and you are allowed 2 bags that weigh a combined 170-300 pounds depending the items (multisig txs) you carry (segwit scheme by core)

Why would you insist on whether it's one bag or two bags? Does it matter to you?

Similarly, segwit allows 1.7MB to 3MB+ of data. Just because it is in two separate data structures, doesn't mean it's less data or that it's ...still 1MB. It isn't.

If one file in your PC saves 1MB and the other saves another 700kb, it's still 1.7MB of data in txs (and not 1MB). And you also solve the malleability problem that is there for years.

im glad that the price is holding right now, i hope that one day it will reach new heights

No one is suggesting it being widely adopted in 2016, or 2017... I said it rolls out in 2016(from a sidechain testnet to a live bitcoin testnet). LN won't become useful until the capacity is much bigger (4-8MB at least) reinforcing my point why the blocksize needs to grow dramatically for the LN to be viable. Which kinda blows up the whole conspiracy theory that Blockstream is delaying the blocksize repeatedly as a stalling tactic because they never want it to grow.

All of that can be automated behind the scenes and the worst possible outcome is the consumer has to wait for the tx to be unfrozen if they want to make an antiquated direct Tx , or if they want to switch from the LN payment channel to Bitpays competing Impulse payment channel network, or they want to sell their BTC for an altcoin.

You understand that the example given of Bob and alice where the funds are locked with multisig and CLTV isn't going to really happen typically because it wouldn't be useful, right? These examples are merely simplified to easier understand. In reality there are going to be layers of multisig where ones funds are locked for 6 months to one person and one can tx with a very large group of people where some people come and go in ones payment channel.

I'm talking about the UI experience, of course what happens behind the scenes is different. This is the same as what will happen when segwit rolls out. All upgraded wallets will send and receive tx the same for the user perspective , but behind the scenes there are now 2 merkle trees. LN is intended to use existing technologies that have already been added to bitcoin . CLTV and multisig ... and wallet providers will be onboard with integrating wallets to process LN txs so there is no learning curve..

What don't you believe , specifically? Do you assume Wallet devs will make it unnecessarily complicated for no reason in order to confuse users?

The protocols , stacks of code, layers of scripting languages that make up the internet are far, far more complicated than the LN and the average grandmother can look at videos of cats on the internet just fine even though she doesn't have a clue how it happens.

When you do the math , the reality is , this isn't a question of choice... we either throw away bitcoin and create centralized databases to handle visa levels of txs or we change bitcoin into a settlement layer. Developers aren't choosing this because they can , they are simply realizing this is the only viable means to make bitcoin scale otherwise it can never go mainstream.

The user won't have to think about the LN ... to them they will be maiking a bitcoin payment and receiving the funds immediately just like now ... there will be no change to the user experience with buying coffee except they will have 2 benefits:
1) Tx conf will be instant ... no waiting every ~10min
2) Tx cannot be double spent like they can now with coinbase/bitpay

BTW ... ETA for LN is scheduled to begin roll out 3rd quarter this year (and only because Core likes to test everything extremely thoroughly)

Miners are still needed because the LN is dependent upon the main chain. Most of the TX fees would be going to the miners as much higher.

Example - Lightning node handles 100k txs per hour, takes an extremely small cut of the txs amounting to a gross revenue of 30 dollars per month , 15-25 going towards expenses and the rest realized net profit. Most of the tx revenue has to be forwarded to the miners where they get extremely high tx fees revenues of eventually increasing to at least 6-7 dollars per tx once the block reward decreases to 0 while the users only pay a couple pennies per tx.

https://lightning.network/


We are way past the whitepaper sir and have working code. Its open source and available for all to see.

https://github.com/ElementsProject/lightning
https://github.com/LightningNetwork/lnd

It is disingenuous to talk about technical limitations that don't exist or insinuate LN is vaporware when we already have code written that you can install yourself.

From what little I know at this time, I'm not very convinced that lightning network is any kind of meaningful solution to long term overall bitcoin transactions (supposedly securely accomplished largely off of the blockchain); however, seg wit seems to be a great next step, and really, we do not know how seg wit is going to play out.

It could be that seg wit really ends up buying a lot of time because of the way that it separates (and removes) less essential aspects from the security (financial) portion of the blockchain.  

In any event, I did not like the way that Todd seemed to reframe the question and to assert that seg wit is the same as a blocksize increase, even though I ultimately agree with his conclusion that a blocksize is not needed at this time and there is not exactly an emergency, at this time to justify planning an exact commitment to a blocksize increase.

I believe that no one can really predict exactly how all of this scaling is going to play out, because we gotta get segwit first and then see how lightning network develops and is proposed because in the end, maybe lightning network is not going to get implemented.

@adam Are you the anti-semite or is it Blitz?

Why did you delete my jstreet post?

What kind of nazi hell is this?

He's blowing smoke up your ass. Or someone is blowing smoke up his ass.

Yes, its in the Lightning Whitepaper and The Core HF has been discussed in the original scaling roadmap (flexcap) with ongoing discussions with another kick the can in Early 2017.

Any questions?

Seriously?

Seriously? Lightning Depends upon radically  larger blocks in the future .... We are talking about 100-200MB blocks. Core has been planning to increase maxblocksize in early 2017... this is old news.

The difficult thing about this conversation is that we are repeatedly being misrepresented or misunderstood. Core has already agreed to compromise and kick the can by increasing capacity.... which means that you really aren't interested in 2MB, but something much bigger... which at this point in time(remember we want bigger blocks too) would be disastrous for bitcoin. Even by Gavin's own calculations Classic could cause a 40% node drop off (worse case scenario) , this is absolutely unacceptable and we need to start reversing this trend immediately.