Skip to content

Instantly share code, notes, and snippets.

Jordan Earls Earlz

View GitHub Profile
View xrc20-2.c
#include <qtum.h>
#include <stdlib.h>
#include <string.h>
//dumb ABI
//sends specified amount from msg.sender balance to address
#define CONTRACT_SEND 1
//returns the balance held by the specified address
#define CONTRACT_BALANCE 0
//returns balance of getSender()
View SCCS upon exit.md

The contract communication stack shall have the following items pushed onto it (in this order) upon contract termination:

  • Rest of stack (ie, the stack is not necessarily cleared and multiple items may be present)
  • User defined contract exit data (optional. Only present if smart contract code does the push)
  • Gas used, uint64_t (pushed by Qtum)
  • Contract error code (pushed by Qtum)

SCCS ABI Proposal:

Before the termination of a contract, the stack should be cleared of any items that the contract does not wish to return to the calling contract. Each contract should specify their own protocol for what data shall be returned from their contract.

View x86 trusted library.md

Qtum x86 Trusted Library Mode

A mode exists called Trusted Library Mode. Calling a contract that uses this mode from another contract requires an explicit "allow" option because of the abilities given to the library code. This supports similar use cases as EVM's delegate-call function, but with more control by the calling contract.

Trusted Library mode is designed to be ideal for helper code and computations.

Execution Differences

When executing (and writing) trusted library code, a different memory model is used. Basically, all of the calling contract memory is "mounted" into the bottom 2Gb of the address space. Basically, all of the standard expected memory space for execution is moved up to address 0x80000000. This means when compiling Trusted Library code, care must be taken to ensure that the program is aware it will be executed at this address. Memory allocation is allowed in trusted library execution, but can only be located in the special memory allocation area. This is to prevent potential

View brainfuck.sol.js
//compiles to 2820 bytes unoptimized, 1524 optimized
//using remix version "soljson-v0.4.18+commit.9cf6e910.js"
pragma solidity ^0.4.15;
contract BrainFucker{
function interpret(bytes s, bytes1[128] input) public returns (bytes1[128] output) {
uint256 ptr=0;
uint256 i=0;
uint256 right = s.length;
View brainfuck.c
//compiles to 740 bytes using -O0, 384 bytes using -Os
//both targeting i386 and with freestanding GCC compiler
typedef unsigned int size_t;
void interpret(volatile char* s, int s_size, volatile char* input, volatile char* output){
int i=0;
View mediumtest.md

foo

bar

  1. foo
  2. bar
  3. baz
  4. biz
Testing 123 code
@Earlz
Earlz / greeter.c
Last active Jun 12, 2018
Using a Qtum prototype implementation including an x86 VM, I built this contract. It's messy cause there is not yet a standard library due to it requiring freestanding code. Compare to the Solidity implementation at https://www.ethereum.org/greeter
View greeter.c
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef unsigned char uint8_t;
typedef unsigned int size_t;
//#include <stdint.h>
// copy-paste some library functions until we get a basic libc working
void* memcpy(void* restrict dstptr, const void* restrict srcptr, size_t size) {
View gist:2e013bc180c78661123e
use std::io;
use std::io::File;
use std::os;
use std::str;
fn main() {
println!("meh");
let filename=&os::args()[1];
let contents: String = match File::open(&Path::new(filename)).read_to_end() {
Ok(s) => str::from_utf8(s.as_slice()).expect("this shouldn't happen").to_string(),
View gist:c8ec449a4fe5a380a4f7
//a program I made to troll my high school with back around 2008
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winioctl.h>
DWORD WINAPI bah(unsigned int t){
//MessageBox(NULL,"hi3","bah",0);
View gist:de3cc5f6ee85c7a69d53
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
This is a list of unspendable addresses with which to burn coins to. When you send a coin to any of these addresses, they are permanently gone and can never be redeemed.
You can prove this by sending a small test amount to the address and then checking a block explorer or using `getrawtransaction txid 1`. You should see the coins output to somehting like `"raw_scriptPubKey": "76a914000000000000000000000000000000000000000088ac"` Some block explorers are also smart enough to indicate in their user interface that the coins were destroyed.
You can find the version number matching to the desired altcoin by checking two places in the code:
chainparams.cpp for bitcoin 0.9 and later based coins:
You can’t perform that action at this time.