The Barry Silbert segwit2x agreement with >80% miner support.

[ComputerGenie]

It was vending machine.
Then coffee.
Now hot dog.
What next?

Well, I had a thing worked out about hookers, but I'm trying to keep it all PG.

[krishnapramod]

UASF is an interesting and very aggressive move towards forcing a split. I think the most pushed-for UASF in the form of BIP148 is far too aggressive too soon and is doomed. August 1 is very close and gives the compromisers very little time to formulate a meaningful and safe middle ground (read segwit + 2MB) to keep miners on board and avoid any splits. Should no compromise occur before that time, those signalling BIP148 will be left feeling very cold with almost no hashrate to support them, and a dead slow blockchain going nowhere. The proponents of BIP148 say there is nothing to lose and that those who are on the main chain will be the ones to lose when a reorganisation happens in the future and the uasf chain becomes the only active chain. I think this is fanciful given the absolutely minuscule miner support it currently has to create such a chain. The only realistic chance it has is if it is also coupled with the ridiculously destabilising move of changing proof of work since it will no longer need existing miner support. This of course then turns it into a hard fork as well...

What I think will happen is UASF will continue to be perceived as a threat that will make the existing players more likely to accept a compromise. The Silbert agreement was doomed from the start without any code or developers or core support but then again it was an overwhelming display of what the miners would agree to. UASF and specifically BIP148 has forced core developers to try and find that compromise point before any significant split could occur. In fact should this eventuate, and I believe it will, those who mine true UASF blocks from August1 before a compromise soft fork will be the only ones left on a dead end fork with a block chain that joins no one.

A large number of core developers are against BIP148 while most are for UASF in principle. UASF could in fact work without such an aggressive short time frame and core support but BIP148 is forcing the issue too soon with too little support.

Obviously the biggest risk of BIP148 is a chain split, but it could be avoided with a split protection soft fork, BIP9 and most importantly this would then lower the SegWit lock-in percentage to 65% from 95%, plus this BIP provides a method for rapid miner activation of SegWit mandatory signalling ahead of the BIP148 activation date, August 1. Obviously, at the end everything depends on majority, but this option seems much safer.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html

[dinofelis]

...The sneaky part in this, is that I have to "commit" my bitcoin stash for 16 hotdogs from the start with you, and you better commit some coins too, or otherwise, you have nothing to lose in this.  So when I buy my first hot dog, instead of paying 2 mBTC, I have to engage already some 40 mBTC with you in a channel.  If after all, the first hot dog I buy is not that great, and I want to buy my second hot dog with a competitor, I have to chose: do I settle on chain, to get 38 mBTC back, but only after 100 blocks or so (the security period) ; or do I want you to transmit my transaction to the competitor (LN usage), which you may very well decide not to do, because, exactly, it is a competitor, or ask an insane fee for it (because, exactly, it is a competitor) ?...

With any Bitcoin transaction, you must "commit all of your stash", so I'm not sure why this is even a mention.

If I buy one hot dog with a normal bitcoin transaction, I have to "commit" the price of ONE hot dog (that is to say, 2 mBTC in our example).  All the rest of my stash is uncommitted and I can use it how I want.  If I plan to buy *potentially* 16 hot dogs with a LN channel, I have to commit at least 16 times the price of a single hot dog, even if right now, I only buy one.  In your example, we had a direct LN channel between buyer of hot dogs and seller of hot dogs, so I have already to commit 32 mBTC even if right now, I only buy one, in order for them to be in my channel already.  That means, I only spend them to you, or *through* you in as much as you give me permission to do so.

As for the rest, it seems that you and I are working on different base information. I'm curious as to where you got this "100 blocks" from; could you link me to this....

100 blocks was, I think, the proposed "time lock" on settlements, so that you can send your "punishment transaction" on chain when your partner sent a scamming settlement before he can move the coins.

https://en.bitcoin.it/wiki/Lightning_Network

Outsourcable enforcement: if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.

[...]

Dispute period: (dispute resolution period[7]) the period of time that Alice has to get her breach remedy transaction added to the blockchain after Mallory has an old commitment transaction added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.

[ComputerGenie]

