path: root/45/3b190c0c865c2167b9aa6ca8f1de410ab5ea44

Return-Path: <rjmarti2@millersville.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F18A4B35
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 05:23:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.millersville.edu (outgoing.millersville.edu
	[166.66.86.75])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 62746AB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 05:23:35 +0000 (UTC)
X-ASG-Debug-ID: 1490851413-0793ff199aea1f0001-D3WCip
Received: from HUBCAS2.muad.local (outlook.muad.local [166.66.87.94]) by
	outgoing.millersville.edu with ESMTP id E6ffHYkz69GP5xZT;
	Thu, 30 Mar 2017 01:23:33 -0400 (EDT)
X-Barracuda-Envelope-From: rjmarti2@millersville.edu
X-Barracuda-Effective-Source-IP: outlook.muad.local[166.66.87.94]
X-Barracuda-Apparent-Source-IP: 166.66.87.94
Received: from STUDMAIL1.muad.local ([2002:a642:56b8::a642:56b8]) by
	HUBCAS2.muad.local ([2002:a642:575e::a642:575e]) with mapi id
	14.03.0339.000; Thu, 30 Mar 2017 01:23:33 -0400
From: Ryan J Martin <rjmarti2@millersville.edu>
To: Aymeric Vitte <vitteaymeric@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Hard fork proposal from last week's meeting
X-ASG-Orig-Subj: RE: [bitcoin-dev] Hard fork proposal from last week's meeting
Thread-Index: AQHSqKgYnQ4DjsxFiU+7a8C6k6bCq6GsiMyAgAAh4QD///FAIg==
Date: Thu, 30 Mar 2017 05:23:31 +0000
Message-ID: <127281C1AA02374F8AAD9EE04FAE878A0218E8B825@STUDMail1.muad.local>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
	<CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
	<f61153c3-9afb-5cee-2c6b-70d67208f015@gmail.com>
	<CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
	<CAFVRnyqxQhu0c-ACfzR5=Z=C1SbR70jrfCaCeEdfSJASSnzpqw@mail.gmail.com>
	<CAD1TkXtze_TVegXz4AeJCxK59+cuwRQ=w4upzX+HoQ90Py52OA@mail.gmail.com>,
	<2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com>
In-Reply-To: <2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [71.207.56.72]
Content-Type: multipart/alternative;
	boundary="_000_127281C1AA02374F8AAD9EE04FAE878A0218E8B825STUDMail1muad_"
MIME-Version: 1.0
X-Barracuda-Connect: outlook.muad.local[166.66.87.94]
X-Barracuda-Start-Time: 1490851413
X-Barracuda-URL: https://166.66.86.75:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 15482
X-Virus-Scanned: by bsmtpd at millersville.edu
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0
	QUARANTINE_LEVEL=4.5 KILL_LEVEL=1000.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.37651
	Rule breakdown below
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	0.00 HTML_MESSAGE           BODY: HTML included in message
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 30 Mar 2017 05:28:40 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 05:23:39 -0000

--_000_127281C1AA02374F8AAD9EE04FAE878A0218E8B825STUDMail1muad_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There is alot going on in this thread so I'll reply more broadly.

     The original post and the assorted limit proposals---lead me to someth=
ing I think is worth reiterating: assuming Bitcoin adoption continues to gr=
ow at similar or accelerating rates, then eventually the mempool is going t=
o 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 ch=
ange, but rather, that if we are going to change the block limit then it sh=
ould be done with the intent to achieve a fee rate that maximize surplus (a=
nd minimize burden) to both users and miners. Even with implementation of a=
 a payment channels system, the pool will likely be faced with having a mou=
ntain of txs. Thus the block limit should be optimized in such that social =
welfare is optimized.
    Optimized is likely not keeping the limit at 1MB; this maximizes benefi=
t to miners (producers) while minimizing users' surplus (consumer). 'Unlimi=
ted' blocks are purely the reverse; maximizing user surplus while minimizin=
g miners' (with the added bonus of creating blocks that will put technical/=
hardware strain on the network). So perhaps pursue something in-between tha=
t actually optimizes based on a social welfare formula---not just an arbitr=
ary auto-adjusting limit like the other proposals I've seen. Feel free to p=
oke holes in this or e-mail me if curious.

     Finally, with respect to getting node counts up, didn't luke-jr or som=
eone come up with an idea of paying nodes a reward by scraping dust and poo=
ling it into a fund of sorts? Was this not possible/feasible? Perhaps at le=
ast 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 donat=
ion 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.


