cr1776
Legendary
Offline
Activity: 4256
Merit: 1313
|
|
April 03, 2017, 12:54:37 PM |
|
Except one crucial difference.
The strongest point of Bitcoin is its decentralization and this is why the scaling debate is such a big issue. Why is it that we're now ok with centralization ? If lightning leads to a few centralized hubs then we need to design it in such a way that this won't cause issues further down the road. We're taking this too lightly. I can spin up a lightning daemon on one of my existing web servers quite quickly. And I could add bitcoind to it easily if it wasn't already on a particular machine. The barriers to entry are low. The cost on an existing server is negligible, but it can bring in revenue. It may be that this increases the number of bitcoin nodes because of this. Very likely the numbers will be higher than the existing number of mining pools since p2pool hasn't been getting much love. Centralized mining is a huge concern.
|
|
|
|
goregrind
|
|
April 03, 2017, 02:52:02 PM |
|
I can spin up a lightning daemon on one of my existing web servers quite quickly. And I could add bitcoind to it easily if it wasn't already on a particular machine. The barriers to entry are low. The cost on an existing server is negligible, but it can bring in revenue. It may be that this increases the number of bitcoin nodes because of this.
Whats the point of you being able to run a lightning node if no payments will be routed through it ? Just because you can run a node doesn't mean it will be used. You will have to compete with the bigger hubs on fees and uptime. The best lightning setup is with one central hub.
|
woot?
|
|
|
cr1776
Legendary
Offline
Activity: 4256
Merit: 1313
|
|
April 03, 2017, 03:12:39 PM Last edit: April 03, 2017, 03:44:33 PM by cr1776 |
|
I can spin up a lightning daemon on one of my existing web servers quite quickly. And I could add bitcoind to it easily if it wasn't already on a particular machine. The barriers to entry are low. The cost on an existing server is negligible, but it can bring in revenue. It may be that this increases the number of bitcoin nodes because of this.
Whats the point of you being able to run a lightning node if no payments will be routed through it ? Just because you can run a node doesn't mean it will be used. You will have to compete with the bigger hubs on fees and uptime. The best lightning setup is with one central hub. What is your definition of "bigger hubs"? My cost is essentially zero, so my fees would be low (or zero if I wanted). My web servers are well connected, good memory, reasonably high CPU power, high bandwidth, low latency, extremely high uptime nodes. The web sites have been online continuously since 1993 or 1994 (depending on the web site). Why wouldn't payments be routed through any one I decided to set up? I don't see "bigger hubs" being a relevant factor - or even a useful description - as to why these "bigger hubs" would be more attractive than one I spun up on a different server. What would they offer that someone couldn't duplicate quite easily? :-)
|
|
|
|
DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
April 03, 2017, 04:43:18 PM Last edit: April 03, 2017, 05:06:02 PM by DooMAD |
|
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person. Does that not limit the utility somewhat? If it's going to help with scaling, surely it needs as many use cases as possible? If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential. All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain. Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with? It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution. It should still be available as an option, certainly, but it's not the complete answer.
|
|
|
|
goregrind
|
|
April 03, 2017, 05:21:04 PM |
|
I don't see "bigger hubs" being a relevant factor - or even a useful description - as to why these "bigger hubs" would be more attractive than one I spun up on a different server. What would they offer that someone couldn't duplicate quite easily? :-)
Suppose that everyone has an open channel to amazon. Given this everyone can pay everyone through amazon with just one channel open. You can spawn as many nodes as you want theres nothing you can do to get any payments routed through your node because X-Amazon-Y will always be the shortest path. The more connected your node is the more useful it is so new nodes have no use.
|
woot?
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
April 03, 2017, 05:30:48 PM |
|
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person. Does that not limit the utility somewhat? If it's going to help with scaling, surely it needs as many use cases as possible? If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential. All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain. Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with? It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution. It should still be available as an option, certainly, but it's not the complete answer. DooMAD, where are you getting all of this from? You often display fear and uncertainty in respect of Lightning and how it will work. Here's my suggestion to you: if you could take the time to read about how Lightning does work, you would be less afraid. It's easy to be afraid when your knowledge of a new subject is incomplete, but you seem determined not to plug the hole in your learning. And please, stop parroting this "available as an option, certainly, but it's not the complete answer" line. It only serves to show how willfully ignorant you are in respect of Lightning: no-one in favour of Lightning believes it, and so no Lightning proponent has ever expressed that desire. It's all in your imagination, you are very paranoid about the Lightning network, aren't you? Calm down, knowledge and learning are your friends, not your enemies.
|
Vires in numeris
|
|
|
DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
April 03, 2017, 06:16:42 PM |
|
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person. Does that not limit the utility somewhat? If it's going to help with scaling, surely it needs as many use cases as possible? If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential. All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain. Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with? It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution. It should still be available as an option, certainly, but it's not the complete answer. DooMAD, where are you getting all of this from? You often display fear and uncertainty in respect of Lightning and how it will work. Here's my suggestion to you: if you could take the time to read about how Lightning does work, you would be less afraid. It's easy to be afraid when your knowledge of a new subject is incomplete, but you seem determined not to plug the hole in your learning. And please, stop parroting this "available as an option, certainly, but it's not the complete answer" line. It only serves to show how willfully ignorant you are in respect of Lightning: no-one in favour of Lightning believes it, and so no Lightning proponent has ever expressed that desire. It's all in your imagination, you are very paranoid about the Lightning network, aren't you? Calm down, knowledge and learning are your friends, not your enemies. If there's uncertainty about how it will work, it probably doesn't help when you tell people there are at least five different variations of it. I take it I should be an expert on every single one before I'm permitted to ask simple questions amid your omniscient presence? Or maybe you could be a touch less condescending and just explain why it's fine to work the way achow101 describes? Maybe try not treating everyone as a hostile combatant and just have a conversation like a normal person would. That would be refreshing. If you recall, my suggestion to you was to work on that not-so-winning personality of yours. You'll find people far more receptive to a sales pitch if they actually like you. I read the original lightning whitepaper and don't recall the part where both parties are mandated to lock funds, just that the total balance had to be locked and funds could be transferred from one party to another in the multisig channel. I'm sure I'll get around to reading it again at some point, but the impression I got was that Bob could put in the total sum and that Alice could put in zero and that Bob could transfer the total to Alice. If Alice has sold an item to Bob for the amount Bob is paying Alice, why does Alice also have to lock funds up "so there is an incentive for both parties to not scam the other person" as Achow101 said?
|
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3570
Merit: 6927
Just writing some code
|
|
April 03, 2017, 07:26:06 PM |
|
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person. Does that not limit the utility somewhat? If it's going to help with scaling, surely it needs as many use cases as possible? If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential. All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain. Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with? It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution. It should still be available as an option, certainly, but it's not the complete answer. Actually, I read that part of the spec incorrectly. From the spec: The channel reserve is specified by the peer's channel-reserve-satoshis; 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially this reserve may not be met, as only one side has funds, but the protocol ensures that progress is always toward it being met, and once met it is maintained.
So you can have a channel where one party puts in 0 funds, but once that party's balance is greater than the channel-reserve-satoshis, their balance cannot go below that minimum so that they always have something to lose if they try to broadcast an older commitment.
|
|
|
|
DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
April 03, 2017, 07:41:16 PM |
|
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person. Does that not limit the utility somewhat? If it's going to help with scaling, surely it needs as many use cases as possible? If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential. All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain. Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with? It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution. It should still be available as an option, certainly, but it's not the complete answer. Actually, I read that part of the spec incorrectly. From the spec: The channel reserve is specified by the peer's channel-reserve-satoshis; 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially this reserve may not be met, as only one side has funds, but the protocol ensures that progress is always toward it being met, and once met it is maintained.
So you can have a channel where one party puts in 0 funds, but once that party's balance is greater than the channel-reserve-satoshis, their balance cannot go below that minimum so that they always have something to lose if they try to broadcast an older commitment. Thank you, achow101. That assuages my concerns. I just wish everyone could be as helpful in resolving such moments of uncertainty.
|
|
|
|
pinkflower
|
|
April 04, 2017, 06:39:31 AM |
|
The explanations have gotten way too complicated for what pawel777 was asking. Im interested in the answer too. Allow me to rephrase the question. In LN, do we need some kind of show money to open a channel? Is it possible to only open a channel now without the show money for future use if I already have the show money?
With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.Edit: You can open a channel where only one party funds it. I read this part of the spec incorrectly. See https://bitcointalk.org/index.php?topic=1848861.msg18444685#msg18444685Thank you for the the simplified post. It makes more sense to me now. Another thing I would want to know is if I open a channel to someone I dont want to have a direct channel to, can I open a channel with another user who I know has a payment channel open to the one I dont want direct channel to, without him needing to acknowledge anything? Since theres no need for the other party to have BTC locked does he still need to approve for me to connect to him or does it happen automatically?
|
|
|
|
pawel7777 (OP)
Legendary
Offline
Activity: 2660
Merit: 1647
|
|
April 04, 2017, 09:28:48 AM |
|
Thanks achow, that's all I was asking. To push the discussion a bit further, is it possible (when LN reaches its full potential) for the average user to use LN without ever performing on-chain transactions? If: 1) LN are secure and fraud resistant; 2) you don't need to engage any funds to open channel; 3) you can connect to pretty much every other user or service via hub; 4) channels can stay open indefinitely (according to the wiki page) - Then it seems perfectly plausible to be able to buy/sell for fiat and perform all kind of transactions directly on LN without ever touching the blockchain. Is there anything that enforces users (or even businesses) to settle on-chain?
|
| Duelbits | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | TRY OUR UNIQUE GAMES! ◥ DICE ◥ MINES ◥ PLINKO ◥ DUEL POKER ◥ DICE DUELS | | | | █▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ ███ ▀▀▀ | | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ KENONEW ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄█ | | 10,000x MULTIPLIER | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ |
[/tabl
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3570
Merit: 6927
Just writing some code
|
|
April 04, 2017, 01:32:39 PM |
|
Thank you for the the simplified post. It makes more sense to me now. Another thing I would want to know is if I open a channel to someone I dont want to have a direct channel to, can I open a channel with another user who I know has a payment channel open to the one I dont want direct channel to, without him needing to acknowledge anything? Since theres no need for the other party to have BTC locked does he still need to approve for me to connect to him or does it happen automatically?
Your question is a bit hard to understand. So you basically want someone to pay you without them knowing that they are paying you? Or do you mean routing payments through a hub without the hub knowing that you are routing payments through him? Either way, I don't think it is possible because each hub in the route will need to create an HTLC and change the balance of each channel involved in the payment, so they will know that a payment is being routed through them. Thanks achow, that's all I was asking. To push the discussion a bit further, is it possible (when LN reaches its full potential) for the average user to use LN without ever performing on-chain transactions? If: 1) LN are secure and fraud resistant; 2) you don't need to engage any funds to open channel; 3) you can connect to pretty much every other user or service via hub; 4) channels can stay open indefinitely (according to the wiki page) - Then it seems perfectly plausible to be able to buy/sell for fiat and perform all kind of transactions directly on LN without ever touching the blockchain. Is there anything that enforces users (or even businesses) to settle on-chain? In theory, yes. In practice, maybe not.
|
|
|
|
Andre_Goldman
Sr. Member
Offline
Activity: 322
Merit: 253
Property1of1OU
|
|
April 04, 2017, 03:11:07 PM |
|
When a LN channel is opened the total amount in a channel is sent to a 2-of-2 multisig address when each party has one of the two keys necessary to spend the BTC.
I'm so slow to get the idea... ... actually I'm thinking if it would be 'Self-enforcing protocol' ... I swear ... I even open a book in order to understand the protocol ... ps-> Are we going to stick to the Classical crypto 'Dramatis Personae'
|
Patent1number: ****-****
|
|
|
|