Out of order, but that's how my trains of thought work...

....

As for the rest, it seems that you and I are working on different base information. I'm curious as to where you got this "100 blocks" from; could you link me to this....

100 blocks was, I think, the proposed "time lock" on settlements, so that you can send your "punishment transaction" on chain when your partner sent a scamming settlement before he can move the coins.
https://en.bitcoin.it/wiki/Lightning_Network

Outsourcable enforcement: if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
[...]
Dispute period: (dispute resolution period[7]) the period of time that Alice has to get her breach remedy transaction added to the blockchain after Mallory has an old commitment transaction added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.

if both parties cooperate, a channel can be closed immediately

So your argument is on some non-discussed issue that is a potential problem and not an actual "usual" one. To that end, I'm not willing (in this thread) to bother with the merits (or lack thereof) of LN; I'm simply hitting on the fact that the main usage of LN would be "consumer based" and not a "bank-style" transaction as suggested.

...The sneaky part in this, is that I have to "commit" my bitcoin stash for 16 hotdogs from the start with you, and you better commit some coins too, or otherwise, you have nothing to lose in this.  So when I buy my first hot dog, instead of paying 2 mBTC, I have to engage already some 40 mBTC with you in a channel.  If after all, the first hot dog I buy is not that great, and I want to buy my second hot dog with a competitor, I have to chose: do I settle on chain, to get 38 mBTC back, but only after 100 blocks or so (the security period) ; or do I want you to transmit my transaction to the competitor (LN usage), which you may very well decide not to do, because, exactly, it is a competitor, or ask an insane fee for it (because, exactly, it is a competitor) ?...

With any Bitcoin transaction, you must "commit all of your stash", so I'm not sure why this is even a mention.

If I buy one hot dog with a normal bitcoin transaction, I have to "commit" the price of ONE hot dog (that is to say, 2 mBTC in our example).  All the rest of my stash is uncommitted and I can use it how I want...

I'm not sure if that last bit is you talking about LN or Bitcoin. If you're talking about Bitcoin, that's precisely not how Bitcoin works. If address 1dakjfhkjkhjsadf has 10,000 BTC and wants to spend 2 mBTC, the entire 10,000 BTC is committed to the transaction (2 mBTC to the receiver and the rest [9999.998 BTC] either back to 1dakjfhkjkhjsadf or to a new "change address" [most usually the latter, depending on software]). With Bitcoin, you are, in fact, committing all of your BTC (from a given address) to each, and every, transaction.

[Paashaas]

No, Segwit+schnorr+LN+RSK+Mimblewimble+TumbleBit will transform Bitcoin into NotBitcoin.  

You dont know what they stand for and how to make Bitcoin mainstream.

Conjoining all this bullshit into one argument waters down the validity of any position you might attempt to maintian.

You cannot troll me with youre cheap mind-game, you aint that smart enough.

PS - In case anyone missed it before: LN can happen without segwit.

PS - In case you missed it; It looks great on paper but in reality it only works on Segwitt the other solution like BU is bugged.

[ComputerGenie]

...[pointless troll attempt]...

PS - In case anyone missed it before: LN can happen without segwit.

PS - In case you missed it; It looks great on paper but in reality it only works on Segwitt the other solution like BU is bugged.

Actually, no. It's a opcode issue that would require a small code change. To change the protocol to allow LN has nothing to do with BU, segwit, or any other scheme (other than the fact that the change for segwit includes the "proper" opcode change to enable the use of LN). The fact that segwit has the opcode change has not a basis, in fact, for the mistaken belief that one has anything to do with the other.

Please do try to understand what you're on about before you try to correct me.

[ComputerGenie]

Am I alone in the belief that: piece by piece, the all of the code that Core wants will eventually be added (no matter what the rest of the world wants), Core will never give up on segwit (even if acceptance was under 1%), and it's all just a issue/matter of timing of implementation?

[dinofelis]

Out of order, but that's how my trains of thought work...

....

As for the rest, it seems that you and I are working on different base information. I'm curious as to where you got this "100 blocks" from; could you link me to this....

