📅 Original date posted:2015-08-09
📝 Original message: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 <mark at 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" <hectorchu at 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 at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/4f288d89/attachment.html>;
Hector Chu [ARCHIVE] /
npub170…jr45x
2023-06-07 17:33:13
in reply to nevent1q…qvvs
Author Public Key
npub170s9de2ganthnna75443h70tnsn2lvmcq5365r0juk8nfa93lthqwjr45xPublished at
2023-06-07 17:33:13Event JSON
{
"id": "7f25d1c6d41e4202dacf101799123241d3719e2e563e90bd9330abbeee8a922a",
"pubkey": "f3e056e548ecd779cfbea56b1bf9eb9c26afb3780523aa0df2e58f34f4b1faee",
"created_at": 1686159193,
"kind": 1,
"tags": [
[
"e",
"c33253e971194f2c7907c001b126807e52ef4e506229e6eaa41e873f7674b436",
"",
"root"
],
[
"e",
"5f392cb2ad073b16b23cb0db62788b8bf45f6c948f5a3e56151a8dc5d1dc57a3",
"",
"reply"
],
[
"p",
"ec441dce91fdd87933cc9222deff2be2b3ac971939fd1f23aa1f9b61f898f361"
]
],
"content": "📅 Original date posted:2015-08-09\n📝 Original message:Thanks Mark.\nOk next obvious question (apologies for all of these but it seems you are\nthe authority on Lightning here). Is the Lightning system limited in the\nnumber of hops there can be in the payment channel? I am looking at the\ninitial Lightning slides presented in February and it looks like the\nlocktime decrements by 1-day along each hop. So the more hops there are the\nlonger my bitcoins are potentially locked up for?\n\nOn 9 August 2015 at 21:18, Mark Friedenbach \u003cmark at friedenbach.org\u003e wrote:\n\n\u003e Child pays for parent, and potentially future sighash modes implemented in\n\u003e the checksig2 operator lightning needs anyway which enable adding inputs to\n\u003e provide additional fee.\n\u003e On Aug 9, 2015 1:15 PM, \"Hector Chu\" \u003chectorchu at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e In the Lightning network it is assumed that the balances can always be\n\u003e\u003e settled on the blockchain if any of the parties along the channel has a\n\u003e\u003e problem. What if the fee on the settlement transactions is not high enough\n\u003e\u003e to enter the blockchain? You can't do replace-by-fee after the fact. Do the\n\u003e\u003e fees always have to assume worst case scenarios on the Bitcoin fee market?\n\u003e\u003e\n\u003e\u003e On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Tom, you appear to be misunderstanding how lightning network and\n\u003e\u003e\u003e micropayment hub-and-spoke models in general work.\n\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e But neither can Bob receive money, unless payment hub has\n\u003e\u003e\u003e advanced it to the channel (or (2) below applies). Nothing requires the\n\u003e\u003e\u003e payment hub to do this.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On the contrary the funds were advanced by the hub on the creation of\n\u003e\u003e\u003e the channel. There is no credit involved. if the funds aren't already\n\u003e\u003e\u003e available for Bob to immediately claim his balance, the payment doesn't go\n\u003e\u003e\u003e through in the first place.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e Don't turn Bitcoin into something uninteresting, please.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Consider how Bob will receive money using the Lightning Network.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Bob receives a payment by applying a contract to his local payment\n\u003e\u003e\u003e\u003e channel, increasing the amount payable to him when the channel is\n\u003e\u003e\u003e\u003e closed.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e There are two possible sources of funding for Bob's increased claim.\n\u003e\u003e\u003e\u003e They can appear alone, or in combination:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Funding Source (1)\n\u003e\u003e\u003e\u003e A deposit from Bob's payment hub\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Bob can receive funds, if his payment hub has made a deposit to the\n\u003e\u003e\u003e\u003e channel. Another name for this is \"credit\".\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e This credit has no default risk: Bob cannot just take payment hub's\n\u003e\u003e\u003e\u003e deposit. But neither can Bob receive money, unless payment hub has\n\u003e\u003e\u003e\u003e advanced it to the channel (or (2) below applies). Nothing requires the\n\u003e\u003e\u003e\u003e payment hub to do this.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e This is a 3rd-party dependency totally absent with plain old bitcoin.\n\u003e\u003e\u003e\u003e It will come with a fee and, in an important way, it is worse than the\n\u003e\u003e\u003e\u003e current banking system. If a bank will not even open an account for Bob\n\u003e\u003e\u003e\u003e today, why would a payment hub lock up hard bitcoin to allow Bob to be\n\u003e\u003e\u003e\u003e paid through a Poon-Dryja channel?\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Funding Source (2)\n\u003e\u003e\u003e\u003e Bob's previous spends\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e If Bob has previously spent from the channel, decreasing his claim on\n\u003e\u003e\u003e\u003e its funds (which he could have deposited himself), that claim can be\n\u003e\u003e\u003e\u003e re-increased.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e To avoid needing credit (1), Bob has an incentive to consolidate\n\u003e\u003e\u003e\u003e spending and income in the same payment channel, just as with today's\n\u003e\u003e\u003e\u003e banks. This is at odds with the idea that Bob will have accounts with\n\u003e\u003e\u003e\u003e many payment hubs. It is an incentive for centralization.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e With Lightning Network, Bob will need a powerful middleman to send and\n\u003e\u003e\u003e\u003e receive money effectively. *That* is uninteresting to me.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/4f288d89/attachment.html\u003e",
"sig": "35b58f773e08884cbc9c3599e0bd0d82a19262d2c48b37c22efa49c22a37363171d6df90bc4ddfa85ccf099dabd3fbd0bf1bdf0e8298d2bb0cce967f684d9002"
}