I hereby claim:
- I am johnzweng on github.
- I am johnzweng (https://keybase.io/johnzweng) on keybase.
- I have a public key ASBoU3gbSHQZPDeYdljl32-5iClAuzGOO1Cb2ZzF2yi8QAo
To claim this, I am signing this object:
I hereby claim:
To claim this, I am signing this object:
| /** | |
| * Johannes Zweng <john@zweng.at>, 2017 | |
| * | |
| * This simple script just loads the 2 bancor contracts (Crowdsale and BNT Token) | |
| * into the geth client and then provides a single status function which you | |
| * can call on the geth console to query the current status of the crowdsale. | |
| * | |
| * Usage: | |
| * ------ | |
| * 1) Start geth instance |
| /** | |
| * Johannes Zweng <john@zweng.at>, 2017 | |
| * | |
| * This simple script just loads the Status.im contracts (Crowdsale and Tokens) | |
| * into the web3 Script API and then provides a single status function which you | |
| * can call on the console to query the current status of the crowdsale. | |
| * | |
| * Usage: | |
| * 1) Store this gist locally on your computer. | |
| * 2) make sure you have "web3" and "bignumber.js" node modules installed. For example like this: |
| Verifying my Blockstack ID is secured with the address 1FemuY4GdW1ToSfF4P6Nex5zR8N2vRZSda https://explorer.blockstack.org/address/1FemuY4GdW1ToSfF4P6Nex5zR8N2vRZSda |
Author: Johannes Zweng (johannes@zweng.at) Date: 19.6.2019
| #!/usr/bin/env bash | |
| # | |
| # Remap some keys on macOS (>=Sierra) | |
| # | |
| # Johnny, 2.11.2020 | |
| # | |
| # Sources: based on https://gist.github.com/zbstof/6cba7d54e105cc5148c8a943d1581cad | |
| # |
| #!/bin/bash | |
| # | |
| # This shell script allows you to check the Taproot signalling on your own | |
| # Bitcoin fullnode (i.e. it does what https://taproot.watch/ does, but | |
| # verified by your own node). | |
| # | |
| # Be a self-sovereign Bitcoiner! | |
| # | |
| # DON'T TRUST, VERIFY! :-) |
We recently rolled out two changes to the Bitcoin block acceptance rules (BIP16 and BIP30); this document records the lessons learned and makes recommendations for handling future blockchain rule changes.
Note: there are "soft" rule changes and "hard" rule changes. "Soft" changes tighten up the rules-- old software will accept all the blocks and transactions created by new software, but the opposite may not be true. "Soft" changes do not require the entire network of miners and merchants and users to upgrade or be left behind.
"Hard" changes modify the rules in a way that old, un-upgraded software consider illegal. At this point it is much, much more difficult (some might say impossible) to roll out "hard" changes, because they require every miner and merchant and user to upgrade.