Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd wrote: > More important though is you shouldn't be using single factor Bitcoin > addresses. Use n-of-m multisig instead and architect your system such > that that every transaction that happens in your service has to be > authorized by both the "online" server(s) that host your website as well > as a second "hardened" server with an extremely limited interface > between it and the online server. This adds a very minor amount of security, if any, if someone manages to hack into your "hot wallet" server they can just initiate a non-multisig transaction and still steal all your bitcoins in that wallet. You can't give the argument that the RPC API is password protected because the password is stored in plain-text in the config so all someone has to do is first grep for the file. There doesn't appear to be a way to force ALL outgoing transactions to be multisig and even if there was one, would you be able to force one of the addresses to be the "hardened" server? That still wouldn't prevent anyone from just stopping bitcoind, changing the config, then restarting it. Unless you're using your own custom wallet software there doesn't seem to be any sufficient way to prevent someone from stealing all your money once they have access to your server. Other software, like MySQL has access controls so I can prevent ALTERs, DROPs, DELETEs, etc for all "live" accounts limiting the scope of any attack if they manage to get into the server. Maybe this is beyond the scope of bitcoind, not sure. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
Didn't mean that bitcoind was connecting over port 443. I didn't even get a chance to compile. I was literally just finished downloading the tar.gz file when my server was terminated. Still trying to convince them I wasn't attacking anyone so they can re-enable the server. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig On Sun, Mar 2, 2014 at 3:56 PM, Wladimir wrote: > > On Sun, Mar 2, 2014 at 7:34 PM, James Hartig wrote: > >> Heads up... downloaded the linux tar.gz to my OVH box and got my server >> terminated. Screenshot from the email: >> http://cl.ly/image/3q0C2a3Y0T0V >> >> They claimed I was attacking 88.198.199.140 over port 443. >> > > Sounds very unlikely that bitcoind would connect to port 443, let alone > 'attack' anything. > > Anything in debug.log regarding that IP? > > Wladimir > > -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig On Sun, Mar 2, 2014 at 8:54 AM, Gavin Andresen wrote: > Please download and help test 0.9.0rc2; binaries are available from: >https://bitcoin.org/bin/0.9.0/test/ > > If no serious bugs are found in this release candidate, it will be the > final 0.9.0 release. > > Release notes (please help proofread/improve these, too): > --- > > Bitcoin Core version 0.9.0rc2 is now available from: > > https://bitcoin.org/bin/0.9.0/test/ > > This is a release candidate for a new major version. A major version brings > both new features and bug fixes. > > Please report bugs using the issue tracker at github: > > https://github.com/bitcoin/bitcoin/issues > > How to Upgrade > -- > > If you are running an older version, shut it down. Wait until it has > completely > shut down (which might take a few minutes for older versions), uninstall > all > earlier versions of Bitcoin, then run the installer (on Windows) or just > copy > over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). > > If you are upgrading from version 0.7.2 or earlier, the first time you run > 0.9.0 your blockchain files will be re-indexed, which will take anywhere > from > 30 minutes to several hours, depending on the speed of your machine. > > On Windows, do not forget to uninstall all earlier versions of the Bitcoin > client first, especially if you are switching to the 64-bit version. > > Windows 64-bit installer > - > > New in 0.9.0 is the Windows 64-bit version of the client. There have been > frequent reports of users running out of virtual memory on 32-bit systems > during the initial sync. Because of this it is recommended to install the > 64-bit version if your system supports it. > > NOTE: Release candidate 2 windows binaries are not code-signed; use pgp > and the SHA256SUMS.asc file to make sure your binaries are correct. > The final 0.9.0 release Windows setup.exe binaries will be code-signed. > > OSX 10.5 / 32-bit no longer supported > - > > 0.9.0 drops support for older Macs. The minimum requirements are now > a 64-bit-capable CPU running OSX 10.6 or later. > > Rebranding to Bitcoin Core > --- > > To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we > have renamed the reference client to Bitcoin Core. > > Autotools build system > --- > > For 0.9.0 we switched to an autotools-based build system instead of > individual > (q)makefiles. > > Using the standard “./autogen.sh; ./configure; make” to build Bitcoin-Qt > and > bitcoind makes it easier for experienced open source developers to > contribute > to the project. > > Be sure to check doc/build-*.md for your platform before building from > source. > > Bitcoin-cli > - > > Another change in the 0.9 release is moving away from the bitcoind > executable > functioning both as a server and as a RPC client. The RPC client > functionality > (“tell the running bitcoin daemon to do THIS”) was split into a separate > executable, 'bitcoin-cli'. The RPC client code will eventually be removed > from > bitcoind, but will be kept for backwards compatibility for a release or > two. > > `walletpassphrase` RPC > --- > > The behavior of the `walletpassphrase` RPC when the wallet is already > unlocked > has changed between 0.8 and 0.9. > > The 0.8 behavior of `walletpassphrase` is to fail when the wallet is > already unlocked: > > > walletpassphrase 1000 > walletunlocktime = now + 1000 > > walletpassphrase 10 > Error: Wallet is already unlocked (old unlock time stays) > > The new behavior of `walletpassphrase` is to set a new unlock time > overriding > the old one: > > > walletpassphrase 1000 > walletunlocktime = now + 1000 > > walletpassphrase 10 > walletunlocktime = now + 10 (overriding the old unlock time) > > Transaction malleability-related fixes > -- > > This release contains a few fixes for transaction id malleability issues: > > - -nospendzeroconfchange command-line option, to avoid spending > zero-confirmation change > - IsStandard() transaction rules tightened to prevent relaying and mining
Re: [Bitcoin-development] Fwd: Bitcoin Core trial balloon: splitting blockchain engine and wallet
Setting aside all security benefits (which the user can obviously choose to implement or ignore), a major benefit here is being able to have multiple wallets use the same blockchain process. I have 3 different bitcoind processes running on the same server to utilize multiple wallets. Using them serially isn't an option in my case. Also, peers can run the cheaper process instead of having the wallet functionality which isn't even used. On the security front, this doesn't seem to be any less secure and it gives the user the flexibility to make it as secure as they feel comfortable. If they want to run them both as the same user with no SELinux or file protections (this isn't stopping or encouraging that) they're already doing that now with bitcoind, albeit with possibly a larger attack surface. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig On Sat, Feb 22, 2014 at 1:53 AM, Wladimir wrote: > > On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell < > dtramm...@dustintrammell.com> wrote: > >> On Fri, 2014-02-21 at 07:43 +0100, Wladimir wrote: >> > The most straightforward way would be to run the blockchain daemon as >> > a system service (with its own uid/gid and set of Apparmor/SELinux >> > restrictions) and the wallet daemon as the user. >> >> This assumes you as a user have the rights to do so. This would be >> preferred, but in some cases may not be possible. Perhaps it should be >> optional? >> > > No! I'm proposing that we force everyone to do it. Using all means > necessary. There should be regular audits that everyone is running the > software exactly in my configuration, and if not, a special task force will > take care that spankings are carried out on the spot. > > Repeated offenders will lose their BitLicense. > > > Please stop kicking this dead horse. It was just a random idea. Maybe a > way how Linux distributions could structure it, but it may or may not apply > in your case. And that's fine, this is free software development, you can > do whatever you want! > > Let's try to bring this discussion back to its original intention: for > anyone that wants to concretely help this along, please help reviewing and > testing the pull requests that jgarzik mentions. > > Wladimir > BTW: All of those patches are helpful for monolithic-bitcoind as well as > they (lay the groundwork for) speeding up block synchronization. > > > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
