Create a template service file at /etc/systemd/system/secure-tunnel@.service
. The template parameter will correspond to the name
of target host:
[Unit]
Description=Setup a secure tunnel to %I
After=network.target
library LZF { | |
function decompress(bytes memory compressed, bytes memory decompressed) internal { | |
uint ip; | |
uint in_end; | |
uint op; | |
assembly { | |
// OP points to the current output location in memory | |
op := add(decompressed, 32) | |
// IP actually points to 31 bytes before the desired location, so | |
// MLOADs work correctly |
/** | |
* Base contract that all upgradeable contracts should use. | |
* | |
* Contracts implementing this interface are all called using delegatecall from | |
* a dispatcher. As a result, the _sizes and _dest variables are shared with the | |
* dispatcher contract, which allows the called contract to update these at will. | |
* | |
* _sizes is a map of function signatures to return value sizes. Due to EVM | |
* limitations, these need to be populated by the target contract, so the | |
* dispatcher knows how many bytes of data to return from called functions. |
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
package main | |
import ( | |
"github.com/syndtr/goleveldb/leveldb" | |
"fmt" | |
"encoding/binary" | |
"github.com/ethereum/go-ethereum/core/types" | |
"bytes" | |
"github.com/ethereum/go-ethereum/rlp" | |
) |
\documentclass{article} | |
% General document formatting | |
\usepackage[margin=0.7in]{geometry} | |
\usepackage[parfill]{parskip} | |
\usepackage[utf8]{inputenc} | |
% Related to math | |
\usepackage{amsmath,amssymb,amsfonts,amsthm} | |
\begin{document} |
Suppose we wish to model a UTXO system on the EVM. We need to represent UTXO tokens such that all value is preserved when tokens are spent. Note: For this example, we are not concerned about the security of the system and are satisfied with giving authorities the power to create tokens (e.g. as in a plasma system).
Consider the following object:
{
owner: <address>,
value: <uint>,
def hexdump( src, length=16, sep='.' ): | |
''' | |
@brief Return {src} in hex dump. | |
@param[in] length {Int} Nb Bytes by row. | |
@param[in] sep {Char} For the text part, {sep} will be used for non ASCII char. | |
@return {Str} The hexdump | |
@note Full support for python2 and python3 ! | |
''' | |
result = []; |
admin.addPeer("enode://da0c61fe14ba9da1a9835b59d811553d21787448724cfe6412bc17f0b14586df91826d8286b2137342d09a8631df5ea548cf301294b05657c2a90f9c3d526721@143.198.119.44:30303"); | |
admin.addPeer("enode://3e2287c6caf363357efc600611ccb777e6997ef8b749b1f87e94d3a7d2b466bbefba163b0620c88804f18bc70cfbe68538720ac2644fc1c970848488cdca0c7a@143.198.114.251:30303"); | |
admin.addPeer("enode://15ea76b5d30ce9eaabf6a9a8fe5ca0ff032534d296b5b8ca6e00a730d08a4aaa019077c382a6b2d08ebc7cf6f8eb888f5e00e0dd378798e3459a555538654370@157.230.6.79:30303"); | |
admin.addPeer("enode://2e718763172902a8fa4bcdda45f77a5c2688de5230e184d154e4867922b8f6ad23e1016379715cb5f55f6c79060563f93896035e35dfb47361d08599d4908ae8@143.198.118.178:30303"); | |
admin.addPeer("enode://9d45f21eeb37bd5555fac0c4094ae3d4d144d93e2313aeb891bf3054b0dcf6ca817961ed29ea1de00389b5c36dc6bbe9b00443e367b16ed8ba251cea6c242044@94.176.237.140:30303"); | |
admin.addPeer("enode://2493b5b8407ccb1c448d7ad358e838066640f273442730caf80acde2fe98522b1d9dcebd2dc982efe44911a49779888fe72defc181c29596facff05e1 |
This gist shows how formal conditions of Solidity smart contracts can be automatically verified even in the presence of potential re-entrant calls from other contracts.
Solidity already supports formal verification of some contracts that do not make calls to other contracts. This of course excludes any contract that transfers Ether or tokens.
The Solidity contract below models a crude crowdfunding contract that can hold Ether and some person can withdraw Ether according to their shares. It is missing the actual access control, but the point that wants to be made