Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-09 📝 Original message:Tom, you appear to be ...
📅 Original date posted:2015-08-09
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/8ce749f3/attachment-0001.html>;
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/8ce749f3/attachment-0001.html>;