Re: [Bitcoin-development] Announcement: libcoin
However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this. I'll be trying your implementation soon. And libbitcoin/subvertx too. Partly because they're also non-interpreted, and partly to what seems better architected... To the minimal extent of my understanding... I'd like to see wallet ops completely separated from background chain ops. ie: have a chain daemon doing it's thing, updating, verifying, etc. The generator doing it's thing. And a wallet app that can independently manage separate wallets in parallel, referencing the live chain files as needed. It seems a library would allow quality focus on the separate functions and let apps/ui's use the fn's as desired on top. Right now, it seems I have to run bitcoind and can only deal with one wallet at a time, having to stop it, deal with state issues, swap in a new wallet, start it, and repeat till illness ensues :( And when the chain is being processed hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever or errors out. If wallet ops or statistical queries on the chain need it for integrity or reading, a db checkpoint/lock/logroll could be implemented into the chain demon processes with a client lib api to trigger it as needed. Don't know, just saying. fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master, you just need to compile and include it by hand if you want it and your package manager doesn't have it. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scaling at the end user level
I never did track down this exact issue but it's an artificial slowdown.. meaning compression and whatever else wouldn't help much. I meant for anyone who wanted to distribute the dataset as a project. It has something to do with the database file locking and flushing.. on some systems I've seen the block chain get fully done in 10-20 mins and on others it slows down to the point where it will never catch up.. but not in a way that's related to the age of the computer or anything. You might want to experiment if you want to track this down.. try building your own libs Rather than use dated/modified packages, I compiled current versions of all component sources manually. and compare different operating systems, on the same hardware to get a more 'true' comparison maybe. True. Used them all before, happy with BSD for now. Just knowing what the general setup is on those zippy systems should suffice. ie: blindly fishing for such a zippy system to compare through various install tests doesn't sound too appealing. It's different than benchmarking. Datapoint: The system below is not zippy. I think everyone is vaguely aware of the problem but it has not been tracked down and eliminated. I don't think the problem is within bitcoin itself but in how truthfully the database file is actually written to disk. Am I correct in guessing that, given a certain height, the data in blkindex and blk0001 should be the same across instances? # file blk* blk0001.dat: data blkindex.dat:Berkeley DB (Btree, version 9, native byte-order) Pursuant to comparison, what is the format of blk0001.dat? If it really gets flushed to disk every block like bitcoin wants it to be, then there is no way that you could get more than 50-60 blocks per second through it (due to rotational latency), but on some operating systems and versions/options it seems to end up caching the writes and flies through it at thousands of blocks per second. The problem is similar to what's mentioned here: http://www.sqlite.org/faq.html#q19 I'm not running Linux with asynchronous data and metadata turned on by default if that's what you mean :) ZFS, disk crypto, standard drive write cache. Looking at it, I'm largely buried in that crypto at 8MB/sec or so. Perhaps it's as simple as some default in the db lib.. and it seems to default to different things on different version/operating systems/filesystems. Hmm, I compiled everything with the defaults. Will go back and look at bdb options. I don't think there was anything interesting there. I'd bet a lot is tied to the fs and cpu. Single core p4@1.8 512k/2g isn't much up against ZFS+disk crypto. It seems to take its time and roll up all but the last database file (of a hundred or more) on receiving sigterm. Is it supposed to roll and delete the last log too? Can I safely delete everything but the blk* files? (wallet excepted of course :) Currently, in KiB... running: 853716 database 747881 blk0001.dat 290601 blkindex.dat 4361addr.dat 137 __db.005 137 __db.004 137 __db.003 137 __db.002 41 __db.006 25 __db.001 sigterm: 750569 blk0001.dat 291497 blkindex.dat 8465database/log.000nnn 4361addr.dat database/log.000133: Berkeley DB (Log, version 16, native byte-order) -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scaling at the end user level
Have any groups published proposals for distributing a weekly precomputed bootstrap chain? rsync? db_dump git db_load? There is also 50% or more compression available in the index and chain. I have proposed packaging part of the block chain (doesn't even have to be weekly, just until the last checkpoint), but people fear it runs contrary to the distributed approach of Bitcoin. Git repos are backed by strong hashes. Each commit could be a single block dump, perhaps into a file hierarchy. Trusted entities, pools, etc could sign at a checkpoint/height. Blockchain tools would need made that can take the blk* and export single blocks and process/export up to a certain block and quit. Everyone would do a comparison and sign a commit hash. Everyone else git pulls. Having the block toolset is a key prequisite to any sort of distribution. They don't exist now :( Maybe the two bitcoin compatible library projects out there will implement them :) Torrents are also strongly hashed and could be signed as well. Making the blockchain tools would be the most important thing to start. BTW: On such an old computer you should probably use one of the thin clients. If that means not validating the chain, then it's as above. I'm not sure if it's right to not care about the history if only making new transactions with a new key post install time and then only validating new transactions as they come in. Will have a look. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Git repo choices
I'm a little unclear on which repo is which and for what intended uses. And other than #1, their descriptions on the hubs are minimal. I'm not the best with git, but getting there. Are these the right way to think of them? And that #1 and #3 are what most builders and hacks should be tracking? #1 https://github.com/bitcoin/bitcoin.git The current development tree. As such, HEAD/master/origin may at times not be exactly reliable/usable. #2 https://git.gitorious.org/bitcoin/bitcoind.git A copy of some chunk of #1 that then died off around v0.4.0. Purposed similar to #3? #3 https://git.gitorious.org/bitcoin/bitcoind-stable.git Another copy of #1. For development along stable branches and making release cuts from same? Releases get pulled back to #1 for keeping? The HEAD/master/origin should be reliable. Why is this functoin not a part of #1? Thanks. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
While Bitcoin-Qt is by far the best client This is purely subjective. One's best is another's worst. These are both things which are particular suitable to clear objective enumeration. Yes, so for the purposes of compiling a list of clients and libraries, please just stick to a table of features. On the subjective part, I'm finding the library+client implementations to be nice, and indeed the future. Afaik, there are two major pairs of these so far that should be listed. Ymmv. Can someone also please set the reply-to header for these lists. It's really annoying to hit reply and not have the list address show up. Thanks :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
it's unclear how best to run this page. It's clear we need one though. the right path is probably the middle one - have some descriptions that try to be neutral Do it in two parts... - overview, history, architecture model, 'whys'. - agnostic table of features, platforms, stats, protocols, etc Last, resolve whether or not bitcoin.org is independant. It cannot be if it does not accept all lib/client under it's umbrella or has a lib/client project of it's own. You will hit up against this, just saying. Bitcoin-Qt This application is a peer-to-peer client that builds the backbone of the Bitcoin network. No, they all do this and build it, subject to their feature set. It is suited for enthusiasts, merchants, miners, developers No, all implementations are suited for whoever, subject to their feature set. and people who want to help support the project. Which project, the given client or the bitcoin meme. People who run Bitcoin-Qt are first class network citizens and have the highest levels of security, privacy and stability. Right, anyone who doesn't is unwashed rebel scum, running default installs of xp, on systems with bad ram, who post their home address, transaction logs, and pink bits on facebook. leave it running in the background so other computers can connect to yours. Again, a feature set / usage model thing. MultiBit fast and easy to use, even for people with no technical knowledge. Hey, we're fast, easy and for noobs, me too. It has a... But at least the backing specifics to that claim are stated. Armory Armory was partly funded by a community donation drive which raised over $4000. Yeah, every lib/client will have a donation thing on their own site, and the developers own real world wallet. Electrum the privacy level is lower than for other clients. Not sure of this claim. It's all in the usage. Run your own remote, use anonymizers, etc. Right? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html Ok, ok. but only because this reminds me of the top-posting and formatting advice page that I can't seem to find right now. But I'm not munging what my client decides to put in to/cc on a g reply either :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.6.x - detachdb in wrong place
Well, detachdb doesn't appear in the -\? help because it's stuffed under pnp, which is not set in my build. please fix for people, tx :) #ifdef USE_UPNP #if USE_UPNP -upnp\t + _(Use Universal Plug and Play to map the listening port (default: 1)) + \n + #else -upnp\t + _(Use Universal Plug and Play to map the listening port (default: 0)) + \n + #endif -detachdb\t + _(Detach block and address databases. Increases shutdown time (default: 0)) + \n + #endif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.6.x - detachdb in wrong place
It isn't inside the ifdef in bitcoin git master. Oh, hmm, well then, what is the difference or usage between these two repositories in regards to the project? Which one are the formal releases tagged (tbz's cut) in? Which one has the branches with the commits that will make it into the next formal release? ie: tracking along 0.5.x, 0.6.x, HEAD/master (to be branched for 0.7.x). https://github.com/bitcoin/bitcoin https://git.gitorious.org/bitcoin/bitcoind-stable I seem to be seeing more tags in the former, and more maintained branches in the latter? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Wallet related bug?
I think there may be an ideal order of ops bug around rescan, wallet upgrades/import and last block markers. I dropped an old wallet in a current blockchain. First ran - in rescan mode. It said old walletver. Then rescanned whole chain. AddToWallet some blockhash, blocks out of range, invalid/nonwallet txid's, which were already in there as legit ones in the old logs. Second run in plain mode. New wallet ver logged. Rescanned the last 20k blocks or so, which might have been the marker last time the old wallet was used. Third and later runs... duplicates the second. Never did say 'upgrading wallet' as it sometimes does. Running detach=1 always. Why scan the last 20k every time? Shouldn't have to if whole chain was scanned. And certainly no more than once if not. Also... Dumping the run params (bitcoin.conf, cmdline) to the log would be good. And not automatically truncate the log when big but just append or roll it. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor hidden service support
Additionally, such addresses are exchanged and relayed via the P2P network. To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in this 80-bit range is mapped to an onion address, and treated as belonging to a separate network. This network range is the same as used by the OnionCat application (though we do not use OnionCat in any way), and is part of the RFC4193 Unique Local IPv6 range, which is normally not globally routable. Other clients that wish to implement similar functionality, can use this test case: 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca. The conversion is simply decoding the base32 onion address, and storing the resulting 80 bits of data as low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. As this range is not routable, there should be no compatibility problems: any unaware IPv6-capable code will immediately fail when trying to connect. You are going to want to include the block of the Phatom project as well: https://code.google.com/p/phantom/ fd00:2522:3493::/48 And the one for 'garlicat' for I2P, which might be more complex due to I2P's addressing: fd60:db4d:ddb5::/48 Note that while these blocks are not expected to be routable, that people may in fact have interfaces, routing tables and packet filters on their machines configured with up to all three of those networks for the purposes therein. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [tor-talk] Tor hidden service support
GregM, wasn't sure how to answer your question, and as to conflicts [1]. I think I grasped it in my reply to something on tor-talk, which is on its way here pending moderation due to bcc. I put that part below. The FYI referred to seednodes as they exist on Tor / I2P today. You are going to want to include the block of the Phatom project as well: https://code.google.com/p/phantom/ fd00:2522:3493::/48 Perhaps some argument to add blocks to the IsRoutable check is in order? Then people who use overlay networks that are actually routable but which use otherwise private space can just add the relevant blocks. / [1] Well bitcoin wouldn't know to offload traffic to any of those / blocks, or a specific host on them, if you had them set up locally / via *Cat or Phantom... for bitcoin use. It would probably end up / half useful similar to the above FYI. But that would just affect / bitcoin, not whatever else you were running on them. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
You're seriously suggesting that I'm using a system which is 720x (one month vs one hour) faster than your P4 1.8GHz? Don't know what you're using since you've not stated it. I find this doubtful, especially since bitcoin's sync is effectively single threaded. Extra cores help with disk, crypto, net, etc... month I've spent about two weeks crunching about the last month's worth of new blocks. Your results are not expected and are not believed to be representative. The config is reproducible, and not believed to be uncommon. try to isolate it Mostly disk and crypto. Shall everyone instead run in bitrot and no-privacy mode? What do we do when we've got 10k trans a day coming in? 50k? 100k, 1M? When the chain gets 1M, 50M, 500M, 1B long? Forget my swamped box, these numbers are coming to others. try to sync from a local node into tmpfs I'd bet some people using 'tmpfs' probably have it unknowingly [fall]backed to swap instead of core. Bitcoin already takes up 3GiB of disk, how many have that much free RAM? How many have 30GiB, 300GiB? If you're building against BDB later than the recommended 4.8 be aware that there have been performance regressions with later versions Yes, I left out that bit of platform so here are the remaining bits... db4830, boost149, vm.kmem_size=65000 I'm not bashing anything or anybody, just detailing a stock config that is underwater. Anybody wishing to verify can get the hardware from their junk pile and the software from freebsd.org. I'll certainly be looking at both it and different setups too. If anyone's using say Linux/BSD, BTRFS/ZFS, crypto, on i386/amd64, they could chime in with their times too. Disk is the cheapest, easiest thing for Joe to get. Think about indexing and checkpointing into said disk. I don't know what bitcoin's doing, but if it's verifying every transaction back to the root, that would seem a bit ridiculous. Joe probably won't be happy buying TiB's for bitcoind, so after that's filled (assuming there's CPU to do it), the trust model has to change. These scales are coming... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
Update: this class of machine just became useless for bitcoin. When blk0002.dat was created to store more blocks, all forward progress processing blocks turned into losing ground by 20 or so a day. Guessing both datfiles were being accessed at once resulting in disk based overload. I've not seen any other mentions of crypto in this thread so I'm not sure how well new hardware would perform. Going shopping I guess. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync the chain, but it was less than two days as that was the span between when I checked on it. It's staying current Well, are you running bitcoin on, say, an FS with sha256 integrity trees for all bits and AES-128-XTS/CBC disk encryption? If not, we're not comparing the same apples, let alone the same OS. Again, I encourage you to investigate your software configuration. Someone suggested I investigate turning off the above features. Since I'd find their loss undesirable [1], and there's not much to be tuned there anyways, I've given up and am investigating what more GHz and cores will do. [1] Keeping data both intact and private is a good thing. Does your checkbook deserve any less? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
You are however using a filesystem (ZFS) I'm aware of the memory and i386 issues, and going shopping. The bdb backend Bitcoin uses does many I/O operations, and writes them synchronously to disk, killing whatever caching your filesystem provides. Sync... yes, depending on the rate/sec and size of them, that would be an issue. Enterprise systems with UPS, good disk, etc assume writes are committed upon return, eliminating need for software apps to do sync. So I need to figure out how to turn that off? Is sync on for everything, or just the wallet (where it could be argued as ok)? For those who run a large database on ZFS, I believe it is advised to put ZFS's intent log on a separate SSD-backed device, to get fast synchronous writes. Guessing bitcoin's writes are small? So a RAM dev intent would be cheaper and faster than SSD for that. on switching the bitcoin block verifier to use a different style database layout (ultraprune), which is smaller, faster, and will support pruning. I'll try to search that. If it's anything like delete old blocks/tx/coins that have both been validated in the past and fully spent in the future since we no longer need to validate further back beyond them [1], that would be interesting. [1] Unless you're a historian or some usage other than casual transactions. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
I'd love to know precisely what Bitcoin is doing thats making your machine so unhappy... but your configuration is uncommon for bitcoin nodes in many distinct ways so it's not clear where to start. That's why I posted the details of the machine so interested people could duplicate it if they are working in these areas. Once I'm on new hardware and playing around I, also, may find some discoveries. I have no doubt that 'common' is windows seven on core2duo without ecc and no crypto or hashing for the disk :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] separate out blockchain db and wallet to two dirs?
I mentioned this somewhere a while ago. It is enough of a sysadmin problem to warrant a feature ticket. Open one on github for it. XDGBDS is not canon. So don't hardcode said paths. All paths should be specifiable in bitcoin the config file, whose location should itself be specifiable on the command line. -- 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
Re: [Bitcoin-development] separate out blockchain db and wallet to two dirs?
I like this idea, although I would say the blockchain should go in /var/lib/bitcoin by default, right? I'm just a longtime LInux guy, not a formal sysadmin, though. Further, bitcoin doesn't allow easy separation of the files without detachdb (off by default), nor does it supply a user agnostic system daemon to do the block processing separately from user wallet ops. So I would suggest until then it remain split up somewhere under .bitcoin rather than in /var or anywhere else. -- 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
Re: [Bitcoin-development] Ok to use 0.8.x?
Bitcoin version 0.8.0 is safe to use for everything EXCEPT creating blocks. So: safe for everybody except solo miners / pool operators. And even solo miners / pool operators can use it if connected to the network only through a 0.7 node. I'll go ahead and use 0.8.x since it will be just transactions and queries. I'm guessing this will all be fixed in a couple weeks and that ASIC and FPGA miners will have their softcode updated, as will the pure softminers (GPU). -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin pull requests
gpg signing commits, like the Linux kernel Though, honestly, when I ACK that means I read the code, which is more important than the author really. github seems fine for that still, though I do wonder if there is a race possible, * just before I click pull, sneak rebases the branch to something evil You might want to look at http://www.monotone.ca/, it does a good job of integrating crypto and review primitives into the workflow. It also has some reliable network distribution models (netsync) that work well over things like Tor, in case a new developer (or old Satoshi) doesn't wish to be in the public light. http://www.monotone.ca/monotone.html Once you have the crypto, it always boils down to human risk factors, rogue, password, cracks, etc which are harder. -- 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
Re: [Bitcoin-development] bitcoin pull requests
Users will have available multisig addresses which require transactions to be signed off by a wallet HSM. (E.g. a keyfob Hardware is a good thing. But only if you do the crypto in the hardware and trust the hardware and its attack models ;) For instance, the fingerprint readers you see everywhere... many of them just present the raw fingerprint scan to the host (and host software), instead of hashing the fingerprint internally and using that as primitive in crypto exchanges with the host. They cheaped out and/or didn't think. So oops, there went both your security (host replay) and your personal privacy (biometrics), outside of your control. All with no protection against physical fingerprint lifting. This doesn't remove the need to improve repository integrity. ... but repository integrity is a general problem that is applicable to many things (after all, what does it matter if you can't compromise Bitcoin if you can compromise boost, openssl, or gcc?) Yes, that case would matter zero to the end product. However having a strong repo permits better auditing of the BTC codebase. That's a good thing, and eliminates the need to talk chicken and egg. It's probably best that Bitcoin specalists stay focused on Bitcoin security measures, and other people interested in repository security come and help out improving it. An obvious area of improvement might be oddity detection and alerting: It's weird that I can rewrite history on github, so long as I do it quickly, without anyone noticing. If no one is verifying the repo, sure, even entire repos could be swapped out for seemingly identical ones. Many repos do not have any strong internal verification structures at all, and they run on filesystems that accept bitrot. Take a look at some OS's... OpenBSD and FreeBSD, supposedly the more secure ones out there... both use legacy repos on FFS. Seems rather ironic in the lol department. Thankfully some people out there are finally getting a clue on these issues, making and learning the tools, converting and migrating things, working on top down signed build and distribution chain, etc... so maybe in ten years the opensource world will be much farther ahead. Or at least have a strong audit trail. -- 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] 0.8.2 branch
Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2) in which the like of release build stoppers or critfixes such as d315eb0 are included... for those tracking that level of defect without wishing to track all the growing post release slush in HEAD? -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Video summarizations of blocksize issues?
On Thu, Jun 18, 2015 at 4:54 AM, odinn odinn.cyberguerri...@riseup.net wrote: Recently I saw the following video: https://www.youtube.com/watch?v=8JmvkyQyD8wt=47m58s For those loosely following the technical issues from outside development circles, but who may be pressed into a voting/adoption type position (miners, users, investors)... is there a parallel presentation of the concepts and arguments from the other side (both, or the various, sides) that they can refer to? Someplace where they are collated and presented? A wiki perhaps? Are these even valid or necessary questions? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Please no GoogleGroups. Stick with mailman or some other open source thing you can move around from place to place as needed. Also, online third party archives die, their web interfaces suck ass, they're bloated, don't export, aren't offline capable or authoritative, etc. You need to make the raw archives (past and future) downloadable in mbox format and updated daily, with full unobfuscated headers for threading and replying, with signatures and attachments. Commonly for newcomers wishing to seed their own MUA's and archives, mirrors, search, and so on. One such breakage of archives by mailman defaults was discussed and corrected here: https://cpunks.org/pipermail/cypherpunks/ You also need to get rid of the tag in the subject, it wastes valuable space and mail filters work just the same without it. Please no forums (see suck above). Unless they have bidirectional realtime message copying between list and forum. Or at least make available exports of their message database. Further, when will the crypto P2P communities develop and use distributed messaging systems... bitmessage, blockchain, etc as rough examples... to avoid old centralized issues. At some point you have to start eating your own dog food and make people run the clients and come to you instead. Disruptive tech is the new good. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
