Topic: Concerns regarding SegWit + Lightning Network? - page 4. (Read 1221 times)

Full nodes can't force the miners to do anything. But full nodes (and their users) can reject anything the miners do.

In your scenario, the miners will be working away on their invalid blockchain, but the valid blockchain will stop growing. At that point all it takes in one miner doing CPU mining on an old Celeron to resume growing the valid blockchain. It may take several difficulty adjustment periods before the single miner can produce a block on schedule, but valid transactions will eventually resume. Meanwhile, the rogue miners will be unable to turn their BogusCoins into value.

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.



If this is so then why not just hash the signatures into the transaction?  Then it would be the same as we have now yet it would be a block size increase to 4mb.  Segwit signatures are not hashed into the UTXO transaction and thus cannot be verified via traditional means.  As far as I understand segwit is done to save space in the UTXO.

“Who can decide whether or not an invalid block makes it into the blockchain?”  Full nodes, that’s who.  “They [full nodes] are not part of the block confirmation process.”  Wrong.  As has been explained to you numerous times in the past few days by several different people, full nodes validate blocks and decide which fully validated chain has the highest total proof-of-work.  Miners can never force full nodes to accept anything invalid.

By analogy, BCH miners could create 8MB blocks and try to entice Bitcoin nodes to accept them.  Could they force full nodes accept those blocks?  No:  Full nodes would reject those blocks, because they are invalid blocks.  A block missing witness data (signatures) would also be invalid.  A block containing invalid transactions is also invalid.

Contra what you say, in Segwit, there is no “witness block”.  Segwit witness data is included inside the same block as the rest of the transaction data.  Signatures are always present.  “This is the whole point of segwit, so that the signature is not needed in the blockchain.”  False.  You have not even the slightest idea of what Segwit is, or how Segwit works; you’re just spouting off nonsense which you evidently make up on the spot.

Who can decide whether or not an invalid block makes it into the blockchain?  Who determines whether a block is valid or not?  Isn't it the miner who mines the next block?  They decided to mine on the last block so they say the last block was valid, no one else's say matters.  Then the only thing left is do is either the miners mine on that last persons block, or say it is invalid and remine the previous block.  No where in this process are non-mining nodes.  They are not part of the block confirmation process.

The problem with segwit is that the block will appear valid and can be validated in the blockchain without the signature being present.  This is the whole point of segwit, so that the signature is not needed in the blockchain.  In order to see if the signature is valid the miner would have to wait for the witness block before they start mining on the last block which takes extra time.

What is so difficult to understand here?  Invalid blocks are not “in the blockchain”.  The only way to add a block to the blockchain, is to mine a valid block.  Those who produce invalid blocks “never actually have any say as to what makes it into the blockchain.”

ir.hn:  You have no idea how Bitcoin works.  You have no idea how Segwit works.  Or at least, you are feigning gross ignorance.  In this thread and others, intelligent and well-informed people have attempted to educate you.  You shoot back with bare assertions and blatant misinformation.  Enough.

General point:  There is a common misconception about the role of miners.  Miners have one, only one, and exactly one job:  To provide the ordering of transactions in a Byzantine fault-tolerant manner (which in turn prevents double-spends).  That’s what miners do.  That is all miners do.  Granted, it is an important and resource-intensive job; that’s why miners get paid for it.  But that is the one and only security function of miners.

Of course, miners must validate each block they produce; if they didn’t, they would be unable to reliably produce valid blocks.  But miners are not the parties responsible for enforcing validation on the network.  Full nodes do that.  Each individual full node does that, so as to provide better security for its owner; and all full nodes collectively do that, thus providing validation security for the whole network.  Observe how here as everywhere, Bitcoin precisely aligns the individual’s selfish interest with the common good.

Full nodes do not blindly “follow the longest chain”.  They follow the chain independently validated by them which has the highest total POW.  A miner who produced invalid blocks would be wasting his hashrate, and likely risking widespread blacklisting of his IP address.  It doesn’t matter if the invalid blocks steal money from Segwit transactions, steal money from old-style transactions, create 21 billion new coins, or are filled with gibberish from /dev/random.  An invalid block is an invalid block, and shall be promptly discarded by all full nodes—period.

ir.hn is creating nonsensical non-arguments by exploiting the aforesaid misconception about the role of miners.  After all the attempts others have made to explain on this and other points, I cannot but conclude that ir.hn is maliciously spreading misinformation.  I write this post for the benefit of others.  I am uninterested in arguing with somebody who is a deliberate liar and/or so manifestly ineducable as to appear braindead.

Non-mining nodes have the power to change the rules to whatever they want - like for example changing PoW algorithm to render all legacy mining equipment useless. By default, if non-mining nodes would stop receiving blocks for a long time, the difficulty would drop low enough to mine blocks on GPU's and CPU's even without any forks - they are non-mining only because of difficulty. But this situation would usually mean that the miners have gone rogue, and since they can launch an attack on minority chain at any time, a hard fork to a new algo would be required.

Currently there are thousands of full nodes, some of them belong to big companies, but they are all peers - the protocol does not care how many BTC you have and how many transaction you do, you are connected with the network for as long as you agree with its rules.

So you are claiming bitcoin is ruled by corporations?  If that were true then wow we should let everyone know!  The reality is if the corporations don't accept the longest blockchain then, well, I guess they would have to stop using bitcoin as that would be their only recourse.  The only power non-mining nodes have is boycott, but they don't have control over bitcoin, only the miners have that, and that is by design.

Miners care because the businesses that accept Bitcoin run full nodes. Businesses will choose to run the nodes that the users are using otherwise they would not have any other customers and would thus be making no money from accepting a different chain. If no one accepts the miner's chain, then they are mining something has no value. Bitcoin is not ruled by miners.

