path: root/c0/ca6530d427784d890fea0d382625603e16243e

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <voisine@gmail.com>) id 1YshKS-0007JH-Tp
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 May 2015 00:48:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.178 as permitted sender)
	client-ip=209.85.216.178; envelope-from=voisine@gmail.com;
	helo=mail-qc0-f178.google.com; 
Received: from mail-qc0-f178.google.com ([209.85.216.178])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YshKR-0003UH-FP
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 May 2015 00:48:48 +0000
Received: by qcbgy10 with SMTP id gy10so31901164qcb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 May 2015 17:48:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.144.67 with SMTP id 64mr2246655qhq.40.1431564522029;
	Wed, 13 May 2015 17:48:42 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Wed, 13 May 2015 17:48:41 -0700 (PDT)
In-Reply-To: <CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
	<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
	<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
	<CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
Date: Wed, 13 May 2015 17:48:41 -0700
Message-ID: <CACq0ZD4_zxhm=qWrP+Nr+fQER4s2R8i7qRjX4HsBWN46uOP2MA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1135380ccf0a0f0516001687
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: 1YshKR-0003UH-FP
Cc: Bitcoin Dev <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: Thu, 14 May 2015 00:48:49 -0000

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

> increasing the block size is simply not a solution, it's just kicking
> the can down the road (while reducing the incentives to deploy real
> solutions like payment channels).

Placing hard limits on blocksize is not the right solution. There are still
plenty of options to be explored to increase fees, resulting in users
voluntarily economizing on block space. It's premature to resort to
destroying the reliability of propagated transaction getting into blocks.

Child-pays-for-parent is useful, but requires the recipient to spend inputs
upon receipt, consuming even more block space. Replace-by-fee may also
help, but users won't know the fee they are getting charged until after the
fact, and it will make worse all the problems that tx malleability causes
today.

We have $3billion plus of value in this system to defend. The safe,
conservative course is to increase the block size. Miners already have an
incentive to find ways to encourage higher fees  and we can help them with
standard recommended propagation rules and hybrid priority/fee transaction
selection for blocks that increases confirmation delays for low fee
transactions.

Aaron Voisine
co-founder and CEO
breadwallet.com

On Wed, May 13, 2015 at 5:11 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

> On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
> > I think long-term the chain will not be secured purely by proof-of-work=
.
> I
> > think when the Bitcoin network was tiny running solely on people's home
> > computers proof-of-work was the right way to secure the chain, and the
> only
> > fair way to both secure the chain and distribute the coins.
> >
> > See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a  for som=
e
> > half-baked thoughts along those lines. I don't think proof-of-work is t=
he
> > last word in distributed consensus (I also don't think any alternatives
> are
> > anywhere near ready to deploy, but they might be in ten years).
>
> Or never, nobody knows at this point.
>
> > I also think it is premature to worry about what will happen in twenty =
or
> > thirty years when the block subsidy is insignificant. A lot will happen
> in
> > the next twenty years. I could spin a vision of what will secure the
> chain
> > in twenty years, but I'd put a low probability on that vision actually
> > turning out to be correct.
>
> I think is very healthy to worry about that since we know it's
> something that will happen.
> The system should work without subsidies.
>
> > That is why I keep saying Bitcoin is an experiment. But I also believe
> that
> > the incentives are correct, and there are a lot of very motivated, smar=
t,
> > hard-working people who will make it work. When you're talking about
> trying
> > to predict what will happen decades from now, I think that is the best
> you
> > can (honestly) do.
>
> Lightning payment channels may be a new idea, but payment channels are
> not, and nobody is using them.
> They are the best solution to scalability we have right now,
> increasing the block size is simply not a solution, it's just kicking
> the can down the road (while reducing the incentives to deploy real
> solutions like payment channels).
>
> Not worrying about 10 years in the future but asking people to trust
> estimates and speculations about how everything will burn in 2 years
> if we don't act right now seems pretty arbitrary to me.
> One could just as well argue that there's smart hard-working people
> that will solve those problems before they hit us.
>
> It is true that the more distant the future you're trying to predict
> is, the more difficult it is to predict it, but any threshold that
> separates "relevant worries" from "too far in the future to worry
> about it" will always be arbitrary.
> Fortunately we don't need to all share the same time horizon for what
> is worrying and what is not.
> What we need is a clear criterion for what is acceptable for a
> hardfork and a general plan to deploy them:
>
> -Do all the hardfork changes need to be uncontroversial? How do we
> define uncontroversial?
> -Should we maintain and test implementation of hardfork whises that
> seem too small to justify a hardfork on their own (ie time travel fix,
> allowing to sign inputs values...) to also deploy them at the same
> time that other more necessary hardforks?
>
> I agree that hardforks shouldn't be impossible and in that sense I'm
> glad that you started the hardfork debate, but I believe we should be
> focusing on that debate rather than the block size one.
> Once we have a clear criteria, hopefully the block size debate should
> become less noisy and more productive.
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr"><span style=3D"font-size:13px">&gt; increasing the block s=
ize is simply not a solution, it&#39;s just kicking</span><br style=3D"font=
-size:13px"><span style=3D"font-size:13px">&gt; the can down the road (whil=
e reducing the incentives to deploy real</span><br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; solutions like payment channels).</spa=
n><br><div><span style=3D"font-size:13px"><br></span></div><div>Placing har=
d limits on blocksize is not the right solution. There are still plenty of =
options to be explored to increase fees, resulting in users voluntarily eco=
nomizing on block space. It&#39;s premature to resort to destroying the rel=
iability of propagated transaction getting into blocks.</div><div><br></div=
><div>Child-pays-for-parent is useful, but requires the recipient to spend =
inputs upon receipt, consuming even more block space. Replace-by-fee may al=
so help, but users won&#39;t know the fee they are getting charged until af=
ter the fact, and it will make worse all the problems that tx malleability =
causes today.</div><div><br></div><div>We have $3billion plus of value in t=
his system to defend. The safe, conservative course is to increase the bloc=
k size. Miners already have an incentive to find ways to encourage higher f=
ees =C2=A0and we can help them with standard recommended propagation rules =
and hybrid priority/fee transaction selection for blocks that increases con=
firmation delays for low fee transactions.</div><div><br></div><div class=
=3D"gmail_extra"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div>=
<div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href=
=3D"http://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></di=
v></div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, May 13, 2015 at 5:11 PM, Jorge Tim=
=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D=
"_blank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"">On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen &lt=
;<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>&gt;=
 wrote:<br>
