51–60 of 141 posts
Bitcoin Cash seems to be doing just fine with on-chain scaling. There are concerns about centralization on miners with it, but in my understanding the incentives planned in the original Bitcoin paper account for that.
Earlier quoted context omitted.
2 isn't true at all, routing isn't nearly that complicated and I don't know why everyone thinks it is. Most routes are expected to be under a few hops. But regardless we will find out soon as the number of nodes on the live system is very rapidly growing. 3 doesn't really apply, as channels can be used as middle hops to rebalance. If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin…
Sounds like you're familiar with the tech, maybe you could answer a couple of questions: > If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side. Could you point me to details about how cross-channel rebalancing happens? Since lightning network channels are purely 1:1 (per th…
Lightning transactions are less like TCP packets, and more like water in a pipe. If I put 1 ml of water in a pipe full of water, 1 ml comes out the other end, but it's not the same water.
It works like this:
I can give you 1 apple, but I contractually obligate you to give 1 apple to my friend Bob, and if you don't you get penalized. You won't actually give Bob the apple I gave you, you'll give him another apple that you have, and if you don't know exactly where bob is, you could give an apple to someone else, telling them to eventually give an apple to bob "or else". (in LN, the "or else" is actually cryptographically secure pre-created transactions)
Because of this, each 1:1 channel is actually a network of 1:1 channels that can move in both ways.
In my first example, there was an unwritten implication that you would have a connection to coinbase somehow through another channel. So if I paid you 1 BTC for something, and you have a connection with coinbase (either directly, or through another channel), then if I buy from coinbase they can send that money "through" you to recharge our channel, without you really "spending" any money. And you are more than happy that happened, because now I can buy more from you directly through our channel, so you might incentivize that kind of routing by setting an extremely low, or even zero, or even NEGATIVE! fee.
>Does that imply that every channel needs to make an on-chain transaction every few days to reopen/keep the channel open?
No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want, all off the blockchain. Only when you either try to cheat, or become non-responsive do locktimes come into play.
Earlier quoted context omitted.
0-confirmation transactions were working excellent before Bitcoin Core added SegWit and other useless stuff. You don't need to wait for a new block if your signed transaction is in the mempool, and it's secure enough for small payments.
0 conf transactions are incredibly insecure. If you accept one you are putting a great deal of trust in the person paying you. Bitcoin transactions are suppose to be trustless.
Or perhaps replacing bitcoin with something that doesn't have fundamental flaws in its design. Hence why a lot of us think it has no inherent value into the future. Of course, those in on the ponzi scheme will disagree with this sentiment.
Earlier quoted context omitted.
Sounds like you're familiar with the tech, maybe you could answer a couple of questions: > If I give money to you for a good/service and drain my channel. Then I buy more Bitcoin from coinbase, coinbase can route that BTC to me through you to rebalance our channel so it is all on my side. Could you point me to details about how cross-channel rebalancing happens? Since lightning network channels are purely 1:1 (per th…
>Could you point me to details about how cross-channel rebalancing happens? Lightning transactions are less like TCP packets, and more like water in a pipe. If I put 1 ml of water in a pipe full of water, 1 ml comes out the other end, but it's not the same water. It works like this: I can give you 1 apple, but I contractually obligate you to give 1 apple to my friend Bob, and if you don't you get penalized. You won't…
Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced?
> No, locktimes only come into play in the case of non-compliance. If we have a channel with a 3-day locktime, on day 2 we can agree to re-up our lock for another 3 days (really at any time we can), we can also agree to close it right now if we want. Only when you either try to cheat, or become non-responsive do locktimes come into play.
Right, I understand that it's for non-compliance, that's why I was assuming that this part has to happen on-chain.
Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?
I understand that the premise of timelocks is that if there's a conflict, the channel collapses and the timelock buffer period allows the victim a period to claim restitution (hence needing to stay online or have a service do it on their behalf).
Earlier quoted context omitted.
See section 9.5 of the lightning whitepaper: > 9.5 Forgetting to Broadcast the Transaction in Time > If one does not broadcast a transaction at the correct time, the counterparty may steal funds. You need to be online all the time (or at least frequently enough) so that you can publish a penalty transaction if your counter party tries to steal coins from you.
This can be easily be solved by pre-signing that transaction and having a third party service broadcast that transaction if you're not online.
Lightning appears to add more problems than solutions. It has a whole bunch of critical issues. Here is a short list. 1. You need to have a computer constantly online or your counter party can easily steal all your money. This leaves you vulnerable to all sorts of attacks. 2. The lightning network works by routing payments through a network to your destination. The issue here is that the routing for the lightning net…
It's an evolving software still in pre-alpha state. But the core idea is solid and if you follow the development you'll see the strides of progress that is being done on all fronts.
To your points.
1. Depending on the options you set to your channels, you could have a window of days (or anything the two parties agree to), to act in case the other party tries to broadcast outdated TXs i.e. steal funds. Also you don't need to have a computer constantly online, you can offload the task to Watchtowers, software dedicated to do that for multiple users concurrently. (You also can have multiple Watchtowers as backups). Also, I imagine it could even be a mobile app. So this is a non-issue.
2. Routing will keep being improved but it's already pretty good and the way you present it screams FUD.
3. Currently crazy low fees aside, LN basically enables the multiplication of on-chain TXs population. I think your assumption is that the retailer will close and reopen a channel for every LN payment they receive which it makes no sense whatsoever from any point of view.
4. If by huge you mean $100 of which the fee is $0.5, sure. You can add any amount you want on an LN channel. Basically it's like a hot-wallet, e.x you can add $1500 for $0.5 fee, and casually spend it for coffees and other small expenses with lower TX fees than a satoshi (since LN supports fees at the millisatoshi = 1/1000 satoshi level).
P.S: This FUD-wave is pretty pitiful, at least get some real arguments. I hope even more people start to recognize that a lot of people have incentives to attack new tech in order to push their narratives for their altcoins or w/e.
Earlier quoted context omitted.
And if you go offline for a few hours, your peers can steal your balance (unless you entrust somebody else to monitor it for you, which has its own tradeoffs)
So basically, it turns into a ridiculously complicated bank. That requires 42tWh of power waste (and growing) to function. I'm sorry, but I'm not impressed. Let's build a solution that scales better on-chain and uses a more power efficient mining algorithm.
Bitcoin Cash seems to be doing just fine with on-chain scaling. There are concerns about centralization on miners with it, but in my understanding the incentives planned in the original Bitcoin paper account for that.
Bitcoin Cash can’t even scrape together enough transactions to form 100kb blocks. It’s rather disengenuous to say it’s scaling better when it has a fraction of the users. Furthermore, larger block size is directly related to centralization. The bcash crowd hopes people forget decentralization is important.
Earlier quoted context omitted.
0-confirmation transactions were working excellent before Bitcoin Core added SegWit and other useless stuff. You don't need to wait for a new block if your signed transaction is in the mempool, and it's secure enough for small payments.
0 conf transactions are incredibly insecure. If you accept one you are putting a great deal of trust in the person paying you. Bitcoin transactions are suppose to be trustless.