Lets say all the non-mining full nodes reject the block.  Why would the miners care?  the miners are the one creating the blockchain.  You can cry foul all day long but unless you can vote with your hashpower on which chain is correct, you are yelling to the wind.

There are computational costs of larger blocks as they can be more computationally expensive to validate. Other considerations include the orphan rate, increased potential for fee sniping, larger attack surface for potential DoS attacks, etc.

Please stop spreading misinformation. This "attack" is not just limited to segwit; miners could have chosen to not verify signatures anyways before segwit activated. Regardless of whether segwit is activated, if a miner produces an invalid block because it contains a transaction that does not have a valid signature (again, regardless of segwit or not), other non-mining full nodes on the network will reject that block and the miner will be wasting his time and electricity.

Could you list some of these consequences? I can think of the obvious reasons like
higher bandwidth and storage requirements, but maybe you have additional reasons why
increasing the blocksize is a bad idea.

Generally, I think that some of the big companies like Coinbase and Bitpay should have
introduced Segwit addresses by now. That would really decrease the current congestion on the
blockchain. Instead they are busy integrating BCH in their respective businesses...

Segwit destruction will snowball.  One miner will figure out it is more profitable to skip verifying signatures.  Then two and three figure it out.  Then those who don't skip verifying signatures will notice their relative reward rate dropping.  Then someone will publish new bitcoin code that makes it more profitable to mine (by not verifying signatures).  The less people verify, then the less risk that skipping sig verification would result in the block getting rejected by the network.   Then more and more will join the bandwagon until those who verify signatures are a minority and at that point bitcoin gets majorly attacked and starts collapsing.

This will be the millionth time I have to respond to the same completely false and fabricated ideas. All of these "complaints" are false.

Blockstream does not "control" a majority of contributors to Bitcoin Core nor do they have any control over what goes into Bitcoin Core. The maintainers are all independent of Blockstream (MIT DCI or Chaincode labs). The only person who has commit access to Bitcoin Core that works for Blockstream is Pieter Wuille, and he has had commit access since long before he co-founded Blockstream.

The Lightning Network is not patented at all by Blockstream or anyone else. It is a free and open standard that is being developed by multiple development teams. In fact, a lot of development is led by non-Blockstream companies like Lightning Labs and ACINQ.

Patents are not really in the spirit of open source, and anyone who tells you that Blockstream or any Bitcoin Core developer has patented anything related to Bitcoin is lying to you.

In general, each user will have several open Lightning channels and that should all be handled by the client you are running. Even with several open channels, while each channel may not be able to make a single large purchase, it is possible for you to make a large payment by sending money through multiple channels.

While there may be several large hubs, it certainly does not introduce that much centralization. Hubs can't change the amount of money that you have and can't dictate anything that you do. If a hub is misbehaving, you can simply stop using them and use someone else or just not use LN.

"Zero conf" was never a feature and unconfirmed transactions were never meant to be accepted. It was already fairly easy to double spend an unconfirmed transaction without it signalling RBF. Furthermore, RBF is node policy, not a consensus rule, so even if Bitcoin Core didn't implement it, miners could still enforce RBF by running modified software. With Opt-in RBF (which is what we have now), it is very clear whether a transaction is more likely to be replaced as it explicitly signals that it can be replaced. If you are a merchant, then you can look at such transactions and hold off on accepting the payment. Since Opt-in RBF is opt in, you can just make transactions that don't opt in, and keep in mind that such transactions are still easily double spendable.

No. That is based on a fundamental misunderstanding of how Segwit works.

That does not matter. Nodes will reject invalid blocks. Nodes are enforcing the consensus rules (which includes Segwit). If a miner produces a consensus-invalid block because they failed to verify the transactions, then nodes will reject it and that block will not be added to the Bitcoin blockchain.

That is correct. Just increasing the block size limit is not a feasible long term solution. It is, effectively "kick the can down the road" and "let someone else later deal with it". Increasing the block size limit comes with a lot more consequences than you think it does and there is a whole lot more nuance to increasing Bitcoin's capacity than you think there is.

Ok, thank you. I wonder what this whole forum then is about in your opinion. I did search for answers but didn't find them yet. Yes, there is plenty of talk about LN and SegWit. But I didn't find specific information about the patent stuff, ZeroConf vs. RBF and so on.

Since you're willing to entertain nearly every poor representation of Bitcoin's development, you really should do your own research. It's not a good use of my time to respond to every newbie on the forum coming up with old objections to Bitcoin development. You're just the latest in a large number of people highlighting concerns. I don't expect it to stop.

So if you're really interested, prove it. Do your own research, and present your conclusions publicly if you like. But this is old stuff marclebit, sorry

"claims have been refuted already before, as is the case for the list of claims in your post." -> Great, this is what I am looking for. Could you perhaps provide me a link or two? Thank you.

In cases like this, I prefer not to refute things that are false or half-true.

The list of things that are false is endless, the only limit is the imagination of any person dreaming them up. It's a waste of effort to handle every false claim, especially if the claims have been refuted already before, as is the case for the list of claims in your post.

@mda: Thank you for the link. But for my understanding it doesn't really cover the aspects mentioned above.

@R_crusoe: Thank you for the tip. But is it related to any of the above issues? I don't think so.

@ Carlton Banks: Thank you, too, for your answer. "If you believe everything you've said" -> I didn't claim that any of these issues are true. It was just a brief summary of some aspects of the mentioned letter so that you (or other readers) don't necessarily need to read the original source by yourself.
I'm just doing some research to find out what is true. I would appreciate answers in the form like "No, issue d) is wrong because of ..." for example.