summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAaron Voisine <voisine@gmail.com>2015-05-13 17:48:41 -0700
committerbitcoindev <bitcoindev@gnusha.org>2015-05-14 00:48:48 +0000
commit92c38470e9bb7181a2f0cb21bdfa978908add48f (patch)
tree41bf469d3d89cb8cc8dc1eac22f2f40d9ea38f3c
parent86ba9709b1dd0e764651e8970f16500af9ea4537 (diff)
downloadpi-bitcoindev-92c38470e9bb7181a2f0cb21bdfa978908add48f.tar.gz
pi-bitcoindev-92c38470e9bb7181a2f0cb21bdfa978908add48f.zip
Re: [Bitcoin-development] Long-term mining incentives
-rw-r--r--c0/ca6530d427784d890fea0d382625603e16243e328
1 files changed, 328 insertions, 0 deletions
diff --git a/c0/ca6530d427784d890fea0d382625603e16243e b/c0/ca6530d427784d890fea0d382625603e16243e
new file mode 100644
index 000000000..7ba5a4539
--- /dev/null
+++ b/c0/ca6530d427784d890fea0d382625603e16243e
@@ -0,0 +1,328 @@
+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--
+
+