From: Aymeric Vitte <vitteaymeric@gmail.com>
To: jg@112bit.com,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Planned Obsolescence
Date: Thu, 15 Dec 2016 19:12:02 +0100 [thread overview]
Message-ID: <116c835c-0f3a-b0d6-6d0a-10a959d2f4de@gmail.com> (raw)
In-Reply-To: <615c88d2a1263810923705c170b25d33@112bit.com>
Maybe there are still some advantages but I don't know why this is not
considered as a major issue by the bitcoin community for the future and
why this looks to be never discussed:
- the size of the bitcoin network in terms of full nodes is ridiculous
and this is continuously decreasing, we cannot consider the bitcoin
network as a decentralized p2p network, what you are proposing is
logical but will of course amplify the problem
>For reasons I am unable to determine a significant number of node
operators do not upgrade their clients.
Why should they? What is the incentive for people to run full nodes and
upgrade? FYI I am part of the 2071 0.13.1 nodes for some good reasons
but will just shut it down when I am done, same for zcash (which as a
matter of fact I upgraded today since by some chance I noticed some
updates I was not aware of neither notified, just running it because I
need it from time to time and just don't kill it so I don't have to wait
for the restart process, maybe others are doing the same or just forgot
that they were running a full node)
Because, again, why should I or we maintain it/them?
I have looked at the proposals in the past (as well as the incentive
program) to reward those that are running full nodes but only found a
very few, never implemented (or even considered)
This is the very same for proposals allowing to start a full node from
zero in an acceptable timeframe (ie not 10 days in my case)
If the consensus is not to solve those two points and have a bitcoin
network controlled then it would be interesting to know why, so people
don't waste time trying to find solutions
Satoshi himself predicted that the full nodes will get centralized, I
think it's wrong, or in that case the bitcoin network cannot pretend to
be a decentralized immutable system (can be compared then to the Tor
network which does not pretend to be decentralized, because it is
centralized, and in addition does not encourage small nodes)
PS: IMHO the email notificiation system makes it difficult to follow
whom is answering to whom/what on this list compared to other lists
--
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
next prev parent reply other threads:[~2016-12-15 18:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
2016-12-15 3:38 ` [bitcoin-dev] Planned Obsolescence jg
2016-12-15 18:12 ` Aymeric Vitte [this message]
2016-12-15 18:48 ` Jorge Timón
2016-12-15 22:25 ` Angel Leon
2016-12-15 22:44 ` Ethan Heilman
2016-12-18 10:34 ` Matt Corallo
2016-12-18 20:50 ` Chris Riley
2016-12-18 20:07 ` Alice Wonder
2016-12-18 20:51 ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
2016-12-19 8:13 ` Alice Wonder
2016-12-21 18:33 ` Marco Falke
2016-12-19 2:22 ` [bitcoin-dev] Planned Obsolescence Matt Corallo
2016-12-19 6:39 ` Btc Drak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=116c835c-0f3a-b0d6-6d0a-10a959d2f4de@gmail.com \
--to=vitteaymeric@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jg@112bit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox