[Bitcoin-development] Video summarizations of blocksize issues?
On Thu, Jun 18, 2015 at 4:54 AM, odinn wrote: > Recently I saw the following video: > https://www.youtube.com/watch?v=8JmvkyQyD8w&t=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
[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
Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
> Bitcoins relative lack of privacy creates a problem with tainted coins > risking becoming unspendable, or spendable only with some users, or at a > discount. So while the policy coded says all coins are equally acceptable, > the information exists so people can unilaterally reject them, depending on > what the taint is. So far revocability hasnt reared it's head that I heard, > nor taint inspection too much? However people have the choice and technical > means to check the taint and send the bitcoins back. a) Is there a paper detailing bitcoin traceability issues? Particularly when using various combinations of the often advised 'use different address for every transaction', 'wash coins', and 'use anonymity networks' privacy enhancement methods. b) People would be nuts to reject tainted coins on the current chain, or any chain. How many of the bills in your wallet passed through 'illicit' transactions? How would you feel if your payee's serial checker bounced yours, possibly forcing you to dispense with them through other, possibly illicit, means? What about a total blackball? Who's going to compensate you? How exactly do you roll that all back? And are you going to KYC and scour the lives of your every potential customer beforehand? What if someone has money to burn and blackballs a million notes for fun. A currency of common global adoption that you can't spend after some thieving crackdealer bought an onion off your garden stand isn't of much use to anyone, not even the purists who come up with such ideas. Specialized currencies in special markets, sure, maybe, all still fraught with the same dilemmas. But for a global common one? No. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ 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
Re: [Bitcoin-development] bitcoin pull requests
> Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big > trouble" risk entirely This isn't really possible. A trojaned client will spend your coin as easily as the owner can, passphrases will be logged, windows box will be owned, secondary remote spendauth sigs into the network chain break similarly, securely hashcheck the trojaned client from cracked userspace on a hacked dll/kernel with uefi backdoor and a trojaned hasher, etc. It's easier for a few developers to meet in person to init and sig a new repo than to try fixing the world's userland and users :) At least that way you get something verifiable back to the root. -- 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
>> 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] 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
[Bitcoin-development] Ok to use 0.8.x?
Assuming a new install and first time connection to the net, is using 0.8.x [1] safe to use, for all (or select?) purposes, regarding the current fork issue? If not, is there a recommended branch, tag, or commit, for all such (or select?) purposes, until such time as an upgrade alert is broadcasted? Thanks. [1] Regarding possible 0.8.x flavors... There are only 'branch master' and 'tag v0.8.0' here: https://github.com/bitcoin/bitcoin There are no 0.8.x branch or tags here yet: https://git.gitorious.org/bitcoin/bitcoind-stable -- 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] 0.8.0rc1 status
> Linux builds of 0.8.0rc1 are in good shape; easily gitian-reproduceable. > Windows builds are varying with every compile, and I think I finally > The OSX build is in pretty good shape, but needs > So: I think the path forward is to announce 0.8.0rc1 with the binaries > we've got, to get more testing. With this new minor bump, I'd like to encourage the project to perform a build check on FreeBSD 8.3 (gcc), and 9.1 (should be clang/llvm). I'll try to get to 8.x but may not be able to in time. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ 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?
Linux typically uses the FHS, which various distros often bastardize: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs BSD typically uses the traditional hierarchy, for which admins often add /home and /opt: http://svnweb.freebsd.org/base/head/share/man/man7/hier.7?revision=HEAD&view=markup You'd have to read them both and decide which camp you're in. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Since bitcoin isn't really an X app at it's core, XDG doesn't really apply. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 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. And when you figure out where I should place my messages in full the first time, please let me know because I obviously need help. -- 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] 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] 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] 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
> shopping. Good thing I can still spend, even with an incomplete blockchain :) > but why do you also need to encrypt 2+ GB of public record? 1) I'm not seeing an option to split the wallet, debug log and other privates pathwise from the blockchain. 2) Because encrypt everything is reasonable standard practice. https://en.wikiquote.org/wiki/Cardinal_Richelieu [ref: disputed quote] BTW, logs for this box say at least 9 days were spent attempting to crunch the most recent 3100 blocks before it was overrun with new ones and retired. (There's no formal start timestamp, just some entries...) -- 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
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
> 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
> Please fix your software stack. Something is wrong > with your system Nothing wrong, it's all default install. I documented the platform for anyone who wants to confirm it. > A full sync here takes something like an hour. And what, similarly, is your platform? It takes 5 seconds... on my Cray. > I would guess that you are running the blockchain download > through the tor-proxy Use of Tor was stated. Tor is fast enough. I can copy the entire 3GiB of the .bitcoin dir in 7 days... off a slow hidden service. And 0.5 days via exit. > encrypting your disk (aes stuff) will not help you much either Encryption is a perfectly reasonable thing to expect users of bitcoin to be interested in doing. In fact, those not encrypting their disks should probably rethink that plan. > encrypting a the storage of a public blockchain seems to me a bit odd ? Well, without detachdb, it's somehow tied to the wallet, whether while processing or offline. And the wallet and debug.log are not relocatable from the data. And encrypting everything is perfectly reasonable anyways. As is storing your valuable data on filesystems that verify the integrity of their data on disk, such as ZFS/BTRFS. These days, crypto, Tor, and ZFS are common and non-arguments. > I get a full blockchain from scratch in 45 minutes on my laptop Again, timings with no CPU/OS/disk specs are useless infos. -- 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] Scalability issues
Given a testbed: Pentium 4 1.8GHz single core, 2GB ram, FreeBSD 8, disk is geli aes-128 + zfs sha-256, bitcoin 0.6.3, Tor proxy, An estimate is made that by the end of the year bitcoin will completely overrun the capabilities of this reasonable class of machines. It already takes a month to build a new blockchain, let alone keep up with new incoming blocks. Yes, it also has workstation duties, yet even if those were removed, it would probably choke by mid 2013. It would appear bitcoin has some *serious* scalability hurdles coming down the road. Most certainly if the user expects to independantly build, manage, and trust their own blockchain. -- 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] Tor hidden service support
Forward past automoderation... > Reading https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt > Is bitcoin software going to incorporate tor binaries within the > application standard application and automatically create a Tor Hidden > Service on behalf of end-user? > > Are there any direction regarding this kind of integration? The document (Tor.txt) assumes the bitcoin user has taken care of that. So no bi-direction needed (I am not TorProject). > Regarding the addressing, why not use directly the .onion address? > They represent in parallel: > - Routing information (providing a path to the destination) > - Proof of identity (owning the private RSA key) > Which is the reason to map it to an IPv6 address? Seems it's used only within bitcoin code to distinguish which proxy or native IPvN path to send bitcoin traffic to (or receive from). It might be simpler than managing onions, i2p's and whatever else throughout the code and the private bitcoin p2p mesh. Though I don't suspect it will conflict [1] with anyone's use of OnionCat, GarliCat, or Phantom... it would just feel odd configuring bitcoin to use Tor or I2P proxy ports (or Phantom native) when you could conceivably just dump the IPv6 traffic to the OS stack for handling once you have the *Cat shims and Phantom set up. They do have a point about about ocat as a shim for their purposes. And Phantom is a special case in that it's all native IPv6 interface, no proxy or shim needed or provided. I will quote an additional note from bitcoin-devel... "Note that while the hidden service support in bitcoin uses a compatible IPv6 mapping with onioncat, it is _not_ onioncat, does not use onioncat, does not need onioncat, and wouldn't benefit from onioncat. The onioncat style advertisement is used because our protocol already relays IPv6 addresses. The connections are regular tor hidden service connections, not the more-risky and low performance ip in tcp onioncat stuff." FYI. There have been a dozen or so onion:8333 nodes and maybe some on I2P long before this work. But I think could only be used as -connect or -addnode seeds with some extra host setup. Never tried it since -proxy was sufficient. Seems this is a simpler and full solution. [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] [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] 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
[Bitcoin-development] Wallet related bug?
I had previously commented on this. My references to wallet ver were really to nFileVersion. And I've since been able to make that, and the real walletversion become current. However it is still doing this every invocation... Rescanning last 14xxx blocks (from block 170xxx)... Which seems unneeded more than 1x. I cannot yet explain. So I expect to avoid all by send the balance from old wallets to new wallet soon instead. The old wallets were ver 10500. -- 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] 0.6.x - detachdb in wrong place
> This is the work model I use: Will try all these things out this weekend. 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] 0.6.x - detachdb in wrong place
> Workflow is ... Thanks very much, I think that helps me/others. I did not realize there were release windows in master and thought it more as the typical full time dev slush. That also explains the presence of all the release tags in github repo. And even, in a divergent way, the presence of github/0.6.2 as path to gitorius/0.6.x. And I agree with the (last bugfix after release) -> import/maintain model, it would be similar in solo repo. > I guess I've been neglecting to update the stable repo with > releases tagged in master. It should be fixed now. Yes, that has helped! Now git'ers can easily compare the release tags to stable 'x' branches on gitorious. I don't know how to do that across repos yet, save manuel diff of checkouts from each, which would have been required prior to this update you made. Also, these declarations of defunctness help sort out too. # git branch -vv -a "This stable branch is no longer maintained." Ok, so for my works I will now track github/master (edge) and gitorious/0.bigN(eg: 6).x (stable) against gitorious/bigTagRelease (latest public). Thanks guys, and Luke :) I hope other with similar questions find this thread. Apology for subverting its subject somehows. -- 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
> be sure to have good backups that never touched the new code... > We have at various times had bugs in master that would corrupt > wallets Sorry, that's to be expected, I shouldn't have asked. > It would be very helpful if anyone offering bitcoin services would > setup parallel toy versions of your sites on testnet... Good point. > we don't currently have enough testing activity on master. I usually test compile / report current and stable of things I use. So I get that github/master is the obvious top of things. But in looking at where the tags are between repositories, it's still not clear to me what the workflow is. Example... There are these release tarballs on sourceforge, which all have tags in github, yet no tags in gitorious. There are no 'x' branches on github, yet there is one release applicable branch on gitorious. I guess I'd expect to see, that if as hinted by Luke that gitorious has the stable trees, that there would be release tags there, laid down at some comfy point in time on the 'x' stable branches there. (The stable branches inheriting new code from master). But there are no such tags. And the releases/tags seem to magically appear from nowhere on github :) Again, I'm trying to extricate myself from CVS here. # sourceforge tarballs 0.6.0 0.6.1 0.6.2 0.6.2.2 # github branches remotes/origin/master432d28d Merge pull request #1477 from gmaxwell/master remotes/origin/0.6.2 40fd689 Bump version to 0.6.2.2 for osx-special build # github tags v0.6.0 v0.6.1 v0.6.2 v0.6.2.1 v0.6.2.2 # gitorius branches remotes/origin/0.6.0.x d354f94 Merge branch '0.5.x' into 0.6.0.x remotes/origin/0.6.x 5e322a7 Merge branch '0.6.0.x' into 0.6.x # gitorious tags v0.6.0.7 -- 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
>> https://github.com/bitcoin/bitcoin >> https://git.gitorious.org/bitcoin/bitcoind-stable > > The latter is Luke's backports of security and stability fixes to > otherwise unmaintained old versions. Ah ok, coming from cvs/svn, it's a bit different to find things. There's something to be said for maintenance of pior branches. Though I see some things I can use in github and my work would be more useful there, so maybe I'll stwitch to that from gitorius/0.6.x. Presumably the github/0.6.2 branch is safe for production? What degree of caution about wallet eating should be made for those using github/master? -- 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] 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
[Bitcoin-development] Manual file cleanup on exit, safe? [coredump backtrace]
When bitcoind exits cleanly, it does not seem safe for the blockchain to clean up the following hierarchy with rm -r ? database/ db.log .lock debug.log addr.dat wallet.dat And what about adding to the above list the following files when bitcoind crashes: __db.* Is there an option to make bitcoind roll/flush the above files on exit so they can be removed/ported? No matter the answers, bitcoind should not be dumping core. Bitcoin version v0.6.2.2-unk-beta () Default data directory /.../.bitcoin Loading addresses... dbenv.open LogDir=/.../.bitcoin/database ErrorFile=/.../.bitcoin/db.log EXCEPTION: 11DbException Db::open: Invalid argument bitcoin in AppInit() terminate called after throwing an instance of 'DbException' what(): Db::open: Invalid argument sh: abort (core dumped) file unknown has LSN 38/7968116, past end of log at 1/28 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment __db_meta_setup: /.../.bitcoin/addr.dat: unexpected file type or format [New Thread 28801140 (LWP 100964/initial thread)] (gdb) bt #0 0x2873e9a7 in kill () from /lib/libc.so.7 #1 0x2852d397 in raise () from /lib/libthr.so.3 #2 0x2873d4da in abort () from /lib/libc.so.7 #3 0x285a0880 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0x285a508a in std::set_unexpected () from /usr/lib/libstdc++.so.6 #5 0x285a50d2 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0x285a4f58 in __cxa_rethrow () from /usr/lib/libstdc++.so.6 #7 0x0816d2ea in PrintException (pex=0x288251b0, pszThread=0x82f4cfa "AppInit()") at util.cpp:792 #8 0x08087625 in AppInit (argc=2, argv=0xbfbfedf0) at init.cpp:113 #9 0x0808766d in main (argc=Cannot access memory at address 0x3) at init.cpp:96 -- 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] RPC and signals - processing priority
While happily processing these: received block ... SetBestChain: new best=... height=... work=... ProcessBlock: ACCEPTED bitcoind very often refuses to answer rpc queries such as getinfo/stop, or signals such as kill/ctrl-c. It even registers: ThreadRPCServer method=getinfo/stop in the debug log. But the action doesn't happen as expected. Shouldn't it be checking and processing all user interrupts like once per block and doing the chain in the background? How do busy commerce servers deal with this poor rpc handling? Is there a way to increase the priority of user scheduled tasks? What's going on? 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
> "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
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
> 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
> 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] off-topic: bitcoin-forum...
> Some time ago i started a googlegroup mailing list, bitcoin-discussion. > It's been pretty low-volume... but it's something. :) > http://groups.google.com/group/bitcoin-discussion Unfortunately it appears to be just as dead as the one on sourceforge. > or we could try to revive the bitcoin-list ml on sf. Well there's a couple things I see... 1) Yes, IMO, a real mailing list for users needs to exist. Among the prior reasons... lists tend to house a more technical crowd than forums which are magnets for initiates. 2) There was originally one client. Now there are many, all adherant to the same bitcoin spec. So while: bitcoin-development@lists.sourceforge.net represents the dev community for the original client, it may not, or won't be, for any other client. And as: bitcoin-l...@lists.sourceforge.net was for, and is administratively tied to, the original client... it may not be the place, or a welcome one, to hold talk of all the adherant clients. 3) The sourceforge list browsing interface is ridiculously lame and overweight, and it doesn't appear to be setting a '^Reply-to: ' header which is bad. Googlegroups would be an ok site I suppose. And a pure MailMan interface would be even better and more customarily accepted. So for the user list, I'd suggest: 1) Search a bit to make sure there's not already a busy list out there somewhere. Check the list aggregator sites like markmail, gmane, etc too. 2) Charter it as bitcoin protocol, client agnostic. 3) Find an impartial administrative and robust home for the list with browsable, searchable and hopefully downloadable archives. 4) Make the announcement to other known client lists/forums. 5) Close any relevant old lists. 6) Promote via similar announcement from time to time. http://groups.google.com/group/bitcoin-discussion/about Description: A place for discussion related to bitcoin. Is this sufficient charter to go with? Is the creator/maintainer known impartial? What happens to ongoing list operations when said people vanish? It is presumed googlegroups itself is robust. -- Try before you buy = See our experts in action! 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-dev2 ___ 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] off-topic: bitcoin-forum...
> I am trying to post on the bitcoin forums (bitcointalk.org) I wish there were a bitcoin-user mailing list??? But the one on sourceforge is dead. Forums are too full of avatars, smilies, sigblocks and dead mass to be of much use. Not to mention when they vanish, any content dies with it instead of living on in various archives. -- 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
[Bitcoin-development] Some state/data file info
I've been playing with the tools in db 4.8.30, and bitcoin stable... My blockchain is up to date. Bitcoin is not running. # strings database/* This will at times yield the addresses in your wallet. So it's not exactly in compliance with 'only your wallet file matters'. Bitcoin always leaves behind at least one "database/log.nnn" file. Shouldn't it roll and delete it on exit like it does the other state files? Particularly after a simple "we're able to do nothing but local operations" invocation like: bitcoind -proxy=127.0.0.1:9050 -keypool=0 -connect=127.0.0.1 -nodnsseed -noirc Similarly, the ".lock" file is never deleted. Shouldn't it be upon exit? Vacuuming addr, blkindex, and wallet with "db_dump | db_load" will save significant space. I do not yet know how to view or validate blk0001.dat. When left with junk, I've been removing everything except: addr.dat - node addresses bitcoin.conf - config blk0001.dat - blocks blkindex.dat - index to blocks wallet.dat - wallet -- 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] 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
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
[Bitcoin-development] Scaling at the end user level
A freshly deployed client on an old p4 has been idly crunching away at building and verifying the initial chain for about a week now. It should be done in a day or two. This seems rather untenable for new users. 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. Of some known future issues... raw transaction rate, the eventual pay (or extort?, depending on how megapools pan out) to process mining environment, and scaling the client count itself... this one appears to be already present. -- 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] 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] CAddrMan: Stochastic IP address manager
> I think it's important that we have more mechanisms then just DNS and > hardcoded seednodes. > This is important because the mechanisms we have are all pretty > subject to blocking. Now— before you say it— Bitcoin isn't intended to > be blocking resistant (combine it with Tor and Tor anti-censorship > tools) > Is the fact that users can addnodes / addr.txt enough of an > alternative to address this? Perhaps not worry about removing it too much. As above, if blocking or other issues arise, people will be hosting manual lists and nodes on hidden sites... Tor/I2P/etc. The nodes are already there. For that matter, since the nodes are talking once seeded, why not deploy a DHT and be done. All you'd need is one friendly node and the list comes in and maintains itself through node expiry rules. Your node publishes its hello for others to discover, etc. IRC, DNS, etc would go away in favor of autonomy. It wouldn't be any more resistant. But if people wanted that, some form of signatures from the hidden nodes would do... if you trusted them. Booting and running is easy, trust isn't (ask the Tor/I2P people). -- 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] Compilation warnings with -Wall
This is counted from the current git master on bsd. The first two are of note and should probably be looked at. A little more work after those and it might be possible to use -Wall by default as addressing even some of these would remove tons of lines from the output :) 1 net.cpp:141: warning: 'pszGet' may be used uninitialized in this function 1 net.cpp:142: warning: 'pszKeyword' may be used uninitialized in this function 1 script.cpp:1427: warning: unused variable 'n' 1 test/miner_tests.cpp:14: warning: unused variable 'pstate' 1 bitcoinrpc.cpp:1533: warning: unused parameter 'parg' 1 bitcoinrpc.cpp:2366: warning: unused parameter 'parg' 1 db.cpp:337: warning: unused parameter 'nHeight' 1 init.cpp:36: warning: unused parameter 'parg' 1 init.cpp:44: warning: unused parameter 'parg' 1 init.cpp:705: warning: unused parameter 'fAutoStart' 1 irc.cpp:258: warning: unused parameter 'parg' 1 json/json_spirit_reader_template.h:362: warning: unused parameter 'i' 1 json/json_spirit_reader_template.h:381: warning: unused parameter 'end' 1 json/json_spirit_reader_template.h:386: warning: unused parameter 'end' 1 json/json_spirit_reader_template.h:391: warning: unused parameter 'end' 1 json/json_spirit_reader_template.h:401: warning: unused parameter 'end' 1 main.cpp:3130: warning: unused parameter 'pindexPrev' 1 net.cpp:1063: warning: unused parameter 'parg' 1 net.cpp:1209: warning: unused parameter 'parg' 1 net.cpp:1380: warning: unused parameter 'parg' 1 net.cpp:1480: warning: unused parameter 'parg' 1 net.cpp:1617: warning: unused parameter 'parg' 1 net.cpp:200: warning: unused parameter 'parg' 1 net.cpp:619: warning: unused parameter 'parg' 13 noui.h:40: warning: unused parameter 'parent' 13 noui.h:40: warning: unused parameter 'style' 13 noui.h:40: warning: unused parameter 'x' 13 noui.h:40: warning: unused parameter 'y' 13 noui.h:53: warning: unused parameter 'nFeeRequired' 13 noui.h:53: warning: unused parameter 'parent' 13 noui.h:53: warning: unused parameter 'strCaption' 13 noui.h:58: warning: unused parameter 'nField' 13 noui.h:58: warning: unused parameter 'strText' 13 noui.h:62: warning: unused parameter 'fn' 13 noui.h:70: warning: unused parameter 'message' 23 script.h:352: warning: unused parameter 'b' 1 serialize.h:1131: warning: unused parameter 'nType' 1 serialize.h:1131: warning: unused parameter 'nVersion' 31 serialize.h:176: warning: unused parameter 'a' 53 serialize.h:460: warning: unused parameter 'nType' 53 serialize.h:460: warning: unused parameter 'nVersion' 66 serialize.h:482: warning: unused parameter 'nType' 66 serialize.h:482: warning: unused parameter 'nVersion' 66 serialize.h:505: warning: unused parameter 'nType' 66 serialize.h:505: warning: unused parameter 'nVersion' 611 serialize.h:747: warning: unused parameter 's' 611 serialize.h:747: warning: unused parameter 'ser_action' 607 serialize.h:753: warning: unused parameter 'ser_action' 671 serialize.h:760: warning: unused parameter 'ser_action' 1 test/test_bitcoin.cpp:25: warning: unused parameter 'parg' 23 uint256.h:359: warning: unused parameter 'nType' 23 uint256.h:359: warning: unused parameter 'nVersion' 66 uint256.h:365: warning: unused parameter 'nType' 66 uint256.h:365: warning: unused parameter 'nVersion' 45 uint256.h:371: warning: unused parameter 'nType' 45 uint256.h:371: warning: unused parameter 'nVersion' 1 util.cpp:1184: warning: unused parameter 'nLine' 1 util.cpp:1184: warning: unused parameter 'pszFile' 1 util.cpp:1184: warning: unused parameter 'pszName' 1 util.cpp:48: warning: unused parameter 'file' 1 util.cpp:48: warning: unused parameter 'line' 28 util.h:682: warning: unused parameter 'nExitCode' 28 util.h:697: warning: unused parameter 'pfn' 1 wallet.cpp:320: warning: unused parameter 'fFindBlock' -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
