moonsettler

Bitcoin denominated ecash without custodial risk

In this scheme the ecash notes don't represent IOUs, the spent ecash notes represent the liability of the User towards the Mint

Abstract

Bitcoin denominated ecash credit secured by publicly arbitrated escrow providing symmetric trust/incentive relationship between Mint and User. Works similar to a credit card top-up scheme. Instead of depositing bitcoin to the Mint to get ecash issued, the Mint issues credit in the form of ecash. The spent ecash tokens represent the User's liability towards the Mint. The User must periodically provide proof of the unspent balance (turning in expired tokens, which can no longer be spent) and

kanzure

"""
Timestamps!

This file creates opentimestamps timestamps for daily IRC logs. It works when
running on a daily basis (called from a cronjob) or when called manually with
multiple days since the last run.

The script will identify all new log files and create timestamps for those new
logfiles.

DavidBurkett

Offline Transactions in Mimblewimble

Mimblewimble is a blockchain protocol that improves on bitcoin's privacy and scalability by using pedersen commitments, schnorr signatures, and a novel technique called 'cut-through'. These benefits have come at a steep cost. Building transactions have thus far required interaction between the sender and receiver to create the outputs and collectively sign the transaction. We present here a method of achieving one-sided transactions while minimizing the impact on the scalability and privacy of mimblewimble.

Current Protocol

Like bitcoin, Grin uses a UTXO model. Transactions are created by including inputs to spend, creating new outputs of equal or lesser value, and signing and building rangeproofs to verify ownership of the inputs.

Unlike bitcoin, Grin uses confidential transactions, so the inputs and outputs are pedersen commitments (r*G + v*H). Instead of the signatures being added to the inputs, there is only one signature per transaction, which is part of the

fjahr

Rolling UTXO Set Hash proposal

TL;DR

I have picked up Pieter Wuille's proposal from 2017 to use a rolling hash for the UTXO set hash. It deals with the problem of a long computation time of the UTXO set hash which results in a slow RPC call gettxoutsetinfo (can take several minutes depending on hardware). I investigated three hash functions: MuHash, ECMH and LtHash and started implementing them in Bitcoin Core for comparison. However only MuHash has a rolling hash implementation

Jaskaranbir

#!/bin/bash

# ===> Set these variables first
branch="$GIT_BRANCH"
# Example: "Jaskaranbir/MyRepo"
repo_slug="$TRAVIS_REPO_SLUG"
token="$GITHUB_TOKEN"
version="$TRAVIS_TAG"

# An automatic changelog generator

achow101

Using Bitcoin Core with Hardware Wallets

This approach is fairly manual, requires the command line, and requires a patched version of Bitcoin Core.

Note: For this guide, code lines prefixed with $ means that the command is typed in the terminal. Lines without $ are output of the commands.

Disclaimer

I am not liable for any coins that may be lost through this method. The software mentioned may have bugs. Use at your own risk.

ottosch

#!/usr/bin/env python

# This script is meant to be used with bitcoin_fork_claimer: https://github.com/ymgve/bitcoin_fork_claimer
# The outputs of this script are the inputs to that script.
# Python 2.x is required

import urllib2
import json
import sys
import collections

cryptomeow

Actual TPS of Bitcoin

Counting on-chain transactions alone to illustrate pretty much anything is wrong. One should take into account at least TX batching.

A possibly better way is to calculate based on new UTXOs created excluding the change outputs.

Doing rough calculations, we assume the worst case of every TX having a change output, so the results are the most pessimistic version and actual numbers are better.

Month	TXs	UTXOs created	Net UTXOs [1]	Naive TPS [2]	Actual TPS [3]

williewillus

This primer is licensed under CC0, do whatever you want.

BUT do note that this can be updated, so leave a link here so readers can see the updated information themselves.

1.13 and 1.14 are lumped together in this doc, you're on your own if you just want to go to 1.13 and not 1.14, for some reason.

1.15 stuff: https://gist.github.com/williewillus/30d7e3f775fe93c503bddf054ef3f93e

Things in Advance

• ResourceLocation now throw on non-snake-case names instead of silently lowercasing for you, so you probably should go and change all those string constants now. More precisely, domains must only contain alphanumeric lowercase, underscore (_), dash (-), or dot (.). Paths have the same restrictions, but can also contain forward slashes (/).

danisfermi

Here are the steps to installing and setting up GDB on Mac OS Sierra/High Sierra. Run brew install gdb. On starting gdb, you will get the following error:

Unable to find Mach task port for process-id 2133: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

To fix this error, follow the following steps: