Skip to content

Instantly share code, notes, and snippets.

Avatar

Jon Atack jonatack

View GitHub Profile
@laanwj
laanwj / stats_bitcoin.py
Last active Jul 17, 2020
Bitcoin network stats script
View stats_bitcoin.py
#!/usr/bin/env python3
import sys
sys.path.append('./bitcoin/test/functional')
from test_framework.authproxy import AuthServiceProxy, JSONRPCException
import time
import os
datadir = os.getenv("DATADIR", os.path.join(os.getenv('HOME'), '.bitcoin'))
with open(os.path.join(datadir,'.cookie'),'r') as f:
cookie = f.read()
@Sjors
Sjors / overview.md
Last active Aug 6, 2020
Hardware Wallet Support in GUI and RPC, using HWI
View overview.md

Project: https://github.com/bitcoin/bitcoin/projects/15

Final User Experience

A user plugs in their hardware wallet and creates a new wallet. It automatigically detects the device and imports the keys:

The user can verify a receive address on their device with just a click:

View PeerLogging.md

Peer Logging

The Bitcoin P2P network is fundamental to the strength of Bitcoin itself. However, as it stands we know very little about the peers we connect to. This makes it difficult to have data-driven conversations about making changes to the P2P protocol. Additionally, we connect and disconnect from peers in a naïve fashion, simply because we are lacking in the information we would need to make better decisions.

We need more data.

To remedy this problem, I propose the following extensions to Bitcoin Core's per-peer logging abilities.

  1. Message Capture
@ariard
ariard / digital-card.txt
Created May 6, 2020
Celebrating the 1-year of Bitcoin PR Review Club
View digital-card.txt
jonatack:
U2FsdGVkX18XDMZfMBvtOjbdzP9FglsfNI1IkmfUsmjhUJc1x8YghQL9jjBRA22G
LMC9KLt7L/7sFJfVm7rEW+yeoWXL6S/K1NWdOvoy6O5pfQF2NMltA6Mzb1q4huVM
x+BW7DNEBF9nDknRwFiAD079WOvLyLbWvPHk1FJp9hW5qRgU/629/XQ0pQX1eqdf
OLVS5AGuTxBgc8AE6tp4i+x7mC037bTBuI9c6X4mngfYpfu9PkSK+DzQx6pXqgTh
uvEprusb8PzsWmUSNbFN4umr9bAbUeezWig7mWNbIEbpBR/jD4YSeTXaBXfP2fvB
BJU/38DWll06Ki46CE/tkTMSjuUg2E5T2hTDppSAC9j6OuhLtt8+ZKLtt2X2tCm8
vdERbOHFdZu/Npsj6vLg8SWsKoen5LvGbRWfuXTWEa9FlTu9t7PMbcc5Zbk/5DKr
yY3jW/4u/bWuZlYca3U8dSZEjGZod+paht4acXoJRUy58RWl3Lg72FZXCuzw7Ph2
@jnewbery
jnewbery / shared_ptr.cpp
Created Apr 18, 2020
Passing shared pointers
View shared_ptr.cpp
#include <iostream>
#include <memory>
struct Base
{
Base() { std::cout << " Base::Base()\n"; }
~Base() { std::cout << " Base::~Base()\n"; }
};
struct TraceByVal
@hebasto
hebasto / bitcoincore-hmp.md
Created Apr 4, 2020
The Bitcoin Core on Heterogeneous Multi-Processing platforms
View bitcoincore-hmp.md

The Bitcoin Core on Heterogeneous Multi-Processing platforms

Consider a system on the heterogeneous computing ARM big.LITTLE architecture, e.g., ODROID-HC1 powered by Samsung Exynos 5 Octa 5422.

As the Bitcoin Core is a highly computationally intensive application, the usage of ultra-low power and slower LITTLE cores could lead to a substantial lagging and errors (see: https://github.com/bitcoin/bitcoin/issues/16008).

Also there are report about other flaws in LITTLE cores design.

The suggested solution of the described problem is to force the CPU core affinity of the Bitcoin Core processes. On Linux this could be achieved by the [taskset](https://linux.die.net/man/1/t

@jnewbery
jnewbery / wallet_dev.md
Last active Nov 22, 2019
Wallet development
View wallet_dev.md

Wallet development

What are a wallet’s functions?

  • Key management
    • Identify owned transactions
    • Generating new addresses
    • Determining how to sign transactions
  • Constructing and sending transactions
    • Parsing addresses and turning them into txOuts
@niftynei
niftynei / dot.txt
Created Sep 5, 2019
notes from outputs investigation
View dot.txt
wallet/db.c -> table schemas + migrations
wallet/wallet.c -> SQL statements
table: outputs
question: what are the values for 'status'
output_state_available= 0,
output_state_reserved = 1,
output_state_spent = 2,
/* Output has been included in a signed funding tx that we've shared
* with a peer; not yet mempooled. Eligible for burning */
View SNICKER_BIP_draft.mediawiki


  BIP&#58; ??
  Layer&#58; Applications
  Title&#58; SNICKER &#45; Simple Non&#45;Interactive Coinjoin with Keys for Encryption Reused
  Author&#58; Adam Gibson <AdamISZ@protonmail.com>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; &#45;
  Status&#58; Proposed
  Type&#58; Informational
  Created&#58; &#45;

View transaction_rebroadcasting.md

Background: Currently, a node will only rebroadcast a transaction if it is the originating wallet. This is awful for privacy.

PR #16698 reworks the rebroadcast logic to significantly improve privacy.

Overview of changes

  • Instead of the wallet directly relaying transactions to peers, the wallet will submit unconfirmed txns to the node, and the node will apply logic to trigger txn rebroadcasts.
  • The node will apply rebroadcast conditions to all transactions.
  • The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer. This is only useful if the txn is dropped from the local mempool before it gets mined.
  • The mempool tracks locally submitted transactions (wallet & rpc) to ensure they are succesfully rebroadcast. Success is defined as receiving a GETDATA for the txn.
You can’t perform that action at this time.