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

[Variogam]

If anything goes wrong, you simply broadcast the latest state of your channel as a normal on-chain bitcoin transaction.

All your money will be returned to your address, and it will be recorded on the blockchain as normal."


You would insert 100 coins, no insurance needed ?

I don't have to trust sales arguments because smarter people than me can read the code and find flaws. Besides the system can be tested before a single coin is ever risked. It's all open source, read the code and make your own mind if you should or should not trust it.

LN flaw is any older state of your channel can be added to Bitcoin blockchain. Your only defence is try to include the latest state of your channel to Bitcoin blockchain in timelly manner, but you cant guarantee your onchain transaction going to be included to Bitcoin blockchain before is too late. LN might find its niche, but its too risky and complicated for average Joe. Bigger blocks would make using LN actually safer.

[hv_]

If anything goes wrong, you simply broadcast the latest state of your channel as a normal on-chain bitcoin transaction.

All your money will be returned to your address, and it will be recorded on the blockchain as normal."


You would insert 100 coins, no insurance needed ?

I don't have to trust sales arguments because smarter people than me can read the code and find flaws. Besides the system can be tested before a single coin is ever risked. It's all open source, read the code and make your own mind if you should or should not trust it.

LN flaw is any older state of your channel can be added to Bitcoin blockchain. Your only defence is try to include the latest state of your channel to Bitcoin blockchain in timelly manner, but you cant guarantee your onchain transaction going to be included to Bitcoin blockchain before is too late. LN might find its niche, but its too risky and complicated for average Joe, like you. Bigger blocks would make using LN actually safer.

Thx - but for the small brainers (< 1MB) you should drop some link why....

[ComputerGenie]

.... So when ComputerGenie began to make various arguments in that regard, I did not recognize or understand that he was making a kind of existential argument that in the end is irrelevant.  

In other words, who gives a ratt's ass if LN is part of bitcoin or not.  LN seems to provide quite a bit of functionality, as described in the FAQ linked article (above) and LN may or may not be used in the future (likely that it will be used), and I am not sure exactly what the speculation is, about LN taking away from bitcoin...

And therein lies the main problems:

• You read what you want to read, not what's on the screen in front of you.

• You misread the multiple times that I said I'm all for LN (as it's intended to be used).
• You can't grasp that this thread is about Bitcoin.
• You can't grasp that, in a conversation about Bitcoin, things that are not the Bitcoin protocol don't matter to the Bitcoin protocol.
• You can't grasp that LN isn't part of Bitcoin, LN has no relevance to the Bitcoin protocol, and LN has no useful place in this conversation.

[allinvain]

If anything goes wrong, you simply broadcast the latest state of your channel as a normal on-chain bitcoin transaction.

All your money will be returned to your address, and it will be recorded on the blockchain as normal."


You would insert 100 coins, no insurance needed ?

I don't have to trust sales arguments because smarter people than me can read the code and find flaws. Besides the system can be tested before a single coin is ever risked. It's all open source, read the code and make your own mind if you should or should not trust it.

LN flaw is any older state of your channel can be added to Bitcoin blockchain. Your only defence is try to include the latest state of your channel to Bitcoin blockchain in timelly manner, but you cant guarantee your onchain transaction going to be included to Bitcoin blockchain before is too late. LN might find its niche, but its too risky and complicated for average Joe. Bigger blocks would make using LN actually safer.

I was not aware of that. These kinds of fine technical details are why I have trust that eventually some smart person will sort it out. Is it a core requirement of how LN functions that any time state of the channel can be included in the Bitcoin blockchain or is it just because LN is not yet fully developed. Hopefully a clever solution can be found to fix this flaw. You are right though, it is a niche technology for now and not likely to be touched by Joe bitcoin user. My gut feeling tells me that btc will not be competing with other payment systems on a sheer transaction volume capability basis; at least not for a long time to come. I think most average people / investors who are aware of bitcoin see it as a sort of digital gold, and nothing more.

[Searing]

Well, I'm a simple fellow on all this. Just an observation...not that it is gonna effect this agreement or anything else....

The most telling thing to me in all this ...is