&gt; I think long-term the chain will not be secured purely by proof-of-wor=
k. I<br>
&gt; think when the Bitcoin network was tiny running solely on people&#39;s=
 home<br>
&gt; computers proof-of-work was the right way to secure the chain, and the=
 only<br>
&gt; fair way to both secure the chain and distribute the coins.<br>
&gt;<br>
&gt; See <a href=3D"https://gist.github.com/gavinandresen/630d4a6c24ac61444=
82a" target=3D"_blank">https://gist.github.com/gavinandresen/630d4a6c24ac61=
44482a</a>=C2=A0 for some<br>
&gt; half-baked thoughts along those lines. I don&#39;t think proof-of-work=
 is the<br>
&gt; last word in distributed consensus (I also don&#39;t think any alterna=
tives are<br>
&gt; anywhere near ready to deploy, but they might be in ten years).<br>
<br>
</span>Or never, nobody knows at this point.<br>
<span class=3D""><br>
&gt; I also think it is premature to worry about what will happen in twenty=
 or<br>
&gt; thirty years when the block subsidy is insignificant. A lot will happe=
n in<br>
&gt; the next twenty years. I could spin a vision of what will secure the c=
hain<br>
&gt; in twenty years, but I&#39;d put a low probability on that vision actu=
ally<br>
&gt; turning out to be correct.<br>
<br>
</span>I think is very healthy to worry about that since we know it&#39;s<b=
r>
something that will happen.<br>
The system should work without subsidies.<br>
<span class=3D""><br>
&gt; That is why I keep saying Bitcoin is an experiment. But I also believe=
 that<br>
&gt; the incentives are correct, and there are a lot of very motivated, sma=
rt,<br>
&gt; hard-working people who will make it work. When you&#39;re talking abo=
ut trying<br>
&gt; to predict what will happen decades from now, I think that is the best=
 you<br>
&gt; can (honestly) do.<br>
<br>
</span>Lightning payment channels may be a new idea, but payment channels a=
re<br>
not, and nobody is using them.<br>
They are the best solution to scalability we have right now,<br>
increasing the block size is simply not a solution, it&#39;s just kicking<b=
r>
the can down the road (while reducing the incentives to deploy real<br>
solutions like payment channels).<br>
<br>
Not worrying about 10 years in the future but asking people to trust<br>
estimates and speculations about how everything will burn in 2 years<br>
if we don&#39;t act right now seems pretty arbitrary to me.<br>
One could just as well argue that there&#39;s smart hard-working people<br>
that will solve those problems before they hit us.<br>
<br>
It is true that the more distant the future you&#39;re trying to predict<br=
>
is, the more difficult it is to predict it, but any threshold that<br>
separates &quot;relevant worries&quot; from &quot;too far in the future to =
worry<br>
about it&quot; will always be arbitrary.<br>
Fortunately we don&#39;t need to all share the same time horizon for what<b=
r>
is worrying and what is not.<br>
What we need is a clear criterion for what is acceptable for a<br>
hardfork and a general plan to deploy them:<br>
<br>
-Do all the hardfork changes need to be uncontroversial? How do we<br>
define uncontroversial?<br>
-Should we maintain and test implementation of hardfork whises that<br>
seem too small to justify a hardfork on their own (ie time travel fix,<br>
allowing to sign inputs values...) to also deploy them at the same<br>
time that other more necessary hardforks?<br>
<br>
I agree that hardforks shouldn&#39;t be impossible and in that sense I&#39;=
m<br>
glad that you started the hardfork debate, but I believe we should be<br>
focusing on that debate rather than the block size one.<br>
Once we have a clear criteria, hopefully the block size debate should<br>
become less noisy and more productive.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div>

--001a1135380ccf0a0f0516001687--