Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote: No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I did wonder what the post actually meant, I recommend appending /s after sarcasm so it's clear. Lots gets lost in text. But I agree with you btw his response was not particularly tactful. On Mon, Jun 1, 2015 at 7:19 PM, Warren Togami Jr. wtog...@gmail.com wrote: By reversing Mike's language to the reality of the situation I had hoped people would realize how abjectly ignorant and insensitive his statement was. I am sorry to those in the community if they misunderstood my post. I thought it was obvious that it was sarcasm where I do not seriously believe particular participants should be excluded. On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle thyshiz...@outlook.com wrote: Doesn't mean you should build something that says fuck you to the companies that have invested in farms of ASICS. To say Oh yea if they can't mine it how we want stuff 'em is naive. I get decentralisation, but don't dis incentivise mining. If miners are telling you that you're going to hurt them, esp. Miners that combined hold 50% hashing power, why would you say too bad so sad? Why not just start stripping bitcoin out of adopters wallets? Same thing. -- From: Warren Togami Jr. wtog...@gmail.com Sent: 1/06/2015 10:30 PM Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements Whilst it would be nice if miners in *outside* China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in *outside* China can't get the trivial amounts of bandwidth required through their firewall *TO THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad, we'll have to carry on without them. On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
Gavin and @NicolasDorier have a point: If there isn't actually scarcity of NOPs because OP_NOP10 could become type OP_EX (if we run out), it makes sense to chose the original unparameterised CLTV version #6124 which also has been better tested. It's cleaner, more readable and results in a slightly smaller script which has also got to be a plus. On Tue, May 12, 2015 at 8:16 PM, Jorge Timón jti...@jtimon.cc wrote: This saves us ocodes for later but it's uglier and produces slightly bigger scripts. If we're convinced it's worth it, seems like the right way to do it, and certainly cltv and rclv/op_maturity are related. But let's not forget that we can always use this same trick with the last opcode to get 2^64 brand new opcodes. So I'm not convinced at all on whether we want #5496 or #6124. But it would be nice to decide and stop blocking this. On Sat, May 9, 2015 at 11:12 AM, Peter Todd p...@petertodd.org wrote: On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Done! https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 -- 'peter'[:-1]@petertodd.org 12c438a597ad15df697888be579f4f818a30517cd60fbdc8 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net wrote: And I'll ask again. Do you have a *specific, credible alternative*? Because so far I'm not seeing one. I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com wrote: Can anyone opposed to this proposal articulate in plain english the worst case scenario(s) if it goes ahead? Some people in the conversation appear to be uncomfortable, perturbed, defensive etc about the proposal …. But I am not seeing specifics on why it is not a feasible plan. See this response: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net wrote: Right now there is this nice warm fuzzy notion that decisions in Bitcoin Core are made by consensus. Controversial changes are avoided. I am trying to show you that this is just marketing. Consensus is arrived when the people who are most active at the time (active in contributing to discussions, code review, giving opinions etc.) agreed to ACK. There are a regular staple of active contributors. Bitcoin development is clearly a meritocracy. The more people participate and contribute the more weight their opinions hold. Nobody can define what these terms even mean. It would be more accurate to say decisions are vetoed by whoever shows up and complains enough, regardless of technical merit. After all, my own getutxo change was merged after a lot of technical debate (and trolling) . then unmerged a day later because it's a shitstorm. I am not sure that is fair, your PR was reverted because someone found a huge exploit in your PR enough to invalidate all your arguments used to get it merged in the first place. So if Gavin showed up and complained a lot about side chains or whatever, what you're saying is, oh that's different. We'd ignore him. But when someone else complains about a change they don't like, that's OK. Heck, I could easily come up with a dozen reasons to object to almost any change, if I felt like it. Would I then be considered not a part of the consensus because that'd be convenient? I don't think it's as simple as that. Objections for the sake of objections, or unsound technical objections are going to be seen for what they are. This is a project with of some of the brightest people in the world in this field. Sure people can be disruptive but their reputation stand the test of time. The consensus system might not be perfect, but it almost feels like you want to declare a state of emergency and suspend all the normal review process for this proposed hard fork. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the patch. Game over. You cannot have committers fighting over what goes in and what doesn't. That's madness. There must be a single decision maker for any given codebase. You are conflating consensus with commit access. People with commit access are maintainers who are *able to merge* pull requests. However, the rules for bitcoin development are that only patches with consensus get merged. If any of the maintainers just pushed a change without going through the whole code review and consensus process there would be uproar, plain and simple. Please don't conflate commit access with permission to merge because it's just not the case. No-one can sidestep the requirement to get consensus, not even the 5 maintainers. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
On Mon, May 4, 2015 at 6:07 AM, Peter Todd p...@petertodd.org wrote: Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. [snip] That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Drak -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
Mike, In all seriousness, are you on the payroll of the NSA or similar to repeatedly attempt to introduce privacy leaks[1] and weaknesses[2] into the ecosystem not to mention logical fallacies like ad hominem attacks; disruption[3] and FUD[4]? Why do you answer objections by hand waving and misdirection as opposed to sound technical reasoning? Remember how hand waving ended for you the last time with your p2p getutxo pull-request[5] and the public flogging the ensued because you refused to accept your implementation was not only flawed but critically vulnerable to attack[6]. Given your intelligence, education and experience, it would seem logical that your behaviour is not random or irrational, but in fact calculated and planned. references: [1] http://www.reddit.com/r/Bitcoin/comments/2byqz0/mike_hearn_proposes_to_build_vulnerable/ [2] https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/ [3] http://www.reddit.com/r/Bitcoin/comments/28zts3/mike_hearn_interview_quotes_progress_on_the/ [4] https://www.youtube.com/watch?v=iMIzMVABFxQ [5] https://github.com/bitcoin/bitcoin/pull/4351 [6] http://www.reddit.com/r/Bitcoin/comments/2eq8gi/getutxos_a_convenient_way_to_crash_bitcoind/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ACK NACK utACK Concept ACK
Would someone also clarify the use of nit for nitpicking and how it plays in the role of consensus? It seems like it's used for minor complaints/preferences. Drak On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik jgar...@bitpay.com wrote: On Wed, Dec 10, 2014 at 1:47 AM, Wladimir laa...@gmail.com wrote: Concept ACK - agree with the idea and overall direction, but haven't reviewed the code changes nor tested it Concept ACK - like the idea; the code may need rewriting (or haven't reviewed). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
This is a pretty good example about refactoring discipline as well as premature/over optimisation. We all want to see more modular code, but the first steps should just be to relocate blocks of code so everything is more logically organised in smaller files (especially for consensus critical code). Refactoring should come in a second wave preferably after a stable release. Refactoring should be in the pure sense, optimising code with absolutely no change in behaviour. When it comes to actual API changes, I think we need to be a lot more careful and should be considered feature requests and get a lot more scrutiny as we are essentially breaking backwards compatibility. #4890 was pretty much merged with no discussion or thought yet other really simple and uncontroversial PRs remain unmerged for months. A key question in the case of EvalScript() would have been, why are we passing txTo and nIn here, and are there any future use cases that might require them? Why should this be removed from the API and the entire method signature changed?. BC breaks always need strong justification. So I've expressed my concern a few times about the speed and frequency of refactoring and also the way it's being done. I am not alone, as others not directly connected with the Bitcoin Core project have also expressed concerns about the number of refactorings for the sake of refactoring, especially of consensus critical code. Careful as we may be, we know from history that small edge case bugs can creep in very easily and cause a lot of unforeseen problems. BtcDrak On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org wrote: BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few days ago and found a fairly large design change that makes merging it currently impossible. Pull-req #4890², specifically commit c7829ea7, changed the EvalScript() function to take an abstract SignatureChecker object, removing the txTo and nIn arguments that used to contain the transaction the script was in and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the nLockTime field of the transaction, and it needs nIn to obtain the nSequence of the txin. We need to fix this if CHECKLOCKTIMEVERIFY is to be merged. Secondly, that this change was made, and the manner in which is was made, is I think indicative of a development process that has been taking significant risks with regard to refactoring the consensus critical codebase. I know I personally have had a hard time keeping up with the very large volume of code being moved and changed for the v0.10 release, and I know BtcDrak - who is keeping Viacoin up to date with v0.10 - has also had a hard time giving the changes reasonable review. The #4890 pull-req in question had no ACKs at all, and only two untested utACKS, which I find worrying for something that made significant consensus critical code changes. While it would be nice to have a library encapsulating the consensus code, this shouldn't come at the cost of safety, especially when the actual users of that library or their needs is still uncertain. This is after all a multi-billion project where a simple fork will cost miners alone tens of thousands of dollars an hour; easily much more if it results in users being defrauded. That's also not taking into account the significant negative PR impact and loss of trust. I personally would recommend *not* upgrading to v0.10 due to these issues. A much safer approach would be to keep the code changes required for a consensus library to only simple movements of code for this release, accept that the interface to that library won't be ideal, and wait until we have feedback from multiple opensource projects with publicly evaluatable code on where to go next with the API. 1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 2) https://github.com/bitcoin/bitcoin/pull/4890 -- 'peter'[:-1]@petertodd.org 1b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get
Re: [Bitcoin-development] bitcoind as a library
On Fri, Nov 28, 2014 at 5:22 PM, Oliver Egginger bitc...@olivere.de wrote: Sorry for the off-topic but while reading this I like to ask you for picocoin, see: https://github.com/jgarzik/picocoin For a research project I'm looking for a C library to operate some block chain analysis (parsing raw blocks and transactions). This might be useful for you https://github.com/MatthewLM/cbitcoin -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon flavien.char...@coinprism.com wrote: My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes. For Open Assets https://github.com/OpenAssets/open-assets-protocol, we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average. Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough. While I am not opposing the proposal, I am not sure about your statistics because while Counterparty is not currently using OP_RETURN encoding, you should factor in the number of CP transactions that would have been OP_RETURNs if they had been permitted (100,000 since inception according their blog[1] with monthly charts at their block explorer[2]). Refs: [1] http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/ [2] http://blockscan.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Sun, Oct 19, 2014 at 8:17 AM, xor x...@freenetproject.org wrote: I joined the list when Bitcoin was already in the 10-billions of market capitalization, and it actually really surprised me how low the traffic is here given the importance of Bitcoin. So as a random stranger to the project, I would vote against that if I was allowed to. There really should be *more* discussion here, and splitting the list up won't help with that. I agree. This is also where the best peer review is to be found. Splitting the list will dilute this. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Wed, Oct 15, 2014 at 4:54 PM, Adam Back a...@cypherspace.org wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Please not sourceforge. * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. Mailman is good enough... -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
