Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-19 📝 Original message:On Sun, May 18, 2014 at ...
📅 Original date posted:2014-05-19
📝 Original message:On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme at i-rme.es> wrote:
> - Allow users to view the bandwith used by Bitcoin Core:
+1 for the sake of transparency
HOWEVER, the impact on this feature RE user population is
unpredictable. Users may see bigger than expected numbers, and switch
off their node.
> - Educate users about the correct setup of a bitcoin node:
+1
> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
Meh. I like example configs, perhaps tuned by the distro. If the
distro (_not_ Bitcoin Core upstream) chooses to install a bitcoin.conf
in the proper location, that's up to them.
> - bitcoind and Bitcoin Core should be in Linux repos:
Agreed with conditions:
1) The distro MUST let bitcoin devs dictate which dependent libs are
shipped with / built statically into the bitcoin binaries/libs.
2) The distro MUST permit fresh updates even to older stable distros.
2) The maintainer(s) MUST be active, and follow bitcoin development,
release status, etc. on a near-daily basis, be able to respond quickly
if security issues arise, etc.
Matt C seems to do a good job of this in Ubuntu PPA, I'm told.
> - Create a "grafical interface" for bitcoind on Linux servers:
> When I say "grafical interface" I mean like "top" command, an interface made
> out of characters in ASCII.
The best path for this is figure out what statistics you want to see,
and have bitcoind export those raw numbers to any willing consumer.
Then write your bitcoind-top on top of that.
> - Split Bitcoin Wallet from Bitcoin Node:
+1
In progress. Disable-wallet support, at compile time or runtime, was
the first step.
> - Inform users if 8333 port is closed:
+1
> - Keep connections if bitcoind is restarted:
> I noticed that if I restart bitcoind (to apply new config) my reset to 0 and
> take some hours to rise up to ~40. I believe that my peers should notice
> that I am down for less than ~15 minutes and try to connect again faster.
No, you don't want this (and it's not possible in many cases anyway).
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
📝 Original message:On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme at i-rme.es> wrote:
> - Allow users to view the bandwith used by Bitcoin Core:
+1 for the sake of transparency
HOWEVER, the impact on this feature RE user population is
unpredictable. Users may see bigger than expected numbers, and switch
off their node.
> - Educate users about the correct setup of a bitcoin node:
+1
> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
Meh. I like example configs, perhaps tuned by the distro. If the
distro (_not_ Bitcoin Core upstream) chooses to install a bitcoin.conf
in the proper location, that's up to them.
> - bitcoind and Bitcoin Core should be in Linux repos:
Agreed with conditions:
1) The distro MUST let bitcoin devs dictate which dependent libs are
shipped with / built statically into the bitcoin binaries/libs.
2) The distro MUST permit fresh updates even to older stable distros.
2) The maintainer(s) MUST be active, and follow bitcoin development,
release status, etc. on a near-daily basis, be able to respond quickly
if security issues arise, etc.
Matt C seems to do a good job of this in Ubuntu PPA, I'm told.
> - Create a "grafical interface" for bitcoind on Linux servers:
> When I say "grafical interface" I mean like "top" command, an interface made
> out of characters in ASCII.
The best path for this is figure out what statistics you want to see,
and have bitcoind export those raw numbers to any willing consumer.
Then write your bitcoind-top on top of that.
> - Split Bitcoin Wallet from Bitcoin Node:
+1
In progress. Disable-wallet support, at compile time or runtime, was
the first step.
> - Inform users if 8333 port is closed:
+1
> - Keep connections if bitcoind is restarted:
> I noticed that if I restart bitcoind (to apply new config) my reset to 0 and
> take some hours to rise up to ~40. I believe that my peers should notice
> that I am down for less than ~15 minutes and try to connect again faster.
No, you don't want this (and it's not possible in many cases anyway).
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/