Eric Lombrozo [ARCHIVE] on Nostr: đź“… Original date posted:2015-06-28 đź“ť Original message:The Lightning network is ...
đź“… Original date posted:2015-06-28
📝 Original message:The Lightning network is essentially a contract negotiation scheme that rewards cooperation. Defection amounts to either broadcasting early or not responding to signature requests. If done right, either of these situations incurs a bigger cost to the uncooperative party than cooperation. This is why I say blockchains are like a fix to the prisoner’s dilemma.
The blockchain becomes essentially a dispute resolution mechanism and a way to anchor stuff. There’s no use case covered by the current method of “flood the entire network and confirm on blockchain” that can’t be covered by a method of “participate in a contract which guarantees me payment on the blockchain if anyone is uncooperative but which rarely requires touching the blockchain” methinks.
- Eric Lombrozo
> On Jun 28, 2015, at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>>
>>> This is probably going to sound impolite, but I think it's pertinent.
>>>
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about this
>>
>> If I don't see how switching from using the thousands of fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
>> terms of decentralization (or security, in terms of Sybil/DoS attacks),
>
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
>> to trust them to not collude with anyone to reverse your payments or destroy the trust
>> in the system in some attack. On the Lightning network, a large hub can't steal my
>> money.
>>
>> I think most people share the sentiment that trustlessness is what matters and
>> decentralization is just a synonym for trustlessness when talking about the blockchain
>> and mining, however decentralization isn't necessarily synonymous with trustlessness
>> nor is centralization synonymous with trust-requiring when you're talking about
>> something else.
>
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of explaining it.
>
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>
> The paper is on http://lightning.network
>
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>
> Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450
>
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>
> There are a couple of recorded presentation videos / podcasts from Joseph Poon.
>
> sf bitcoin dev presentation:
>
> https://www.youtube.com/watch?v=2QH5EV_Io0E
>
> epicenter bitcoin:
>
> https://www.youtube.com/watch?v=fBS_ieDwQ9k
>
> There's a related paper from Christian Decker "Duplex Micropayment Channels"
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
>
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>
>> a) Lightning Network is nothing but a whitepaper right now. We are a long
>> way from a practical implementation supported by even one wallet.
>
> maybe you want to check in on
>
> https://github.com/ElementsProject/lightning
>
> and help code it.
>
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>
> I have been saying the same thing ad-nauseam for weeks.
>
>> b) The Lightning Network paper itself says bigger blocks will be needed even
>> if (especially if!) Lightning is wildly successful.
>
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>
>
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/a8c34cc4/attachment-0001.sig>;
📝 Original message:The Lightning network is essentially a contract negotiation scheme that rewards cooperation. Defection amounts to either broadcasting early or not responding to signature requests. If done right, either of these situations incurs a bigger cost to the uncooperative party than cooperation. This is why I say blockchains are like a fix to the prisoner’s dilemma.
The blockchain becomes essentially a dispute resolution mechanism and a way to anchor stuff. There’s no use case covered by the current method of “flood the entire network and confirm on blockchain” that can’t be covered by a method of “participate in a contract which guarantees me payment on the blockchain if anyone is uncooperative but which rarely requires touching the blockchain” methinks.
- Eric Lombrozo
> On Jun 28, 2015, at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>>
>>> This is probably going to sound impolite, but I think it's pertinent.
>>>
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about this
>>
>> If I don't see how switching from using the thousands of fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
>> terms of decentralization (or security, in terms of Sybil/DoS attacks),
>
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
>> to trust them to not collude with anyone to reverse your payments or destroy the trust
>> in the system in some attack. On the Lightning network, a large hub can't steal my
>> money.
>>
>> I think most people share the sentiment that trustlessness is what matters and
>> decentralization is just a synonym for trustlessness when talking about the blockchain
>> and mining, however decentralization isn't necessarily synonymous with trustlessness
>> nor is centralization synonymous with trust-requiring when you're talking about
>> something else.
>
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of explaining it.
>
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>
> The paper is on http://lightning.network
>
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>
> Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450
>
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>
> There are a couple of recorded presentation videos / podcasts from Joseph Poon.
>
> sf bitcoin dev presentation:
>
> https://www.youtube.com/watch?v=2QH5EV_Io0E
>
> epicenter bitcoin:
>
> https://www.youtube.com/watch?v=fBS_ieDwQ9k
>
> There's a related paper from Christian Decker "Duplex Micropayment Channels"
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
>
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>
>> a) Lightning Network is nothing but a whitepaper right now. We are a long
>> way from a practical implementation supported by even one wallet.
>
> maybe you want to check in on
>
> https://github.com/ElementsProject/lightning
>
> and help code it.
>
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>
> I have been saying the same thing ad-nauseam for weeks.
>
>> b) The Lightning Network paper itself says bigger blocks will be needed even
>> if (especially if!) Lightning is wildly successful.
>
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>
>
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/a8c34cc4/attachment-0001.sig>;