1) the spam and all the full block stuff went away as soon as consensus was reached on seg witness being done anyway by the 2mb camp (non-core) that
    flies even if the 2mb becomes an issue in the future after August. If this had never happened, their would have been no incentive for doing anything
    other than just implementing seg witness promptly ..and work on this stuff later (as supposedly is agreed to now ..again imho I think that is how it is setup)

2) who has incentive to FORCE this issue with the spam attacks that now mysteriously disappeared...what is the agenda (I'll not speculate on this just tossing
    it out there as weird as all hell) .......was it just sandbox control of the dump truck by a bunch of 2-year-olds..that is the end result of 2 years of cluster?

3) Ego and control..no matter how you look at this in hindsight or how you go about seeing this whole thing since the failed Hong Kong agreement.....nobody involved
    looks in any way or shape 'clean' after this cluster....everyone seems to want to toy for themselves and screw the community.

Just something that should be mentioned as a "was it really just a play for control" the whole charade of high transaction fees and slow confirm times....
just a lever to make some kind of ego protecting 'stand' with seg witness the starting point..and a jump off point for more clusterf'ing around in the future?

anyway, just looking at it from that point of view, it makes me sad as hell, we have drifted that far down, since the attempt at the Hong Kong agreement...we
are a long way imho on both sides from principle and logic determining progress....and I fear it will become worse the next 'go around' end of this fall 2017.


 

[Variogam]

Is it a core requirement of how LN functions that any time state of the channel can be included in the Bitcoin blockchain or is it just because LN is not yet fully developed. Hopefully a clever solution can be found to fix this flaw.

Older LN channel state is cryptographically valid the same way as newer state. The only incentive not to trying to add older LN channel state to Bitcoin blockchain is the other party with newer state can punish it by getting all such channel coins for themselves - but only if the tansaction can be added to Bitcoin blockchain in timelly manner (you can set the time how long your fine to have stuck your LN coins when opening the channel - this corresponds to the time available to react for having confirmed tansaction in Bitcoin blockchain should this scenario happen). This has theoretical attack vector possible with big LN hubs and congested Bitcoin - like with exchange hacks, it is only matter of time when such attack become reality one day.

[ComputerGenie]

...it is only matter of time when such attack become reality one day.

Can anybody say : "The DAO"   

[hv_]

Is it a core requirement of how LN functions that any time state of the channel can be included in the Bitcoin blockchain or is it just because LN is not yet fully developed. Hopefully a clever solution can be found to fix this flaw.

Older LN channel state is cryptographically valid the same way as newer state. The only incentive not to trying to add older LN channel state to Bitcoin blockchain is the other party with newer state can punish it by getting all such channel coins for themselves - but only if the tansaction can be added to Bitcoin blockchain in timelly manner (you can set the time how long your fine to have stuck your LN coins when opening the channel - this corresponds to the time available to react for having confirmed tansaction in Bitcoin blockchain should this scenario happen). This has theoretical attack vector possible with big LN hubs and congested Bitcoin - like with exchange hacks, it is only matter of time when such attack become reality one day.

