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
Re: [Bitcoin-development] Linux packaging letter
On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn m...@plan99.net wrote: Hi, Some of us have put together an open letter to the Linux packaging community, outlining why Bitcoin is different to other programs and asking them to not patch or modify the upstream sources. Please consider signing it if you agree (I think the wording by now is fine, so don't edit the contents - use the comment feature if you want to though). https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi The trigger for this is the discovery that Debian bitcoind's got split out of the consensus some time in April, for reasons that nobody yet figured out but is presumably related to a patch (eg it uses system leveldb). Hi Mike, Debian's bitcoin is maintained on an open and archived mailing list and git repo: Debian Bitcoin Packaging Team pkg-bitcoin-de...@lists.alioth.debian.org If there is a problem or question, getting an answer should be really easy. It would be good to include them in the discussion there (I CC:ed the list). If the upstream developers have a consensus that distribution packaging is not in the best interest of the project, then I personally would defer to their judgement and request removal. I'm leaving this open for other opinions from the Debian side. That said, let me summarize the arguments and see if we can figure out a permanent solution: 1) It appears that the consensus of upstream developers is that any distributed binary should only be linked against libraries that the bitcoin developers have tested and audited since any compatibility bug is a risk to both the user and the network. Response: Is there a way to certify the Debian libraries? Debian bitcoind/bitcoin-qt runs the compile test during all architectures. MIPS has been failing recently, but no one has looked into it yet. Perhaps it's not worth developers efforts yet, but at some point the technology should reach a point it can be redistributed. 2) Bitcoin is new technology, so any patches have the ability of harming both the network and user. Response: I, and I'm sure everyone else working on it, totally agrees. All patches are public [1], you can see that the patches are only to the build system (except for one adding a debug message). Is there a specific patch or bug that is problematic? This seems to be reiterating (1) above: don't patch the build system to use libraries that were not audited by the developers. The two solutions are: (1) no one besides the upstream developers compiles and distributes binaries, ever, or (2) upstream comes up with a system where someone besides them can compile working binaries for distribution. Most likely the best solution is to do (1) until upstream sets up a system to allow (2). I'm curious as to other's opinions. Thanks, Scott [1] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=tree;f=debian/patches;h=ba576f9f3ddad47a2f85dcbfb7a0b3482834f19f;hb=HEAD -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
On Tue, Jul 23, 2013 at 9:45 PM, Douglas Huff dh...@jrbobdobbs.org wrote: Honestly, until I read the quoted part of your response, I actually wasn't in favor of this whole thing since in general the types of issues being mentioned are, in large part, the types of issues that maintainers deal with all the time. On Jul 23, 2013, at 3:02 PM, Scott Howard showard...@gmail.com wrote: Response: Is there a way to certify the Debian libraries? Debian bitcoind/bitcoin-qt runs the compile test during all architectures. MIPS has been failing recently, but no one has looked into it yet. Perhaps it's not worth developers efforts yet, but at some point the technology should reach a point it can be redistributed. The fact that you're even trying to package and/or at some point have packaged and shipped big endian binaries is straight up *NEGLIGENT.* Stop that. Now. It won't work. Thanks for showing that this *is* necessary, I guess. before people get too upset, I'm talking about little-endian MIPS (debian-mipsel) http://www.debian.org/ports/mips/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr l...@dashjr.org wrote: This means a lot of additional work for the maintainers of the library packages, and the security team; for example, the security team must understand that they *cannot* deploy a critical security bugfix to LevelDB until someone competent has reviewed that it is behaviourally (including bug behaviours!) compatible with the versions in use everywhere else/previously. I think it is likely all this additional work/delays will be considered unacceptable to your library/security teams, thus using the bundled/embedded LevelDB is probably the best solution. The above is a key point, lukejr addressed it well I think it is likely all this additional work/delays will be considered unacceptable to your library/security teams, thus using the bundled/embedded LevelDB is probably the best solution. MIPS has been failing recently, but no one has looked into it yet. Perhaps it's not worth developers efforts yet, but at some point the technology should reach a point it can be redistributed. MIPS (and any other big endian architecture) has *always* failed on the Satoshi codebase, and will not be supported until someone has time to dedicate to fixing the numerous little-endian assumptions in the code. I have an incomplete port, but it isn't very high on my priority list to figure out what else it's missing. To be clear, bitcoind/bitcoin-qt is only built on little endian machines https://buildd.debian.org/status/package.php?p=bitcoin Debian could probably get away with packaging Bitcoin-Qt and bitcoind as-is with no modifications, and not have any problems. It's only when you begin making modifications that it becomes a problem. There are also some concerns that it puts a much larger price on compromising Debian's build servers and/or repositories (suddenly the attacker can steal a LOT of money). The only current modification is to use system leveldb instead of the packaged leveldb. (There is also a patch porting libmemenv.a to several other architectures, but that is only used in test suites - so it shouldn't pose a risk to users). The official binaries are not simply built by upstream developers: using Gitian, *anyone* can produce bit-for-bit identical binaries. Official releases are only published after 3 or more people have done an independent compile and signed the output. It would be excellent if the whole of Debian could work toward achieving this level of security eventually, which would make distributing Bitcoin node software much safer as well. Ironically, debian (in general) doesn't trust upstream security maintenance of third part libraries - that's why they typically get dropped in favor of use system libraries. In this case, upstream doesn't trust (rightfully) that some future debian security team bug fix to a stable library won't be tested properly against bitcoin, causing problems for users (since bitcoin might expect buggy library behavior). I'm not the original packager or maintainer - I just came across the package in really bad shape and helped bring it to something reasonable and have done the most recent uploads (since 0.8, I believe). Since updated libraries could pose a security risk because bitcoin may expect buggy behavior, I think that is a good argument for debian to use the included library. However, I'm just a recent helper - I still want to hear what people who have been doing this for longer think. ~Scott -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DOS-Attacks on bitcoin-client?
On Sun, Apr 7, 2013 at 10:43 AM, Oliver Egginger bitc...@olivere.de wrote: Hello, I'm using your bitcoin-qt client (version 0.8.1). Normally everything is working pretty fine, but sometimes it seems that other nodes produce an enormous amount of traffic. I have not had the time to investigate thoroughly yet. I only have briefly viewed with tshark. So far I have just restarted the client in the hope that it no longer connects with the 'evil' node. This usually works quite well. Is anything about DOS-Attacks known to you? Many new users have started using the reference client which downloads the whole blockchain from peers. There currently isn't a throttling mechanism [1] so it's possible to quickly eat up your bandwidth. You can try QoS on your router or use the -nolisten command line flag. You will still relay transactions, just not serve the whole blockchain. [1] https://github.com/bitcoin/bitcoin/issues/273 -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] separate out blockchain db and wallet to two dirs?
This idea is from a Debian user [1]. What do you think of moving the 2 GB db to $HOME/.cache/bitcoin and leaving the wallet and other config files in $HOME/.bitcoin? This is so backups can skip the .cache directory and the proposal follows the freedesktop.org XDG Base Directory Specification [2]. Personal info/settings stays in .bitcoin/ and everything that can be rebuilt goes to .cache/bitcoin/ I know users can do a work around and set it up themselves with symlinks, but interested in what you guys think. Cheers, Scott (Debian Developer but new to bitcoin) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660286 [2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