100 blocks was, I think, the proposed "time lock" on settlements, so that you can send your "punishment transaction" on chain when your partner sent a scamming settlement before he can move the coins.
https://en.bitcoin.it/wiki/Lightning_Network

Outsourcable enforcement: if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
[...]
Dispute period: (dispute resolution period[7]) the period of time that Alice has to get her breach remedy transaction added to the blockchain after Mallory has an old commitment transaction added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.

if both parties cooperate, a channel can be closed immediately

So your argument is on some non-discussed issue that is a potential problem and not an actual "usual" one. To that end, I'm not willing (in this thread) to bother with the merits (or lack thereof) of LN; I'm simply hitting on the fact that the main usage of LN would be "consumer based" and not a "bank-style" transaction as suggested.

I thought that every form of one-sided settling ALWAYS included a waiting period.  I don't see how it can work without.  Because the "settlement" of today, is the "scamming broadcast" of tomorrow.   If I had the possibility to settle one-sided and have my stash available IMMEDIATELY, the security in the LN channel would be gone, no ?  I don't see how a one-sided (honest) settlement can NOT include a waiting time.

[ComputerGenie]

I thought that every form of one-sided settling ALWAYS included a waiting period.  I don't see how it can work without.  Because the "settlement" of today, is the "scamming broadcast" of tomorrow.   If I had the possibility to settle one-sided and have my stash available IMMEDIATELY, the security in the LN channel would be gone, no ?  I don't see how a one-sided (honest) settlement can NOT include a waiting time.

In the simplest terms, yes there is a "waiting period", however, that period (to the best of my understanding) comes before the transaction is finalized.

