James Hartig [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-24 to 2014-03-05
💬 Posted a total of 4 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:14:43

- reply

📅 Original date posted:2014-03-05
📝 Original message:On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd <pete at petertodd.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/cb5a68a9/attachment.html>

2023-06-07 15:14:32

- reply

📅 Original date posted:2014-03-02
📝 Original message: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 <laanwj at gmail.com> wrote:
>
> On Sun, Mar 2, 2014 at 7:34 PM, James Hartig <fastest963 at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140302/c3b35489/attachment.html>

2023-06-07 15:14:30

- reply

📅 Original date posted:2014-03-02
📝 Original message: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 <gavinandresen at gmail.com>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
> of
> mutated transactions
> - Additional information in listtransactions/gettransaction output to
> report wallet transactions that conflict with each other because
> they spend the same outputs.
> - Bug fixes to the getbalance/listaccounts RPC commands, which would report
> incorrect balances for double-spent (or mutated) transactions.
> - New option: -zapwallettxes to rebuild the wallet's transaction
> information
>
> Transaction Fees
> ----------------
>
> This release drops the default fee required to relay transactions across
> the
> network to 0.01mBTC per kilobyte. Note that getting a transaction relayed
> across the network does NOT guarantee that the transaction will be
> accepted by a miner and included in a block, and the default fee accepted
> by miners remains 0.1mBTC per kilobyte.
>
> As in previous releases, the relay fee may be changed with the
> -minrelaytxfee
> command-line option, and miners may change the default minimum fee they
> accept
> with the -mintxfee command-line option.
>
> 0.9.0rc2 Release notes
> =======================
>
> RPC:
>
> - New notion of 'conflicted' transactions, reported as
> confirmations: -1
> - 'listreceivedbyaddress' now provides tx ids
> - Add raw transaction hex to 'gettransaction' output
> - Updated help and tests for 'getreceivedby(account|address)'
> - In 'getblock', accept 2nd 'verbose' parameter, similar to
> getrawtransaction,
> but defaulting to 1 for backward compatibility
> - Add 'verifychain', to verify chain database at runtime
> - Add 'dumpwallet' and 'importwallet' RPCs
> - 'keypoolrefill' gains optional size parameter
> - Add 'getbestblockhash', to return tip of best chain
> - Add 'chainwork' (the total work done by all blocks since the genesis
> block)
> to 'getblock' output
> - Make RPC password resistant to timing attacks
> - Clarify help messages and add examples
> - Add 'getrawchangeaddress' call for raw transaction change destinations
> - Reject insanely high fees by default in 'sendrawtransaction'
> - Add RPC call 'decodescript' to decode a hex-encoded transaction script
> - Make 'validateaddress' provide redeemScript
> - Add 'getnetworkhashps' to get the calculated network hashrate
> - New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait'
> fields
> in 'getpeerinfo' output
> - Adding new 'addrlocal' field to 'getpeerinfo' output
> - Add verbose boolean to 'getrawmempool'
> - Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed
> balance
> - Explicitly ensure that wallet is unlocked in `importprivkey`
> - Add check for valid keys in `importprivkey`
>
> Command-line options:
>
> - New option: -nospendzeroconfchange to never spend unconfirmed change
> outputs
> - New option: -zapwallettxes to rebuild the wallet's transaction
> information
> - Rename option '-tor' to '-onion' to better reflect what it does
> - Add '-disablewallet' mode to let bitcoind run entirely without wallet
> (when
> built with wallet)
> - Update default '-rpcsslciphers' to include TLSv1.2
> - make '-logtimestamps' default on and rework help-message
> - RPC client option: '-rpcwait', to wait for server start
> - Remove '-logtodebugger'
> - Allow `-noserver` with bitcoind
>
> Block-chain handling and storage:
>
> - Update leveldb to 1.15
> - Check for correct genesis (prevent cases where a datadir from the wrong
> network is accidentally loaded)
> - Allow txindex to be removed and add a reindex dialog
> - Log aborted block database rebuilds
> - Store orphan blocks in serialized form, to save memory
> - Limit the number of orphan blocks in memory to 750
> - Fix non-standard disconnected transactions causing mempool orphans
> - Add a new checkpoint at block 279,000
>
> Wallet:
>
> - Bug fixes and new regression tests to correctly compute
> the balance of wallets containing double-spent (or mutated) transactions
> - Store key creation time. Calculate whole-wallet birthday.
> - Optimize rescan to skip blocks prior to birthday
> - Let user select wallet file with -wallet=foo.dat
> - Consider generated coins mature at 101 instead of 120 blocks
> - Improve wallet load time
> - Don't count txins for priority to encourage sweeping
> - Don't create empty transactions when reading a corrupted wallet
> - Fix rescan to start from beginning after importprivkey
> - Only create signatures with low S values.
>
> Mining:
>
> - Increase default -blockmaxsize/prioritysize to 750K/50K
> - 'getblocktemplate' does not require a key to create a block template
>
> Protocol and network:
>
> - Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
> - Send tx relay flag with version
> - New 'reject' P2P message (BIP 0061, see
> https://gist.github.com/gavinandresen/7079034 for draft)
> - Dump addresses every 15 minutes instead of 10 seconds
> - Relay OP_RETURN data TxOut as standard transaction type
> - Remove CENT-output free transaction rule when relaying
> - Lower maximum size for free transaction creation
> - Send multiple inv messages if mempool.size > MAX_INV_SZ
> - Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and
> MIN_PEER_PROTO_VERSION
> - Do not treat fFromMe transaction differently when broadcasting
> - Process received messages one at a time without sleeping between messages
> - Improve logging of failed connections
> - Bump protocol version to 70002
> - Add some additional logging to give extra network insight
> - Added new DNS seed from bitcoinstats.com
>
> Validation:
>
> - Log reason for non-standard transaction rejection
> - Prune provably-unspendable outputs, and adapt consistency check for it.
> - Detect any sufficiently long fork and add a warning
> - Call the -alertnotify script when we see a long or invalid fork
> - Fix multi-block reorg transaction resurrection
> - Reject non-canonically-encoded serialization sizes
> - Reject dust amounts during validation
> - Accept nLockTime transactions that finalize in the next block
>
> Build system:
>
> - Switch to autotools-based build system
> - Build without wallet by passing `--disable-wallet` to configure, this
> removes
> the BerkeleyDB dependency
> - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to
> more
> recent versions
> - Windows 64-bit build support
> - Solaris compatibility fixes
> - Check integrity of gitian input source tarballs
> - Enable full GCC Stack-smashing protection for all OSes
>
> GUI:
>
> - Switch to Qt 5.2.0 for Windows build
> - Add payment request (BIP 0070) support
> - Improve options dialog
> - Show transaction fee in new send confirmation dialog
> - Add total balance in overview page
> - Allow user to choose data directory on first start, when data directory
> is
> missing, or when the -choosedatadir option is passed
> - Save and restore window positions
> - Add vout index to transaction id in transactions details dialog
> - Add network traffic graph in debug window
> - Add open URI dialog
> - Add Coin Control Features
> - Improve receive coins workflow: make the 'Receive' tab into a form to
> request
> payments, and move historical address list functionality to File menu.
> - Rebrand to `Bitcoin Core`
> - Move initialization/shutdown to a thread. This prevents “Not responding”
> messages during startup. Also show a window during shutdown.
> - Don't regenerate autostart link on every client startup
> - Show and store message of normal bitcoin:URI
> - Fix richtext detection hang issue on very old Qt versions
> - osx: Make use of the 10.8+ user notification center to display growl like
> notifications
> - osx: Added NSHighResolutionCapable flag to Info.plist for better font
> rendering on Retina displays.
> - osx: Fix bitcoin-qt startup crash when clicking dock icon
> - linux: Fix Gnome bitcoin: URI handler
>
> Miscellaneous:
>
> - Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
> - Add '-regtest' mode, similar to testnet but private with instant block
> generation with 'setgenerate' RPC.
> - Add 'linearize.py' script to contrib, for creating bootstrap.dat
> - Add separate bitcoin-cli client
>
> Credits
> --------
>
> Thanks to everyone who contributed to this release:
>
> - Andrey
> - Ashley Holman
> - b6393ce9-d324-4fe1-996b-acf82dbc3d53
> - bitsofproof
> - Brandon Dahler
> - Calvin Tam
> - Christian Decker
> - Christopher Latham
> - Chuck
> - coblee
> - constantined
> - Cory Fields
> - Cozz Lovan
> - Daniel Larimer
> - David Hill
> - Dmitry Smirnov
> - Drak
> - Eric Lombrozo
> - fanquake
> - fcicq
> - Florin
> - frewil
> - Gavin Andresen
> - Gregory Maxwell
> - gubatron
> - Guillermo Céspedes Tabárez
> - Haakon Nilsen
> - HaltingState
> - Han Lin Yap
> - harry
> - Ian Kelling
> - Jeff Garzik
> - Johnathan Corgan
> - Jonas Schnelli
> - Josh Lehan
> - Josh Triplett
> - Julian Langschaedel
> - Kangmo
> - Lake Denman
> - Luke Dashjr
> - Mark Friedenbach
> - Matt Corallo
> - Michael Bauer
> - Michael Ford
> - Michagogo
> - Midnight Magic
> - Mike Hearn
> - Nils Schneider
> - Noel Tiernan
> - Olivier Langlois
> - patrick s
> - Patrick Strateman
> - Peter Todd
> - phantomcircuit
> - phelixbtc
> - Philip Kaufmann
> - Pieter Wuille
> - Rav3nPL
> - regergregregerrge
> - Robert Backhaus
> - Roman Mindalev
> - Rune K. Svendsen
> - Ryan Niebur
> - Scott Ellis
> - Scott Willeke
> - Sergey Kazenyuk
> - Shawn Wilkinson
> - Sined
> - sje
> - Subo1978
> - super3
> - Tamas Blummer
> - theuni
> - Thomas Holenstein
> - Timon Rapp
> - Timothy Stranex
> - Vaclav Vobornik
> - vhf / victor felder
> - Vinnie Falco
> - Warren Togami
> - Wil Bown
> - Wladimir J. van der Laan
>
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140302/2604d884/attachment.html>

2023-06-07 15:13:54

- reply

📅 Original date posted:2014-02-24
📝 Original message: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 <laanwj at gmail.com> wrote:
>
> On Sat, Feb 22, 2014 at 2:09 AM, Dustin D. Trammell <
> dtrammell at 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.
> </s>
>
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140224/efb926ae/attachment.html>