Earlier quoted context omitted.
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.
if you have to trust third parties, whats the point?
Bitcoin has a huge scaling problem–Lightning could be the solution
61–70 of 141 posts
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#62I was wondering recently, why Bitcoin is even needed for a Lightning-like network? Just settle the channels in cash (or even bank transfers), it won't be any more traceable than Bitcoin. Moreover, there is a successful precedent of such network: https://en.wikipedia.org/wiki/Hawala Seems like a large enough "overlay network" over cache reserves and bank accounts can be made barely traceable and pretty efficient.
Lightning's core innovation is the use of the Bitcoin blockchain as a cryptographic backstop for payment channels. If the other party in a payment channel stops cooperating, you can broadcast the current commitment transaction to the blockchain, which effectively refunds the current balance back to each party. There's a similar mechanism for enforcing the hashed time lock contracts that make Lightning payment chains…
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#63Earlier quoted context omitted.
2. Where is the evidence of this? Sure, routing can be easy and short if it's centralized and the number of hops is small. But, if it's centralized, then what's the point of using Bitcoin? Where is this mystical routing algorithm that will work in the presence of constant capacity changes over a decentralized network? 3. The issue here is that the flow for all channels across the entire network needs to be about bala…
Lightning uses the same routing algorithm as tor — it’s an onion router. It has the added benefit of no one in the network knowing where transactions are from or whom they’re to. With regards to channel capacity — fees in lightning are proportional to the amount of the transaction. If you are sending a transaction which consumes a large amount of capacity, you pay a high fee. Note how this is a fundamental difference…
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#64Earlier quoted context omitted.
>Bitcoin Cash seems to be doing just fine with on-chain scaling Has it though? AFAIK it still has lower transaction volume than bitcoin.
There were some episodes in the latest months of very intense traffic (either an “attack” or someone stress testing) and Bitcoin Cash has endured it just fine. Let’s see how it works out when adoption grows. If it doesn’t scale, then the timing for off-chain scaling will be more appropriate.
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#65Earlier 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.
Sure, but there’s services you can outsource that to. Furthermore, if you only use lightning for sending payments (the majority of us) then publishing an earlier version of the channel benefits you!
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#66For example: « That means you can use a single payment channel to make lots of payments to many different people—all while generating just a handful of transactions on the underlying blockchain.»
I am no bitcoin expert, but AFAIK the bitcoin network can currently process in the order of tens of transactions per second, and that is a low number compared to the 50-100k transactions per second that VISA et similia are currently capable of processing.
So, many are "lots"? How many are "a handful"?
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#67Bitcoin 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 transactions are confirming for less than 5 Sat/b since the spamming stopped. http://core.jochen-hoenicke.de/queue/#24h
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#68Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#69Earlier quoted context omitted.
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.
They are. Some context might help: when it originally launched, Bitcoin Cash was slower and more unusable than Bitcoin if you needed even a single confirmation, because the forker fucked up the difficulty adjustment algorithm so badly that blocks were every hour or so most of the time. So the Bitcoin Cash community pushed the idea that zero-confirmation transactions were safe there, unlike on the evil SegwitCoin chai…
Re: Bitcoin has a huge scaling problem–Lightning could be the solution
#70Earlier quoted context omitted.
>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…
Sorry, I didn't mean in layman metaphors but the actual mechanics. (I am technical and fairly familiar with Bitcoin, I'm just having a hard time convincing myself from reading the Lightning whitepaper and I'm hoping to find some alternative explanations that are clearer.) Like what kind of transactions/operations need to happen between nodes for two channels to get rebalanced? > No, locktimes only come into play in t…
So "rebalancing" is kind of a word for a side-effect of normal routing.
It's all based on fees. So if you have a channel with "the network" (either through 1 or more channels to a big hub, or some other way), and I have a single channel with you, then another channel with "the network".
Our channel started off with .5 BTC from each of us. Then I paid you .4 BTC so the channels are:
You: .9 BTC, Me: .1 BTC.
Nodes broadcast fees, so you would broadcast that for me to send money from me to you (either directly, or through a "hop"), it will cost 20 satoshis. But you can also broadcast that for someone to send money the opposite direction (from you to me), it's free right now. Someone that wanted to pay a 3rd party unrelated to us would try to find a route that went from you to me then to the rest of the network.
So really "rebalancing" is just incentivizing someone else to rebalance your channel by exploiting their selfishness and want of low transaction fees and to include you as part of a hop. Fees can even go negative, which would make it super beneficial for someone else to include your channel in their transaction (even if it's out of the way, or doesn't serve any real purpose) to get a bit of money from it!
Who actually broadcasts the fees can be found by looking through popular node software (each node only broadcasts one direction of the channel, and I don't remember which it is right now), as well as the broadcast system (which I genuinely don't know off the top of my head).
>Aren't timelocks enforced on chain? How can we agree to extend our timelock without committing that agreement to the blockchain?
Yes and no. They are "enforced" on chain in the sense that they can't be accepted into a block until a specific block number. But they aren't ever broadcast to anyone else until you are ready to use them. In essence all LN transactions are created, but kept secret until ready to be used. The whole concept of LN relies on the fact that if we make a transaction but never broadcast it, did it really happen? If you and me agree to make a new transaction saying "this expires in 3 days from right now", technically the original transaction is now valid once 3 days pass from it, but if you try to broadcast the tx that forces all the money to you, I can broadcast the transaction that proves that we did something else after that (our second "update the locktime"), and then gives all the money to me.
Every time we do something to transact, we also create a set of transactions that serve as proof that the old transactions are in fact "old" and shouldn't be accepted, and if anyone tries to broadcast them, we can invalidate them (and enforce a "penalty" to dissuade anyone from trying to cheat).