1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
Return-Path: <tomh@thinlink.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 55D79B13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 02:55:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com
[209.85.192.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0082710D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 10 Jul 2015 02:55:16 +0000 (UTC)
Received: by pdbqm3 with SMTP id qm3so31992983pdb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 09 Jul 2015 19:55:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=4fyx77CaHPBS+svsfpi0NlRG51NzwDyg6XIfBSHedA0=;
b=BaNS09LGMVaBACDC9xR3VC8Ob7AXJpUhlySXvKYLEasJHo9fzeN7yb8YoqwONmo7ze
Gh1aRg8FNzlD85OUyH/LVOLnz1aWsQVPslw4LWejBJUOdbfQfKU61vUIG/1NvWIQc9Kh
ft3VIH6rpeZzh3l5obKcoSyxPCy4RvmWTrKfDL2j3BPRLox8IT7Ppfl6d0NlEmOI/bM9
uRuaIWRXblM9EsFNIVbxH+xK09+I6vPQDfjGAKIXK02AavEm7MP+wNHJ7KyHwuY7cMKQ
90nyzL4p+6DGf5JMAcBmXw4iEmXwcc+50I2vP+e0sllwCXo4wTx8ERngnWkvZRtq2dfx
eCbw==
X-Gm-Message-State: ALoCoQnaPJ0kWrUekheVT1jSi75tQ95L3USv8IrhCW5LZIuznipEEZaMKAbCixkD/yfEXXmv8d/m
X-Received: by 10.70.43.72 with SMTP id u8mr37361804pdl.33.1436496916753;
Thu, 09 Jul 2015 19:55:16 -0700 (PDT)
Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net.
[99.8.65.117]) by smtp.googlemail.com with ESMTPSA id
w3sm1051252pdl.45.2015.07.09.19.55.14
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 09 Jul 2015 19:55:15 -0700 (PDT)
Message-ID: <559F3413.6040307@thinlink.com>
Date: Thu, 09 Jul 2015 19:55:15 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl> <CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com> <CAOoPuRarNoPwLxVqjJ_g4b6HsWJecB-oCdfEjaknKbUnKdnmEg@mail.gmail.com> <CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com> <COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl> <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com> <CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com> <CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@mail.gmail.com>
<CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
In-Reply-To: <CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2015 02:55:17 -0000
>> 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.
|
