Skip to content

Instantly share code, notes, and snippets.

Jon Atack jonatack

Block or report user

Report or block jonatack

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@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: ??
  Layer: Applications
  Title: SNICKER - Simple Non-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

I propose reworking the rebroadcast logic to

  1. Significantly improve privacy
  2. Create a cleaner divide between wallet & node responsibilities

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

Conceptual 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 not keep track of “my” transactions but instead, apply rebroadcast conditions to all transactions.
  • The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer. This is to ensure the txn is not dropped from the local mempool.
@fjahr
fjahr / bitcoin_debugging.md
Last active Nov 18, 2019
Debugging Bitcoin Core
View bitcoin_debugging.md

This document is currently optimized for MacOS. If you would like to help me add Linux equivalent commands, please let me know.

Debugging Bitcoin Core

This guide is designed to give beginners of C++ development and/or people new to the bitcoin core code base an overview of the tools available for debugging issues as well as giving hints where issues may trip you up.

Table of contents

View git-br.py
#!/usr/bin/env python3
import subprocess
import os
if os.name == 'posix':
RED = "\033[1;31m"
BLUE = "\033[0;34m"
CYAN = "\033[0;36m"
GREEN = "\033[0;32m"
RESET = "\033[0;0m"
@PierreRochard
PierreRochard / your_lightning_commitment_transaction_with_htlcs
Created May 9, 2019
Your version of the commitment transaction that you are holding off-chain (with HTLCs)
View your_lightning_commitment_transaction_with_htlcs
# Based on a diagram posted by @pm47 https://github.com/lightningnetwork/lightning-rfc/issues/553#issuecomment-455641943
+------------------------------------------------+
| 2-of-2 multi-sig funding tx confirmed on-chain |
+------------------------------------------------+
|
|
|
|
View evaluate.lisp
; https://z0ltan.wordpress.com/2018/08/04/simple-expression-evaluator-comparison-between-haskell-rust-and-common-lisp/
; this version: 2018, Rainer Joswig, joswig@lisp.de
; we create a bunch of structures for the expression types
; each structure defines a constructor of the same name
; each expression knows the corresponding Lisp function
(defstruct (val (:constructor val (e))) e)
(defstruct (bop :conc-name) e1 e2 op)
View partition-resistance.md

Network partition resistance

For the Bitcoin network to remain in consensus, the network of nodes must not be partitioned. So for an individual node to remain in consensus with the network, it must have at least one connection to that network of peers that share its consensus rules. This document describes how we attempt to achieve this.

We can't rely on inbound peers to be honest, because they are initiated by others. It's impossible for us to know, for example, whether all our inbound peers are controlled by the same adversary.

You can’t perform that action at this time.