Re: [bitcoin-dev] What Lightning Is
Lightning will never catch on as it basically demands that everyone who uses it to become a speculator. Payment hubs and merchants will be at the mercy of the bitcoin price while their funds stay locked up in payment channels. This idea is a dead-end. On 10 August 2015 at 22:43, Adam Back via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: In terms of usage I think you'd more imagine a wallet that basically parks Bitcoins onto channels at all times, so long as they are routable there is no loss, and the scalability achieved thereby is strongly advantageous, and there is even the potential for users to earn fees by having their wallets participate in channel rebalancing (where hubs pay users to rebalance channels - end up with the same net position but move funds from one user-owned channel to another.) Exchange deposit, withdrawal, payments, even in-exchange trades can usefully happen in lightning for faster, cheaper more scalable transactions. Adam ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
On Aug 10, 2015 7:03 PM, odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Note that I've been in favor of going ahead with Cameron Garnham's dynamic softfork proposal right now, which can be seen at http://is.gd/DiFuRr No offence, but I think that anyone who claims a block size limit change can be done as a soft fork has some basic reading to do first. Also, please keep this thread about Lightning. -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
On Tue, Aug 11, 2015 at 05:02:40AM +0800, Anthony Towns wrote: On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote: I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what new pieces of infrastructure need to get built to make it all work. A use-case to start with: A customer starts with eleven on-chain bitcoin. They want to pay for a nice cup of tea. Sigh, kanzure on irc points out I misread this -- I read on-channel not on-chain. In that case, I think the answer is the customer doesn't pay for tea via lightning. They have to setup a channel with someone first, and to do that, they'll need a sufficiently confirmed anchor transaction, and I don't think zero confirmations would be enough for that. So: -1 Oh, how did that guy pay for tea with his phone? That's cool! Scan the QR code, yeah, where the lightning logo is Cool, I'll try it tomorrow 0 go home, open a lightning channel, sleep, look forward to getting tea tomorrow For step 0, I guess it's: 0.1 Choose a hub to connect to (could be randomly selected) 0.2 Choose an amount to fund the channel (0.5 btc would be a lot) 0.3 Are you sure? 0.4 [wait briefly while counterparty signs] 0.5 [wait for 10 confirmations?] I don't think it's at all clear how 0.1 works in practice yet -- routing has barely been spitballed, and without knowing how routing works, it's hard to say who to connect to. Hard to say how much to put in in step 0.2 too -- if it takes a while to refresh funds in a channel (you have to do a blockchain txn eg), then that you should put more in; if you have multiple channels for whatever reason, maybe you can put less in each. The Are you sure? might require some legal TCs in practice. You need to have some realtime communication with your channel counterpary when creating the anchor; but that should be fairly quick. You also need to establish some random numbers and keys, but those could be done in advance. I think you (or your counterparty) will want to wait for a few confirmations before your channel is actually usable. So I think it'll take over an hour for a channel to be open in even the best case. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
In terms of usage I think you'd more imagine a wallet that basically parks Bitcoins onto channels at all times, so long as they are routable there is no loss, and the scalability achieved thereby is strongly advantageous, and there is even the potential for users to earn fees by having their wallets participate in channel rebalancing (where hubs pay users to rebalance channels - end up with the same net position but move funds from one user-owned channel to another.) Exchange deposit, withdrawal, payments, even in-exchange trades can usefully happen in lightning for faster, cheaper more scalable transactions. Adam ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote: I thought it's worth mentioning there is a specific Lightning Network development mailing list at http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already some pretty interesting explanations in the archives. While that is interesting, and I'll surely check it out, I think this list should get a good idea of what the limitations are. Where does it NOT make sense to use LN, where would it be better to put the transaction directly on the blockchain? This is what I'd like to know. Gavins usecase is useful, I'm also wondering about remittances and allowing international payments and global economy (company in Nairobi buys stock from company in Spain). -- Thomas Zander ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] What Lightning Is
On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote: Don't turn Bitcoin into something uninteresting, please. Consider how Bob will receive money using the Lightning Network. Bob receives a payment by applying a contract to his local payment channel, increasing the amount payable to him when the channel is closed. There are two possible sources of funding for Bob's increased claim. They can appear alone, or in combination: Funding Source (1) A deposit from Bob's payment hub Bob can receive funds, if his payment hub has made a deposit to the channel. Another name for this is credit. This credit has no default risk: Bob cannot just take payment hub's deposit. But neither can Bob receive money, unless payment hub has advanced it to the channel (or (2) below applies). Nothing requires the payment hub to do this. This is a 3rd-party dependency totally absent with plain old bitcoin. It will come with a fee and, in an important way, it is worse than the current banking system. If a bank will not even open an account for Bob today, why would a payment hub lock up hard bitcoin to allow Bob to be paid through a Poon-Dryja channel? Funding Source (2) Bob's previous spends If Bob has previously spent from the channel, decreasing his claim on its funds (which he could have deposited himself), that claim can be re-increased. To avoid needing credit (1), Bob has an incentive to consolidate spending and income in the same payment channel, just as with today's banks. This is at odds with the idea that Bob will have accounts with many payment hubs. It is an incentive for centralization. With Lightning Network, Bob will need a powerful middleman to send and receive money effectively. *That* is uninteresting to me. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Tom, you appear to be misunderstanding how lightning network and micropayment hub-and-spoke models in general work. But neither can Bob receive money, unless payment hub has advanced it to the channel (or (2) below applies). Nothing requires the payment hub to do this. On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. if the funds aren't already available for Bob to immediately claim his balance, the payment doesn't go through in the first place. On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote: Don't turn Bitcoin into something uninteresting, please. Consider how Bob will receive money using the Lightning Network. Bob receives a payment by applying a contract to his local payment channel, increasing the amount payable to him when the channel is closed. There are two possible sources of funding for Bob's increased claim. They can appear alone, or in combination: Funding Source (1) A deposit from Bob's payment hub Bob can receive funds, if his payment hub has made a deposit to the channel. Another name for this is credit. This credit has no default risk: Bob cannot just take payment hub's deposit. But neither can Bob receive money, unless payment hub has advanced it to the channel (or (2) below applies). Nothing requires the payment hub to do this. This is a 3rd-party dependency totally absent with plain old bitcoin. It will come with a fee and, in an important way, it is worse than the current banking system. If a bank will not even open an account for Bob today, why would a payment hub lock up hard bitcoin to allow Bob to be paid through a Poon-Dryja channel? Funding Source (2) Bob's previous spends If Bob has previously spent from the channel, decreasing his claim on its funds (which he could have deposited himself), that claim can be re-increased. To avoid needing credit (1), Bob has an incentive to consolidate spending and income in the same payment channel, just as with today's banks. This is at odds with the idea that Bob will have accounts with many payment hubs. It is an incentive for centralization. With Lightning Network, Bob will need a powerful middleman to send and receive money effectively. *That* is uninteresting to me. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
I'm glad Tom is bringing these points up. There seems to be an assumption by many that LN will be automatically awesome by virtue of it being technically feasible with having considered whether it is economically feasible or desirable. So much stock has been placed in LN as the solution to the block size debate, yet it could turn out that it sucks in practice. Then what? On Aug 9, 2015 5:27 PM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Aug 9, 2015 11:54 AM, Mark Friedenbach m...@friedenbach.org wrote: On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. That's a chuckle. As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it. We'll see whether hubs assess a fee for depositing funds, whether the fee depends on the amount deposited, and whether it depends on the amount of time it stays there. I predict all of the above. There is a name for these kinds of fees. Can you guess it? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
While we're on the subject of payment hubs / lightning network... I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what new pieces of infrastructure need to get built to make it all work. A use-case to start with: A customer starts with eleven on-chain bitcoin. They want to pay for a nice cup of tea. Walk me through what happens before/during/after the transaction, assuming I have a lightning-enabled wallet on my iPhone and the tea shop has a lightning-enabled cash register. Assume neither the customer nor the tea shop are technically sophisticated -- assume the customer is using an SPV wallet and the tea shop is using a service similar to Bitpay. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
I suspect there is some amount of confusion here on terms. The hub is essentially swapping funds between payment channels. The hub's entire business is centered around having payment channels open with other hubs/users. If the hub requires user funds to open these channels... then the users have no reason to pay the hub anything in fees. A hub that doesn't use it's own funds to open payment channels to other hubs/merchants is useless. On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote: On Aug 9, 2015 11:54 AM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. That's a chuckle. As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it. We'll see whether hubs assess a fee for depositing funds, whether the fee depends on the amount deposited, and whether it depends on the amount of time it stays there. I predict all of the above. There is a name for these kinds of fees. Can you guess it? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Thanks Mark. Ok next obvious question (apologies for all of these but it seems you are the authority on Lightning here). Is the Lightning system limited in the number of hops there can be in the payment channel? I am looking at the initial Lightning slides presented in February and it looks like the locktime decrements by 1-day along each hop. So the more hops there are the longer my bitcoins are potentially locked up for? On 9 August 2015 at 21:18, Mark Friedenbach m...@friedenbach.org wrote: Child pays for parent, and potentially future sighash modes implemented in the checksig2 operator lightning needs anyway which enable adding inputs to provide additional fee. On Aug 9, 2015 1:15 PM, Hector Chu hector...@gmail.com wrote: In the Lightning network it is assumed that the balances can always be settled on the blockchain if any of the parties along the channel has a problem. What if the fee on the settlement transactions is not high enough to enter the blockchain? You can't do replace-by-fee after the fact. Do the fees always have to assume worst case scenarios on the Bitcoin fee market? On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Tom, you appear to be misunderstanding how lightning network and micropayment hub-and-spoke models in general work. But neither can Bob receive money, unless payment hub has advanced it to the channel (or (2) below applies). Nothing requires the payment hub to do this. On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. if the funds aren't already available for Bob to immediately claim his balance, the payment doesn't go through in the first place. On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote: Don't turn Bitcoin into something uninteresting, please. Consider how Bob will receive money using the Lightning Network. Bob receives a payment by applying a contract to his local payment channel, increasing the amount payable to him when the channel is closed. There are two possible sources of funding for Bob's increased claim. They can appear alone, or in combination: Funding Source (1) A deposit from Bob's payment hub Bob can receive funds, if his payment hub has made a deposit to the channel. Another name for this is credit. This credit has no default risk: Bob cannot just take payment hub's deposit. But neither can Bob receive money, unless payment hub has advanced it to the channel (or (2) below applies). Nothing requires the payment hub to do this. This is a 3rd-party dependency totally absent with plain old bitcoin. It will come with a fee and, in an important way, it is worse than the current banking system. If a bank will not even open an account for Bob today, why would a payment hub lock up hard bitcoin to allow Bob to be paid through a Poon-Dryja channel? Funding Source (2) Bob's previous spends If Bob has previously spent from the channel, decreasing his claim on its funds (which he could have deposited himself), that claim can be re-increased. To avoid needing credit (1), Bob has an incentive to consolidate spending and income in the same payment channel, just as with today's banks. This is at odds with the idea that Bob will have accounts with many payment hubs. It is an incentive for centralization. With Lightning Network, Bob will need a powerful middleman to send and receive money effectively. *That* is uninteresting to me. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Right, you've stated a bunch of facts, but how does it answer my concerns of the exploding cost of the network the more interconnected it it? On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I suspect there is some amount of confusion here on terms. The hub is essentially swapping funds between payment channels. The hub's entire business is centered around having payment channels open with other hubs/users. If the hub requires user funds to open these channels... then the users have no reason to pay the hub anything in fees. A hub that doesn't use it's own funds to open payment channels to other hubs/merchants is useless. On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote: On Aug 9, 2015 11:54 AM, Mark Friedenbach m...@friedenbach.org wrote: On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. That's a chuckle. As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it. We'll see whether hubs assess a fee for depositing funds, whether the fee depends on the amount deposited, and whether it depends on the amount of time it stays there. I predict all of the above. There is a name for these kinds of fees. Can you guess it? ___ bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
I thought it's worth mentioning there is a specific Lightning Network development mailing list at http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already some pretty interesting explanations in the archives. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
That was not in reply to you. On 08/09/2015 03:09 PM, Hector Chu wrote: Right, you've stated a bunch of facts, but how does it answer my concerns of the exploding cost of the network the more interconnected it it? On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I suspect there is some amount of confusion here on terms. The hub is essentially swapping funds between payment channels. The hub's entire business is centered around having payment channels open with other hubs/users. If the hub requires user funds to open these channels... then the users have no reason to pay the hub anything in fees. A hub that doesn't use it's own funds to open payment channels to other hubs/merchants is useless. On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote: On Aug 9, 2015 11:54 AM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. That's a chuckle. As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it. We'll see whether hubs assess a fee for depositing funds, whether the fee depends on the amount deposited, and whether it depends on the amount of time it stays there. I predict all of the above. There is a name for these kinds of fees. Can you guess it? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Hi Gavin, On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote: I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what new pieces of infrastructure need to get built to make it all work. I'm writing a (hopefully more accessible) summary on Lightning currently. It might not go into too much detail with infrastructure, but is a bit more UX focused. A customer starts with eleven on-chain bitcoin. They want to pay for a nice cup of tea. Walk me through what happens before/during/after the transaction, assuming I have a lightning-enabled wallet on my iPhone and the tea shop has a lightning-enabled cash register. Assume neither the customer nor the tea shop are technically sophisticated -- assume the customer is using an SPV wallet and the tea shop is using a service similar to Bitpay. It's a bit of a tangent, but I see it as necessary that all Lightning services/wallets support on-chain payments for a multitude of reasons, including usability and long-term security/fungibility. For that reason, the UX flow for payment after channels are established should not be significantly different than Payment Protocol based payment flows (with the only exception being a possible additional fee dialog box/alert when the fees will be higher than expected/on-chain). -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
On 8/9/2015 2:45 PM, Hector Chu wrote: Tom, my understanding is that the money that is debited from a payment hub is simultaneously credited from either another payment hub or the person making the payment, so that the net funds flow at a payment hub always sums to zero. That describes the steady-state dynamics. I refer to the hub funding required to initiate and maintain the ability to receive payments. If Bob opens a channel at his hub, doesn't use it for spending, and Alice sends 1 BTC to the channel, her payment can only be applied if the hub has funded the channel with at least 1 BTC. Yes, the hub receives an offsetting payment (from Alice, ultimately) in another channel. But to make this work, it must subject 1 BTC to shared control with Bob and forfeit the use of that money for other purposes (opportunity cost) while the channel is open. The opportunity cost is likened to gold lease rates in the LN paper. I would be surprised if the rates charged to consumers for BTC credit aren't much closer to today's BTC borrowing rates. We'll see. Burying this cost in general fees might not work very well, because different Bobs may want different maximum payment amounts, and channels open for different lengths of time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Hi Hector, On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote: Is the Lightning system limited in the number of hops there can be in the payment channel? I am looking at the initial Lightning slides presented in February and it looks like the locktime decrements by 1-day along each hop. So the more hops there are the longer my bitcoins are potentially locked up for? The hops are limited to the time-value which the sender wishes to pay and the minimum acceptable timeout between each hop. It should be relatively cheap if you game it out, though (I don't forsee me opening a 1 BTC channel and being able to make $5 per month...) 1-day is used as a convenience. However, the time between hops should be somewhat long, as the intermediate steps can be extended further when you want to offload the HTLCs to others who have a channel open with both counterparties. E.g. Alice sends a payment to Dave through Bob and Carol. Bob has a channel with Carol and has an HTLC with it, but that channel seems to be used a lot. Erin has a relationship to both Bob and Carol, she can offload the payment so that the payment actually goes to A-B-E-C-D. B-C is now completely clear. On Aug 9, 2015 1:15 PM, Hector Chu hector...@gmail.com wrote: In the Lightning network it is assumed that the balances can always be settled on the blockchain if any of the parties along the channel has a problem. What if the fee on the settlement transactions is not high enough to enter the blockchain? You can't do replace-by-fee after the fact. Do the fees always have to assume worst case scenarios on the Bitcoin fee market? How do you send coins if you wanted to send funds below the current IsStandard value? It should be no different. If your wallet can't send funds below the IsStandard value on-chain today, then I don't think it should be able to to in the future, right? If you send funds *at* the minimum IsStandard value today, you're probably paying really high fees, this is a problem that exists today. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
