1.bitcoin source code
Walk through Sourcecode 源码解读
Nobody Understands Bitcoin (And That’s OK)
1.1 Overview architecture
Bitcoin Core architecture overview
Dev++ 02-22-EN | An overview of Bitcoin Core architecture - James O’Beirne | Platforms:
- slides: http://jameso.be/dev++2018/
- video: https://www.youtube.com/watch?v=L_sI_tXmy2U
1.2 Code Anatomy
Bitcoin Core 0.11 (ch 3): Initialization and Startup
Bitcoin Core 0.11 (ch 5): Initial Block Download
network sync: net_processing:
Header first IBD
request management system
To minimize information spread in the network, messages are propagated in the Bitcoin network with the help of an advertisement-based request management system. Namely, if node A receives information about a new Bitcoin object (e.g., a transaction or a block)from another node,A will advertise this object to its other connections (e.g. nodeV) by sending them an inv message; these messages are much smaller in size than the actual objects, because they only contain the hash and the type of object which is advertised. Only if node V has not previously received the object advertised by the inv message,V will request the object from A with a getdata request.Following the Bitcoin protocol, nodeAwill subsequently respondwith a Bitcoin object, e.g., the contents of a transaction or a block.By doing so, inventory messages limit the amount of data broadcast in the network. Notice that in case the object advertised corresponds to a block, neighbor V first requests the block header before the actual block data. Here, when a block header is advertised via a headers message, the receiving node internally stores the highest block known by the sending peer. The receiving node also validates any received header, by verifying its corresponding PoW. Transactions, on the other hand, are requested directly using a transaction inv message.
2.1 Atomic transactions
atomic transaction http://www.ofnumbers.com/2014/01/28/what-is-an-atomic-transaction/
Atomic cross-chain trading https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
In short, when exchanging one cryptocoin with another (such as a Bitcoin for a Litecoin or colored coins), either the trade occurs or it does not. Michael Goldstein explains this concisely over at Lex Cryptographia:
Two parties agree to exchange one cryptocurrency for another, and the transaction is done in such a way that neither side can execute their portion of the trade without releasing funds to the other party. The trade either happens in its entirety, or not at all, which means nobody can walk away empty-handed. The worse possible outcome is that no trade occurs at all and everybody keeps what they had.
The key is the nLockTime function described in Atomic cross-chain trading. I also recommend looking through the Bitcointalk thread Alt chains and atomic transfers.
2.2 Transaction Malleability
闪电网络解决方法 sighash no input
Segregate witness方法（transaction id不包含签名） ### 2.3 仲裁交易
2.4 微支付通道 Micropayment Channel
Revocable Sequence Maturity Contract
Ever wanted to run a c-lightning node without having to run bitcoind? Your problems are over: with the new
trustedcoin plugin you can rely on block explorers for everything!
Still better than Paypal. And it works!
2.6 segregated witness
# Why Separate execution of unlocking and locking scripts
Here you can see a list of all Bitcoin CVEs, including the one you are talking about.
To understand what happened in CVE-2010-5141 you need to understand Script execution and OP_PUSHDATA. When validating a script, bitcoin-core used to use a stack and fusion script_sig with script_pubkey onto it, which led to a stack being :
You could simply use an OP_PUSHDATA in script_sig, which would push the scriptpubkey onto the stack without executing it.
The scriptpubkey not executed resulting in conditions under which you can spend the output that are not set. Thus you could spend any output using OP_PUSHDATA. Now, the code executes script_sig on a stack, copy it (to stackCopy), then executes script_pubkey on stack (the first one).
Here is the link to the function evaluating the script.
**# Timelock Defense Against Fee Sniping ??? don’t understand**
**# chater 07 Complex Script Example**
A few more things to consider when reading this example. See if you can find the answers:
● Why can’t the lawyer redeem the third execution path at any time by selecting it with FALSE on the unlocking script?
● How many execution paths can be used 5, 35, and 105 days, respectively, after the UTXO is mined?
● Are the funds lost if the lawyer loses his key? Does your answer change if 91 days have elapsed?
● How do the partners "reset" the clock every 29 or 89 days to prevent the lawyer from accessing the funds?
● Why do some CHECKSIG opcodes in this script have the VERIFY suffix while others don’t?
**# chater 10**
In practice, a miner may intentionally mine a block taking less than the full reward. Such blocks have already been mined and more may be mined in the
There are also "stake grinding" attacks which require a trivial amount of currency. In a stake grinding attack, the attacker has a small amount of stake and goes through the history of the blockchain and finds places where their stake wins a block. In order to consecutively win, they modify the next block header until some stake they own wins once again. This attack requires a bit of computation, but definately isn't impractical.
Deep Dive of the History Revision Attack
[Bitcoin tech talk](https://jimmysong.substack.com/people/1811560-jimmy-song)
Bitcoin Cold Storage Using a Bitcoin Core Wallet https://dev-notes.eu/2017/08/setup-and-manage-bitcoin-core-cold-storage-wallet/
[Bitcoin core tutorial & code walk through](http://embedded-design-vic.blogspot.com/2017/07/bitcoin-core-tutorial-and-source-code.html)