summaryrefslogtreecommitdiff
path: root/cb/ad10ec7420098bd19196d552ee24e6458d43dc
blob: 1980c54c1c1030a937a25c7cc32b6833d03205ed (plain)
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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <voisine@gmail.com>) id 1Ytn43-0006TT-CP
	for bitcoin-development@lists.sourceforge.net;
	Sun, 17 May 2015 01:08:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.50 as permitted sender)
	client-ip=209.85.192.50; envelope-from=voisine@gmail.com;
	helo=mail-qg0-f50.google.com; 
Received: from mail-qg0-f50.google.com ([209.85.192.50])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Ytn42-0008VV-HR
	for bitcoin-development@lists.sourceforge.net;
	Sun, 17 May 2015 01:08:23 +0000
Received: by qgfa7 with SMTP id a7so20573323qgf.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 16 May 2015 18:08:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.17.103 with SMTP id b100mr9167216qkh.71.1431824897128;
	Sat, 16 May 2015 18:08:17 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Sat, 16 May 2015 18:08:16 -0700 (PDT)
In-Reply-To: <5557A9F9.1080408@phauna.org>
References: <5550D8BE.6070207@electrum.org>
	<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
	<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
	<CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
	<CACq0ZD4_zxhm=qWrP+Nr+fQER4s2R8i7qRjX4HsBWN46uOP2MA@mail.gmail.com>
	<CAPg+sBjxXe0spytGsP1BUzNZhJFDYu_yacdhTy5F+O-X8EG7NQ@mail.gmail.com>
	<CACq0ZD7qF0oEYHfQFxLMn3OOD=ibVAfE-U5YURLrtmWVMzDpgQ@mail.gmail.com>
	<CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@mail.gmail.com>
	<CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
	<5557A9F9.1080408@phauna.org>
Date: Sat, 16 May 2015 18:08:16 -0700
Message-ID: <CACq0ZD74KBt5+mfyupjvtMe9Q_CEimCedX=WmPe_cUDLydVuVQ@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Owen Gunden <ogunden@phauna.org>
Content-Type: multipart/alternative; boundary=001a1146918a5fbe8505163cb655
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(voisine[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Ytn42-0008VV-HR
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
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: Sun, 17 May 2015 01:08:23 -0000

--001a1146918a5fbe8505163cb655
Content-Type: text/plain; charset=UTF-8

On Sat, May 16, 2015 at 1:35 PM, Owen Gunden <ogunden@phauna.org> wrote:

>
> This strikes me as a leap. There are alternatives that still use bitcoin
> as the unit of value, such as sidechains, offchain, etc. To say that
> these are "not bitcoin" is misleading.
>

The only options available today and in the near future that I'm aware of
are of the centralized custody variety, which is pretty bad in my opinion,
but your point is taken.


>
> Are we sure that raising the block size is the only way to avoid
> "unpredictable transaction failure"? If so, and it's as bad as you say
> it is, aren't we screwed anyway when we inevitably start hitting the cap
> (even if it's raised 10x or 20x)? And if that's the case, then don't we
> do a disservice to users by continuing to pretend that we can make this
> problem go away?
>

When we start bumping up against the block size limit, the transactions at
the margins will experience failure in a way that will be unpredictable to
current wallet software. We can slow blockchain growth by increasing fees
alone, without introducing the additional cost of unpredictability around
confirmation failure, which when it comes down to it is just another
(extreme) way to keep usage low. Instead of fees and unpredictable
confirmation, why not just have fees alone. A single, upfront, known cost.


>
>
> On what do you base this? Gold has a very high cost of using (storage,
> transport) and yet is perhaps the most widely accepted store of value.
>

I would argue that the reason gold is not the one world global currency
that it once was is because of those costs. That's why people shifted over
time to gold backed bank notes and eventually fiat.

--001a1146918a5fbe8505163cb655
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
ure"><div dir=3D"ltr"><div dir=3D"ltr">On Sat, May 16, 2015 at 1:35 PM, Owe=
n Gunden <span dir=3D"ltr">&lt;<a href=3D"mailto:ogunden@phauna.org" target=
=3D"_blank">ogunden@phauna.org</a>&gt;</span> wrote:<br></div></div></div><=
/div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><br>
</span>This strikes me as a leap. There are alternatives that still use bit=
coin<br>
as the unit of value, such as sidechains, offchain, etc. To say that<br>
these are &quot;not bitcoin&quot; is misleading.<span class=3D""><br></span=
></blockquote><div><br></div><div>The only options available today and in t=
he near future that I&#39;m aware of are of the centralized custody variety=
, which is pretty bad in my opinion, but your point is taken.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br></span>Are we =
sure that raising the block size is the only way to avoid<br>
&quot;unpredictable transaction failure&quot;? If so, and it&#39;s as bad a=
s you say<br>
it is, aren&#39;t we screwed anyway when we inevitably start hitting the ca=
p<br>
(even if it&#39;s raised 10x or 20x)? And if that&#39;s the case, then don&=
#39;t we<br>
do a disservice to users by continuing to pretend that we can make this<br>
problem go away?<br></blockquote><div><br></div><div>When we start bumping =
up against the block size limit, the transactions at the margins will exper=
ience failure in a way that will be unpredictable to current wallet softwar=
e. We can slow blockchain growth by increasing fees alone, without introduc=
ing the additional cost of unpredictability around confirmation failure, wh=
ich when it comes down to it is just another (extreme) way to keep usage lo=
w. Instead of fees and unpredictable confirmation, why not just have fees a=
lone. A single, upfront, known cost.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span class=3D""><br>
<br>
</span>On what do you base this? Gold has a very high cost of using (storag=
e,<br>
transport) and yet is perhaps the most widely accepted store of value.<br><=
/blockquote><div><br></div><div>I would argue that the reason gold is not t=
he one world global currency that it once was is because of those costs. Th=
at&#39;s why people shifted over time to gold backed bank notes and eventua=
lly fiat.</div></div></div></div>

--001a1146918a5fbe8505163cb655--