回目录 《比特币:深度解析》
Walk through Sourcecode 源码解读
refer: https://github.com/lyhistory/blockchain_btc/blob/master/basic/bitcoincore_v0.17.1_sourcecode.txt
Nobody Understands Bitcoin (And That’s OK) https://blog.lopp.net/nobody-understands-bitcoin-and-thats-ok/
Bitcoin Core architecture overview http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/edgedevplusplus/overview-bitcoin-core-architecture/
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
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 https://bitcoin.org/en/glossary/headers-first-sync https://bitcoin.org/en/glossary/initial-block-download https://bitcoin.org/en/developer-guide#headers-first https://bitcoin.stackexchange.com/questions/44400/can-there-be-stale-blocks-in-header-first-implementation
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. https://eprint.iacr.org/2015/578.pdf
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.
闪电网络解决方法 sighash no input
Segregate witness方法(transaction id不包含签名) ### 2.3 仲裁交易
Revocable Sequence Maturity Contract HLTC
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!
More: https://github.com/fiatjaf/lightningd-gjson-rpc/tree/x1/cmd Binary: https://github.com/fiatjaf/lightningd-gjson-rpc/releases/tag/x1
手把手教你在树莓派上部署比特币闪电节点+全节点 https://www.weibo.com/ttarticle/p/show?id=2309404252965299998074
# Why Separate execution of unlocking and locking scripts
https://bitcointalk.org/index.php?topic=5095376.new#new https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures 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 : Code: