pindi

Not quite. The essence of a double-spend attack is creating two transactions spending the same bitcoin: one to the merchant (call it A) and one to another of your accounts (call it B). You send A to the merchant and secretly submit B to another node. A looks valid to the merchant, so they accept it.

Now it's basically a 50-50 chance of which transaction will make it into the ledger and which will be rejected as invalid because the input was already spent. If you have your own compute power, you can shift this, up to the extreme of having >50% of the total power, in which case you can guarantee B is accepted, since you can outmine any chain that includes A. However, there is no reason you would need to forfeit any reward if you personally mine the block with the transaction in it.

Confirmations shift the probabilities back towards the merchant, since no honest node will mine on a chain not already including A because the one including A is longer. In this case you must mine secretly on the chain including B until it exceeds the length of the chain including A. This absolutely requires more than 50% of the network compute power, since you must totally outmine the honest network. But again, if you can get the length of chain B up to the point where it exceeds chain A, the block rewards in chain B are yours and those in chain A are forfeit.

I don't know that comparing EC2 reserved instances to DigitalOcean is really "apples-to-apples", since DigitalOcean has hourly billing and no upfront cost just like EC2 on-demand, and unlike EC2 reserved.

I think the focus is on pedantic corrections that are entirely irrelevant to the discussion and serve only to make the commenter feel superior. For example, see this recent thread [1].

The first commenter proposes a device that would use a Molex connector. The second points out that the device needs to interface with a wire not found on the Molex 8981 connector, a useful correction. The third makes the inane observation that Molex the company makes many connectors, when it is obvious that the first two commenters were referring to the Molex 8981 connector specifically.

[1] https://news.ycombinator.com/item?id=5638420

A similar method is a "pepper", a form of salt common to all users and stored in the application configuration, allowing the passwords to resist attack even if the hash and user-specific salt are lost. The reason it's not often used is that the assumption is that if your database is compromised, any other commonly-used secret keys on the server will be too. It can be useful for defense in depth, though.

Also IcoMoon for generating icon fonts: http://icomoon.io

Well, not dangerous so much as will fail with a "Model instance is not JSON serializable" message. So of course you'll need to construct the list/dictionary representation of your data manually. A good framework can help with that, but this isn't something that's solvable in the general case with just a response subclass without risking data leaks as you stated. (The other option in the original post makes this mistake, making both suggested options insecure)

> Django does not have a built in JSON HTTP response, so you are going to have to either man up and roll your own (good luck)

Am I missing something? What's wrong with:

   return HttpResponse(json.dumps(data), mimetype='application/json')

The JSONResponse class suggested automatically implements JSONP, which is extremely dangerous. Consider a view on /accounts/info which returns some information about the currently logged in user. A malicious site could embed

  <script src="http://example.com/accounts/info?callback=someFunction">

Good idea, posted my reply: https://github.com/zmoazeni/csscss/issues/25

It seems like when run on SCSS mode, it expands mixins before running the redundancy check. For instance, two of my selectors both include three of the same mixins, which end up expanding into 23 rules, and CSSCSS reports 25 shared rules between them. (Further inspection confirms that exactly 2 normal rules are shared.)

I would think that using mixins should also count as having eliminated redundancy. A simple solution would be to ignore them, or more ideally the redundancy check could treat mixins just as a normal rule, so that it could detect using the same set of mixins in multiple places as redundancy.

Sounds like Google TiSP: http://www.google.com/tisp/install.html

You may want to mention that the Python library is not thread-safe, since it essentially uses a global variable to store the logged statements until the middleware writes them to the response. Shouldn't be a problem when used with a development server, though.

It's certainly detectable with precise instruments, but it's not practical to test each and every bit of gold one acquires so thoroughly. Hence the opportunity for counterfeit gold that passes casual inspection and weighs about the right amount.

Tungsten has a density extremely similar to that of gold (19.25 g/cm³ for tungsten, 19.30 g/cm³ for gold), and is substantially less expensive. And tungsten counterfeiting does happen: http://www.zerohedge.com/news/tungsten-filled-10-oz-gold-bar...

It's used in the sense of "decentralized": no one company controls the Persona system as a whole. Authentication is performed against the domain of the email address the user gives, falling back to authenticating with Mozilla's central server if and only if the domain doesn't support Persona yet.

Memory corruption is generally defined as occurring when the contents of RAM are modified in a way not intended by the original programmers. [1] Under this definition, buffer overflow attacks would certainly qualify, as would this exploit.

[1] http://en.wikipedia.org/wiki/Memory_corruption

I have a system exactly like this at my company, with a prettier UI on top of the SQL querying. I've been considering open sourcing it for a while; I wonder if there really is a demand for this, or if it's one of those things that everyone prefers to roll themselves.

Well, if they crashed on a certain block then the operators of the client would notice and presumably update to a newer version of the client. The problem in this case was more subtle: the old clients did not crash on the block, they simply rejected it as invalid and continued working on an alternate subtree.

If you did somehow create a block that all clients except yours crashed on, you still wouldn't gain control of the network because the difficulty of creating a new block is calibrated according to the total power of the network, and only re-calibrates every few blocks. So for a while, you would still be effectively competing against the former power of the network, giving the client developers time to fix the crash.

No. You would have 100% control of the subtree following that failing block, but it would be very quickly outpaced by another subtree that the rest of the network would be working on. You need to construct a block that close to 50% of clients fail on, so that the network's work is split between two subtrees and they grow at about the same rate.

Puppet does have a single run mode of usage: http://docs.puppetlabs.com/man/apply.html

I use it to manage just 5 servers, with a Fabric script that rsyncs the manifests up to the servers then runs `puppet apply` to apply the changes.

When run in client-server mode, Puppet will run every 30 minutes by default, overwriting local changes with the configuration on the server.

When defining our initial data schema, we forgot to put a unique constraint on user email addresses. There ended up being quite a few duplicates, so before we added the constraint I had to write a query to remove the duplicate users. About 2/3 of our users didn't have an email listed, and my query failed to take that into account, so it wiped out all but one of those users.

When developing Javascript apps locally, I often use SimpleHTTPServer so I can access them through http:// rather than file:/// URLs, which tend to interact badly with the same-origin policy.

No, Django's XML deserialization is not used automatically. It is only used for mass importing objects to the database, which most sites would allow only admin users to do.

"Node.py" is Twisted [1] and/or Tornado [2]. And you're definitely correct.

[1] http://twistedmatrix.com/trac/

[2] http://www.tornadoweb.org/

They do, you just have to request it:

    //Python
    >>> repr(1000000 * 8.2)
    '8199999.999999999'
    >>> "%lf" % (1000000 * 8.2)
    '8200000.000000'

Not quite: Dwarf Fortress has always used OpenGL (http://www.bay12forums.com/smf/index.php?topic=28841.0) to render tiles that just happen to be ASCII characters onto the screen. The fan effort was to port it to SDL, making it much more efficient.

A great initiative from a great team.

For anonymous users, generate a random token and store it in a cookie. Or you can use the IP address as nivla suggested.

Yes, at with these techniques you're tracking users across requests. But that's the point of this kind of analytics, isn't it?

The tokens are cryptographically signed with a shared secret between the main server and analytics server. So an attacker can't forge another user's token. IP addresses would be a good solution also, especially if you need to track anonymous users.

I often have the same concern. What I ended up doing was issuing a token to each user, and verifying the token on the logging endpoint. That way, if someone decided to fill the logs with spam, we can easily delete all the events from that token. From what I've seen, major analytics services seem to do nothing at all to prevent a client from pretending to be any user, so this kind of abuse is probably rare enough that it shouldn't be a big concern. Some basic rate limiting is always a good idea, though.