Title: So I just read the LN white paper... Post by: Predatron on February 03, 2018, 11:59:43 PM ... and I'm a little concerned. Of course I could be misunderstanding things,
but there are several references to soft forks being needed: However, Lightning Network’s bidirectional micropayment channel requires the malleability soft-fork described in Appendix A to enable near-infinite scalability while mitigating risks of intermediate node default. The Lightning Network uses a SIGHASH_NOINPUT transaction to spend from this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged. SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions can be spent from before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash flags. Mark Freidenbach has proposed that Sequence Numbers can be en- forcible via a relative block maturity of the parent transaction via a soft-fork[12]. This would allow some basic ability to ensure some form of relative block confirmation time lock on the spending script. With systemic and potentially fatal errors if they are not implemented: 9.6 Inability to Make Necessary Soft-Forks Changes are necessary to bitcoin, such as the malleability soft-fork. Addi- tionally, if this system becomes popular, it will be necessary for the system to securely transact with many users and some kind of structure like a blockheight timestop will be desirable. This system assumes such changes to enable Lightning Network to exist entirely, as well as soft-forks ensuring the security is robust against attackers will occur. While the system may continue to operate with only some time lock and malleability soft-forks, there will be necessary soft-forks regarding systemic risks. Without proper community foresight, an inability to establish a timestop or similar func- tion will allow systemic attacks to take place and may not be recognized as imperative until an attack actually occurs. And then it goes on to say that the block size will need to be increased anyway! 10 Block Size Increases and Consensus If we presume that a decentralized payment network exists and one user will make 3 blockchain transactions per year on average, Bitcoin will be able 52 to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions/MB, or 500 bytes/Tx). This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin. A simple increase of the block size would be a hard fork, meaning all nodes will need to update their wallets if they wish to participate in the network with the larger blocks. While it may appear as though this system will mitigate the block size increases in the short term, if it achieves global scale, it will necessitate a block size increase in the long term. Creating a credible tool to help prevent blockchain spam designed to encourage transactions to timeout becomes imperative. And the solution to this makes no sense to me: To mitigate timelock spam vulnerabilities, non-miner and miners’ con- sensus rules may also differ if the miners’ consensus rules are more restrictive. Non-miners may accept blocks over 1MB, while miners may have different soft-caps on block sizes. If a block size is above that cap, then that is viewed as an invalid block by other miners, but not by non-miners. The miners will only build the chain on blocks which are valid according to the agreed-upon soft-cap. This permits miners to agree on raising the block size limit with- out requiring frequent hard-forks from clients, so long as the amount raised by miners does not go over the clients’ hard limit. This mitigates the risk of mass expiry of transactions at once. All transactions which are not re- deemed via Exercise Settlement (ES) may have a very high fee attached, and miners may use a consensus rule whereby those transactions are exempted from the soft-cap, making it very likely the correct transactions will enter the blockchain. So my question is, how can you accept blocks that are not accepted by the miners? And, what is the status of these required soft forks? Title: Re: So I just read the LN white paper... Post by: achow101 on February 04, 2018, 12:09:25 AM ... and I'm a little concerned. Of course I could be misunderstanding things, A lot has changed with LN's design since the paper was published.but there are several references to soft forks being needed: And, what is the status of these required soft forks? However, Lightning Network’s bidirectional micropayment channel requires Transaction malleability has been resolved with segwit which has activated on Bitcoin.the malleability soft-fork described in Appendix A to enable near-infinite scalability while mitigating risks of intermediate node default. The Lightning Network uses a SIGHASH_NOINPUT transaction to spend from this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged. SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions can be spent from before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash flags. Mark Freidenbach has proposed that Sequence Numbers can be en- Relative lock times have been soft forked into Bitcoin with OP_CHECKSEQUENCEVERIFY.forcible via a relative block maturity of the parent transaction via a soft-fork[12]. This would allow some basic ability to ensure some form of relative block confirmation time lock on the spending script.[/i][/b] These are the only two soft forks that are necessary for LN to work on Bitcoin, and both have activated. And then it goes on to say that the block size will need to be increased anyway! It will, or perhaps there will be more improvements which shrink the size of transactions. LN is not the end all be all solution for Bitcoin transaction capacity, but it certainly will provide a huge boost.And the solution to this makes no sense to me: What they are describing is the soft limit on block sizes. It is not invalid to create a block that is less than say, 500 kB. However the miners may collude and decide that they won't mine any blocks larger than 500 kB. This does not break consensus rules and all non-mining full node will still accept blocks larger than 500 kB. Just the miners won't produce a block larger than 500 kB and if they see one, they will reject it thus it won't go into the blockchain. This is effectively a miner enforced soft fork.To mitigate timelock spam vulnerabilities, non-miner and miners’ con- sensus rules may also differ if the miners’ consensus rules are more restrictive. Non-miners may accept blocks over 1MB, while miners may have different soft-caps on block sizes. If a block size is above that cap, then that is viewed as an invalid block by other miners, but not by non-miners. The miners will only build the chain on blocks which are valid according to the agreed-upon soft-cap. This permits miners to agree on raising the block size limit with- out requiring frequent hard-forks from clients, so long as the amount raised by miners does not go over the clients’ hard limit. This mitigates the risk of mass expiry of transactions at once. All transactions which are not re- deemed via Exercise Settlement (ES) may have a very high fee attached, and miners may use a consensus rule whereby those transactions are exempted from the soft-cap, making it very likely the correct transactions will enter the blockchain. So my question is, how can you accept blocks that are not accepted by the miners? Title: Re: So I just read the LN white paper... Post by: Predatron on February 04, 2018, 12:27:06 AM These are the only two soft forks that are necessary for LN to work on Bitcoin, and both have activated. Perfect thanks for clarifying that! What they are describing is the soft limit on block sizes. It is not invalid to create a block that is less than say, 500 kB. However the miners may collude and decide that they won't mine any blocks larger than 500 kB. This does not break consensus rules and all non-mining full node will still accept blocks larger than 500 kB. Just the miners won't produce a block larger than 500 kB and if they see one, they will reject it thus it won't go into the blockchain. This is effectively a miner enforced soft fork. Right, but in the example they were talking about block sizes over 1MB, which as I understand it is a hard limit. Also, is there anything to stop everyone from connecting to just one "master-node" on the network, thus making all transactions just one hop to anyone else? I presume this master-node would need enough BTC to handle the liquidity of everyone, but that is theoretically possible. Title: Re: So I just read the LN white paper... Post by: nullius on February 04, 2018, 12:34:20 AM ... and I'm a little concerned. Of course I could be misunderstanding things, but there are several references to soft forks being needed: You appear to be referencing “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments” by Joseph Poon and Thaddeus Dryja (https://lightning.network/lightning-network-paper.pdf), which you did neither linked to nor precisely identified. First, observe that the date on the first page is “January 14, 2016”. When it speaks of required softforks, it speaks of the Segwit upgrade which occurred in the year 2017. According to my calendar, 2017 has already passed. You also mashed together disparate pieces of text, without identifying which parts of the document you were copying. This makes it very hard to follow. I will provide pinpoint section and page references for readers. Now, to address your specific questions: However, Lightning Network’s bidirectional micropayment channel requires the malleability soft-fork described in Appendix A to enable near-infinite scalability while mitigating risks of intermediate node default. That is from Section 3, on page 7. The Lightning Network uses a SIGHASH_NOINPUT transaction to spend from this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged. SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions can be spent from before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash flags. That is from Section 3.1.2, on page 8. Mark Freidenbach has proposed that Sequence Numbers can be en- forcible via a relative block maturity of the parent transaction via a soft-fork[12]. This would allow some basic ability to ensure some form of relative block confirmation time lock on the spending script.[/i][/b] That is from Section 3.3, on page 13. With systemic and potentially fatal errors if they are not implemented: 9.6 Inability to Make Necessary Soft-Forks <snip> Your refer to the text starting at page 52. The malleability fix was deployed as part of the Segwit upgrade. It has been active on the Bitcoin network since 24 August 2017. There cannot be an inability to make the necessary soft-fork, when the soft-fork is already done. And the solution to this makes no sense to me: To mitigate timelock spam vulnerabilities, non-miner and miners’ con- sensus rules may also differ if the miners’ consensus rules are more restrictive. Non-miners may accept blocks over 1MB, while miners may have different soft-caps on block sizes. If a block size is above that cap, then that is viewed as an invalid block by other miners, but not by non-miners. The miners will only build the chain on blocks which are valid according to the agreed-upon soft-cap. This permits miners to agree on raising the block size limit with- out requiring frequent hard-forks from clients, so long as the amount raised by miners does not go over the clients’ hard limit. This mitigates the risk of mass expiry of transactions at once. All transactions which are not re- deemed via Exercise Settlement (ES) may have a very high fee attached, and miners may use a consensus rule whereby those transactions are exempted from the soft-cap, making it very likely the correct transactions will enter the blockchain. So my question is, how can you accept blocks that are not accepted by the miners? You quote from Section 10, on page 53. Zeroth of all, there is no longer a 1MB block size limit; indeed, there is no longer a block size limit at all. Since 24 August 2017, Bitcoin has instead had a block weight limit of 4000000 bytes (4MB). It is expected that over time, average blocksizes will work out to a bit over 2MB. First of all, you will observe that the text speaks of long-term planning. There is ongoing Bitcoin hardfork research (https://bitcoinhardforkresearch.github.io/) into how to safely fork the network if such a thing becomes required. The text itself answers your specific question: Miners can refuse to build on consensus-valid blocks. It would be financially suicidal for any individual miner or pool to attempt enforcing such a policy: They would quickly wind up building their own minority chain, which would be rejected by nodes in favour of the chain with higher total POW. But if all miners were to agree to build only on blocks smaller than the consensus hard limit, then they could do that. N.b. that non-mining nodes don’t produce new blocks, and the smaller blocks would be consensus-valid. And, what is the status of these required soft forks? As aforesaid, the required soft fork was done half a year ago. It is called Segwit. Edit—self-correction: As noted from achow101’s post, I somehow zoned out on the checksequenceverify (CSV) softfork (BIPs 68, 112, 113). That was activated on the network on 4 July 2016. Title: Re: So I just read the LN white paper... Post by: BenOnceAgain on February 04, 2018, 12:45:32 AM A lot has changed with LN's design since the paper was published. Do you know if there's a more recent version of the Lightning Network white paper? The latest I've found is version 0.5.9.2 dated January 14, 2016. Thanks, Ben Title: Re: So I just read the LN white paper... Post by: achow101 on February 04, 2018, 01:17:19 AM Right, but in the example they were talking about block sizes over 1MB, which as I understand it is a hard limit. The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through.Also, is there anything to stop everyone from connecting to just one "master-node" on the network, thus making all transactions just one hop to anyone else? I presume this master-node would need enough BTC to handle the liquidity of everyone, but that is theoretically possible. No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with.Do you know if there's a more recent version of the Lightning Network white paper? The latest I've found is version 0.5.9.2 dated January 14, 2016. There are not versions of the paper itself, but there is a much more detailed specification of the lightning network available here: https://github.com/lightningnetwork/lightning-rfc/.That specification is what implementors are using to actually implement software for the Lightning Network.Title: Re: So I just read the LN white paper... Post by: Predatron on February 04, 2018, 02:11:55 AM According to my calendar, 2017 has already passed. Gee thanks, hadn't noticed. The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through. Ah ok I see, thanks. No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with. Except for the cost of opening a new channel (which shouldn't be more than a couple dollars I think). Right? Just saying it seems like even a small fee would deter people from opening many p2p connections when you can just have one open that serves all your needs with minimal fees. Obviously LN is going to need one more layer on top as an end-user GUI/app that makes this simple so grandma can use it, just trying to visualize that. Do you know if there's a more recent version of the Lightning Network white paper? The latest I've found is version 0.5.9.2 dated January 14, 2016. Thanks for asking that, was going to myself as well. Here is the link that works to the latest protocol from achow101: https://github.com/lightningnetwork/lightning-rfc/ (https://github.com/lightningnetwork/lightning-rfc/) ----- Edit: quote attribution Title: Re: So I just read the LN white paper... Post by: nullius on February 04, 2018, 03:24:14 AM According to my calendar, 2017 has already passed. Gee thanks, hadn't noticed. Sorry, I think I overreacted here. From your further posts, it seems your questions have been sincere. I should explain. There is a steady stream of posts, often from new accounts, which desperately try to find something, anything wrong with Lightning. I sometimes see excellent posters waste hours and an ocean of virtual ink trying to keep up with frivolous arguments. And while there’s nothing wrong with a new account, insofar as all start that way, that gives no post history for me to check and see if you be that type. Thus you may understand my reflexive irritation at apparent fear, uncertainty, and doubt expressed over the urgent need for softforks which were already done. The task of pulling up the page numbers so that other readers could find context for a mish-mash of disparate quotes did not help matters. There is a very competitive market, with a hefty dose of politics involved. There are many people with an axe to grind against Bitcoin. Lightning Network is a brilliant new system with a promising future—Bitcoin’s future. I think you can see where many of us who simply want to enjoy this new technology may oft be a bit on the defensive. No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with. Except for the cost of opening a new channel (which shouldn't be more than a couple dollars I think). Right? Just saying it seems like even a small fee would deter people from opening many p2p connections when you can just have one open that serves all your needs with minimal fees. I myself tend to expect that the connectedness of nodes will roughly follow something like a Gaussian (bell-shaped) distribution. Those connected to only one node would be at one extreme; nodes connected to a very large number of others would be at the other; and most would lie somewhere in the middle. But that, as all else said on this topic, is a matter of more or less well-informed speculation. I think we will really need to wait and see how the network grows. Obviously LN is going to need one more layer on top as an end-user GUI/app that makes this simple so grandma can use it, just trying to visualize that. It’s not a matter of layers. From what I understand, there are existing userfriendly implementations which seem not so different than userfriendly GUI Bitcoin wallets; though I am not familiar with them as I should be. Anyway, I’ve seen screenshots which looked simple and slick. Time for me to catch up with what’s happening there! Title: Re: So I just read the LN white paper... Post by: Anti-Cen on February 04, 2018, 09:21:23 AM The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through. This is a major problem for Bitcoin because like i keep saying the development team are working for the wrong masters and by allowing the miners to ramp fees up to $55 and doing nothing it may have been a fatal wound to Bitcoin and the price has been going down ever since. We have 20,000 miner so the ones that don't like the changes can leave and allow the remaining miners to share around whats left and earn a honest wage. Title: Re: So I just read the LN white paper... Post by: nullius on February 04, 2018, 09:58:03 AM Thus you may understand my reflexive irritation at apparent fear, uncertainty, and doubt... There are many people with an axe to grind against Bitcoin. With apologies for the ridiculous noise, I believe this incidentally demonstrates my point: This is a major problem for Bitcoin because like i keep saying the development team are working for the wrong masters and by allowing the miners to ramp fees up to $55 and doing nothing it may have been a fatal wound to Bitcoin and the price has been going down ever since. We have 20,000 miner so the ones that don't like the changes can leave and allow the remaining miners to share around whats left and earn a honest wage. To avoid derailing the thread over a known troll, I will avoid taking that any further. Title: Re: So I just read the LN white paper... Post by: racebum on February 06, 2018, 08:40:10 PM According to my calendar, 2017 has already passed. Gee thanks, hadn't noticed. Sorry, I think I overreacted here. From your further posts, it seems your questions have been sincere. I should explain. There is a steady stream of posts, often from new accounts, which desperately try to find something, anything wrong with Lightning. I sometimes see excellent posters waste hours and an ocean of virtual ink trying to keep up with frivolous arguments. And while there’s nothing wrong with a new account, insofar as all start that way, that gives no post history for me to check and see if you be that type. i'm reasonably new to crypto but a seasoned securities trader. it took me roughly two weeks to realize this. seems like there is a LOT of hype/marketing from sockpuppet accounts, fake articles, just a hype train often in the name of market manipulation. team evil with bcash is one that definitely comes to mind has it always been like this or is it a fairly recent development with all the alt coins we now have, many with pumpNdump strats in place? Title: Re: So I just read the LN white paper... Post by: nullius on February 06, 2018, 09:09:30 PM i'm reasonably new to crypto but a seasoned securities trader. it took me roughly two weeks to realize this. seems like there is a LOT of hype/marketing from sockpuppet accounts, fake articles, just a hype train often in the name of market manipulation. team evil with bcash is one that definitely comes to mind has it always been like this or is it a fairly recent development with all the alt coins we now have, many with pumpNdump strats in place? Good question; but it’s off-topic in this thread and in this forum, so I transplanted my answer here: Fork wars are déjà vu (https://bitcointalk.org/index.php?topic=2893115.0). Please direct all further discussion of this question to that thread. |