Bitcoin Forum
February 20, 2018, 10:34:09 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
Author Topic: Segfault on hardened Linux systems  (Read 3591 times)
Offline Offline

Activity: 826
Merit: 1000

View Profile
January 24, 2011, 08:12:57 PM

Unless somebody volunteers to fix/maintain this, I'm inclined to simply remove all of the "try to make the CPU miner go faster" optimizations from bitcoin.
How about leaving the optimizations in there, unless/until they cause some problem? If an optimization causes a maintenance problem, then it can be removed.

If there's hostile action against bitcoin, it might be valuable to muster every last CPU cycle by encouraging everyone to turn on generation.

When the standard client was patched to fix the overflow bug, the "valid" block chain overtook the "sabotaged" one in less than a day. One of the reasons for that was the success of the pleading (in this forum) for everyone to install the new client as soon as possible, and to turn on generation.
Hero Member
Offline Offline

Posts: 1519166049

View Profile Personal Message (Offline)

Reply with quote  #2

Report to moderator
Automated Bitcoin Fork Extraction Tool WE DO TOUGH WALLETS: BCH | BTG | BCD | SBTC | UBTC | B2X | BCX | BTF Electrum 2FA, Trezor, Ledger, SegWit, Bech32
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Offline Offline

Activity: 1
Merit: 0

View Profile
January 29, 2011, 03:27:06 PM

I'm running bitcoin on hardened Gentoo.  Everything works short of generation.  If I understand the conversation so far, some optimizations fail on hardened systems, but if they are disabled, generation will likely work.  On the other hand, the integrity of the network as a whole is bolstered by legitimate clients working efficiently, so removing optimization will probably be a net loss.

How about a compile-time switch?  It's not uncommon for optimized code to get along poorly with hardening measures.  I'm not familiar with the code base, let alone the developers, so I couldn't intelligently guess about the tradeoffs involved, but it seems to me that it would make sense to include a toggle that defaults to "optimize" (current condition), but can be flipped to "just do it the slow ugly way".  That way I could contribute my CPU cycles (if somewhat inefficiently), and the vast majority of the rest of the world, who don't run extremely hardened systems, don't have to be drastically affected.  Ideally that could trickle down to a Gentoo USE flag.  Smiley

I'll be happy to help with testing, provide traces, etc.  My system is protected by ASLR, non-executable stacks, GCC's stack-smashing protection, and any other bit I could flip in the kernel or elsewhere to harden the system, excluding mandatory access control (so no selinux, grsecurity, etc).  If it runs on my rig, it should run anywhere.

If I disappear, my email username is aabugher, provider is gmail.
Pages: « 1 [2]  All
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!