holiman

pragma solidity ^0.4.4;
contract X{
    
    string junk;
    function y() returns(string){
        //Uncomment the 'junk' below to make gas-measurements
        //junk="0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF012345

holiman

#!/bin/bash
# Linux version
# Use this script to pipe in/out of the clipboard
#
# Usage: someapp | clipboard     # Pipe someapp's output into clipboard
#        clipboard | someapp     # Pipe clipboard's content into someapp
#

if command -v xclip 1>/dev/null; then
    if [[ -p /dev/stdin ]] ; then

holiman

Background

In EIP-255 , @karalabe proposes a PoA-scheme which reuses the current header-fields. The PoA-scheme has the following scheme to handle forks (caused by malicious minters or general latency):

If the number of authorized signers are N, and we allow each signer to mint 1 block out of K, then at any point in time N-K miners are allowed to mint. To avoid these racing for blocks, every signer would add a small random "offset" to the time it releases a new block. This ensures that small forks are rare, but occasionally still happen (as on the main net). If a signer is caught abusing it's authority and causing chaos, it can be voted out.

This gist outlines another scheme, by using the difficulty header.

Description

holiman

contract DeliveryBoy{
    /*
     * Delivery boy is very important, but not so clever
     */
    function deliver(address recipient){
        selfdestruct(recipient);
    }
}

contract MailMan{

holiman

package main

import (
	"fmt"
	"math/rand"
	"os"
	"path/filepath"
	"strconv"
)

holiman

Current (Istanbul) costs

With Istanbul rules, EIP-2200: https://eips.ethereum.org/EIPS/eip-2200#test-cases, the following gas usages apply for the various scenarions below:

Code	Used Gas	Refund	Original	1st	2nd	3rd	Effective gas (after refund)
0x60006000556000600055	1612	0	0	0	0		1612
0x60006000556001600055	20812	0	0	0	1		20812

holiman

{"code": "3fc6e06b433eba44326043a4bdc77d736320fb323ff85ea8dc766d9cd29faebdd8d29507b351b2e93f031f6fe65730d45797ddfd3c710241d47446783f695f12fe395235b76fc6ddc7ddccc8e159f956318cb0021d4bd650a33ca5360a6953efd8c727d331f63d6a6377b1f48ce7d04dc8dd7265562e203e311fee5726ed3cd9b4c9555ece2138a89deddda230d601b1fac8918e21efaf9d4540dbdc590f0239307bf103b68f9aa27b36122acdd76e4408f12cab335eff92bfc6b5fee222954922667ca42246547f32dd6eb651bc4e8de3b7034a65d831ec08cfdf6b32d235ad27ce3108954b93bf2f64a890bbd5161b32e395f6f9dd69f91e76aeea5d305073702cdca635b73870066495ed9e8f76dea5dbc945b689eeec35172535095829324b414982db4e8d16b3c6fdef3541a5169d8e9610edb927512fa6784329576c0e357e2e2ccffaa1194cd3e6722c5a90767346219334a194b58f4cedd63a619f5979fa59ba3058b3903458d5d3076a25b50365adc3cc53ab97b5b98b5137cd7da1e193c522218e67a833078d2bfb1d6287362e8fdccf8fb89aaa73bc2eebdf3e9d1af5695036655346eb803f72666820b04890fafd288f1a493679cdda3124144afeddb3cc3f063e3d2e7691d12862a084e13a7c6d53c58b9cdf90aec6d37c1f0f2b2850adb03a0c44c46334606b5c6a3a307eeb382adab553d9739a

holiman

This audit was performed by Martin Holst Swende.

Based on the following commit-hash:

https://github.com/ConsenSys/MultiSigWallet/commit/8fd9e0f97572b0e7a2ae4f50233168789162d96d

1. MultiSigWallet

holiman

{
 "TestSelfdestruct": {
  "env": {
   "currentCoinbase": "b94f5374fce5edbc8e2a8697c15331677e6ebf0b",
   "currentDifficulty": "0x20000",
   "currentGasLimit": "0x26e1f476fe1e22",
   "currentNumber": "0x1",
   "currentTimestamp": "0x3e8",
   "previousHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
  },

holiman

Part one: Caching in consensus

The magic of caching

It's sometimes said, within software engineering, that there are no 'golden bullets' -- magical stuff that automatically fixes all of your problems. But actually, there is something that is pretty close to a golden bullet in many scenarios. After everything has been stretched to the limit, but the software still falls short of the demands being put on it, there's one thing that engineers will reach for: The Cache.

A cache layer can scale something orders of magnitude, it can and should be used wherever appropriate. When we can put in a caching layer, we suddenly have a shelve where we can put "stuff" that might be useful later. It's great.

Caching, and perhaps more specifically cache invalidation, is generally considered as a difficult problem, and it can of course be tuned and experimented with at length, before it's fully matured. Do we want least-recently-used eviction? Least-frequently-used? Do we want strict eviction guarantees, or is fuzz