- The book seems to favor Python, but the book is over 2 years old, a lifetime in this industry. What is the "most favored" dev environment for BitCoin dev right now?
+ IDE? (E.g. - PyCharm for Python, or WebStorm for JS/TS, or whatever. Doesn't have to be JetBrains, I just happen to like their stuff)
+ Programming language? Python, JS (or TS)?, etc.
I have no idea. I’m a C programmer; and I prefer to write code in vi(1). Not “Vim”.
nvi.The best language for writing Bitcoin-related code is
C the language at which you yourself most excel. Well, as long as it’s not COBOL, MUMPS, or BF, I suppose.
- How does the blockchain network prevent errors in the miner's calculations from corrupting the transactions? For example, suppose a bunch of miners are using the same CPU or GPU that has a known defect in, for example, the overflow/underflow handling in the arithmetic logic units or perhaps a flaw in the transcendental functions on a GPU card, etc.? I know a lot of miners use ASICs but I don't see why that architecture would be immune to such problems?
There is a common misconception that miners provide the security of the network. This is patently false. Miners have exactly one job: To provide Byzantine fault-tolerant ordering of transactions, thus preventing double-spends. It is a valuable and resource-intensive job; and that is why they get paid for it. But it is still only one function in a machine with many moving parts.
This ACM Queue article provides an excellent overview of how Bitcoin fits together against the backdrop of decades of academic research. As its centre, it explains how Satoshi Nakamoto repurposed Adam Back’s HashCash to create the first-ever practical implementation of a Byzantine fault-tolerant decentralized database with excellent Sybil resistance. That is the purpose of mining, and its only purpose.
Validation security is provided by
full nodes. Each individual full node provides validation security for its owner; and all full nodes collectively enforce the consensus rule validation security of the entire network. Thus here as everywhere else, Bitcoin aligns the individual’s selfish interest with the common good: People who want the highest security will run a full node to secure themselves, and thus help secure everybody else, also.
In the scenario you describe, I do expect that hashing and signature validation would catch the errors; and the block containing corrupted transactions would be discarded by full nodes as if it had never existed. A full node does
not blindly follow “the longest chain”, as you may have heard: Rather, a full node follows the
independently validated and fully valid chain with the highest total proof-of-work.
This also applies to malicious mining of deliberately corrupted transactions, attempted thefts, ridiculously huge blocks, etc. Sometimes you may see nonsensical FUD claiming that miners could seize money by planting theft transactions in blocks,
e.g. by ignoring Segwit validation rules; no, they would get exactly the same result as if they filled blocks with the output of /dev/random.
- Regarding smart contracts directly on the BitCoin network (i.e. - not Ethereum based), I see two projects in the field: Ivy and Rootstock. How does Ivy relate to Rootstock if at all?
I have not been following development of those lately, so I can’t say.
If you are interested in smart contracts, you may appreciate a peek at current R&D which
may potentially someday become the future of Bitcoin smart contracts:
Simplicity (PDF). Powerfully expressive smart contracts written with in a formally verifiable DSL, running on a formally verified VM, would have none of the exploding clown car disasters inevitably resulting from the stupidity of bolting a Turing-complete VM onto a blockchain.
- Please list your favorite tools and tutorials.
Tools depend on what job you need done; and I don’t really know any good tutorials off the top of my head. But here are some educational links:
HTH.
