<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body bgcolor="#FFFFFF" fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<div>There is alot going on in this thread so I'll reply more broadly.</div>
<div><br>
</div>
<div> The original post and the assorted limit proposals---lead me to something I think is worth reiterating: assuming Bitcoin adoption continues to grow at similar or accelerating rates, then eventually the mempool is going to be filled with thousands
of txs at all times whether block limits are 1MB or 16MB. This isn't to say that increasing the limit isn't a worthwhile change, but rather, that if we are going to change the block limit then it should be done with the intent to achieve a fee rate that maximize
surplus (and minimize burden) to both users and miners. Even with implementation of a <span style="font-size: 13.3333px;">a payment channels system</span><span style="font-size: 10pt;">, the pool will likely be faced with having a mountain of txs. Thus the
block limit should be optimized in such that social welfare is optimized. </span></div>
<div> Optimized is likely not keeping the limit at 1MB; this maximizes benefit to miners (producers) while minimizing users' surplus (consumer). 'Unlimited' blocks are purely the reverse; maximizing user surplus while minimizing miners' (with the added bonus
of creating blocks that will put technical/hardware strain on the network). So perhaps pursue something in-between that actually optimizes based on a social welfare formula---not just an arbitrary auto-adjusting limit like the other proposals I've seen. Feel
free to poke holes in this or e-mail me if curious.</div>
<div><br>
</div>
<div> Finally, with respect to getting node counts up, didn't luke-jr or someone come up with an idea of paying nodes a reward by scraping dust and pooling it into a fund of sorts? Was this not possible/feasible? Perhaps at least in the near and medium
term something outside of protocol changes could be done to pay a reward to nodes. Even if this is done via voluntary donation system, it may be useful for the purposes of seeing how people respond to incentives and working out an elasticity measure of sorts
for running a node. </div>
<div><br>
</div>
<div><br>
</div>
<div>Ryan J. Martin</div>
<div>rjmarti2@millersville.edu</div>
<div>(on freenode: tunafizz )</div>
<div><br>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF572660" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>From:</b> bitcoin-dev-bounces@lists.linuxfoundation.org [bitcoin-dev-bounces@lists.linuxfoundation.org] on behalf of Aymeric Vitte via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org]<br>
<b>Sent:</b> Wednesday, March 29, 2017 6:33 PM<br>
<b>To:</b> Jared Lee Richardson; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Hard fork proposal from last week's meeting<br>
</font><br>
</div>
<div></div>
<div>
<p>I have heard such theory before, it's a complete mistake to think that others would run full nodes to protect their business and then yours, unless it is proven that they are decentralized and independent</p>
<p>Running a full node is trivial and not expensive for people who know how to do it, even with much bigger blocks, assuming that the full nodes are still decentralized and that they don't have to fight against big nodes who would attract the traffic first<br>
</p>
<p>I have posted many times here a small proposal, that exactly describes what is going on now, yes miners are nodes too... it's disturbing to see that despite of Tera bytes of BIPs, papers, etc the current situation is happening and that all the supposed decentralized
system is biased by centralization</p>
<p>Do we know what majority controls the 6000 full nodes?</p>
<br>
<div class="moz-cite-prefix">Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">> <span style="font-size:12.8px">Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage.</span><br>
<br>
<span style="font-size:12.8px">That's very poor logic, sorry. Restricted-space SSD's are not a cost-effective hardware option for running a node. Keeping blocksizes small has significant other costs for everyone. Comparing the cost of running a node under
arbitrary conditons A, B, or C when there are far more efficient options than any of those is a very bad way to think about the costs of running a node. You basically have to ignore the significant consequences of keeping blocks small.<br>
<br>
If node operational costs rose to the point where an entire wide swath of users that we do actually need for security purposes could not justify running a node, that's something important for consideration. For me, that translates to modern hardware that's
relatively well aligned with the needs of running a node - perhaps budget hardware, but still modern - and above-average bandwidth caps.</span>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">You're free to disagree, but your example only makes sense to me if blocksize caps didn't have serious consequences. Even if those consequences are just the threat of a contentious fork by people who are mislead about the
real consequences, that threat is still a consequence itself.</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev
<span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="auto">
<div>
<div class="gmail_extra">Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage. Throw on top of it standard consumer usage, and you're often left with less than 200 GB of free
space. Bitcoin consumes more than half of that, which feels very expensive, especially if it motivates you to buy another drive.</div>
</div>
<div class="gmail_extra" dir="auto"><br>
</div>
<div class="gmail_extra" dir="auto">I have talked to several people who cite this as the primary reason that they are reluctant to join the full node club.</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader" target="_blank"></fieldset> <br>
<pre>_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets" target="_blank">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets" target="_blank">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist" target="_blank">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass" target="_blank">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org" target="_blank">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com" target="_blank">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live" target="_blank">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor" target="_blank">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms" target="_blank">https://www.github.com/Ayms</a></pre>
</div>
</div>
</div>
</body>
</html>