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.
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.
Serious question: How is "pepper" any different than encrypting a traditional salted hash using a symmetric cipher as if it were any other kind of data?
Wrap it up in a convenience function and you're done.
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
and access the account information of any user logged into your site. JSONP is a technique to bypass the same-origin policy in appropriate cases; don't just blindly apply it everywhere or you're giving up the protection of the policy.
might also be worth noting that django-tastypie is the defacto standard for REST apis, and sends and returns json (among many other serialization formats) very easily. This obviously doesn't work for all ajax cases, but its extremely useful nonetheless.
json.dumps() can be dangerous if used on your raw domain data. You should specify the exact schema being sent down to the client so you don't accidentally leak something (this can happen very easily in Python)
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)
yep, I build response objects ( my own term, not great but it describes what they are ) that are basic subsets of the object that I want to serialize to json. That way I'm sure only the fields that I really want to send are making it out.
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.
This has come up a couple times. I wouldn't mind this topic moving it to github so the conversation doesn't get lost. And others can contribute to it long after this gets buried on HN.
My initial opinion is that even though your SCSS code is consolidated, the resulting CSS code is still duplicated all over the place. To me, that is a code smell. Particularly when I need to debug from the web developer tools.
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.
Detectable if you measure density carefully enough (though do people? I don't know). If you did that with plutonium instead (way more expensive than gold obviously, so it would be a silly thing to do) then you could get it as close as you wanted.
As an interesting sidebar, there's a series of photos of some of the scientists on Tinian posing with a small box containing the core of the Fat Man bomb - a 3.5" diameter sphere of Plutonium that was apparently worth at the time the equivalent of about $5 billion dollars.
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.
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.