Tom Harding [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-09 📝 Original message:>> On 6/28/2015 9:32 AM, ...

📅 Original date posted:2015-07-09
📝 Original message:>> On 6/28/2015 9:32 AM, Raystonn . wrote:
>>> Write coalescing works fine when you have multiple writes headed to
>>> the same (contiguous) location. Will lightning be useful when we
>>> have more unique transactions being sent to different addresses, and
>>> not just multiple transactions between the same sender and address?
>>> I have doubts.

> On 6/28/2015 10:29 AM, Gavin Andresen wrote:
>> Don't get me wrong, I think the Lightning Network is a fantastic idea
>> and a great experiment and will likely be used for all sorts of great
>> payment innovations (micropayments for bandwidth maybe, or maybe
>> paying workers by the hour instead of at the end of the month). But I
>> don't think it is a scaling solution for the types of payments the
>> Bitcoin network is handling today.

On 6/28/2015 11:58 AM, Adam Back wrote:
> Lightning allows Bitcoin to scale even without a block-size increase,
> and therefore considerably impacts any calculation of how much
> block-size is required. In this light you appear to have been
> attempting to push through a change without even understanding the
> alternatives or greater ecosystem.


Lightning Network (LN) does not "allow Bitcoin to scale". LN is a
bitcoin application. The properties of LN are dependent on bitcoin, but
they are distinct from bitcoin.

In particular, an under-appreciated aspect of LN is that in order for
your interactions to be consolidated and consume less blockchain space,
you must give up significant control of the money you send AND the money
you receive.

If either sender or receiver wants to record a transaction in the
blockchain immediately, there is no space savings versus bitcoin. More
blockchain space is actually, used, due to LN overhead.

If both sender and receiver are willing to delay recording in the
blockchain, then the situation is analogous to using banks. Sender's
hub pays from sender channel, to receiver channel at receiver's hub.

Neither side fully relinquishes custody of the money in their multisig
payment hub channels -- this is an improvement on traditional bank
accounts -- BUT...

- Sender is required to lock funds under his hub's signature - this is
well discussed
- Less well discussed: *to achieve any consolidation at all, receiver
must ALSO be willing to lock received funds under his hub's signature*

I'll put it another way. LN only "solves" the scaling problem if
receiver's hub has pre-commited sufficient funds to cover the receipts,
AND if receiver endures for a period of time -- directly related to the
scaling factor -- being unable to spend money received UNLESS his
payment hub signs off on his spend instructions.