From: Tom Harding <tomh@thinlink•com>
To: Adam Back <adam@cypherspace•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Thu, 09 Jul 2015 19:55:15 -0700 [thread overview]
Message-ID: <559F3413.6040307@thinlink.com> (raw)
In-Reply-To: <CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
>> 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.
next prev parent reply other threads:[~2015-07-10 2:55 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-28 5:34 Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29 ` Benjamin
2015-06-28 12:37 ` Adam Back
2015-06-28 16:32 ` Raystonn .
2015-06-28 17:12 ` Mark Friedenbach
2015-06-28 17:18 ` Benjamin
2015-06-28 17:29 ` Gavin Andresen
2015-06-28 17:45 ` Mark Friedenbach
2015-06-28 17:51 ` Adam Back
2015-06-28 18:58 ` Adam Back
2015-06-28 21:05 ` Gavin Andresen
2015-06-28 21:23 ` Michael Naber
2015-06-28 22:07 ` Adam Back
2015-06-29 0:59 ` Eric Lombrozo
2015-06-29 1:13 ` Eric Lombrozo
2015-06-29 1:45 ` Andy Schroder
2015-06-30 0:42 ` Tom Harding
2015-07-10 2:55 ` Tom Harding [this message]
2015-06-28 17:53 ` Jorge Timón
2015-06-28 19:22 ` Andrew Lapp
2015-06-28 19:40 ` Benjamin
2015-06-28 12:32 ` Milly Bitcoin
-- strict thread matches above, loose matches on Subject: below --
2015-06-27 14:39 Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29 ` Randi Joseph
2015-06-27 15:32 ` Peter Todd
2015-06-27 16:19 ` Michael Naber
2015-06-27 17:20 ` Peter Todd
2015-06-27 17:26 ` Benjamin
2015-06-27 17:37 ` Peter Todd
2015-06-27 17:46 ` Benjamin
2015-06-27 17:54 ` Peter Todd
2015-06-27 17:58 ` Venzen Khaosan
2015-06-27 19:34 ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09 ` Michael Naber
2015-06-27 16:28 ` Mark Friedenbach
2015-06-27 16:37 ` Peter Todd
2015-06-27 17:25 ` Michael Naber
2015-06-27 17:34 ` Peter Todd
2015-06-27 18:02 ` Jameson Lopp
2015-06-27 18:47 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559F3413.6040307@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox