pool2win

P2Pool-v2

This gist describes a scheme to reboot p2pool with minimal changes to P2Pool’s design. The goal of the project is to reboot p2pool with a linear chain with a transaction system to enable trading of shares between miners. Smaller miners will trade their share with the larger miners to get paid over lightning, while the larger miners are paid out using the coinbase outputs.

pool2win

use tokio::sync::{mpsc, oneshot};
use tokio::time;

struct MyActor {
    receiver: mpsc::Receiver<ActorMessage>,
    next_id: u32,
    subscribers: Vec<ClientActorHandle>,
    reader: mpsc::Receiver<u32>,
}
enum ActorMessage {

pool2win

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Update: This now has a BIP and WIP implementation

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

pool2win

Braidpool Payout

pool2win

Each bead commits to:
    | Bitcoin Block header                                       | Slots Merkle Root |
    | Coinbase | timestamp | nonce | TX Merkle Root | prev block |

Where the block header is a standard bitcoin block header as expanded in the second line
and each bead commits to <Slots Merkle Root> which should be added to the <metadata> 
field as described in:
    https://github.com/mcelrath/braidcoin/blob/master/braidpool_spec.md

The Slots data structure is a key-value table containing:

pool2win

#lang racket

;; define place holder functions for demo
(define (pk key) (eq? key #t))
(define (older num) (> num 1000))
(define (hash160 val) (val))

(let ([key_revocation 'abc]
      [key_local 'def]
      [key_remote 'xyz]