Re: [Bitcoin-development] Running a full node
> But I'd like to know what storage, RAM and bandwidth resources are > needed. I guess that the problem is not the CPU. Hi Francis, Here are some rough guidelines for you, based on the statistics from my node: disk usage: about 30GB currently for the blockchain data. It'll only keep growing from here, but relatively slowly. cpu usage: pretty much nothing, after you have synced the blockchain. ram usage: after it runs for a few months, my node gets up to using 1.5 GB of ram or so. bandwidth usage: my node averages about 500GB of traffic per month, most of it outgoing. Hope that gives you a rough idea of what you can expect for running full node. Best, Daniel -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
This discussion is quite bikesheddy, but (or thus? :) ) I will put in my 2c. The main thing to think about, I think, is "what would be best for the users". To that end, I suggest the following: * I do think a page on bitcoin.org listing relatively major, and relatively vetted, clients is a good idea. Removing it completely and relegating it to a wiki page, which is likely to contain all sorts of marginal crufty clients, would likely be a disservice to the users. * Randomized order is likely also a disservice to the users. We should list clients in order of "goodness", as determined by whoever(s) we decide to put in charge of the page. This "goodness" should likely to be some kind of weighted average of features, security, goodness for bitcoin network, etc. [1] ** If randomized order is after all chosen, it should be done in javascript client-side, rather than doing daily page reorgs. If people without JS don't see random, it's not material at all. * Prose vs. feature matrix: both have their good and bad points, as discussed upthread. I think the users will be best served by a combination of both: ** Prose descriptions of clients should deliberately include negative points, not just let the user infer them by lack of corresponding positive mention. (e.g. "This client has fast startup time. That means you're completely trusting the server operator with your money.") This task is left up to the person(s) in charge. ** A feature matrix, with carefully chosen and /well defined/ categories, /in addition to prose/ would likely also be of service to the users. That could be left to the wiki though. The current wiki clients page seems to be having a good go at it.[2] ** If we are targeting people who "don't know what they're doing", it may be a good idea to have a 'decision assistant' type setup, where users are asked several questions and are recommended clients based on these answers. (This could be done in a static way by having a matrix of questions.) Finally - I'd say we're spending disproportionate developer resources on this question, and if it were completely up to me, I'd resolve this situation in the following quick-and-painless way: leave page as is, add negative points to prose, link to wiki clients list. Estimated time to completion: 1 hour (to think through which negative points to add). [1] Meehl, 1954, clinical versus statistical prediction... (see also Grove and Meehl, 1996; Sawyer, 1966) (and yes, despite the age of some of this research, the conclusions have been surprisingly robust and timeproof.) [2] https://en.bitcoin.it/w/index.php?title=Clients&oldid=28615 -nanotube signature.asc Description: OpenPGP digital signature -- 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] Bitcoin Testing Project
on 09/25/2012 02:32 PM steve said the following: > Anyone interested in helping out/reviewing processes? even if it is just > some encouragement, it is all greatly appreciated. not enough time in the day for me to seriously help out, but since you asked, here's some encouragement. :) more testing == good. signature.asc Description: OpenPGP digital signature -- 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] Bitcoin Testing Project
on 09/26/2012 01:49 AM Wladimir said the following: > I'm willing to write this. But I know these kinds of proposals always > end in a big discussion about what should be and what should not be on > bitcoin.org, however we should be a bit pragmatic here. May I suggest a page bitcoin.org/developers, that links to a wiki page of developer resources? That way there's an easy link from the main site, but the content is readily editable and expandable. signature.asc Description: OpenPGP digital signature -- 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] Proposal: MultiBit as default desktop client on bitcoin.org
on 07/09/2013 06:56 AM Jim said the following: > + it will bump up the MultiBit download from about 11MB to 30-40MB > (I think). This drops the maximum copies of MultiBit the multibit.org > server can deliver per day from around 90,000 to 30,000ish. > The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
on 07/09/2013 10:28 AM Mike Hearn said the following: > SourceForge has a horrible UI and blocks some countries. It also exposes > us to a large and potentially hackable mirror network. Whilst we're not > bandwidth constrained on our own servers, let's try and keep using them. the point was just that "if need be" free capacity is available without having to throw money at it. until there's no need, doesn't matter. also hackability (and ui) should be irrelevant for the autoupdate process (which i presume will do all kinds of checksum and sig verification). and it's likely the autoupdates that will create very lumpy download demand. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
If you want package authentication, you should at least throw in some digital signing, not just a checksum. With a compromised host, both the checksum and binaries can be changed undetectably, but if there's a signature made by a key that is not kept on the host, there's no way to fake a valid binary. There may be other issues people would want to bring up, but surely just a checksum is not sufficient. on 08/05/2013 10:39 AM Wendell said the following: > For usability purposes, we at Hive would like to have an > auto-updater in our wallet app. > > What is a safe way to do this? I understand that Bitcoin-QT lacks > such an updater for security reasons... Has been thought out in more detail since that decision was made? > > We have been toying around with the idea of placing one server > behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. > > Any thoughts or advice about any of this? > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > > > -- > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > > > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
> This is a decentralized currency, and we should avoid centralizing > decisions. This is something that impacts the community at large, and > deserves input and discussion at every level. > > I would suggest posting on all possible forums "proposal: switch to > uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion > is generated. If the support is broad, it will be plain from the > responses if there is a consensus. Perhaps everyone will agree it is > the best course, and we can make an easy change. > > But we need less "core dev fiat" not more :) > this seems like such a paint-the-bikeshed problem that it's sure to generate vast volumes of discussion, waste a lot of people's time, and all for only a dubious (imo) gain. (case in point - here i am contributing to it :) ). i agree that we should avoid centralizing this. i'll go a step further and note that the client already has a dropdown allowing individuals to choose units. merchants are free to choose to price in different units. exchanges are free to denominate trade in different units. i suggest we just let the market do its thing and not get into trying to 'make a decision' of any sort. -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)
> Does anybody besides me think maybe we should name them something > other than "BEP" ? > > I'm worried we'll regret it in two years when a google for "BEP003" > takes you to the BitTorrent EPs instead of the BitCoin EPs. this is an excellent "painting the bikeshed" question, so i cannot resist participation :) imo, anyone who has any business looking at the beps (which would generally be technically-minded people), will be smart enough to google for "bitcoin bep003" to find what he's looking for. so i don't see an issue, whatever acronym we end up using. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin 0.4.0 released
> Can you post secure file checksums somewhere, preferably not on Sourceforge? as long as it's gpg-signed, what's the difference where it is posted? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Wiki
+1 on git. not necessarily as replacement, but at least as backup. could possibly use markdown and github pages, which automagically pushes git commits out to the website (uses markdown syntax, iirc) On Thu, Oct 27, 2011 at 11:22 AM, Nils Schneider wrote: > Can we use a git repo or something more redundant for BIPs? They're > rather important and the wiki has been unreliable before. > > On 27.10.2011 17:15, Amir Taaki wrote: >> Anybody know how to contact MT about getting it back online? I still >> haven't finished copy-editing the BIPs and need access to them since >> there's a new one to be added. >> >> >> -- >> The demand for IT networking professionals continues to grow, and the >> demand for specialized networking skills is growing even more rapidly. >> Take a complimentary Learning@Cisco Self-Assessment and learn >> about Cisco certifications, training, and career opportunities. >> http://p.sf.net/sfu/cisco-dev2dev >> >> >> >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall > a picture of their QR code and a bitcoin address. I don't own a mobile phone > so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. ok, imagine if firstbits didn't exist. instead of going to firstbits, you would have gone to your terminal, opened up brmlabs website, and copied the address from there? there may be some arguments for name-> address translation, but i'm sorry to say, that your example is not one of them. if anything, it seems to suggest that firstbits is completely useless, since it saves approximately zero effort. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On Mon, Dec 12, 2011 at 9:37 PM, Amir Taaki wrote: > lol, way to miss the point nanotube. > > FirstBits *is* useless, but not for the reasons you specified. But simply > because the resources it needs rises exponentially as the number of > participants in the network grows linearly. > > The point is that if FirstBits were built into the implementation, that would > allow me to simply send to 1brmlab. The proposal here is not for a website > where people can lookup bitcoin addresses, but a shared naming scheme between > bitcoin implementations. Here's the story again: well, it's easy to miss the point when the example you use doesn't make the point you think you're making. :D but ok, yes, it would be nice to send directly to something like 1brmlab from the client. i suppose figuring out how to make sure that 1brmlab actually does send to whom you think it sends, is left to the details of implementation, but that's a separate question. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] off-topic: bitcoin-forum...
on 02/19/2012 04:32 PM grarpamp said the following: >> 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. 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 or we could try to revive the bitcoin-list ml on sf. -- 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...
on 02/19/2012 07:13 PM grarpamp said the following: >> 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. That's exactly what i said above, in a more euphemistic fashion :D > 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. indeed. > 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. i'm sure that with the list being unused, we could change the charter and do whatever with it, and the people who matter probably won't object. > 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. Indeed, good points on all counts. > 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. good points. re 1), i'm pretty sure that -dev is the most active bitcoin-related public mailing list. things may have changed in the past half-year, but it seems unlikely. > 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. charter can be changed if needed. creator/maintainer, that being me, is generally known to be a pretty decent guy :). i'm not attached to this particular list though, but whatever happens, i'd hope that there will be more people willing to share administrative duties. not sure if googlegroups is the best interface, if we can find some good free host with mailman, downloadable archives, the works, that may be preferable. i started that group on gg simply because it was free and easily available and easy to set up. -- 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