Ryan J. Martin
rjmarti2@millersville.edu
(on freenode: tunafizz )

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org [bitcoin-dev-bounces@li=
sts.linuxfoundation.org] on behalf of Aymeric Vitte via bitcoin-dev [bitcoi=
n-dev@lists.linuxfoundation.org]
Sent: Wednesday, March 29, 2017 6:33 PM
To: Jared Lee Richardson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting


I have heard such theory before, it's a complete mistake to think that othe=
rs would run full nodes to protect their business and then yours, unless it=
 is proven that they are decentralized and independent

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 stil=
l decentralized and that they don't have to fight against big nodes who wou=
ld attract the traffic first

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 d=
espite of Tera bytes of BIPs, papers, etc the current situation is happenin=
g and that all the supposed decentralized system is biased by centralizatio=
n

Do we know what majority controls the 6000 full nodes?

Le 29/03/2017 =E0 22:32, Jared Lee Richardson via bitcoin-dev a =E9crit :
> Perhaps you are fortunate to have a home computer that has more than a si=
ngle 512GB SSD. Lots of consumer hardware has that little storage.

That's very poor logic, sorry.  Restricted-space SSD's are not a cost-effec=
tive hardware option for running a node.  Keeping blocksizes small has sign=
ificant other costs for everyone.  Comparing the cost of running a node und=
er 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.

If node operational costs rose to the point where an entire wide swath of u=
sers that we do actually need for security purposes could not justify runni=
ng a node, that's something important for consideration.  For me, that tran=
slates to modern hardware that's relatively well aligned with the needs of =
running a node - perhaps budget hardware, but still modern - and above-aver=
age bandwidth caps.

You're free to disagree, but your example only makes sense to me if blocksi=
ze caps didn't have serious consequences.  Even if those consequences are j=
ust the threat of a contentious fork by people who are mislead about the re=
al consequences, that threat is still a consequence itself.

On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wr=
ote:
Perhaps you are fortunate to have a home computer that has more than a sing=
le 512GB SSD. Lots of consumer hardware has that little storage. Throw on t=
op 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.

I have talked to several people who cite this as the primary reason that th=
ey are reluctant to join the full node club.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev





_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

--_000_127281C1AA02374F8AAD9EE04FAE878A0218E8B825STUDMail1muad_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" id=3D"owaParaStyle"></style>
</head>
<body bgcolor=3D"#FFFFFF" fpstyle=3D"1" ocsi=3D"0">
<div style=3D"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>&nbsp; &nbsp; &nbsp;The original post and the assorted limit proposals=
---lead me to something I think is worth reiterating: assuming Bitcoin adop=
tion continues to grow at similar or accelerating rates, then eventually th=
e mempool is going to be filled with thousands
 of txs at all times whether block limits are 1MB or 16MB. This isn't to sa=
y 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 inte=
nt to achieve a fee rate that maximize
 surplus (and minimize burden) to both users and miners. Even with implemen=
tation of a&nbsp;<span style=3D"font-size: 13.3333px;">a payment channels s=
ystem</span><span style=3D"font-size: 10pt;">, the pool will likely be face=
d with having a mountain of txs. Thus the
 block limit should be optimized in such that social welfare is optimized.&=
nbsp;</span></div>
<div>&nbsp; &nbsp; Optimized is likely not keeping the limit at 1MB; this m=
aximizes benefit to miners (producers) while minimizing users' surplus (con=
sumer). '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 t=
he other proposals I've seen. Feel
 free to poke holes in this or e-mail me if curious.</div>
<div><br>
</div>
<div>&nbsp; &nbsp; &nbsp;Finally, with respect to getting node counts up, d=
idn't luke-jr or someone come up with an idea of paying nodes a reward by s=
craping dust and pooling it into a fund of sorts? Was this not possible/fea=
sible? Perhaps at least in the near and medium
 term something outside of protocol changes could be done to pay a reward t=
o nodes. Even if this is done via voluntary donation system, it may be usef=
ul for the purposes of seeing how people respond to incentives and working =
out an elasticity measure of sorts
 for running a node.&nbsp;</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=3D"font-family: Times New Roman; color: #000000; font-size: 16px=
