From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F18A4B35 for ; 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 ; 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 To: Aymeric Vitte , Bitcoin Protocol Discussion 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: , <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.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
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 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 a payment channels s= ystem, 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;
    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.

     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. 


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

From: 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]
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 meeti= ng

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

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

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

Do we know what majority controls the 6000 full nodes?


Le 29/03/2017 =E0 22:32, Jared Lee Richardso= n via bitcoin-dev a =E9crit :
> 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.

That's very poor logic, sorry.  Restr= icted-space SSD's are not a cost-effective hardware option for running a no= de.  Keeping blocksizes small has significant other costs for eve= ryone.  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.  You basically have to ignore the significant consequences of keep= ing 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= 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.

You're free to disagree, but your exa= mple only makes sense to me if blocksize caps didn't have serious consequen= ces.  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.

On Wed, Mar 29, 2017 at 9:18 AM, David Vorick vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
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.

I have talked to several people who= cite this as the primary reason that they are reluctant to join the full n= ode club.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev




_______________________________________________=0A=
bitcoin-dev mailing list=0A=
bitcoin-dev@lists.linuxfoundation.org=0A=
https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev=0A=


-- =0A=
Zcash wallets made simple: https://github.com/Ayms=
/zcash-wallets=0A=
Bitcoin wallets made simple: https://github.com/=
Ayms/bitcoin-wallets=0A=
Get the torrent dynamic blocklist: http://peersm.com/get=
blocklist=0A=
Check the 10 M passwords list: http://peersm.com/findmyass=0A=
Anti-spies and private torrents, dynamic blocklist: http://torre=
nt-live.org=0A=
Peersm : http://www.peersm.com=0A=
torrent-live: https://github.com/Ayms/torrent-live<=
/a>=0A=
node-Tor : https://www.github.com/Ayms/node-Tor=
=0A=
GitHub : https://www.github.com/Ayms
--_000_127281C1AA02374F8AAD9EE04FAE878A0218E8B825STUDMail1muad_--