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 29EC4AB9 for ; Thu, 30 Mar 2017 10:13:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FC1ECB for ; Thu, 30 Mar 2017 10:13:20 +0000 (UTC) Received: by mail-wr0-f174.google.com with SMTP id k6so47637703wre.2 for ; Thu, 30 Mar 2017 03:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:cc:to:message-id:date:user-agent :mime-version:in-reply-to; bh=3L2TwgI2uPbZNHsPxgBhWxETVN2SmQJ3oDwRE+lzHtI=; b=pw+xXi20jIZrjwZ8q+k8fTCHLmIFilP4mGNfpM7VRI5ZPjwQgDVFJiVpgkfj9+8eIo xeqqmKAMxGc5XeOKTjMeWkzs1iGpDNhJ0j0sXA6th480VHR2vw68DMfxoVbmIJHTnqRw fBc0AB+nUXPAf3Qv3aN2q92WCMwed2dM2A8R+X5Q8lfM+ywfTXAp/Hb75xZTUgdvwH0C KsRnqWaCZ6UGr4SsX1LKGpslY44Dn2hqft65USTDRjAEZfY+r8t5UiDSoBCkD8tHS8PU U9USvoJJcvQyFTvDDVoB7ITv3qyEKjPG1Z0li0aE/t314Devd16sOXGHbD6KxcqYx6oM jmMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:cc:to:message-id:date :user-agent:mime-version:in-reply-to; bh=3L2TwgI2uPbZNHsPxgBhWxETVN2SmQJ3oDwRE+lzHtI=; b=RlddM7LQhjER6GtDyQWuoy4GNBZSS4+VBnrdsm638vj1TBpIrzcAMu5BPmyyANsZ0X au90MQ7qszQVvAzVsIAQIXoyyn5opbxMiynKrCuNhn7IiQTwQ33jw2njZWeq2sRs4ibG RkMMPx8vb62Yc4gVwczBb/nruUHblLzXd16fP7zzksOqa2eTbB1h7vevTEt5rnZgU/Nc QGdyGIUxpyckX62aeentOMYdL6FYyyMhS1kC4SG/MRqXLDksbPYKANx61qFt58mTw8Rv GJ7CXYQKpNY3Bi/WqqXEZbW0EDXUgohuLToeCsPfmrqiqYv0K2PiTgTpbd/iIxWkLzIQ UbyQ== X-Gm-Message-State: AFeK/H1ItTzrZhviELZZkrp85wn9cIxNQhzBydNXU62ueLcnKWVygR1U7psaG54KTUgIQA== X-Received: by 10.28.208.7 with SMTP id h7mr2688840wmg.79.1490868798778; Thu, 30 Mar 2017 03:13:18 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-52-124.w83-201.abo.wanadoo.fr. [83.201.223.124]) by smtp.googlemail.com with ESMTPSA id 35sm2192380wrn.9.2017.03.30.03.13.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 03:13:17 -0700 (PDT) References: <2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com> From: Aymeric Vitte To: Bitcoin Dev Message-ID: Date: Thu, 30 Mar 2017 12:13:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CF4283CBB91CFAD0868118FF" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 10:13:22 -0000 This is a multi-part message in MIME format. --------------CF4283CBB91CFAD0868118FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Apparently we will not get an understanding and we will probably be told soon that this is going off topic, so short answer Eh --> No, maybe you would like to quote Mozilla or the W3C too, all of those organizations are financed by the big companies and are promoting their interests (specs, DRM, etc), then would you really trust them? A full node does not have to validate all tx and blocks, I am not aware of any P2P system organized with peers and intermediate nodes (with no incentive) that did survive (diaspora for example), and the most famous one (who btw is handling much more traffic than what you describe) is doing well because there is an intrinsic incentive for the users, see my comment here https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation, surprising to see that nobody raised those issues during the consultation Paradoxally crypto currencies allow now to reward/sustain other systems, then probably they should concentrate first on how to reward/sustain themselves, different ideas have surfaced to reward the full nodes but still seem very far to materialize Coming back again to the subject, does anyone have any idea of who are behind the existing full nodes and how to rank them according to their participation to the network? Up to now there has been quasi no discussion about what are the plans for the full nodes which tends to suggest that this is obvious Le 30/03/2017 à 03:14, Jared Lee Richardson a écrit : > > 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, > > It is a complete mistake to think that others would create a massive > website to share huge volumes of information without any charges or > even any advertising revenue. > > https://en.wikipedia.org/wiki/List_of_most_popular_websites > > Wikipedia, 5th largest website. Well, I guess there's some exceptions > to the complete mistake, eh? > > Relying on other nodes to provide verification for certain types of > transactions is completely acceptable. If I'm paying a friend $100, > or paying my landlord $500, that's almost certainly totally fine. > There's nothing that says SPV nodes can't source verifications from > multiple places to prevent one source from being compromised. There's > also some proposed ideas for fraud proofs that could be added, though > I'm not familiar with how they work. If verification was a highly in > demand service, but full nodes were expensive, companies would spring > up that offered to verify transactions for a miniscule fee per month. > They couldn't profit from 100 customers, but they could profit from > 10,000 customers, and their reputation and business would rely on > trustworthy verification services. > > I certainly wouldn't suggest any of those things for things like > million dollar purchase, or a purchase where you don't know the seller > and have no recourse if something goes wrong, or a purchase where > failure to complete has life-altering consequences. Those > transactions are the vast minority of transactions, but they need the > additional security of full-node verification. Why is it unreasonable > to ask them to pay for it, but not also ask other people who really > don't need that security to pay for it? If a competing blockchain > successfully offers both high security and low-fee users exactly what > that particular user needs, they have a major advantage against one > that only caters to one group or the other. > > > Running a full node is trivial and not expensive for people who know > how to do it, even with much bigger blocks, > > This logic does not hold against the scale of the numbers. Worldwide > 2015 transaction volume was 426 billion and is growing by almost 10% > per year. In Bitcoin terms, that's 4.5 GB blocks, and approximately > $30,000 in bandwidth a month just to run a pruning node. And there's > almost no limit to the growth - 426 billion transactions is despite > the fact that the majority of humans on earth are unbanked and did not > add a single transaction to that number. > > I don't believe the argument that Bitcoin can serve all humans on > earth is any more valid than the argument that any computer hardware > should be able to run a node. Low node operational costs mean a > proportional penalty to Bitcoin's usability, adoption, and price. Low > transaction fee costs mean a proportional high node operational cost, > and therefore possibly represent node vulnerabilities or verification > insecurities. > > There's a balancing point in the middle somewhere that achieves the > highest possible Bitcoin usability without putting the network at > risk, and providing layers of security only for the transactions that > truly need it and can justify the cost of such security. > > > > On Wed, Mar 29, 2017 at 3:33 PM, Aymeric Vitte > wrote: > > 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 > > 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 > > 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 > > Do we know what majority controls the 6000 full nodes? > > > Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit : >> > 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. >> >> 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. >> >> 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. >> >> 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. >> >> On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev >> > > wrote: >> >> 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. >> >> I have talked to several people who cite this as the primary >> reason that they 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 > -- 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 --------------CF4283CBB91CFAD0868118FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Apparently we will not get an understanding and we will probably be told soon that this is going off topic, so short answer