">
<hr tabindex=3D"-1">
<div id=3D"divRpF572660" style=3D"direction: ltr;"><font face=3D"Tahoma" si=
ze=3D"2" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@lists.linuxfoun=
dation.org [bitcoin-dev-bounces@lists.linuxfoundation.org] on behalf of Aym=
eric 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 meeti=
ng<br>
</font><br>
</div>
<div></div>
<div>
<p>I have heard such theory before, it's a complete mistake to think that o=
thers 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 s=
till 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 w=
hat is going on now, yes miners are nodes too... it's disturbing to see tha=
t despite of Tera bytes of BIPs, papers, etc the current situation is happe=
ning 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=3D"moz-cite-prefix">Le 29/03/2017 =E0 22:32, Jared Lee Richardso=
n via bitcoin-dev a =E9crit&nbsp;:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">&gt;&nbsp;<span style=3D"font-size:12.8px">Perhaps you are=
 fortunate to have a home computer that has more than a single 512GB SSD. L=
ots of consumer hardware has that little storage.</span><br>
<br>
<span style=3D"font-size:12.8px">That's very poor logic, sorry.&nbsp; Restr=
icted-space SSD's are not a cost-effective hardware option for running a no=
de.&nbsp; Keeping blocksizes small has significant&nbsp;other costs for eve=
ryone.&nbsp; Comparing the cost of running a node under
 arbitrary conditons A, B, or C when there are far more efficient options t=
han any of those is a very bad way to think about the costs of running a no=
de.&nbsp; You basically have to ignore the significant consequences of keep=
ing blocks small.<br>
<br>
If node operational costs rose to the point where an entire wide swath of u=
sers that we do actually need for security purposes could not justify runni=
ng a node, that's something important for consideration.&nbsp; 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=3D"font-size:12.8px"><br>
</span></div>
<div><span style=3D"font-size:12.8px">You're free to disagree, but your exa=
mple only makes sense to me if blocksize caps didn't have serious consequen=
ces.&nbsp; 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=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Wed, Mar 29, 2017 at 9:18 AM, David Vorick vi=
a bitcoin-dev
<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=0A=
            .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir=3D"auto">
<div>
<div class=3D"gmail_extra">Perhaps you are fortunate to have a home compute=
r 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 oft=
en 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=3D"gmail_extra" dir=3D"auto"><br>
</div>
<div class=3D"gmail_extra" dir=3D"auto">I have talked to several people who=
 cite this as the primary reason that they are reluctant to join the full n=
ode club.</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader" target=3D"_blank"></fieldset> <br>
<pre>_______________________________________________=0A=
bitcoin-dev mailing list=0A=
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.or=
g/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev</a>=0A=
</pre>
</blockquote>
<br>
<pre class=3D"moz-signature" cols=3D"72">-- =0A=
Zcash wallets made simple: <a class=3D"moz-txt-link-freetext" href=3D"https=
://github.com/Ayms/zcash-wallets" target=3D"_blank">https://github.com/Ayms=
/zcash-wallets</a>=0A=
Bitcoin wallets made simple: <a class=3D"moz-txt-link-freetext" href=3D"htt=
ps://github.com/Ayms/bitcoin-wallets" target=3D"_blank">https://github.com/=
Ayms/bitcoin-wallets</a>=0A=
Get the torrent dynamic blocklist: <a class=3D"moz-txt-link-freetext" href=
=3D"http://peersm.com/getblocklist" target=3D"_blank">http://peersm.com/get=
blocklist</a>=0A=
Check the 10 M passwords list: <a class=3D"moz-txt-link-freetext" href=3D"h=
ttp://peersm.com/findmyass" target=3D"_blank">http://peersm.com/findmyass</=
a>=0A=
Anti-spies and private torrents, dynamic blocklist: <a class=3D"moz-txt-lin=
k-freetext" href=3D"http://torrent-live.org" target=3D"_blank">http://torre=
nt-live.org</a>=0A=
Peersm : <a class=3D"moz-txt-link-freetext" href=3D"http://www.peersm.com" =
target=3D"_blank">http://www.peersm.com</a>=0A=
torrent-live: <a class=3D"moz-txt-link-freetext" href=3D"https://github.com=
/Ayms/torrent-live" target=3D"_blank">https://github.com/Ayms/torrent-live<=
/a>=0A=
node-Tor : <a class=3D"moz-txt-link-freetext" href=3D"https://www.github.co=
m/Ayms/node-Tor" target=3D"_blank">https://www.github.com/Ayms/node-Tor</a>=
=0A=
GitHub : <a class=3D"moz-txt-link-freetext" href=3D"https://www.github.com/=
Ayms" target=3D"_blank">https://www.github.com/Ayms</a></pre>
</div>
</div>
</div>
</body>
</html>

--_000_127281C1AA02374F8AAD9EE04FAE878A0218E8B825STUDMail1muad_--