Atlanta BitDevs is a place for free and open Bitcoin education in Atlanta. Discussions will be technical but are open to people of all skill levels. 📙 Atlanta BitDevs' reading groups are small sessions where we focus on a specific topic within Bitcoin development and help each other understand it through discussion.
- Website: https://atlantabitdevs.org/
- Discord: https://discord.com/invite/gQmJwWC5Ts
- Meetup Group: https://www.meetup.com/atlantabitdevs/
FoReadings's Event, I'd like to share some learnings from my time in the Chaincode seminar Bitcoin Protocol Development. We'll talk about how Bitcoin Core has changed from it's first implementation, through all of the different major upgrades like segwit and taproot.
- Meetup Event: https://www.meetup.com/atlantabitdevs/events/293932563/
- Bitcoin research and development center based in Midtown Manhattan, New York
- Projects: Develop various projects in the Bitcoin and Lightning Network ecosystem
- Seminars: Help those seeking to contribute to the Bitcoin and Lightning Network ecosystem
- 6 weeks, 1 90 minute session per week
- Meet with fellow developers, challenge yourself, and receive guidance from current contributors
- Weekly prep takes "4-6 hours"
- Seminars consist of 10-25 participants with rotating discussion groups of 3-5
- Two types
- Chaincode content
- My work
- Readings:
- Extra:
- Highlights selected historical events, software releases and bug fixes before and after Satoshi left the project
- Includes a section about the current state of Bitcoin development
- Includes a timeline visualization: https://b10c.me/projects/bitcoin-dev-history/
- Chaincode content
- My work
- Readings:
- Extra:
- Chaincode content
- My work
- Readings: Compact Blocks
- BIP152
- Method of reducing the amount of bandwidth used to propagate new blocks to full nodes
- Uses simple techniques to reduce bandwidth necessary for new block propagation to full
- Note: this is possible because nodes share much of the same mempool contents
- Sending peers send compact block “sketches” to receiving peers
- Sketches include the following information
- 80-byte header of new block
- Shortened transaction identifiers (txids) designed to prevent Denial-of-Service (DoS) attacks
- Some full transactions: sending peer predicts txns that the receiving peer doesn’t have
- Chaincode content
- My work
- Readings:
- Full Node (Fully Validating Node) = a node that is capable of validating transactions and blocks. Instead of searching through the blocks database every time, full nodes keep some state, i.e. a UTXO (unspent transaction output or “coins”) set.
- Archive Node = a node that has a copy of the entire history of the blockchain
- Mining Node = a node that produces new blocks
- Light Clients = generic term for a node that doesn’t keep the full state necessary for full validation and instead trusts other full nodes to do so
- "light client” is often used synonymously with Simplified Payment Verification (SPV) Nodes, and not to be confused with Pruning Nodes
- Outbound P2P Connection = automatic connection that your node initiated through peer discovery
- Inbound = automatic connection that your peer initiated (to your peer, this connection is outbound)
- Manual = connection that was made manually (e.g. through CLI or RPC) instead of automatically
- Full-Relay outbound connections expect to communicate everything, including blocks, transactions, and addrs (used to find peers, similar to IP addresses, and not to be confused with wallet addresses used in transactions)
- Block-Only-Relay outbound connections only expect to receive blocks. Not to be confused with blocks-only mode
- One-Shot and Feelers are temporary outbound connections used in node discovery