Tx again - so think about all the possible attacks that are still unknown (I piss at ANY code reading and testnets - that's NO production proof / even SW in LTC is a proof of no-use)) ? How many options you had attacking Bitcoin over its first 1-3 years?

We should really better get back 'conservative' and get Bitcoin stronger and risk-free with highest reputation than ever!  Scale the thing up to the sky and pay the miners for our all security -  or scam them and you pay later by loosing your coins.

And if you still think you need new toys -> get scammed in the altcoin sections!


Listen to expert Matt Corallo at 35Min to a question of a friend of mine about the security issues - dodgy...

https://www.youtube.com/watch?v=GMvWDg9dtcw

[ComputerGenie]

For anyone still confused about my stance on LN:

• I am in favor of LN for what it is
• Bitcoin is part of LN
• LN is not part of Bitcoin
• An analogous example of the above would be: "all squares are rectangles, but not all rectangles are squares".
• Since LN is not part of Bitcoin, LN has no useful place in the conversation of Bitcoin protocol changes
• Since LN is not part of Bitcoin, LN has no useful place in the conversation of Bitcoin scaling
• Since LN is not part of Bitcoin, saying that LN is "part of a scaling solution for Bitcoin" is saying "the solution for scaling Bitcoin is to not use Bitcoin"

[The One]

This question answer seems to describe Lightning Network in a comprehensive way that does not really seem to be out of line with my previous layman rendition.

https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70

Q 14.1: A standard bitcoin Tx is dependent on confirmations in the blockchain… So, is it really fair to claim that a Lightning Tx is the same as a normal bitcoin Tx?

A:

This is a valid point, they are not the same…

A Lightning Tx is a zero-confirmation Tx. But if it is broadcasted to the bitcoin network; it will be just as valid as any “on-chain” zero-confirmation Tx.

Both types of Tx will eventually be mined into the bitcoin blockchain if they pay a sufficient fee.

However, a LN-Tx has a different security model that makes it much more reliable when compared to a standard zero-confirmation Tx.

A Lightning Tx is only indirectly secured by Proof of Work. This is due to fact that a Lightning Network will be completely dependent on the underlying bitcoin network (see Q12)

Within an open Lightning channel; there is a different set of game-theoretical mechanisms that provide a different type of security model.

Lightning will extend the capabilities of bitcoin without the need for a trusted third party.

But the tradeoff is that you must monitor the bitcoin network by the operation of a full-node.

This monitoring can be outsourced, but in that case you must trust an external server to actually do its job. Your money will still not be routed through this server. The only role of the server is to monitor the bitcoin network, and to broadcast a so-called Penalty Transaction when necessary.

Note that the use of this service is an option, in case you don’t want to run your own full-node.

It will not be possible for this third party to steal money from a Lightning channel.

Also note that the LN is intended as a platform for low-value-transfer (sub $100)

All LN transactions are multi-signature and both participants in a channel must sign for a Tx to become valid. A traditional double-spending attack is therefore made extremely difficult.

However, there is a risk that someone can broadcast an obsolete Lightning Tx to the bitcoin network.

An obsolete Lightning Tx is a Tx that does not represent the latest state of its channel.

The above mentioned risk is the reason that you (or a service that you trust) must operate a “Watcher Node”.

This node will monitor all the transactions that are broadcasted to the bitcoin network.

If your Watcher Node discovers an obsolete Tx; it will (as a countermeasure) broadcast a “Penalty Transaction”

The Penalty Transaction gives you the power to confiscate all the money within your channel (including the money that belongs to your counterpart)

However, a penalty Tx can only become valid after the discovery of a broadcasted obsolete Tx.

Your ability to broadcast a Penalty Transaction makes it very risky for your counterpart to broadcast an obsolete Tx.

Another security/privacy feature, is that all Lightning Tx will be end-to-end encrypted between the participants.

***********

The above in red needs more research. "The Penalty Transaction gives you the power to confiscate all the money within your channel (including the money that belongs to your counterpart)" That doesn't look good. This looks like a backdoor for government to come in and steal. Scammers to take advantage of. “Watcher Node” - looks like a centralise entity and isn't trustless.

[classicsucks]

Yes. However if a trader is doing arbitrage trading between two exchanges, why use LN?

Lets say i want to sent BTC from exch A to exch B, btc takes so long. I just look at another coin like Stellar and if safe and profitable, buy STR, send to exch B, convert to BTC, make the usual profit. Stellar already does the job securely and very fast, less than 30 seconds; so why would anyone use LN?

Bingo. For the past year, altcoins have been used precisely for all of LN's stated use cases - that's why the altcoin market cap has exploded. Many more people trust and use altcoins. Due to the network effect, many of those who accepted bitcoin for payment last year now accept altcoins this year. Investors see growth potential in alts now that bitcoin has stagnated. All of this is due to the scaling roadblock. Vitalik wakes up each day and thanks the Core devs for supressing growth of bitcoin.

Altcoins are absolutely superior to LN in every way: No theoretical new second-layer model is needed. LN is basically pointless. But Blockstream has a $75 million bet on LN.

The only problem with using altcoins is that often there is a dependency on notoriously-untrustworthy exchanges...

[-ck]

Here Jeff Garzik is explaining how the requirement for a >1MB block worked exactly as predicted saying it's not a problem at all...

https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000094.html

Peter Todd asks the valid question of why the hard fork bit wasn't used.

https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000098.html

Important quote

One of your arguments against soft-forks has been that they "fool nodes"(1) by
changing the rules in undetectable ways. One of the counter arguments to your
argument is we explicitly ensure that soft fork mechanisms use nVersion
signalling to ensure all nodes are given an opportunity to learn that the fork
is happening; malicious soft-forks of course don't do this, but the fact
they're possible is an unavoidable by-product of Bitcoin's design.

From the point of view of a headers only lite client, segwit2x is a soft fork
with no nVersion signalling mechanism.

Now, to be secure all wallets, lite clients or not, will need updating in the
event of a hard fork to - for instance - ensure they're getting seed nodes from
appropriate places and the like, and to ensure funds aren't lost in replay
attacks. I'm unclear as to why something that can be fixed in a line or two of
code - code that needs to be changed anyway to safely support the hard fork -
trumps these important issues of user consent that you have brought up before
yourself.

1) https://twitter.com/jgarzik/status/861656643918069760