Since everyone seems to be fond of the traditional banking examples, the best way to term it is that LN is like writing post-dated checks.
Over-simplified, but:
You write the post-dated check with the understanding that it will not be cashed before that time. With LN, that post-date allows you both the chance to "rip up" the check and write a different check for a different amount (and the 1st check no longer exists). Much like with real post-dated checks, the holder can, at any time, deposit the check and the date becomes irrelevant (because banks stopped looking at dates long ago). LN allows both sides to "walk away" at any given time (I want no more hot dogs or you don't want to sell me any more) and thus "finalizing" the most recent transaction.

There is no "one sided" to it (or any commercial transaction), because it is a valid transaction.

[jbreher]

Am I alone in the belief that: piece by piece, the all of the code that Core wants will eventually be added (no matter what the rest of the world wants), Core will never give up on segwit (even if acceptance was under 1%), and it's all just a issue/matter of timing of implementation?

Indeed. Veruca 'core' Salt has decreed.

[CoinCube]

UASF is an interesting and very aggressive move towards forcing a split. I think the most pushed-for UASF in the form of BIP148 is far too aggressive too soon and is doomed. August 1 is very close and gives the compromisers very little time to formulate a meaningful and safe middle ground (read segwit + 2MB) to keep miners on board and avoid any splits. Should no compromise occur before that time, those signalling BIP148 will be left feeling very cold with almost no hashrate to support them, and a dead slow blockchain going nowhere. The proponents of BIP148 say there is nothing to lose and that those who are on the main chain will be the ones to lose when a reorganisation happens in the future and the uasf chain becomes the only active chain. I think this is fanciful given the absolutely minuscule miner support it currently has to create such a chain. The only realistic chance it has is if it is also coupled with the ridiculously destabilising move of changing proof of work since it will no longer need existing miner support. This of course then turns it into a hard fork as well...

What I think will happen is UASF will continue to be perceived as a threat that will make the existing players more likely to accept a compromise. The Silbert agreement was doomed from the start without any code or developers or core support but then again it was an overwhelming display of what the miners would agree to. UASF and specifically BIP148 has forced core developers to try and find that compromise point before any significant split could occur. In fact should this eventuate, and I believe it will, those who mine true UASF blocks from August1 before a compromise soft fork will be the only ones left on a dead end fork with a block chain that joins no one.

A large number of core developers are against BIP148 while most are for UASF in principle. UASF could in fact work without such an aggressive short time frame and core support but BIP148 is forcing the issue too soon with too little support.

I will be honest the bolded portion concerns me. Forcing a chain split should be utterly off of the table. It is anathema to the very concept of consensus based management. I personally see very little difference between a split forced by a mining consortium over the objections of the larger community and a split forced by a majority of USAF nodes over the objections of the mining community and big block supporters.

The core developers have taken the role of intellectual leaders/stewards of bitcoin. A prime if not the prime duty of this job is to guide development in such a way that overall consensus is maintained. I fail to see how UASF is anything other then a lazy attempt to use force because compromise and consensus are "just to hard".

In the next week or two I will have my node up and running. Not it makes much difference but I will be using that node to oppose whichever party is first to try to "force" this issue. If that is BIP148 I will be running a non UASF node. If it is a contentions miner hardfork then I will support of whatever proof-of-work change or other countermeasures are deployed in response.

The status quo expensive transactions and all is far better than a bitcoin that breaks into pieces.

[ComputerGenie]

...The status quo expensive transactions and all is far better than a bitcoin that breaks into pieces.

That's about the most intelligent sentence I've read in the whole 34 pages of this thread. 

[dinofelis]

I thought that every form of one-sided settling ALWAYS included a waiting period.  I don't see how it can work without.  Because the "settlement" of today, is the "scamming broadcast" of tomorrow.   If I had the possibility to settle one-sided and have my stash available IMMEDIATELY, the security in the LN channel would be gone, no ?  I don't see how a one-sided (honest) settlement can NOT include a waiting time.

In the simplest terms, yes there is a "waiting period", however, that period (to the best of my understanding) comes before the transaction is finalized.

Since everyone seems to be fond of the traditional banking examples, the best way to term it is that LN is like writing post-dated checks.
Over-simplified, but:
You write the post-dated check with the understanding that it will not be cashed before that time. With LN, that post-date allows you both the chance to "rip up" the check and write a different check for a different amount (and the 1st check no longer exists). Much like with real post-dated checks, the holder can, at any time, deposit the check and the date becomes irrelevant (because banks stopped looking at dates long ago). LN allows both sides to "walk away" at any given time (I want no more hot dogs or you don't want to sell me any more) and thus "finalizing" the most recent transaction.

Yes, but the coins committed in that channel will not become spendable before the waiting period.  So you cannot commit them in another channel, and you cannot use them in a classical transaction, before that period.  They are unspendable UTXO before the end of the waiting period (that's exactly what the waiting period is made for !).  Contrary to banks, bitcoin does look at dates.

So, if I was planning to buy 16 hot dogs with you, I have to commit right now the price of 16 hot dogs (say, 32 mBTC) in a channel with you.  If I buy one hot dog, I send you a LN transaction in that channel so that you are now the owner of 2 mBTC, but my other 30 mBTC are still committed in that channel.  If I find the hot dog you sold me, disgusting, I will change my mind, and want to buy my 15 other hot dogs elsewhere, but my 30 mBTC are still locked up in that channel with you.  

I can do 2 possible things:
a) use the LN to pay another hot dog provider through you ; but I'm depending on you to ALLOW me to do that payment.  You can always refuse/delay/.... any LN payment that goes through a channel with you.  If you refuse to transmit my payment, the other hot dog seller will not be paid.  You might have an incentive to not process transactions for your competitor.  And I can't do anything else with my 30 mBTC in the channel with you as long as I keep that channel.

b) settle the channel with you, to get my 30 mBTC free.  But then I have to pay an on-chain fee, I have to hope that my transaction will get included in the chain, and I won't be able to spend these 30 mBTC before the waiting period.

So once my 30 mBTC are locked up in the channel with you, and you don't give me the permission to spend them with your competitor, I have no way to pay my hot dog with your competitor using my 30 mBTC within the waiting period.

[dinofelis]

A large number of core developers are against BIP148 while most are for UASF in principle. UASF could in fact work without such an aggressive short time frame and core support but BIP148 is forcing the issue too soon with too little support.

This can only illustrate their inconsistent stance, then.  A UASF only makes sense if there is a genuine chain split.  We've been hearing the stories about the need of consensus, and the "danger of hard forks" because, goodness me, that could cause a chain split.  But now they are in favour of forcing a chain split, even though with what technically is a soft fork.  They seem to admit that their whole argument for "soft forks only" was just an inconsistent stance with a hollow argument.

A consensus hard fork is much less dangerous than a forced split with a soft fork.

[ComputerGenie]

....

OK, now I see what you're getting at. (However, I still maintain that this is no different than a standard Bitcoin transaction where having a given address that has 32 mBTC, sending me 2 mBTC, and the remaining 30 mBTC goes to your change address; you still can't spend the remaining 30 mBTC until it hits a block.)

Again, that's getting into the use-case merits level of LN, which I think is moot to this thread and to Bitcoin in general.

That being said, I find that adding an opcode (or even a couple opcodes) to the protocol so that people can willfully engage in something like that is not a "bad" thing, in and of itself. The merits of a specific use-case of an extension to a protocol aside, it's generally a "good thing" to add potential use-cases that have minor overhead cost to the protocol itself.
I'm not sure you and I will find "common ground" on LN, because we look at it differently. You're focused in on the "worse case scenarios" of a particular use-case, whereas I look it from a pragmatic perspective of "will this extension to the protocol have a net gain to the protocol?" (and in my mind the answer is "Yes", and that answer doesn't specifically involve LN). I think that the change to the protocol will allow other "things" beyond LN to potentially expand the usage of Bitcoin as a protocol in the future.

[dinofelis]

....

OK, now I see what you're getting at. (However, I still maintain that this is no different than a standard Bitcoin transaction where having a given address that has 32 mBTC, sending me 2 mBTC, and the remaining 30 mBTC goes to your change address; you still can't spend the remaining 30 mBTC until it hits a block.)

But you CAN spend it the next block.   While after settling, you can only spend it after, say, 100 blocks or (in the original paper by Poon) after 1000 blocks - whatever was the "timeout" security set by the channel.

That being said, I find that adding an opcode (or even a couple opcodes) to the protocol so that people can willfully engage in something like that is not a "bad" thing, in and of itself. The merits of a specific use-case of an extension to a protocol aside, it's generally a "good thing" to add potential use-cases that have minor overhead cost to the protocol itself.
I'm not sure you and I will find "common ground" on LN, because we look at it differently. You're focused in on the "worse case scenarios" of a particular use-case, whereas I look it from a pragmatic perspective of "will this extension to the protocol have a net gain to the protocol?" (and in my mind the answer is "Yes", and that answer doesn't specifically involve LN). I think that the change to the protocol will allow other "things" beyond LN to potentially expand the usage of Bitcoin as a protocol in the future.

I'm actually favourable to something like the LN, even though I think it will not work as we think.  But ONLY on a chain without limits, because the whole security of the LN system resides in the guarantee to be able to settle and to "punish" within the time-out period.  Without that guarantee, the LN is highly unsafe.  And I'm fully against pushing people OFF the chain with artificial limitations of the chain capacity (which, at the same time, makes the LN ultra unsafe).

However, I know that bitcoin's design runs into problems with unlimited blocks.  But that's because bitcoin's design is fundamentally flawed (which Greg Maxwell discovered too).  However, bitcoin's flawed design will only screw it up in the long run.  For the moment, it is better to keep it running the time it lasts and to kill it artificially with very small blocks for wrong reasons is, I think, a bad idea (however, it is the current design of bitcoin which contains this limit).

[ComputerGenie]

...While after settling, you can only spend it after, say, 100 blocks or (in the original paper by Poon) after 1000 blocks - whatever was the "timeout" security set by the channel....

I think you may need to reread the paper again (you seemed to have missed both the word "example" when you read it the 1st time).  If you don't want "some defined number of blocks" to be 10; 100; 1,000; or 10,000, then don't set ""some defined number of blocks"" to be  10; 100; 1,000; or 10,000 when you create the parent transaction.
I'm still not sure how your argument is relevant to this thread, or Bitcoin, but I am sure that your being stuck on this "example" number is like you offering to pay me 100,000 BTC and then getting upset because I want the 100,000 BTC.  

[dinofelis]

...While after settling, you can only spend it after, say, 100 blocks or (in the original paper by Poon) after 1000 blocks - whatever was the "timeout" security set by the channel....

I think you may need to reread the paper again (you seemed to have missed both the word "example" when you read it the 1st time).  If you don't want "some defined number of blocks" to be 10; 100; 1,000; or 10,000, then don't set ""some defined number of blocks"" to be  10; 100; 1,000; or 10,000 when you create the parent transaction.

But it is necessary for the security of the channel to set a high enough number, so that during this time you can:
1) observe that your counter party has been cheating on you
2) get the punishing transaction into the chain before it times out

