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

Lightning is off-block and consists of banks that charge fees and many developers are running away from Bitcoin for this reason just as fast as they can.

That didn't take a page to make the point did it now !

I would argue with you but you keep waving that moderator stick and banning people that won't agree or you remove the posts
so why not pop over to zero-hedge and try having a chat Andrew because I don't like fighting with one hand tied behind my back

Yes you have been reported for your bias moderation and should not post here if you cannot control yourself.

Im asking mostly because Peter Rizun and Andrew Stone claimed on (I think it was) Scaling Bitcoin 2017, that they had simulations of bitcoin working with 1GB, or even 1TB blocksizes, and I was curious about what and how these "simulations" were being done and how legit are those.

https://www.youtube.com/watch?v=5SJm2ep3X_M

If they can do simulations to test how the system behaves at a certain scale, I guess simulations with LN could somehow be done.

Also, I remember hearing about how you could make money by having an open channel with a certain amount of BTC (kind of PoS for BTC through LN). What are the details on this? (I guess it's the fee that you mentioned), how would the profit that you could make depending on your stake be calculated? and what are the implications of this game theory wise.

Close.  You can send and receive with a party with whom you’ve established a channel.  Well, what if you’re connected to Alice, and you want to send money to Bob?  If Alice has a channel open with Bob, then you can have Alice “route” your payment for a small fee—essentially letting Alice be a mini-Visa network for you.  These routes can be extended with multiple hops, potentially (but not necessarily) passing through large hubs; did you ever play “six degrees” style games?  Developers with a focus on privacy have also been working on onion-routing Lightning transactions; think of a Tor which routes money, instead of routing stream sockets.  (PSA: This message is posted through Tor.)

Conceptually, roughly, the reason why the system can’t be gamed is that you send Lightning payments by providing your counterparty with sufficient information to slam the channel closed with the updated balance, and claim all their money on-chain.  Cheaters can’t do much mischief, in those conditions.  That’s a sketch of the system’s general shape.  The Lightning whitepaper (PDF) provides a good technical overview of how it really works under the hood.


On-chain transactions also happen when closing the channel; that’s how final balances are settled on-chain.

You ask an excellent question about simulations.  I would appreciate more information about that, myself.

A related question is of how many global users Lightning could handle, and what tps it could reach, with the current capacity of the blockchain.  Back of the envelope, if on average a channel handles x LN transactions, and an on-chain block can hold y transactions, then the upper bound of Lightning capacity (ignoring other Bitcoin use) is about x*y/2 transactions per average 10-minute Bitcoin block.  I recently came across a neat little chart giving some numbers here; sorry, I can’t seem to find it at the moment.  The numbers looked fairly impressive, even given my desire to see orders-of-magnitude scaling of the Bitcoin ecosystem’s transactional capacity.

In that regard, I look at Lightning as a huge force multiplier for any further incremental on-chain scaling improvements.  Of course, I also hope that Lightning itself will see further scaling improvements as it matures.  If it gives big, then I’ll want bigger—well, one step at a time!


Well, spurious opening and closing of channels would simply be a matter of spamming the blockchain with spurious transactions.  We have that problem already.  I don’t immediately see how Lightning itself could be problematically spammed, given that it’s relatively low and symmetric in resource use (spam needs highly asymmetric costs), and channel participation is by voluntary mutual agreement; but I do not yet have sufficient Lightning expertise to say authoritatively that it couldn’t happen somehow.  Another interesting question I shall need to think about.  Any takers here?

Right, so the only on-chain activity that happens with LN is in the opening of a channel?

So I create a channel with 1 BTC, and now I can send instant cheap transactions out of that 1 BTC to any other open LN channel and none of that is ever recorded anywhere but it's still non gameable?

In any case, have simulation models of lightning network been performed to somehow predict what fees will be like once people all over the world are opening channels? like at what rate will people be opening channels? (from what I understand, closing a channel is irrelevant, on-chain transactions only happen when opening)

Let's say people load up $1000 bucks a month worth of BTC in a channel for the month to spend from... how do we know this will be viable and for how long?

What about spamming the LN? as in attackers opening and closing channels just like they do now to spam the network with regular spam.

Ouch.  I jumped into the middle, replying to a user who was making the same blatantly incorrect assertions about Segwit in many different threads simultaneously.  I somehow missed that this thread started with talk of “the flippening”, that link we’ve all seen, and blah blah blah about Blockstream.  Oops.  I should be more careful.

Well, OP here got useful replies; and he seems to have responded graciously enough.  For every troll, shill, and professional liar hawking a tall tale, there are n newbies being sincerely misled—for an uncomfortably large value of n.  Your advice to them is sound, savushkinTA; but how is a newbie to know that he’s tumbling down a rabbit hole, one wherein all the rabbits have been killed and eaten by poisonous snakes?

You should do your own research because asking that directly in an open forum will only result in trolls swarming all over the place.

LN transactions do not “converge within a block and get settled blockchain”.  No record of them ever reaches the blockchain.

The only LN use of the blockchain is channel maintenance transactions, “people opening and closing LN channels” as you said.

Imagine that you and I make an agreement to trade between each other, and track our trades in a private ledger.  We create an entry in a global public ledger, devoting funds to our private ledger transactions.  When we’re done and we want to settle accounts, we record our respective final balances from our private ledger in the global public ledger.  All else in the private ledger stays there, nowhere else.

Of course here, our “private ledger” is magical.  It provides each of us a unilateral recourse to force the current balances into the global ledger, in case of cheating; so there is no counterparty risk.

No, I may not have been clear with my post.

I am obviously aware that LN transactions are happening off-chain, but then these off-chain transactions converge within a block and get settled blockchain. So what im claiming is: when LN gets widespread, the rate at which these blocks get filled with off-chain transactions will be faster.
Also, people opening and closing LN channels will lead to on-chain usage too.

Eventually I don't see how this wouldn't lead to higher fees for those using on-chain.

Sure, we'll have a period of lower fees once segwit + people using LN for smaller transactions kick in, but eventually the current block space wouldn't cut it for those wanting to transact on-chain.

How far are we from that? who knows. With the fake spam it's hard to evaluate actual usage. We will just need to wait and see how the mempool looks like with a widespread LN and segwit I guess.

Not everyone is going to suddenly start using LN at the same time. Some people will suck it up and be the first people to open a channel and pay higher fees. As their transactions move off chain, the fee will decrease, and more people will then join. That will happen so on and so forth; the fee will decrease gradually as more people use LN and more people will begin using LN as it becomes more widely accepted and the barrier to entry (i.e. the funding transaction's transaction fee) decreases.

During adoption, there will be a fee in the form of the on chain transaction to stake your coins and open a channel? So basically we are asking the userbase to endure a one time "adoption fee" in the name of lowering overall fees long term.  When lightning network is operational, and transactions are largely off chain, then the on chain demand is reduced creating the fee reduction.  That seems to be the biggest barrier to adoption, the requirement for "paying a fee to reduce fees". 

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

The problem I see with the "just not use LN" argument, is that once Lightning network is widespread and we have channels all over the world filling flocks with all these microtransactions, the overall on-chain fee will be higher than ever, at some point it will be non-viable for most people to transact on-chain. For people using LN, it wouldn't matter, as their transactions will eventually go into a block mixed with the rest of LN transactions (btw, who sets the fee for an "LN-tx filled block"?) but for people that want to transact on-chain, it will be extremely expensive, unless im missing something here.

PS: Im not saying "make blocks bigger as soon as they get filled" and such nonsense are a solution, im just pointing out at how widespread LN usage could lead to unusable on-chain transactions.

You’re welcome, and thanks for the kind words!  May I suggest you try running a node on your own hardware, in your physical possession.  Core has made great effort to keep requirements accessible; no big server or datacentre backbone connection is required.  Your keys, your hardware, your security, fully decentralized and in your control.  It all just fits together.

Peaceful holidays likewise.

Aside, the mempool minimum fee is a per-node rule, not a consensus rule.  (Of course, most will go with the default.)  That makes sense, because selection amongst consensus-valid transactions is in the discretion of miners; and:


Hmmm; compare and contrast the node’s view of data it has received without any attempt at Byzantine fault-tolerant ordering, and Satoshi’s decentralized BFT database in action:


Excellent point, for obtaining a proper perspective in this particular discussion.


That’s because corporate and government mis-information services consist of misinformation professionals.  Also, disinformation professionals—a subtle distinction in the field of mass-scale lying.

After a miner mines an block, they send that block to other full nodes on the Bitcoin network. This includes miners and non-miners, there's no difference.

If the block breaks the rules, no other node will add it to their blockchain. The miner of a block can decide only on what their node accepts, not what everyone elses node accepts. Invalid blocks will be rejected


You're exploiting the way that decentralised networks are understood, and it's not very smart.

Every node has their own copy of the blockchain, there is no "the" blockchain. Bitcoin is designed to make all nodes agree on what the blockchain contains in the past, but the newest block is always in contention. So sure, a miner can add any total garbage non-conforming block to their own copy of the blockchain. And when that miner broadcasts non-compliant garbage, everyone else running the consensus rules will not add that to their version of the blockchain.

This is the beauty of the blockchain design, you're arguing as if it's still 2008 and you don't get it yet. Even the corporate and government mis-information services like Bloomberg or the BBC understand what you do not about how a blockchain works.

@ achow101: Thank you so much for your effort to cope for my questions! I very much appreciate that and have sent you a small donation. 

(Perhaps it will take quite long until the donation gets to you since I've set the fee to only 75 satoshi per bytes. My hardware wallet suggested a fee at approx. 600 s/byte which would have resultet in a much higher fee than the actual donation. By the way, at 60 s/byte I've got the error mesage "mempool min fee not met". I didn't know there is a minimum fee.)

A big thanks also to nullius for the very enlightening additions! 

By the way, I also run a Bitcoin full node on a VPS. 

Thank you for this very informative posts guys.

I wish you peaceful holidays.
Marcel

Wherefore ideas such as Malice Reactive Proof of Work Additions (MR POWA) (blogged, reblogged, discussed on this forum—theymos immediately pointed out one obvious problem).  I do not endorse that proposal; I think it’s interesting, but I have no desire to see collateral damage made of all the fine folks who invested their lives’ savings in SHA-256 hardware, and swore they would mine Bitcoin or nothing.

Thus far, Bitcoin has successfully stared down threats and active attempts to cause exactly what you describe.  Anti-Core/anti-Segwit/pro-BCH/2X/whatever watering holes have been perpetually filled with talk of “the flippening” and “killing off the legacy chain” (i.e. Bitcoin), amidst much bravado.  At one point just last month, there was a serious contest of hashpower accompanied by market manipulations which pumped-and-dumped BCH, whilst knocking down Bitcoin down 30% for all of a few days.  This was timed carefully, so that the desertion of malicious miners would hit right after a 2016th-block difficulty adjustment.  Bitcoin got kind of slow, as its hashpower plummeted; BCH supporters were jeering that Bitcoin would grind to a halt, predicting that hashpower would drop low enough that it would take months to reach the next difficulty adjustment.  That situation lasted for approximately 48 hours, until miners flocked back to where they could make the biggest profits.  The end of that battle was that Bitcoin’s hashpower stabilized, little guys who threw their money into BCH at its peak got wiped out—and Bitcoin’s exchange rate rebounded to a new all-time high within a week or so, thus giving miners all the more reason to stay with Bitcoin!

The more often Bitcoin faces such attacks, the worse it crushes its attackers; and thus, the more of a reputation it gains for being “anti-fragile” and a “honey badger” (or “money badger”).  From a public relations perspective, attempts at “flippening” away Bitcoin by draining its hashpower have made those who try such things look ridiculous.

The war isn’t over, of course; and I myself am worried about miner centralization as a matter of principle.  It is most worrisome that the world’s biggest vendor of SHA-256 ASICs is actively pro-BCH/anti-Bitcoin, and currently accepting payment in BCH instead of Bitcoin.  I want to see commodity SHA-256 ASICs sold cheaper than GPUs, and as readily available.  I think that’s probably the best solution, long-term.  Too bad I am not a hardware guy.

This has always struck me as possibly the biggest realistic attack vector for the network, the lack of emergency difficulty adjustment.   The Celeron would work great, provided you get through 2016 or so blocks, but depending on how much hashpower you've lost, that could take a prohibitively long time?   Is the solution here pretty much "we can hardfork if the time ever comes"

Miners are perfectly free to mine invalid chains, if they want.  As I’ve said elsewhere, they can mine chains of blocks filled with the output of /dev/random in lieu of transactions, if they want.  But those invalid chains will not exist to the Bitcoin network.  “What full nodes think is valid or not” absolutely does affect the blockchain:  Indeed, that determines what the blockchain is.


You have it precisely backwards:  Hashpower follows value.  In the altcoin space, I’ve been fascinated to watch as an ASIC-resistant, GPU-mined coin’s mining difficulty rises and falls immediately following fluctuation of the ratio of its value to the value of other GPU-mined coins.  Of course, many big mining farms have the switch set to occur automatically.

Bitcoin does not derive its value from mining hashpower.  Bitcoin’s value incentivizes and indeed, pays for hashpower.  As codewench says, if all the ASIC miners started churning out invalid blocks, Bitcoin could proceed with “an old Celeron”—but of course that would not happen, because miners want to make money.  Some miners such as Jihan (Bitmain) may have a long-term profit strategy driven by ulterior motives, and/or security exploits (substantially fixed by Segwit) which give them a profit advantage on a forkchain; and some may simply be fools, in the sense of bad businessmen.  But the rest will run to mine the coin with the highest value.  That is Bitcoin.  And to get their profits, the miners need their blocks to be accepted by full nodes—rejection by full nodes means no mining profits!  That’s one important part of what you keep missing.

More generally, you need to understand the purpose of mining.  I have repeatedly tried to explain that to you in these various different threads.  Look up Byzantine fault tolerance, the Byzantine generals problem, and the double-spend problem.  Start learning.


What you just said is such a long string of disconnected non sequitur that I don’t even know where to start.

The bird’s-eye overview of how Segwit actually works:  Segregated Witness transactions are serialized in such a manner that the “witness data” (public keys and signature) is dealt with separately from the input/output/script data, within the same block.  This permits witness data to be omitted in communications with old, non-upgraded nodes, and only with them.  Segwit nodes receive all transaction data, including signatures, within the same block.  None of this has anything to do with the UTXO set.

The principal purpose of segregating the witness data was to permit changing the blocksize without a hardfork.  Segwit doesn’t just change the blocksize limit:  It gets rid of the blocksize limit entirely.  Instead, Bitcoin now has a block weight limit of 4000000 bytes.  Transaction data in the old serialization format is weighted (much) more heavily; Segwit witness data is measured with much lighter “weight”, byte for byte.  The upshot is that old, non-upgraded nodes will continue seeing blocks with a maximum size of 1000000 bytes; whereas upgraded nodes can take advantage of larger blocks.  Instead of a hardfork which suddenly and totally breaks old nodes, we have a gradual transition which lets old nodes continue minimal function until their owners get around to upgrading.

That is the block capacity part of Segwit.  In my opinion, the most important parts of Segwit are that it also includes bugfixes for transaction malleability and the quadratic sighash scaling problem; and it includes a script versioning system, for forward-compatibility with future new features.  I’m not Litecoin user, but I do concur with what Charlie Lee said in favour of Segwit (as I just quoted in one of these other threads you started).  The block capacity upgrade was the smallest part of Segwit, so to speak.

Now unless you have something new to say, other than rehashing the same drastically incorrect bare assertions, or unless somebody else pipes up with something interesting, I will bow out of these threads for now so as to stop bumping them—and to not become this guy:

One thing I have learned in the altcoin space is that value follows hashpower.  A coin with high hashpower will have a higher value on average, and as a coins hashpower increases, so does the value.  If the majority of Bitcoin miners start mining InvalidCoin fork, then that is the new Bitcoin.  Could a node point out that there was an invalid transaction and that miners should stop on their chain and restart on that old block?  Sure, but remember "One CPU one Vote", if the majority of miners just continue mining InvalidCoin, then the "CPU's" have spoken.

Forks happen all the time on altcoin chains and what it does is make it so the cartel is the only one who can mine and all other miners are out of luck.  The minority miners can't convince anyone that they are actually the ones mining the real altcoin.  Value follows hashpower.