[Bitcoin-development] alternatives to the 20MB block limit, measure first!
Hello all, With all the discussion about the Block size limit, I thought it would be interesting to measure, in some sense, the average Tx size. Then given a fixed average block period (Bp) of 10 minutes (i.e 600 seconds), all one needs to do to estimate an average block size is ask the question: what average transaction rate (tps) do you want? So for tps ~ 10 (Tx/sec) and an average transaction size (avgTxSz) of 612 Bytes (last ten blocks up to block 357998 (2:05pm EDT 5/25/2015) we have a block size of 612 * 10 * 600 = 3,672,000 Bytes Alternatively, given an avgTxSz ~612 and maxBl = 1,000,000 we have (maxBl / avgBlSz) / Bp is the actual current max tps, which is ~2.72 tps. The avgBlSz for the 10 blocks up to block # 357999 is ~ 576 Bytes, so the current possible tps is ~2.89 and the maxBL for a tps = 10 is 3,456,000 bytes. So I think one should state one's assumed tps and a measured or presumed avgTxSz before saying what a maxBl should be. So for a maxBl ~20,000,000 Bytes and a current avgTxSz ~600 Bytes, the tps ~55.5 FWIW Ron (aka old c coder) -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I thought I should shortcut my research by asking a direct question here. As I understand it, the blockchain actually provides an extra piece of reliable data that is not being exploited by applications. Which data? The time. In this case 'the time' as agreed by 50% of the participants, where those participants have a strong financial incentive to keep that 'time' fairly accurate. (+/- about 10 minutes) Is this a reasonable understanding of 'time'? ... aka timestamps on the block Ok... 'time' on the blockchain could be 'gamed' ... but with great difficulty. An application presented with a fake blockchain can use quite a few heuristics to test the 'validity' of the block chain. It can review the usual cryptographic proofs, and check that difficulty is growing/declining only in a realistic manner up to the most recent block. Even use some arbitrary test like difficulty 10,000,000,000 ... on the presumption that any less means that the Bitcoin system has failed massively from where it currently is and has become an unreliable time source. Reliable 'time' has been impossible up until now - because you need to trust the time source, and that can always be faked. Using the blockchain as an approximate time source gives you a world wide consensus without direct trust of any player. So if this presumption is correct, then we can now build time capsule applications that can not be tricked into exposing their contents too early by running them in a virtual environment with the wrong system time. Is this right? or did miss I something fundamental? Ron - -- public identify: https://www.onename.io/ron_ohara -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4 hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc= =T5fw -END PGP SIGNATURE- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
In this scenario how do you ensure the miner solving the block cannot reapportion the subsidy to himself rather than the pool? On Jun 17, 2014 2:09 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
as I understood your proposal the entire block would be created on the miner rather than just the block header. Currently miners do not receive a list of transactions, they receive information required to create the block header, this is how you keep miners honest. if the miner is creating the full block we are right back to where we were. I've only worked with implementing the mining process for a few months now so someone correct me if I have the process wrong On Jun 17, 2014 7:01 AM, Raúl Martínez r...@i-rme.es wrote: Because he cant change the coinbase once the proof of work is done. El 17/06/2014 15:58, Ron Elliott ronaldbelli...@gmail.com escribió: In this scenario how do you ensure the miner solving the block cannot reapportion the subsidy to himself rather than the pool? On Jun 17, 2014 2:09 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] error Bitcoin cannot be compiled without assertions. NOT
Message: 2 Date: Wed, 4 Jun 2014 08:15:08 -0400 From: Jeff Garzik jgar...@bitpay.com Subject: Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT To: Mike Hearn m...@plan99.net Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net, Ron rd...@yahoo.com Message-ID: cajhla0ptthfvd-1br5s2k-4uw6v6qleyabf2ysrxoosjth9...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Yes, check macros like that can be useful. I like the kernel's policy, which parallels our direction: 1) Enable and use lightweight assertions for most users. 2) No assertions with side effects If you want to compile them out, that's fine, but they should always be present in production software. _ I don't think many of you actually read what I said, and you went off on your own tangents. I said: this commit and code with all side effects removed from the assertions. in Vol 37, Issue 4 I intentionally left the gcc code alone. Only the MSC code is assert fixed. I would have hoped that someone would have noticed and incorporated these changes into the gcc code. Simply by removing the #ifdef _MSC_VER ... #else ... #endif etc. etc. Did I say I compiled them out? No! Did anyone bother to look at my code or what I said? Here is an example from main.cpp CTransaction::UpdateCoins(... -// add outputs +// add outputs sure looks like an assert with side effects here!? +#ifdef _MSC_VER +bool +fTest = inputs.SetCoins(txhash, CCoins(*this, nHeight)); +#ifdef _DEBUG +assert(fTest); +#else +if( !fTest ) +releaseModeAssertionfailure( __FILE__, __LINE__, __PRETTY_FUNCTION__ ); +#endif +#else assert(inputs.SetCoins(txhash, CCoins(*this, nHeight))); +#endif Note that I do the test, and if debugging, I let it abort() the program if it fails. Note that in release mode it calls a new function on failure, that I leave you to discover what it does. I see that this assert has been fixed in 0.9.x, but I think my fix is better, since it allows release mode code to run better, if not identically. I changed every assert() in the bitcoind 086 sources to behave this way. Since C++ is perniciously baroque, it is not clear if a side effect can or has occurred in the most innocuous of C++ statements. Is the example above side-effect free? Here is a piece of what I made my decision on: http://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html and the link to the book previously given. Also, no one answered the question about bitcoin-qt, to whit, can or should it be compiled in RELEASE mode because of this? Should it have always been compiled in DEBUG mode in the past too? Ron -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin codebase is actually really simple and readable.
From: bitcoin-development-requ...@lists.sourceforge.net bitcoin-development-requ...@lists.sourceforge.net To: bitcoin-development@lists.sourceforge.net Sent: Wednesday, October 23, 2013 3:38 AM Subject: Bitcoin-development Digest, Vol 29, Issue 20 Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 2. Re: Revisiting the BIPS process, a proposal (Peter Todd) -- On Tue, Oct 22, 2013 at 09:34:57AM +0200, Martin Sustrik wrote: On 22/10/13 09:03, Gregory Maxwell wrote: On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ? Take care, the information in the wiki is woefully incomplete. Imagine myself, with no prior knowledge of Bitcoin looking at the document. It starts with Hashes. What hashes? No idea what's going on. Etc. Now compare that to a well written RFC. It starts with introduction, description of the problem, explains the conceptual model of the solution, then dives into the details. There's also Security Considerations part in every RFC that is pretty relevant for Bitcoin. As I said, I am willing to help with writing such document, it would be a nice way of learning the stuff, however, help from core devs, such as answering question that may arise in the process, or reviewing the document would be needed. Writing such RFCs is dangerous due to the consensus nature of Bitcoin - it makes people think the standard is the RFC, rather than the code. I hear one of the better intros to Bitcoin is the Khan academy videos, but I've never watched them myself. Once you understand how it works, start reading source code - the Bitcoin codebase is actually really simple and readable. However remember that the implications of that codebase are anything but simple; there's lots of reasons to think Satoshi himself didn't understand Bitcoin all that well, even by the time he left the project. -- 'peter'[:-1]@petertodd.org 000f155e7a648e84a83589048ae1cacb0c60bfce2437553b6af4 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 685 bytes Desc: Digital signature -- I feel that I must respond to the statements that 1. the Bitcoin codebase is actually really simple and readable. 2. However remember that the implications of that codebase are anything but simple; there's lots of reasons to think Satoshi himself didn't understand Bitcoin all that well, even by the time he left the project. On point one: if it was/is so readable, why hasn't it been documented better, if at all? Why haven't the obscure names of important items been globally searched and replaced? Why are there still mixed formatting styles still in the code. I think it is the fear that C++ is so brittle, that one change may bring the whole house of cards down. I feel that it is the language (C++) that is hindering the expression of ideas in the code. This goes to your point two about Satoshi's understanding. I think just the opposite: that he knew what he wanted but that C++ hindered him in expressing and implementing it. I think that if anything, C++ was what Satoshi didn't understand all that well. But then who does understand C++, really? See https://groups.google.com/forum/#!msg/comp.lang.lisp/7xCvdzijzgU/4xCFzLc3d5EJ and the quote: Whenever I solve a difficult problem with C++, I feel like I’ve won a bar fight. — Michael Fogus I don't think readability is attainable easily in C++. It requires intentionally writing so that others may understand your code. How many programmers have ever done that? And this is like swimming upstream in C++, where things are designed to be hidden! Ron -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] on CDB::Rewrite()
I only bring this up here since I can't raise https://bitcointalk.org? Perhaps it runs on the silk road servers:) Upon looking at the 0.8.5 earlier code for CDB:Rewrite(), in the files db.h and db.cpp, you will notice that in db.h it is declared bool static, but in db.cpp it isn't. Is this a problem? Or a feature? Or nothing at all? Furthermore, it is called only in wallet.cpp --CWallet::EncryptWallet() but its return value is ignored? Again, intentional or a bug or a feature or a ...? Now CWallet::EncryptWallet() is called by AskPassphraseDialog::accept() and WalletModel::setWalletEncrypted()and they seem very interested in what CWallet::EncryptWallet() returns. Could this be involved in some old issue with wallet encryption on bitcoin-qt 0.8.1? There seems to be plenty of this kind of suspicious code to ferret about in, with one's IDE during quiet moments. Amusing is to follow return 0 and return 1 to try and infer their meaning, their intent? Ron -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] locks and directories
Hello Is it required, presumed, assumed, coincidence, chance or irrelevant that the three different databases in bitcoin: 1. the network addresses database, reflected in peers.dat 2. the levelDB block chain database (blocks/blkn.dat, blocks/revn.dat, blocks/index/n.sst et al, chainstate/n.sst et al) 3. the Berkeley DB wallet database (db.log, wallet.dat, database/log.n1) are all in the datadir directory? I only ask since it would seem that a more mature (?) bitcoind or bitcoin-qt would optionally, like the three (databases) in separate paths or drives, etc. It would seem easier to transport, backup etc. the pieces one wants. I find the block chain database is the most important (time consuming), because of its size, to duplicate and transport in order to backup. This also attacks the Criticism section in https://en.bitcoin.it/wiki/Bitcoin-Qt The first question is: can one backup by just looking at the dates, and just back up those files with the equal or newer dates, and the log, current and manifest files? An initial then incremental backups, as it were. I am thinking of the frailties of data on OS's such as Windows in the hands of the less than adept shall we say. Also if one takes part in backing up one's data, one may actually have some idea where it is! Ron-- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] the XBT
Hello, Has everyone seen http://www.coindesk.com/bitcoin-gaining-market-based-legitimacy-xbt/ Bitcoin has its own ISO currency code. Ron -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
of the wallet an abbreviated 5 lower case letter cryptic bitdb reminds me of the time when ram and disc storage were dear and compilers couldn't handle long names! I would call it something much grander! Only 46 places to change ! Also the member DbEnv dbenv is equally underplayed as it is the main actor in the play! Let's not even mention pdb being used both for a BerkeleyDB CDB.Db* and as an albeit private leveldb DB*.! Pointers that aren't called pSomething, un-commented/un-documented magic numbers where commented constants should be, and on and on it goes. So I just sit back doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you architects march ahead oblivious to the cryptic minefield of code that exists underneath :) My aim is to first clean up the code enough so that I can understand it. Then eventually, take it over to a real Windows project/solution where it can be made into an executable that is palatable for the masses. Getting off soapbox now and retreating to the back...(bitcointalk.org that is) Ron-- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Modularizing Bitcoin
From: bitcoingrant@gm... - 2013-05-16 10:02 One of the primary upcoming priorities for bitcoin’s infrastructure, beyond the bloom filter, will be the continued modularization of the system. Here at the Bitcoin Grant, we would like to jump start this development with a financial incentive and initiate an ongoing conversation on how we can work together towards developing a smarter, more efficient system of tomorrow, today. Up for grabs: 500 bitcoins or $500,000; whichever is greater. Taking on a project of this scope is a highly intensive, technical undertaking and we believe excellent developers should be compensated as such, especially when it comes to open source projects. One of the main goals will be to separate the wallet from the node, as we have already done with mining. This way, the wallet, which will only hold private keys and create transactions, would pass transactions directly to a relay node, based on the bloom filter. Meanwhile, the block node will maintain the block chain and validate and relay new blocks. Such developments would significantly strengthen the system. Modularization would make cancer attacks less likely and increase the node count, which, currently, is fairly low. This is by no means is a feature request, merely ideas as to initiate a discussion. We welcome any feedback or suggestions. And of course, let us know if you would like to contribute to this project by submiting a grant proposal. http://bitcoingrant.org http://bitcoingrant.org/lang=en Hello I don't know if this is the proper method of replying or even if I am allowed to reply! Modularization can have many meanings, depending upon one's past! The code is somewhat compartmentalized/modularized now. But if one forces complete separation of the parts, with a 'loose coupling', etc., I find that the performance tends to suffer and the size increases. In the Java world there is the notion of refactoring one's code. This would be too much, I think, in this case. When I developed with a team and alone, I would make what used to be called 'step-wise refinements' on existing working code. To me, one of things this meant was doing a one to one transformation of the source code, in such a way as to have the identical, byte for byte, executable file, but a 'better' set of source files. A similar process would seem appropriate here. Especially since there is much in the code that I don't understand :) As to 'separating the wallet from the node', do you mean allowing the wallet.dat file to be anywhere, and not restricted to the 'OS default' or 'datadir' directory? If so, I have done that with no change to the current behavior, and also the wallet.dat now can have any legal filename too! I haven't tested it yet on bitcoin-qt, but it runs on bitcoind. I am still 'ramping up' on github to get the code into view. After testing on bitcoin-qt of course. What may I ask, is a cancer attack? If any of this inappropriate, forgive me. Ron -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
