jcnelson

Verifying that +judecn is my Bitcoin username. You can send me #bitcoin here: https://onename.io/judecn

jcnelson

Keybase proof

I hereby claim:

• I am jcnelson on github.
• I am judecn (https://keybase.io/judecn) on keybase.
• I have a public key ASDSv0l4bYpy4eOMWPxezzyKsadeo5Xxrr5Ulm8Atohfygo

To claim this, I am signing this object:

jcnelson

Verifying my Blockstack ID is secured with the address 16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg

jcnelson

Verifying my Blockstack ID is secured with the address 15gxXgJyT5tM5A4Cbx99nwccynHYsBouzr https://explorer.blockstack.org/address/15gxXgJyT5tM5A4Cbx99nwccynHYsBouzr

jcnelson

Testnet Outage Post-Mortem

From 19 July through 24 July, the Stacks testnet had experienced repeated outages every few hours. The symptom was the repeated recurrence of errors such as the following:

WARN [1595867918.213] [src/chainstate/stacks/db/blocks.rs:2861] [ThreadId(6)] Block 36a6b25fb7dd1775761b80b567425dd886f35272a5cc6a7661df0d99662f9d1c state root mismatch: expected 2fbb24799b4ea08ca50a8a2c75749735a6aa60415758a1394525f789a109067c, got 65fbf51eea07de1a75c5c45373c6aa3c7975e88269948114c0468acbf461cf66

jcnelson

Preventing Deep Chain Reorganizations from Non-canonical Anchor Blocks

While nodes may be required to re-process all sortitions due to a late-arriving anchor block, nodes do not need to do so eagerly if the anchor block is not part of the canonical Stacks chain. Put another way, if nodes could determine whether or not an anchor block is part of the canonical chain without needing to process any Stacks blocks, then they would not need to reprocess their chainstates if a late-arriving anchor block would not change which Stacks fork was the canonical Stacks chain. The ability to ignore late non-canonical anchor blocks would make the network resilient

jcnelson

Problem

For various technical reasons, a given PoX reward cycle can have only so many reward addresses registered. This in turn is what necessitates a high minimum Stacking threshold. The design of the PoX smart contract (which controls this) works around this limitation by providing a way to delegate one's STX to a Stacking delegate, who in turn will Stack all of its clients' STX to clinch reward addresses that the clients could not have obtained individually. The implementation of a Stacking delegate is left unspecified.

This document sketches an implementation that allows anyone to be a Stacking delegate, such that the most economically advantageous action for the delegate is to honestly fulfill its role by gathering and Stacking its clients' STX, collecting the BTC sent to its PoX reward addresses, and disbursing the Bitcoin it receives.

Background

Broadly speaking, delegated Stacking works as follows:

1. The client sends a delegate-stx transaction, indicating a particular Stacking delegate

jcnelson

Problem

NFTs exist on Ethereum, and we want to "port" them to Stacks. To avoid duplicity, any mechanism that does this will necessary need to do two things:

• Burn the NFT on Ethereum, thereby rendering it un-transferable
• Instantiate the NFT on Stacks

This document sketches a "NFT bridge" system that allows a trusted intermediary to gather burned NFTs on Ethereum and instantiate them on Stacks. The intermediary can grant the NFTs to the original Ethereum owner by sending them to a Stacks address of their choosing (that they would specify as part of burning the NFT), or it can hold on to the newly-ported NFTs and auction them off.

Design Sketch

jcnelson

;; lookup table for converting 1-byte buffers to uints via index-of
(define-constant BUFF_TO_BYTE (list 
    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
    0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
    0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f
    0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f
    0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e 0x4f
    0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f
    0x60 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
    0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7a 0x7b 0x7c 0x7d 0x7e 0x7f

jcnelson

Blockchains Do Not Scale

(Warning: rant)

Let me say that again for the people in the back. Blockchains. Do. Not. Scale. Period. Full Stop. Do not pass Go; do not collect $200. A scalable blockchain is a digital Philosopher's Stone -- a sought-after but non-existant substance surrounded by crazies, grifters, and the occult. If you gave these people money to buy their magic gold-transmuting eternal-live-producing crystalized spice melange, all you got was a rock.

The whole point of building anything at all on a blockchain is to make it so anyone who wants to can easily run a full replica of the code. This, and this alone, is what keeps blockchain networks both resilient and accountable to their users, since users by and large hold each other accountable. The easier it is to run a node, the more people will run nodes, and thus the more resilient the system will be to node failures, network partitions, and nefarious actors. The downside is that, because blockchains are a type of [replic