Eh --> No, maybe you would like to quote Mozilla or the W3C too, all of those organizations are financed by the big companies and are promoting their interests (specs, DRM, etc), then would you really trust them?

A full node does not have to validate all tx and blocks, I am not aware of any P2P system organized with peers and intermediate nodes (with no incentive) that did survive (diaspora for example), and the most famous one (who btw is handling much more traffic than what you describe) is doing well because there is an intrinsic incentive for the users, see my comment here https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation, surprising to see that nobody raised those issues during the consultation

Paradoxally crypto currencies allow now to reward/sustain other systems, then probably they should concentrate first on how to reward/sustain themselves, different ideas have surfaced to reward the full nodes but still seem very far to materialize

Coming back again to the subject, does anyone have any idea of who are behind the existing full nodes and how to rank them according to their participation to the network? Up to now there has been quasi no discussion about what are the plans for the full nodes which tends to suggest that this is obvious


Le 30/03/2017 à 03:14, Jared Lee Richardson a écrit :
> 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,

It is a complete mistake to think that others would create a massive website to share huge volumes of information without any charges or even any advertising revenue.
https://en.wikipedia.org/wiki/List_of_most_popular_websites

Wikipedia, 5th largest website.  Well, I guess there's some exceptions to the complete mistake, eh?

Relying on other nodes to provide verification for certain types of transactions is completely acceptable.  If I'm paying a friend $100, or paying my landlord $500, that's almost certainly totally fine.  There's nothing that says SPV nodes can't source verifications from multiple places to prevent one source from being compromised.  There's also some proposed ideas for fraud proofs that could be added, though I'm not familiar with how they work.  If verification was a highly in demand service, but full nodes were expensive, companies would spring up that offered to verify transactions for a miniscule fee per month.  They couldn't profit from 100 customers, but they could profit from 10,000 customers, and their reputation and business would rely on trustworthy verification services.

I certainly wouldn't suggest any of those things for things like million dollar purchase, or a purchase where you don't know the seller and have no recourse if something goes wrong, or a purchase where failure to complete has life-altering consequences.  Those transactions are the vast minority of transactions, but they need the additional security of full-node verification.  Why is it unreasonable to ask them to pay for it, but not also ask other people who really don't need that security to pay for it?  If a competing blockchain successfully offers both high security and low-fee users exactly what that particular user needs, they have a major advantage against one that only caters to one group or the other.

> Running a full node is trivial and not expensive for people who know how to do it, even with much bigger blocks,

This logic does not hold against the scale of the numbers.  Worldwide 2015 transaction volume was 426 billion and is growing by almost 10% per year.  In Bitcoin terms, that's 4.5 GB blocks, and approximately $30,000 in bandwidth a month just to run a pruning node.  And there's almost no limit to the growth - 426 billion transactions is despite the fact that the majority of humans on earth are unbanked and did not add a single transaction to that number.

I don't believe the argument that Bitcoin can serve all humans on earth is any more valid than the argument that any computer hardware should be able to run a node.  Low node operational costs mean a proportional penalty to Bitcoin's usability, adoption, and price.  Low transaction fee costs mean a proportional high node operational cost, and therefore possibly represent node vulnerabilities or verification insecurities.

There's a balancing point in the middle somewhere that achieves the highest possible Bitcoin usability without putting the network at risk, and providing layers of security only for the transactions that truly need it and can justify the cost of such security.



On Wed, Mar 29, 2017 at 3:33 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:

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

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

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

Do we know what majority controls the 6000 full nodes?


Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
> 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.

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.

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.

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.

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

I have talked to several people who cite this as the primary reason that they 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
-- 
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
--------------CF4283CBB91CFAD0868118FF--