And basically the question is shrugged off and he is referred back to the git pull request citing tl/dr:

https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000096.html

[ComputerGenie]

Read as:
The "backwards compatible softfork" that is designed to be followed by a "backwards compatible hardfork" isn't backwards compatible with the old clients that will no longer work after the fork anyway.
 

[-ck]

Read as:
The "backwards compatible softfork" that is designed to be followed by a "backwards compatible hardfork" isn't backwards compatible with the old clients that will no longer work after the fork anyway.
 

Right, pretty much... There's not really any such thing as a backwards compatible hardfork, only some SPV clients might not validate enough information that they get hijacked.

[CuriousInvestor]

It is correct to say LN does not scale bitcoin as it only creates centralization for micropayments at the second layer. But it also allows atomic cross chain transactions.

[Variogam]

The point is there wont be two working chains, so from this perspective arguing with "hijacked" or "replay attacks" is moot.

[-ck]

The point is there wont be two working chains, so from this perspective arguing with "hijacked" or "replay attacks" is moot.

You're assuming there won't be two chains. Why? At this stage there's every reason to believe core will not support the 2MB hard fork component of segwit2x leading to two chains. If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts.

[Variogam]

If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts.

Even with small hashrate, this chain wont work - expect orphaning with empty blocks to kill the small chain economically. Even doublespends could be a problem. This reminds me of Luke-jr attack with his pool to merged minined altcoins - Im pretty sure similar incentive is here as well. The same reason why BIP148 would not work.

[-ck]

If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts.

Even with small hashrate, this chain wont work - expect orphaning with empty blocks to kill the small chain economically. Even doublespends could be a problem. This reminds me of Luke-jr attack with his pool to merged minined altcoins - Im pretty sure similar incentive is here as well. The same reason why BIP148 would not work.

Assuming they want to spare the hashrate indeed. If it's large enough, however, then it would be too expensive a venture for them to do. At this stage there's enough pool support for segwit2x to believe there isn't enough hashrate (15%) to sustain a fork separate from it in any meaningful way, especially since some of that 15% is not showing support for regular segwit and likely to jump to the bigger fork.

[FiendCoin]

If you're saying the hashrate will be small on core's fork, this is precisely the issue - what chain will economic entities and SPV clients follow. It is possible to voluntarily and involuntarily follow a lower hashrate fork. Note I'm not arguing in favour of anything, just pointing out the facts.

Even with small hashrate, this chain wont work - expect orphaning with empty blocks to kill the small chain economically. Even doublespends could be a problem. This reminds me of Luke-jr attack with his pool to merged minined altcoins - Im pretty sure similar incentive is here as well. The same reason why BIP148 would not work.

Assuming they want to spare the hashrate indeed. If it's large enough, however, then it would be too expensive a venture for them to do. At this stage there's enough pool support for segwit2x to believe there isn't enough hashrate (15%) to sustain a fork separate from it in any meaningful way, especially since some of that 15% is not showing support for regular segwit and likely to jump to the bigger fork.

Still feels like a massive clusterfuck is going to happen.

Funny thing is, in some alternate universe SegWit activated without a fight and is north of 10k right now, while in another alternate universe bitcoin is in its death throws do to political fighting over blocksize/control and probably sub 200 on its way $10.

We'll probably fall somewhere between the two