atlanta-bitdev-socratic-seminar-17.md

Bitcoin Socratic Seminar #17

https://atlantabitdevs.org/2023/04/18/bitcoin-socratic-seminar-17/ https://www.meetup.com/atlantabitdevs/events/292584775/

Topics

Stratum V2

• Why Stratum v2?

  • Stratum v1 is old and has many problems

• What is the Stratum protcol?

  • Mining protocol used to facilitate communication between Bitcoin miners and mining pools
  • Allows miners to easily connect to pools, contribute hashrate and receive awards
  • Been in use since 2012 (👴)

• What are the problems with Stratum v1?

  • Doesn't support modern transport protocols like TCP or QUIC (UDP) resulting in slower communication between miners and pools
  • Doesn't use TLS to encrypt data across network (yikes 😱) so data packets are in plain text
  • Vulnerable to man-in-the-middle attacks
    • Attackers can intercept and modify mining instructions sent from the pool to the miner
    • Attackers can redirect the miner hashpower to a different pool or steal the miner rewards

• How does Stratum v2 fix these problems?

  1. Uses TLS to encrypt communication between miners and pools making it much more difficult for attackers to intercept or modify data
  2. Adds Job Negotiator (new protocol) + template provider (miner)
     • JN runs sub-protocol to distribute miner's templates (used to select transactions) to the pool
     • V1: Templates for assembling txs are managed by the pool itself (central point of failure); can lead to censoring txs by excluding them from the template
     • V2: Templates are managed by each miner individually
     • JN distributes templates from each miner to the other nodes in the pool
     • Makes bitcoin pool infrastructure more decentralized

TLDR

Stratum v2 makes mining pools more secure, more efficient and more decentralized.

Ordinal swap BIP

• Uses PSBTs to allow two parties to swap inscriptions
• Uses SINGLE|ANYONECANPAY to create PSBTs
• PSBT signed and published as offer by seller
• Buyer updates PSBT with appropriate inputs and outputs
• Seller:
  • Create PSBT with inscription UTXO input and a new address with sell amount as output
  • Sign PSBT
  • Publish PSBT as defined in NIP
• Buyer:
  • Add new address as output in PSBT to receive inscription
  • Create dummy UTXO if not available in wallet (Less than 1000 sats)
  • Add UTXO to pay seller and dummy UTXO as inputs in PSBT
  • Sign and broadcast transaction

NIP 31001

• P2P marketplace for buying/selling assets
• Claims "Using Nostr would solve [the] reputation problem"
• Does not explain how; todo is defining a kind for reputation
• Hot take: nostr does not, in any way shape or form "solve the reputation problem"
• What does? Moderate centralization of trusted authorities to issue credentials (SSI)
• Its a cool idea, and nostr can definitely facilitate a P2P market place
• However, idk how well it'll achieve that goal. I doubt it'll do it at scale better than prior, more well-defined systems (SSI)

NIP 69

• Operational NIP
• Proposes a common, translatable "vocabulary" to use in reporting content (NIP 36 explicit content or NIP 56 reporting spam)

NIP 26

• Proposes clarity to the wording for conditions on when and on what kind of notes can a delegated key can sign
• Key delegation is a lot like xpub, xpriv (HD wallet keys) where xpriv can be used to create a new child priv key, pubkey and then addresses
• Parent key stored offline, and delegated keys used for daily interactions
• Delegation key example

nostr:delegation:<pubkey of publisher (delegatee)>:<conditions query string>

• Amazingly ... it looks a lot like a new DID spec from TBD called DID:nostr 🧐

did:nostr:e2bdaa90e96a4fafb9f1c36f9b378e4bbd6fea26e5d47063e7b30aa15de37d48

• DIDs need not be stored offline, in fact you should share your DID with anyone you want
• The DID then allows you to create / revoke keys in the same HD manner
• DID remains static
• Superior key rotation / management
• Nostr key delegation problem: do your followers now have to follow every delgatee key? How do they easily relate the delegatee pubkey to the parent? It sounds like you've split your parent npub into a bunch of new children npubs effectively creating new identites
• Check it out here: https://github.com/TBD54566975/did-nostr

n3xb

• Naive Nostr No-KYC Exchange for Bitcoin
• Not sure how well this works without reputation or identity
• Mentions that "client software ... enforces the trades by utilizing Bitcoin fidelity bonds"
• But doesn't explain Bitcoin fidelity bonds
• Anyone familiar with this concept? Or BFB in general?