As of March 2018, Raspbian does not yet include the latest Python release, Python 3.6.8 This means we will have to build it ourselves, and here is how to do it.
- Install the required build-tools (some might already be installed on your system).
| user www-data; | |
| worker_processes auto; | |
| pid /run/nginx/nginx.pid; # only line changed from default | |
| include /etc/nginx/modules-enabled/*.conf; | |
| events { | |
| worker_connections 768; | |
| # multi_accept on; | |
| } |
Here's a guide about when and how to use prepared statements.
The first reason to use a prepared statement is to protect against SQL injections.
You can do this by removing all special characters, but there are times when that's not practical. (Example: you want to allow users who have apostrophes in their names to register for your website.) You can do it by escaping all of the strings that you pass into the SQL query, but it's easy to forget to sanitize a single field.
So how do you protect against SQL injection? Here is the simple way to never fall prey to SQL injection: never put a user-provided string into an SQL query, except as a parameter to a prepared statement.
This is a guide to install libfive. libfive is a very unfinished program that allows you to model volumes. In other words, you can give libfive a functional representation of a solid, and libfive will figure everything else out, and render the resulting mesh. Pretty cool.
Conventions used by this document: # indicates a command run by root, and $ indicates user.
| #!/usr/bin/env python3 | |
| from math import sqrt | |
| class Point: | |
| def __init__(self,x_init,y_init): | |
| self.x = x_init | |
| self.y = y_init | |
| def shift(self, x, y): |
| echo "Acquire::http::Proxy \"http://apt-cacher:3142\";" > /etc/apt/apt.conf.d/01proxy |
| 2015-11-03 22:05:38 | |
| 02:26 petertodd no, really, like, all the big pools do this | |
| 02:26 CodeShark do what? SPV? | |
| 02:27 petertodd CodeShark: yeah, they use getblocktemplate and what not to find | |
| when other pools make blocks, and quickly build on top of them - actually SPV is putting | |
| it strongly, they don't really do any authentication | |
| [log edited for brevity] |
| Your post advocates a | |
| ( ) sidechains ( ) block-size increase ( ) anti-spam ( ) lightning-network ( ) off-chain | |
| approach to scaling Bitcoin. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws.) | |
| ( ) There is no explanation of how Bitcoins on the sidechain will get back onto the mainchain. | |
| ( ) This will make it more difficult to run a full node, when node counts are already dropping. | |
| ( ) The idea of "spam transactions" is not well defined, and every proposed filtering method impedes legitimate use cases. | |
| ( ) Your approach allows unrelated nodes to defraud each other, and there is no arbitration process other than "complain on reddit." |
| ## I used the following program to benchmark ECDSA multiply vs. ECDSA | |
| ## multiply-then-add. | |
| ## | |
| ## Originally from http://bitcoin.stackexchange.com/a/25039 | |
| ## | |
| ## Sample output (where I get my 2% figure from.) | |
| ## ======================================================================= | |
| ## 7.90899729849 | |
| ## 8.05856181495 | |
| ## pubkey 0x50863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352L 0x2cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6L |