Re: [Bitcoin-development] About the small number of bitcoin nodes
- Create a grafical interface for bitcoind on Linux servers: Create a command, for example bitcoind show that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say grafical interface I mean like top command, an interface made out of characters in ASCII. FYI someone created this! It's still in the initial stages, I'm sure the author could use some help to grow this into a full-functional node admin tool. https://github.com/azeteki/bitcoind-ncurses Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez r...@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/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
On Mon, May 19, 2014 at 10:48 AM, Wladimir laa...@gmail.com wrote: Some hacking with ncurses could quickly make a decent tool here. It could be packaged with bitcoin itself but that's not necessary. For example Tor has the tool 'arm' which is a separate package. Regarding tor-arm, here are some screenshots: https://www.atagar.com/arm/screenshots.php It shows, among other things: - bandwidth up/down graphs - CPU usage - debug logging (in real time) - connected peers+statistics - currently active configuration Would be nice to have a similar tool for bitcoind. Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
Is the small number of bitcoin nodes a concern? If yes, why? What kind of attack can the network suffer? And where can we find statistical information about the full nodes running? I guess the only effective incentive to keep a node running would be financial. A kind of proof of stake would be nice on bitcoin. But I have no idea how to begin with. Felipe Micaroni Lalli Walltime: https://walltime.info Bitcoin Paranoid Android developer PGP ID: 0x4c0afccfed5cde14 BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N On 19/05/2014, at 07:39, Wladimir laa...@gmail.com wrote: On Mon, May 19, 2014 at 10:48 AM, Wladimir laa...@gmail.com wrote: Some hacking with ncurses could quickly make a decent tool here. It could be packaged with bitcoin itself but that's not necessary. For example Tor has the tool 'arm' which is a separate package. Regarding tor-arm, here are some screenshots: https://www.atagar.com/arm/screenshots.php It shows, among other things: - bandwidth up/down graphs - CPU usage - debug logging (in real time) - connected peers+statistics - currently active configuration Would be nice to have a similar tool for bitcoind. Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
On 19/05/14 14:15, Mike Hearn wrote: As an interested party not intimately familiar with the bitcoin codebase who also spent some time setting up a node a while ago, I would like to add one thing to the above list - network rate limiting. The problem is that this is easier said than done. Bitcoin Core won't notice a remote peer is working but slow and switch to a faster one, and even if it did, it'd just mean throttling your connection would cause all remote nodes to give up and hit the other unthrottled peers even more. Does this mean that you can currently actively hurt the network by adding a node with a very slow upstream / downstream? If so, what is the recommended minimum amount of bandwidth you should allocate for a node? I've already throttled mine with QoS based on the script in the contrib/ folder. Bjørn Øivind signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
On Mon, May 19, 2014 at 11:26 AM, Bjørn Øivind Bjørnsen bo.bjorn...@gmail.com wrote: On 18/05/14 19:43, Raúl Martínez wrote: snip some good ideas As an interested party not intimately familiar with the bitcoin codebase who also spent some time setting up a node a while ago, I would like to add one thing to the above list - network rate limiting. There is already an (old) patch that implements that. It won't be merged, though, until headers-first and parallel block download is in. Only when the node can download blocks from multiple peers at once it is really safe to allow limiting rates. (sure - there are tricks to limit rates anyway, like the script in contrib/qos, but to have it generally available the block download needs to be more robust first) Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
(sure - there are tricks to limit rates anyway, like the script in contrib/qos, but to have it generally available the block download needs to be more robust first) One thing we could consider as a short term solution (if headers first+parallel downloading will take a while, which seems plausible) is to add a service bit that says I have chain data and am willing to Bloom filter it for you, but I won't serve full block data, and then just exclude all of those from the chain download logic. It should not be a deep change to the code headers first is impacting, and would allow home users who may have no tolerance for block chain uploads at all to still take part and offer useful services to the network. I know Pieter likes the idea of an archival node service bit, or something like that. I'd been thinking that the stored chain height value would be better, but perhaps we need to divorce I have CPU and can filter from I have bandwidth and can serve more vigorously. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
On Mon, May 19, 2014 at 3:11 AM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez r...@i-rme.es wrote: - 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. Update: (1) and (3) are doable, however, Debian and Ubuntu policies make (2) very difficult (with the exception of security patches). Micha Bailey and I worked to get bitcoin removed from Debian and Ubuntu stable releases because they would not allow (2). There are other mechanisms that could accomplish (2) (backports, volatile, and updates repositories), however they are not enabled by default and require user intervention. Debian unstable does allow (2) since there is no release, and there is a package in Debian unstable. That package is blocked from transitioning to a stable release. We've also blacklisted it from Ubuntu so that Ubuntu doesn't just autoimport and release the Debian unstable package in an Ubuntu stable release. Micha is also working to have all old versions of bitcoin removed from previous released Ubuntu versions. Matt C's PPA is the best way of getting (1-3) above on Ubuntu, and the Debian unstable package is probably the best way of getting (1-3) above in Debian. Both require users to add a line to their apt sources list; the Debian package would also require apt pinning. Regards, Scott -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