10 blocks, if ever you computer goes down, or there is a serious spam attack, you will never catch the guy sending a scammy settlement.  100 blocks means that you have to check a few times a day that your partner has not been scamming you, and hope that you will get your punishing transaction in fast enough that it gets in the chain before time-out.  1000 blocks is probably safe unless you go on a holiday, but your funds cannot be touched for a week.

I'm still not sure how your argument is relevant to this thread, or Bitcoin, but I am sure that your being stuck on this "example" number is like you offering to pay me 100,000 BTC and then getting upset because I want the 100,000 BTC.  

It is relevant in as much as segwit/LN is proposed as a solution to scaling.  It seems that you are missing the consequences of having to commit funds in a channel, before you even want to spend them.  The committed funds are locked up in the channel until you can settle, pay the fee, and wait for the time out to occur.  It is exactly NOT like offering you 100 000 BTC.  It is rather like a real bank account: I have to commit my money to that bank, and I'm depending on that bank, afterwards, to be nice enough to do the payments I want to do with my money in that account.  True, contrary to a bank account, I can eventually get my money back out of the account, but it takes a settlement, and a lock-out period.

This is why my argument was that you don't commit too lightly your funds to just any dude on the internet, and why it is better to use a "big, trustworthy partner" in LN links, rather than just any "Joe" on the internet in a P2P way, because even though if you are vigilant, that Joe cannot run with your money (he can only run with your money if he sends a scammy settlement, and you didn't catch it within the lock-out period), your funds are nevertheless at his mercy of permission to transact, and are out of your ability to get them back for a given lock-out period.

[ComputerGenie]

...10 blocks, if ever you computer goes down, or there is a serious spam attack, you will never catch the guy sending a scammy settlement.  100 blocks means that you have to check a few times a day that your partner has not been scamming you, and hope that you will get your punishing transaction in fast enough that it gets in the chain before time-out.  1000 blocks is probably safe unless you go on a holiday, but your funds cannot be touched for a week....

Again, you're arguing the minutia of an off-topic specific use-case addition of a single opcode.

...It is relevant in as much as segwit/LN is proposed as a solution to scaling...

It's really not and it's really not.
I can falsely advertise my dog as a cat, does that make it relevant in a cat thread?

Your argument amounts to: "All trail-mix is bad because BrandA uses hazelnuts, instead of peanuts, and I don't like hazelnuts."






For the record, anyone trying to sell someone else on the co-joined merits of LN/segwit as a "package" is attempting to make an "appeal to emotion"; they are hoping that the want for LN (usually due to over-hyped mis/disinformation), or some alleged result of the two combined, will sway opinion to a pro-segwit point of view.

[-ck]

In the next week or two I will have my node up and running. Not it makes much difference but I will be using that node to oppose whichever party is first to try to "force" this issue. If that is BIP148 I will be running a non UASF node. If it is a contentions miner hardfork then I will support of whatever proof-of-work change or other countermeasures are deployed in response.

One thing about the bitcoin network is its resilience against being forced to change. The consensus system has proven itself time and time again. It's my opinion that you need not worry as any group trying to force change will fail as has been demonstrated in the past. UASF via BIP148 will be a spectacular failure and consequently the enthusiasm for UASF will likely dwindle along with it. I'm pretty sure that if support stays at <1% hashrate on August1, and pools running UASF will frantically pull out to avoid mining on a dead end chain. Additionally the miners won't be forcing a hardfork as they haven't even begun doing any code, nor have coders, for their Silbert fork. At this stage I'm willing to bet segwit2X will be the way out. There doesn't seem any significant opposition to it any more.