In March 2021, Bitcoin Association launched Bitcoin SV Academy with an introductory course on Bitcoin Development.
This free Bitcoin Development course focuses on the formative skills and crucial concepts to successfully build applications with Bitcoin.
To help you gauge whether this course is a good match for your academic aspirations, we’ve provided you with an outline of the course material, course reviews and feedback from one of the introduction to Bitcoin development course alumni.
To give you further insight in the course, this blog offers you a compilation of insightful questions from our Discord channel - with answers provided by the very individuals who create the course material.
Introductory Development course FAQ
Q: Which programming languages are required for the Introductory Development course? I know how to read and edit Perl and C++ is that enough?
A: You should be able to make sense of the code snippets, most of the tools are in JavaScript, so it would be helpful to know some Java. A lot of code snippets use JavaScript. But the course is written in such a way that you should be able to make sense of the concepts without knowing JavaScript or node/js. The focus is to explain concepts and usage more than writing code in this course.
Q: Does the Introductory Development course require coding practice or tasks to do? Or is it just reading and answering like the introduction course?
A: Some lessons have code snippets that you can read through or practice. Doing coding is optional and depends on your interest. Most of the assessments don't require you to code, but only to have understood the concepts.
Q: Do you know any links regarding bitcoin BSV programming (JavaScript preferable)?
A: The second Bitcoin SV academy course, Introduction to Bitcoin Development, covers what you need to get started developing with BSV: building, writing, posting TXs and getting, reading, deserialising them.
The main library used for JS as of today is the BSV library.
There's also a typed version on GitHub.
Q: Will the library work with HandCash?
A: The library has all the basics needed to build keys, txs, etc. HandCash is its own wallet that's focused on payments, so for example, you could build an app that generates QR codes for a lite wallet that you could then fund with your HandCash wallet. HandCash also has their HandCash Connect SDK which is essentially an API that allows you to integrate HandCash into your app as an authentication mechanism and a payments mechanism.
One thing that I want to stress though is that HandCash is strictly a payment wallet. They don't support data transactions, and I wouldn't recommend using a general payments wallet for building data transactions.
It's better to use a lite wallet design and transaction templates from within your app to handle data. Also, if you're inclined, I strongly recommend reading up on SPV and Peer channels (previously SPV Channels) as it's how all apps in BSV will eventually need to run in order to keep up with network scaling and increasing block sizes.
Finally, the Electrum SV SDK is a great tool that packages some components together, so you can develop on a local version of the BSV blockchain (the headless version is the most up to date).
Q: When you mean Handcash is focused on payments, do you mean like a shopping cart? Don't all transactions have some exchange of payment (satoshis) at some point?
A: I mean it's only focused payment transactions, i.e. Pay to Public Key Hash (P2PKH) transactions, where the transaction is transferring the ownership of a certain amount of satoshis (the smallest unit of BSV) from one address to another.
One way to think about it is in the context of Object Oriented programming (OOP). If you think of a transaction as being a general interface, all transactions have to have the requisite parts:
- Version no. (4 bytes)
- Input count (1-9 bytes)
- Input list (Variable length: funding UTXOs)
- Output count (1-9 bytes)
- Output list (Variable length: new UTXOs)
- nLocktime (4 bytes)
But, within each new UTXO, you have a locking script which uses the Turing complete Bitcoin Script language (based on Forth) that allows you to build almost anything. So, for example, you can build out a transaction template that utilises the first UTXO for storing data, the second UTXO for doing something with the data, the 3rd UTXO for sending an update signal to an IoT device, etc.
To break it down a bit further, you could create a UTXO interface, and then build out various objects from it and then insert them into a TX object to create a TX template.
Dr. Wright goes into a bit more detail on how it could work in a couple of talks with sCrypt creator Xiao Hui Liu.
To get back to answering your question, HandCash doesn't support custom UTXO locking scripts, it only allows for P2PKH (which is colloquially known as a standard transaction type).
Q: Which programming language should I learn if I want to become a Bitcoin developer?
A: It really doesn't matter that much. Choose one that you find most intuitive and learn the fundamentals with that language. Once you get to a certain point, the skills are transferable to most languages and you can learn a new one in 3 - 6 months.
One language that's been specifically designed to work well with parallel and distributed programming (what Bitcoin is designed to facilitate natively) is Go or GoLang. However, JavaScript and the myriad of JS frameworks continue to be the most used for front-end development (JS, HTML, and CSS), so you may want to start with Angular2+, React, or Vue and then incorporate GoLang as your back-end language for a full stack.
The key is to choose one framework and one back-end language that you like coding in, and then stick with them until you've become proficient enough with the fundamentals (conditionals/logic/design patterns) that your skills are transferable to a variety of languages and contexts.
Q: I have a problem with testnet coins: How do I get them?
A: Join the Testnet Telegram support group.
Q: This course needs some updates
A: Yes, we're currently in the midst of doing a full rework of the course.
One of the main reasons is to be more tool agnostic and focus on promoting approaches instead. Further, we're moving away from OP_RETURN toward using PUSH_DATA and Simplified Payment Verification (SPV).
Q: Quick question on payment channels: If I understand correctly, the last (greatest nSequence) transaction that is signed only by the last sender can be lost. The previous transaction would have already been signed by both parties allowing the provider or receiver of funds to redeem the payment. Is this correct?
Doesn’t it need both signatures for an amended transaction?
I’m assuming the last transaction would have been amended and then signed and sent to the second party for final signature. So, if this transaction does not get signed by the second party, this transaction can get lost.
I’m obviously misunderstanding something here.
A: You’re correct. If the script needs 2 signatures, only the most recent version that has 2 signatures will be accepted.
nLocktime has nothing to do with spendable, it only controls when it can be mined, dependent on nSequence being non-final. Obviously, if it is non-final it is also non-spendable, because it cannot be put onto the ledger.
Q: What does the R in R-Puzzle stand for? Random?
A: The signature is (r,s). R stands for this r value of the signature.
Q: Can you recommend a course, videos, etc. to learn the basics of all this ECC stuff? I have still trouble to understand all this 100%
A: Overall, there are three foundational concepts that, if understood well, can make the initial learning journey for Bitcoin SV easier: Hash Functions, Merkle Trees, and Digital Signatures.
To help you tackle these concepts, the BSV Academy is releasing short courses on each of these Bitcoin Primtives.
The Digital Signatures course focusses on Digital Signature Schemes such as RSA (based upon the name of its inventors Rivest-Shamir-Addlemen), Digital Standard Signature, ECDSA (Elliptic Curve Digital Signature Algorithm), used by enterprise products. For the scope of this course, our focus would only be ECDSA as used in Bitcoin SV.
However, to build a conceptual understanding, we will go in the following order:
Chapter 1 - What are Digital Signatures
Chapter 2 - ECDSA Pre-requisites
Chapter 3 - ECDSA
Chapter 4 - Bitcoin and Digital Signatures
Q: Can anyone recommend a good Faucet?
Bitcom and BitShell both look really interesting. I’d appreciate it if anyone could help me get them configured properly. Do they point to the mainnet or testnet? How do I change that? How much satoshi do I need in the wallet to play around with it? How do I avoid the npm errors throwing? That sort of thing. This is a very powerful and very cool tool.
A: If you're familiar with containers at all, you may find Jad Wahab’s RegTest stack helpful. It's a full dockerised dev environment that allows you to run your own local BSV chain and generate your own blocks (remember, block rewards are only accessible when they've reached a block depth of at least 100)
Q: Hi. I'm working on creating Metanet tx via the nChain Metanet PDF. It has a section:
‘It should be emphasised that creating an edge between two nodes is the creation of a logical link between them, and does not necessarily mean one spending an output of the other. This allows the creation of edges to remain as flexible as possible over time.’
It looks like it's possible to sign a Tx without spending UTXO from a key. I don't know how it works. Is there any sample transaction, or code snippet that does this? I'm trying to separate a node address and funding address, which will make Metanet tx creating easier for my app.
A: You can have different funding UTXO and the Metanet edge created from a parent node. I hope the diagram below explains how to do it. Basically, your TxID1 will have two inputs, one signing the parent pub key to make the reference with P(parent) and another from the spending tx.
