diff options
author | Aaron Voisine <voisine@gmail.com> | 2015-05-13 17:48:41 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-14 00:48:48 +0000 |
commit | 92c38470e9bb7181a2f0cb21bdfa978908add48f (patch) | |
tree | 41bf469d3d89cb8cc8dc1eac22f2f40d9ea38f3c | |
parent | 86ba9709b1dd0e764651e8970f16500af9ea4537 (diff) | |
download | pi-bitcoindev-92c38470e9bb7181a2f0cb21bdfa978908add48f.tar.gz pi-bitcoindev-92c38470e9bb7181a2f0cb21bdfa978908add48f.zip |
Re: [Bitcoin-development] Long-term mining incentives
-rw-r--r-- | c0/ca6530d427784d890fea0d382625603e16243e | 328 |
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">> increasing the block s= +ize is simply not a solution, it's just kicking</span><br style=3D"font= +-size:13px"><span style=3D"font-size:13px">> 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">> 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'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'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"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D= +"_blank">jtimon@jtimon.cc</a>></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 <= +;<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>>= + wrote:<br> +> I think long-term the chain will not be secured purely by proof-of-wor= +k. I<br> +> think when the Bitcoin network was tiny running solely on people's= + home<br> +> computers proof-of-work was the right way to secure the chain, and the= + only<br> +> fair way to both secure the chain and distribute the coins.<br> +><br> +> 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> +> half-baked thoughts along those lines. I don't think proof-of-work= + is the<br> +> last word in distributed consensus (I also don't think any alterna= +tives are<br> +> 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> +> I also think it is premature to worry about what will happen in twenty= + or<br> +> thirty years when the block subsidy is insignificant. A lot will happe= +n in<br> +> the next twenty years. I could spin a vision of what will secure the c= +hain<br> +> in twenty years, but I'd put a low probability on that vision actu= +ally<br> +> turning out to be correct.<br> +<br> +</span>I think is very healthy to worry about that since we know it's<b= +r> +something that will happen.<br> +The system should work without subsidies.<br> +<span class=3D""><br> +> That is why I keep saying Bitcoin is an experiment. But I also believe= + that<br> +> the incentives are correct, and there are a lot of very motivated, sma= +rt,<br> +> hard-working people who will make it work. When you're talking abo= +ut trying<br> +> to predict what will happen decades from now, I think that is the best= + you<br> +> 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'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't act right now seems pretty arbitrary to me.<br> +One could just as well argue that there'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're trying to predict<br= +> +is, the more difficult it is to predict it, but any threshold that<br> +separates "relevant worries" from "too far in the future to = +worry<br> +about it" will always be arbitrary.<br> +Fortunately we don'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't be impossible and in that sense I'= +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-- + + |