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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1YzTOt-0000x4-FX
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 17:21:23 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.197])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YzTOs-0007EY-95
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 17:21:23 +0000
Received: from mail-qc0-f173.google.com ([209.85.216.173]) by
mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
0MSsEt-1YYLm51YST-00RpIN for
<bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 19:21:16 +0200
Received: by qcxw10 with SMTP id w10so50245083qcx.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 10:21:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.22.130 with SMTP id 2mr40617158qkw.45.1433179275763; Mon,
01 Jun 2015 10:21:15 -0700 (PDT)
Received: by 10.96.112.164 with HTTP; Mon, 1 Jun 2015 10:21:15 -0700 (PDT)
In-Reply-To: <CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com>
References: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>
<CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com>
Date: Mon, 1 Jun 2015 18:21:15 +0100
Message-ID: <CALqxMTE57mEiG7VuEDSfBDswCeYPWRoa1DEY9iL=P0xLFu8YCA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:/E4DyeCq8RoYPaYlmnbTeTZKISdqqJtOxq9kXH0HMKbEt74M7mG
0aI2tZRnghA2r7wRns+Kj/Wl8g0EdBhTkxSTgE3S+JR0wqNBTbLkM10fUdRuz1AFL7BIa+X
jIM2EVGMpqMiJN/xjeZ9JOpMz3sw19bIXHsdDmOeP0uoW5tFkudlbjelj1kHYxX/wYDYn3D
2vK9TXfWlpK1iqSncEQfg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:DyRQJMRsDqM=:OQ3uAFd2Fz5NJ+g1E8hpcE
pRn1HIhszYGjDtc8YLoFvnKkHQisjNktg0QR+1oNe0j93acpuDw45mwkmV/alTuui6c2KGEVq
E9fY6Hb6nXfra0n5e+hUU2NccrYYlfntpxTJL2Fq4kQXOFn/0fQCDl56A1BHuX4BWC+m1Bhpf
fo/D9kM3PZS9BcE3yQ2wINkTNOh6f5HG5GBvyg1SAwF/iUkb/6I9LrVcv65wJ1dyMyhC2dwnq
fa9QNIjBtXX6t7yyiRN9HTbEDuVP7geK9m2JknoQMFl7M0zi3H33OeaOlL8P7tYkb2HDXp54R
0MtyDzT3C7dgHwoqOyHn+KPV+aVCdF2zTCvTB0+B7HUpTQ+OxxkbJ6pFj+23jyprsavQwlyu+
RJhUUXchsf+XNmiEfH+SXTKGNHhjQPoQ9G6ZAFfXWETMMTivZHBrIPqmzXHoESM+X4ig0b53P
TTnghl1YxRauUTkR50vZ5f/MoEb0tC3r8Qt/4kXSGaSGXCoJpGwuN+Cp5D7Blzzbpw73NKfJ6
sRzR7JA3cFvRER+xyMRe3Ntqp8Z7rc5iLQ8ACCUcp/Td1YPYtvEdjt6rRspF/U2X8wDX6XgCU
kFsuph5HSKXgU/wSex1l8oR2Q7OTUKLyRtSxiYvXT6EQkY2dMBLrQ38FL484UoBOfPRRlvOha
W8kj5SrJj6lJUMeMm7p74vLdfSsxrJzxvq4wbiq6ECeBJ7w==
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.197 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1YzTOs-0007EY-95
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension
blocks)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 17:21:23 -0000
Mike wrote:
>> Businesses who are keen to
>> have more transactions, would make it their problem to implement in
>> their wallet, or ask the wallet vendor/maintainer they're working with
>> to do it. Nothing breaks if they dont use it.
>
>
> I don't see how this is the case. If an exchange supports extension blocks
> and I withdraw from that to a wallet that doesn't, the money will never
> arrive from my perspective. Yet the exchange will claim they sent it and
> they will wash their hands of the matter. Disaster.
To be clear in case you are missing part of the mechanism.: it is
forward and backwards compatible meaning a 1MB address can receive
payments from an 8MB address (at reduced security if it has software
that doesnt understand it) and a 1MB address can pay an 8MB address by
paying to an OP_TRUE that has meaning to the extension block nodes.
A 1MB client wont even understand the difference between a 1MB and 8MB
out payment. An 8MB client will understand and pay 1MB addresses in a
different way (moving the coin back to the 1MB chain).
So its opt-in and incrementally deployable. Exchanges could encourage
their users to use wallets that support 8MB blocks, eg by charging a
fee for 1MB transactions. If 1MB blocks experience significant fee
pressure, this will be persuasive. Or they could chose not to and eat
the cost. This is all normal market adoption of a new cheaper
technical option (in this case with a tradeoff of reduced
security/more centralisation for those opting in to it).
>> Because the more complex one is safer, more flexible, more future
>> proof and better for decentralisation
>
> I disagree with all of those points. I find Lightning/Stroem etc to be more
> dangerous, less flexible, and worse for decentralisation. I explain why
> here:
Extension blocks & lightning are unrelated things.
While I understand the need for being practical, there is IMO, amongst
engineering maxims something as far as being too pragmatic,
dangerously pragmatic even. We cant do stuff in bitcoin that has bad
carry costs, nor throw out the baby with the bathwater.
The situation is just that we are facing a security vs volume tradeoff
and different people will have different requirements and comfort
zones. If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum. What I
am proposing empowers you to do experiments in that direction without
getting into a requirements conflict with people who value more
strongly the bitcoin properties arising from it being robustly
decentralised.
I am not sure personally where the blocksize discussion comes out - if
it stays as is for a year, in a wait and see, reduce spam, see
fee-pressure take effect as it has before, work on improving improve
decentralisation metrics, relay latency, and do a blocksize increment
to kick the can if-and-when it becomes necessary and in the mean-time
try to do something more long-term ambitious about scale rather than
volume. Bitcoin without scale improvements probably wont get the
volume people would like. So scale is more important than volume; and
security (decentralisation) is important too. To the extreme analogy
we could fix scale tomorrow by throwing up a single high perf
database, but then we'd break the security properties arising from
decentralisation. We should improve both within an approximately safe
envelope IMO.
Adam
|
