transactions - What is the Merkle root? - Bitcoin Stack ...

Proof Of Work Explained

Proof Of Work Explained
A proof-of-work (PoW) system (or protocol, or function) is a consensus mechanism that was first invented by Cynthia Dwork and Moni Naor as presented in a 1993 journal article. In 1999, it was officially adopted in a paper by Markus Jakobsson and Ari Juels and they named it as "proof of work".
It was developed as a way to prevent denial of service attacks and other service abuse (such as spam on a network). This is the most widely used consensus algorithm being used by many cryptocurrencies such as Bitcoin and Ethereum.
How does it work?
In this method, a group of users competes against each other to find the solution to a complex mathematical puzzle. Any user who successfully finds the solution would then broadcast the block to the network for verifications. Once the users verified the solution, the block then moves to confirm the state.
The blockchain network consists of numerous sets of decentralized nodes. These nodes act as admin or miners which are responsible for adding new blocks into the blockchain. The miner instantly and randomly selects a number which is combined with the data present in the block. To find a correct solution, the miners need to select a valid random number so that the newly generated block can be added to the main chain. It pays a reward to the miner node for finding the solution.
The block then passed through a hash function to generate output which matches all input/output criteria. Once the result is found, other nodes in the network verify and validate the outcome. Every new block holds the hash of the preceding block. This forms a chain of blocks. Together, they store information within the network. Changing a block requires a new block containing the same predecessor. It is almost impossible to regenerate all successors and change their data. This protects the blockchain from tampering.
What is Hash Function?
A hash function is a function that is used to map data of any length to some fixed-size values. The result or outcome of a hash function is known as hash values, hash codes, digests, or simply hashes.
The hash method is quite secure, any slight change in input will result in a different output, which further results in discarded by network participants. The hash function generates the same length of output data to that of input data. It is a one-way function i.e the function cannot be reversed to get the original data back. One can only perform checks to validate the output data with the original data.
Nowadays, Proof-of-Work is been used in a lot of cryptocurrencies. But it was first implemented in Bitcoin after which it becomes so popular that it was adopted by several other cryptocurrencies. Bitcoin uses the puzzle Hashcash, the complexity of a puzzle is based upon the total power of the network. On average, it took approximately 10 min to block formation. Litecoin, a Bitcoin-based cryptocurrency is having a similar system. Ethereum also implemented this same protocol.
Types of PoW
Proof-of-work protocols can be categorized into two parts:-
· Challenge-response
This protocol creates a direct link between the requester (client) and the provider (server).
In this method, the requester needs to find the solution to a challenge that the server has given. The solution is then validated by the provider for authentication.
The provider chooses the challenge on the spot. Hence, its difficulty can be adapted to its current load. If the challenge-response protocol has a known solution or is known to exist within a bounded search space, then the work on the requester side may be bounded.
· Solution–verification
These protocols do not have any such prior link between the sender and the receiver. The client, self-imposed a problem and solve it. It then sends the solution to the server to check both the problem choice and the outcome. Like Hashcash these schemes are also based on unbounded probabilistic iterative procedures.
These two methods generally based on the following three techniques:-
This technique depends upon the speed of the processor. The higher the processor power greater will be the computation.
This technique utilizes the main memory accesses (either latency or bandwidth) in computation speed.
In this technique, the client must perform a few computations and wait to receive some tokens from remote servers.
List of proof-of-work functions
Here is a list of known proof-of-work functions:-
o Integer square root modulo a large prime
o Weaken Fiat–Shamir signatures`2
o Ong–Schnorr–Shamir signature is broken by Pollard
o Partial hash inversion
o Hash sequences
o Puzzles
o Diffie–Hellman–based puzzle
o Moderate
o Mbound
o Hokkaido
o Cuckoo Cycle
o Merkle tree-based
o Guided tour puzzle protocol
A successful attack on a blockchain network requires a lot of computational power and a lot of time to do the calculations. Proof of Work makes hacks inefficient since the cost incurred would be greater than the potential rewards for attacking the network. Miners are also incentivized not to cheat.
It is still considered as one of the most popular methods of reaching consensus in blockchains. Though it may not be the most efficient solution due to high energy extensive usage. But this is why it guarantees the security of the network.
Due to Proof of work, it is quite impossible to alter any aspect of the blockchain, since any such changes would require re-mining all those subsequent blocks. It is also difficult for a user to take control over the network computing power since the process requires high energy thus making these hash functions expensive.
submitted by RumaDas to u/RumaDas [link] [comments]

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.
  • Bitcoin (BTC) is a peer-to-peer cryptocurrency that aims to function as a means of exchange that is independent of any central authority. BTC can be transferred electronically in a secure, verifiable, and immutable way.
  • Launched in 2009, BTC is the first virtual currency to solve the double-spending issue by timestamping transactions before broadcasting them to all of the nodes in the Bitcoin network. The Bitcoin Protocol offered a solution to the Byzantine Generals’ Problem with a blockchain network structure, a notion first created by Stuart Haber and W. Scott Stornetta in 1991.
  • Bitcoin’s whitepaper was published pseudonymously in 2008 by an individual, or a group, with the pseudonym “Satoshi Nakamoto”, whose underlying identity has still not been verified.
  • The Bitcoin protocol uses an SHA-256d-based Proof-of-Work (PoW) algorithm to reach network consensus. Its network has a target block time of 10 minutes and a maximum supply of 21 million tokens, with a decaying token emission rate. To prevent fluctuation of the block time, the network’s block difficulty is re-adjusted through an algorithm based on the past 2016 block times.
  • With a block size limit capped at 1 megabyte, the Bitcoin Protocol has supported both the Lightning Network, a second-layer infrastructure for payment channels, and Segregated Witness, a soft-fork to increase the number of transactions on a block, as solutions to network scalability.

1. What is Bitcoin (BTC)?

  • Bitcoin is a peer-to-peer cryptocurrency that aims to function as a means of exchange and is independent of any central authority. Bitcoins are transferred electronically in a secure, verifiable, and immutable way.
  • Network validators, whom are often referred to as miners, participate in the SHA-256d-based Proof-of-Work consensus mechanism to determine the next global state of the blockchain.
  • The Bitcoin protocol has a target block time of 10 minutes, and a maximum supply of 21 million tokens. The only way new bitcoins can be produced is when a block producer generates a new valid block.
  • The protocol has a token emission rate that halves every 210,000 blocks, or approximately every 4 years.
  • Unlike public blockchain infrastructures supporting the development of decentralized applications (Ethereum), the Bitcoin protocol is primarily used only for payments, and has only very limited support for smart contract-like functionalities (Bitcoin “Script” is mostly used to create certain conditions before bitcoins are used to be spent).

2. Bitcoin’s core features

For a more beginner’s introduction to Bitcoin, please visit Binance Academy’s guide to Bitcoin.

Unspent Transaction Output (UTXO) model

A UTXO transaction works like cash payment between two parties: Alice gives money to Bob and receives change (i.e., unspent amount). In comparison, blockchains like Ethereum rely on the account model.

Nakamoto consensus

In the Bitcoin network, anyone can join the network and become a bookkeeping service provider i.e., a validator. All validators are allowed in the race to become the block producer for the next block, yet only the first to complete a computationally heavy task will win. This feature is called Proof of Work (PoW).
The probability of any single validator to finish the task first is equal to the percentage of the total network computation power, or hash power, the validator has. For instance, a validator with 5% of the total network computation power will have a 5% chance of completing the task first, and therefore becoming the next block producer.
Since anyone can join the race, competition is prone to increase. In the early days, Bitcoin mining was mostly done by personal computer CPUs.
As of today, Bitcoin validators, or miners, have opted for dedicated and more powerful devices such as machines based on Application-Specific Integrated Circuit (“ASIC”).
Proof of Work secures the network as block producers must have spent resources external to the network (i.e., money to pay electricity), and can provide proof to other participants that they did so.
With various miners competing for block rewards, it becomes difficult for one single malicious party to gain network majority (defined as more than 51% of the network’s hash power in the Nakamoto consensus mechanism). The ability to rearrange transactions via 51% attacks indicates another feature of the Nakamoto consensus: the finality of transactions is only probabilistic.
Once a block is produced, it is then propagated by the block producer to all other validators to check on the validity of all transactions in that block. The block producer will receive rewards in the network’s native currency (i.e., bitcoin) as all validators approve the block and update their ledgers.

The blockchain

Block production

The Bitcoin protocol utilizes the Merkle tree data structure in order to organize hashes of numerous individual transactions into each block. This concept is named after Ralph Merkle, who patented it in 1979.
With the use of a Merkle tree, though each block might contain thousands of transactions, it will have the ability to combine all of their hashes and condense them into one, allowing efficient and secure verification of this group of transactions. This single hash called is a Merkle root, which is stored in the Block Header of a block. The Block Header also stores other meta information of a block, such as a hash of the previous Block Header, which enables blocks to be associated in a chain-like structure (hence the name “blockchain”).
An illustration of block production in the Bitcoin Protocol is demonstrated below.

Block time and mining difficulty

Block time is the period required to create the next block in a network. As mentioned above, the node who solves the computationally intensive task will be allowed to produce the next block. Therefore, block time is directly correlated to the amount of time it takes for a node to find a solution to the task. The Bitcoin protocol sets a target block time of 10 minutes, and attempts to achieve this by introducing a variable named mining difficulty.
Mining difficulty refers to how difficult it is for the node to solve the computationally intensive task. If the network sets a high difficulty for the task, while miners have low computational power, which is often referred to as “hashrate”, it would statistically take longer for the nodes to get an answer for the task. If the difficulty is low, but miners have rather strong computational power, statistically, some nodes will be able to solve the task quickly.
Therefore, the 10 minute target block time is achieved by constantly and automatically adjusting the mining difficulty according to how much computational power there is amongst the nodes. The average block time of the network is evaluated after a certain number of blocks, and if it is greater than the expected block time, the difficulty level will decrease; if it is less than the expected block time, the difficulty level will increase.

What are orphan blocks?

In a PoW blockchain network, if the block time is too low, it would increase the likelihood of nodes producingorphan blocks, for which they would receive no reward. Orphan blocks are produced by nodes who solved the task but did not broadcast their results to the whole network the quickest due to network latency.
It takes time for a message to travel through a network, and it is entirely possible for 2 nodes to complete the task and start to broadcast their results to the network at roughly the same time, while one’s messages are received by all other nodes earlier as the node has low latency.
Imagine there is a network latency of 1 minute and a target block time of 2 minutes. A node could solve the task in around 1 minute but his message would take 1 minute to reach the rest of the nodes that are still working on the solution. While his message travels through the network, all the work done by all other nodes during that 1 minute, even if these nodes also complete the task, would go to waste. In this case, 50% of the computational power contributed to the network is wasted.
The percentage of wasted computational power would proportionally decrease if the mining difficulty were higher, as it would statistically take longer for miners to complete the task. In other words, if the mining difficulty, and therefore targeted block time is low, miners with powerful and often centralized mining facilities would get a higher chance of becoming the block producer, while the participation of weaker miners would become in vain. This introduces possible centralization and weakens the overall security of the network.
However, given a limited amount of transactions that can be stored in a block, making the block time too longwould decrease the number of transactions the network can process per second, negatively affecting network scalability.

3. Bitcoin’s additional features

Segregated Witness (SegWit)

Segregated Witness, often abbreviated as SegWit, is a protocol upgrade proposal that went live in August 2017.
SegWit separates witness signatures from transaction-related data. Witness signatures in legacy Bitcoin blocks often take more than 50% of the block size. By removing witness signatures from the transaction block, this protocol upgrade effectively increases the number of transactions that can be stored in a single block, enabling the network to handle more transactions per second. As a result, SegWit increases the scalability of Nakamoto consensus-based blockchain networks like Bitcoin and Litecoin.
SegWit also makes transactions cheaper. Since transaction fees are derived from how much data is being processed by the block producer, the more transactions that can be stored in a 1MB block, the cheaper individual transactions become.
The legacy Bitcoin block has a block size limit of 1 megabyte, and any change on the block size would require a network hard-fork. On August 1st 2017, the first hard-fork occurred, leading to the creation of Bitcoin Cash (“BCH”), which introduced an 8 megabyte block size limit.
Conversely, Segregated Witness was a soft-fork: it never changed the transaction block size limit of the network. Instead, it added an extended block with an upper limit of 3 megabytes, which contains solely witness signatures, to the 1 megabyte block that contains only transaction data. This new block type can be processed even by nodes that have not completed the SegWit protocol upgrade.
Furthermore, the separation of witness signatures from transaction data solves the malleability issue with the original Bitcoin protocol. Without Segregated Witness, these signatures could be altered before the block is validated by miners. Indeed, alterations can be done in such a way that if the system does a mathematical check, the signature would still be valid. However, since the values in the signature are changed, the two signatures would create vastly different hash values.
For instance, if a witness signature states “6,” it has a mathematical value of 6, and would create a hash value of 12345. However, if the witness signature were changed to “06”, it would maintain a mathematical value of 6 while creating a (faulty) hash value of 67890.
Since the mathematical values are the same, the altered signature remains a valid signature. This would create a bookkeeping issue, as transactions in Nakamoto consensus-based blockchain networks are documented with these hash values, or transaction IDs. Effectively, one can alter a transaction ID to a new one, and the new ID can still be valid.
This can create many issues, as illustrated in the below example:
  1. Alice sends Bob 1 BTC, and Bob sends Merchant Carol this 1 BTC for some goods.
  2. Bob sends Carols this 1 BTC, while the transaction from Alice to Bob is not yet validated. Carol sees this incoming transaction of 1 BTC to him, and immediately ships goods to B.
  3. At the moment, the transaction from Alice to Bob is still not confirmed by the network, and Bob can change the witness signature, therefore changing this transaction ID from 12345 to 67890.
  4. Now Carol will not receive his 1 BTC, as the network looks for transaction 12345 to ensure that Bob’s wallet balance is valid.
  5. As this particular transaction ID changed from 12345 to 67890, the transaction from Bob to Carol will fail, and Bob will get his goods while still holding his BTC.
With the Segregated Witness upgrade, such instances can not happen again. This is because the witness signatures are moved outside of the transaction block into an extended block, and altering the witness signature won’t affect the transaction ID.
Since the transaction malleability issue is fixed, Segregated Witness also enables the proper functioning of second-layer scalability solutions on the Bitcoin protocol, such as the Lightning Network.

Lightning Network

Lightning Network is a second-layer micropayment solution for scalability.
Specifically, Lightning Network aims to enable near-instant and low-cost payments between merchants and customers that wish to use bitcoins.
Lightning Network was conceptualized in a whitepaper by Joseph Poon and Thaddeus Dryja in 2015. Since then, it has been implemented by multiple companies. The most prominent of them include Blockstream, Lightning Labs, and ACINQ.
A list of curated resources relevant to Lightning Network can be found here.
In the Lightning Network, if a customer wishes to transact with a merchant, both of them need to open a payment channel, which operates off the Bitcoin blockchain (i.e., off-chain vs. on-chain). None of the transaction details from this payment channel are recorded on the blockchain, and only when the channel is closed will the end result of both party’s wallet balances be updated to the blockchain. The blockchain only serves as a settlement layer for Lightning transactions.
Since all transactions done via the payment channel are conducted independently of the Nakamoto consensus, both parties involved in transactions do not need to wait for network confirmation on transactions. Instead, transacting parties would pay transaction fees to Bitcoin miners only when they decide to close the channel.
One limitation to the Lightning Network is that it requires a person to be online to receive transactions attributing towards him. Another limitation in user experience could be that one needs to lock up some funds every time he wishes to open a payment channel, and is only able to use that fund within the channel.
However, this does not mean he needs to create new channels every time he wishes to transact with a different person on the Lightning Network. If Alice wants to send money to Carol, but they do not have a payment channel open, they can ask Bob, who has payment channels open to both Alice and Carol, to help make that transaction. Alice will be able to send funds to Bob, and Bob to Carol. Hence, the number of “payment hubs” (i.e., Bob in the previous example) correlates with both the convenience and the usability of the Lightning Network for real-world applications.

Schnorr Signature upgrade proposal

Elliptic Curve Digital Signature Algorithm (“ECDSA”) signatures are used to sign transactions on the Bitcoin blockchain.
However, many developers now advocate for replacing ECDSA with Schnorr Signature. Once Schnorr Signatures are implemented, multiple parties can collaborate in producing a signature that is valid for the sum of their public keys.
This would primarily be beneficial for network scalability. When multiple addresses were to conduct transactions to a single address, each transaction would require their own signature. With Schnorr Signature, all these signatures would be combined into one. As a result, the network would be able to store more transactions in a single block.
The reduced size in signatures implies a reduced cost on transaction fees. The group of senders can split the transaction fees for that one group signature, instead of paying for one personal signature individually.
Schnorr Signature also improves network privacy and token fungibility. A third-party observer will not be able to detect if a user is sending a multi-signature transaction, since the signature will be in the same format as a single-signature transaction.

4. Economics and supply distribution

The Bitcoin protocol utilizes the Nakamoto consensus, and nodes validate blocks via Proof-of-Work mining. The bitcoin token was not pre-mined, and has a maximum supply of 21 million. The initial reward for a block was 50 BTC per block. Block mining rewards halve every 210,000 blocks. Since the average time for block production on the blockchain is 10 minutes, it implies that the block reward halving events will approximately take place every 4 years.
As of May 12th 2020, the block mining rewards are 6.25 BTC per block. Transaction fees also represent a minor revenue stream for miners.
submitted by D-platform to u/D-platform [link] [comments]

TKEYSPACE — blockchain in your mobile

TKEYSPACE — blockchain in your mobile
Someone says that the blockchain in the phone is marketing. This is possible for most applications, but not for Tkeycoin. Today we will talk about how the blockchain works in the TkeySpace app.
Who else is not in the topic, TkeySpace is a financial application for decentralized and efficient management of various cryptocurrencies, based on a distributed architecture without using a client-server.
In simple words, it is a blockchain in the user’s mobile device that excludes hacking and hacker attacks, and all data is encrypted using modern cryptographic methods.


Let’s start with the most important thing — the blockchain works on the principles of P2P networks, when there is no central server and each device is both a server and a client, such an organization allows you to maintain the network performance with any number and any combination of available nodes.
For example, there are 12 machines in the network, and anyone can contact anyone. As a client (resource consumer), each of these machines can send requests for the provision of some resources to other machines within this network and receive them. As a server, each machine must process requests from other machines in the network, send what was requested, and perform some auxiliary and administrative functions.
With traditional client-server systems, we can get a completely disabled social network, messenger, or another service, given that we rely on a centralized infrastructure — we have a very specific number of points of failure. If the main data center is damaged due to an earthquake or any other event, access to information will be slowed down or completely disabled.
With a P2P solution, the failure of one network member does not affect the network operation in any way. P2P networks can easily switch to offline mode when the channel is broken — in which it will exist completely independently and without any interaction.
Instead of storing information in a single central point, as traditional recording methods do, multiple copies of the same data are stored in different locations and on different devices on the network, such as computers or mobile devices.
This means that even if one storage point is damaged or lost, multiple copies remain secure in other locations. Similarly, if one part of the information is changed without the consent of the rightful owners, there are many other copies where the information is correct, which makes the false record invalid.
The information recorded in the blockchain can take any form, whether it is a transfer of money, ownership, transaction, someone’s identity, an agreement between two parties, or even how much electricity a light bulb used.
However, this requires confirmation from multiple devices, such as nodes in the network. Once an agreement, otherwise known as consensus, is reached between these devices to store something on the blockchain — it can’t be challenged, deleted, or changed.
The technology also allows you to perform a truly huge amount of computing in a relatively short time, which even on supercomputers would require, depending on the complexity of the task, many years or even centuries of work. This performance is achieved because a certain global task is divided into a large number of blocks, which are simultaneously performed by hundreds of thousands of devices participating in the project.

P2P messaging and syncing in TkeySpace

TkeySpace is a node of the TKEY network and other supported networks. when you launch the app, your mobile node connects to an extensive network of supported blockchains, syncs with full nodes to validate transactions and incoming information between nodes, so the nodes organize a graph of connections between them.
You can always check the node information in the TkeySpace app in the ⚙ Settings Contact and peer info App Status;
TkeySpace creates initiating connections to servers registered in the blockchain Protocol as the main ones, from these servers it gets the addresses of nodes to which it can join, in turn, the nodes to which the connection occurred share information about other nodes.
TkeySpace sends network messages to nodes from supported blockchains in the app to get up-to-date data from the network.
The Protocol uses data structures for communication between nodes, such as block propagation over the network, so before network messages are read, nodes check the “magic number”, check the first bytes, and determine the type of data structure. In the blockchain, the “magic number” is the network ID used to filter messages and block traffic from other p2p networks.
Magic numbers are used in computer science, both for files and protocols. They identify the type of file/data structure. A program that receives such a file/data structure can check the magic number and immediately find out the intended type of this file/data structure.
The first message that your node sends is called a Version Message. In response, the node waits for a Verack message to establish a connection between other peers. The exchange of such messages is called a “handshake”.
After the “handshake” is set, TkeySpace will start connecting to other nodes in the network to determine the last block at the end of the required blockchain. At this point — nodes request information about blocks they know using GetBlock messages — in response, your node receives an inv (Inventory Message) from another node with the information that it has the information that was requested by the TkeySpace node.
In response to the received message, inv — TkeySpace sends a GetData message containing a list of blocks starting immediately after the last known hash.

Loading and storing blocks

After exchanging messages, the block information is loaded and transactions are uploaded to your node. To avoid storing tons of information and optimize hard disk space and data processing speed, we use RDBMS — PostgreSQL in full nodes (local computer wallet).
In the TkeySpace mobile app, we use SQLite, and validation takes place by uploading block headers through the Merkle Tree, using the bloom filter — this allows you to optimize the storage of your mobile device as much as possible.
The block header includes its hash, the hash of the previous block, transaction hashes, and additional service information.
Block headers in the Tkeycoin network=84 bytes due to the extension of parameters to support nChains, which will soon be launched in “combat” mode. The titles of the Bitcoin block, Dash, Litecoin=80 bytes.
And so, let’s continue — application nodes receive information from the blockchain by uploading block headers, all data is synchronized using the Merkle Tree, or rather your node receives and validates information from the Merkle root.
The hash tree was developed in 1979 by Ralph Merkle and named in his honor. The structure of the system has received this name also because it resembles a tree.
The Merkle tree is a complete binary tree with leaf vertexes containing hashes from data blocks, and inner vertexes containing hashes from adding values in child vertexes. The root node of the tree contains a hash from the entire data set, meaning the hash tree is a unidirectional hash function. The Merkle tree is used for the efficient storage of transactions in the cryptocurrency blockchain. It allows you to get a “fingerprint” of all transactions in the block, as well as effectively verify transactions.
Hash trees have an advantage over hash chains or hash functions. When using hash trees, it is much less expensive to prove that a certain block of data belongs to a set. Since different blocks are often independent data, such as transactions or parts of files, we are interested in being able to check only one block without recalculating the hashes for the other nodes in the tree.
The Merkle Tree scheme allows you to check whether the hash value of a particular transaction is included in Merkle Root, without having all the other transactions in the block. So by having the transaction, block header, and Merkle Branch for that transaction requested from the full node, the digital wallet can make sure that the transaction was confirmed in a specific block.
The Merkle tree, which is used to prove that a transaction is included in a block, is also very well scaled. Because each new “layer” added to the tree doubles the total number of “leaves” it can represent. You don’t need a deep tree to compactly prove transaction inclusion, even among blocks with millions of transactions.

Statistical constants and nChains

To support the Tkeycoin cryptocurrency, the TkeySpace application uses additional statistical constants to prevent serialization of Merkle tree hashes, which provides an additional layer of security.
Also, for Tkeycoin, support for multi-chains (nChains) is already included in the TkeySpace app, which will allow you to use the app in the future with most of the features of the TKEY Protocol, including instant transactions.

The Bloom Filter

An additional level of privacy is provided by the bloom filter — which is a probabilistic data structure that allows you to check whether an element belongs to a set.
The bloom filter looks for whether a particular transaction is linked to Alice, not whether Alice has a specific cryptocurrency. In this way, transactions and received IDs are analyzed through a bloom filter. When “Alice wants to know about transaction X”, an ID is requested for transaction X, which is compared with the filled segments in her bloom filter. If “Yes” is received, the node can get the information and verify the transaction.

HD support

The multi-currency wallet TkeySpace is based on HD (or hierarchical determinism), a privacy-oriented method for generating and managing addresses. Each wallet address is generated from an xPub wallet (or extended public key). The app is completely anonymous — and individual address is generated for each transaction to accept a particular cryptocurrency. Even for low-level programming, using the same address is negative for the system, not to mention your privacy. We recommend that you always use a new address for transactions to ensure the necessary level of privacy and security.
The EXT_PUBLIC_KEY and EXT_SECRET_KEY values for DASH, Bitcoin, and Litecoin are completely identical. Tkeycoin uses its values, as well as other methods for storing transactions and blocks (RDBMS), and of course — nChains.

Secret key

Wallets in the blockchain have public and private keys.
Centralized applications usually store users’ private keys on their servers, which makes users’ funds vulnerable to hacker attacks or theft.
A private key is a special combination of characters that provides access to cryptocurrencies stored on the account. Only a person who knows the key can move and spend digital assets.
TkeySpace — stores the encrypted key only on the user’s device and in encrypted form. The encrypted key is displayed as a mnemonic phrase (backup phrase), which is very convenient for users. Unlike complex cryptographic ciphers, the phrase is easy to save or write. A backup keyword provides the maximum level of security.
A mnemonic phrase is 12 or 24 words that are generated using random number entropy. If a phrase consists of 12 words, then the number of possible combinations is 204⁸¹² or 21¹³² — the phrase will have 132 security bits. To restore the wallet, you must enter the mnemonic phrase in strict order, as it was presented after generation.


Now we understand that your application TkeySpace is a node of the blockchain that communicates with other nodes using p2p messages, stores block headers and validate information using the Merkle Tree, verifies transactions, filters information using the bloom filter, and operates completely in a decentralized model. The application code contains all the necessary blockchain settings for communicating with the network, the so-called chain parameters.
TkeySpace is a new generation mobile app. A completely new level of security, easy user-friendly interfaces and all the necessary features that are required to work with cryptocurrency.
submitted by tkeycoin to Tkeycoin_Official [link] [comments]

Bitcoin Witness: use the worlds most secure, immutable, and decentralised public database to attest to the integrity of your files

About me

I have only ever done basic web development before but over the last 4-6 months i have been spending my time learning javascript, vuejs and a few blockchain technologies. I have finally finished the first release of Bitcoin Witness. I am aware that similar services already exist but my focus has been on simplifying the user experience and also making it scalable and free for anyone to use. Below provides more info on the app. I would love your feedback on the app and ideas / suggestions for me to take into the roadmap.

About Bitcoin Witness is a free service that allows you to take any file and have its fingerprint witnessed in a bitcoin transaction. The service then allows you to download a proof file that can be used as verifiable evidence that your files fingerprint matches the fingerprint witnessed in the bitcoin transaction. The verification can be done using open source software even if our website does not exist in the future.

Protecting your data

We do not store your files data, in fact your files data is never even sent to our servers. Instead, your file is analysed locally in the browser to generate a SHA256 hash which is your files fingerprint.
The only data we do store is the file name, the fingerprint (hash), and the proof file generated by the app. This is so you can access and download proofs in the future. Anyone can retrieve the proof by presenting the original file at any time.
As you witness files, their fingerprint is also stored in your local cache so that you can easily retrieve the proof files when you load bitcoin witness on that device. It is recommend you download the proof once they are available to remove any reliance on our service.

How it works

Bitcoin Witness uses the Chainpoint protocol for many of its operations. Chainpoint is a layer two decentralised network that runs atop of (and supports the scaling of) bitcoin. Currently there are ~6500 community run Chainpoint nodes. Chainpoint nodes receive hashes and aggregate them together in a Merkle tree. The root of this tree is then included in a bitcoin transaction.
Your files fingerprint becomes part of a tree that is initially secured and witnessed in a Chainpoint calendar block (a decentralised database maintained by Chainpoint nodes) before being witnessed in a bitcoin transaction (the most secure decentralised database in the world).

Steps performed to witness your file

The end to end process for witnessing your file and retrieving a downloadable proof takes around ~90 minutes. This is because we wait for 6 bitcoin block confirmations before the proof file is made available.
The steps to witness files is as follows:
1. Generate the files fingerprint
When you select a file it is processed locally in the browser using the SHA256 algorithm to generate its fingerprint. We call it a fingerprint because if the same file is processed using this algorithm in the future, it will always result in the same hash value (fingerprint). If any modifications are made to your file it will result in a completely different hash value.
2. Combine the files fingerprint with entropy from NIST
The National Institute of Standards and Technology (NIST) randomness beacon generates full entropy bit strings and posts them in blocks every minute. The published values include a cryptographic link to all previous values to prevent retroactive changes.
Your files fingerprint is hashed with this random value to prove that the file was witnessed after that random value was generated.
3. Witness the file in the Chainpoint calendar
Chainpoint nodes aggregate your hash with other hashes in the network to create a Merkle tree and generate partial proof.
After ~ 12 seconds we retrieve a proof which includes the NIST value, timestamp information and the other hashes in the tree required to verify your files fingerprint in the anchor hash of a Chainpoint Calendar Block.
4. Witness the file in the bitcoin blockchain
The anchoring hash of the calendar block is then sent in the OP_RETURN of a Bitcoin transaction. As a result, this value is included in the raw transaction body, allowing the transaction ID and the Merkle path from that transaction to the Bitcoin block’s Merkle root to be calculated.
After 6 confirmations (~60 minutes) the final proof file is made available which contains all the Merkle path information required to verify your proof.

Steps to verify a file was witnessed by Bitcoin

The easiest way to verify a file has been witnessed is to visit and upload the proof file or the original file. Bitcoin Witness performs the verification processes and returns the relevant information about when the file was witnessed.
With that said, the benefit of the service is that even if the bitcoin witness app does not exist in the future. People must still be able to verify the files integrity (don’t trust us, trust bitcoin).
There are 2 steps to verify that your file was witnessed. The steps seek to verify that both your original file, and the downloaded proof file, have not been modified since the time of the bitcoin transaction / block. These steps are outlined below and can be performed using open source software.
1. Verify your file has not been modified
Generate a Sha256 hash of your file and check that the hash value generated matches the “hash” value in the proof file you are about to verify.
There are plenty of free online tools available that allow you to generate a hash of your file. And you can check the “hash” value in the proof file by opening it in a text editor.
2. Verify the proof file has not been modified
Re-run the operations set out in the proof file and then validate that the hash value produced at the end of the operations matches the Merkle root value in the bitcoin block.
The Chainpoint Parse library is open source software that can be used to re-run the operations in the proof file. The result can be verified to match the bitcoin Merkle root using any block explorer.

Future Vision and Roadmap

Today marks the release of the first version of the bitcoin witness app which can be found at The immediate focus is on some additional features some users have already suggested
The broader vision and road map for bitcoin witness is to remove the need to trust organisations and each other with our data and instead trust bitcoin. We want to enable a world where people can make claims about data and that bitcoin’s immutable ledger can be used to verify that claim. The current version allows people to claim “This data has not been modified since that point in time”. An example of a future claim might be; “I was in possession of this data at that point in time”

Support us and get involved

This has been a fun learning experience. Would love it if you could all test out the app and give me feedback on the app, the user experience, any roadmap items I should think about. I welcome any comments here or join our telegram
For regular updates you can follow our twitter.
submitted by gaskills to Bitcoin [link] [comments]

CKB Monthly Report 2018 Dec


Changes in RFCs

The RFC (Request for Comments) process is intended to provide an open and community driven path for new protocols, improvements and best practices. One month later after open source, we have 11 RFCs in draft or proposal status. We haven't finalized them yet, discussions and comments are welcome.

Changes in CKB

CKB has released v0.2.0 and v0.3.0 in this month.
Rust 2018. We have upgraded all the major repositories to Rust 1.31.0 and 2018 edition. After the Rust upgrade, we can switch to numext, which is a high-performance big number library relying on some new features in 1.31.0.
CKB is dockerized. It has never been easier to run a CKB node:
docker run -ti nervos/ckb:latest run 
The node started via
ckb run 
no longer produces new blocks. This feature is now in a new process which is launched by
ckb miner 
(#52). The new process gets block template from a node and submits new block with resolved PoW puzzle via node's RPC. The RPC interface for miners is temporary, and we are working on an RFC proposal for this. After this change, we also modularized RPCs (#118). Now each RPC module can be disabled via config file.
Another feature we are actively developing is peers management. This month, we have implemented network group and inbound peer eviction which described in RFC0007. We also delivered a new version of
which allow us to support security strategies defined in RFC0007 in the future.
Annoyed by the problems of existing P2P libraries, we started to work on a brand new P2P protocol from the ground up. It is still in an early stage and is a minimal implementation for a multiplexed p2p network based on
that supports mounting custom protocols. We already implemented 3 core components yamux/secio/service. yamux and secio are mainly refer to their corresponding golang implementations, API are clear and easy to use. Those 3 core components are all use channel based lock-free design with good code readability and maintainability. We are adding up more custom protocols layers, and is going to integrate the discovery protocol soon as described in RFC0012.
We have refactored the rust utility library to mock time for debug and test (#111). It is now available as a separate crate.
There are some other features we are still working on, such as implementation of RFC0006 and RFC0011, and the RFC about serialization format CFB. We are going to release them in next month.

Changes in VM

Changes in SDK

submitted by tonyyuhang to NervosNetwork [link] [comments]

With all of the hullabaloo about a thin Dogecoin wallet, specifically naming Electrum, I went and analyzed both Electrum and the official P2P protocol's own thin-client support. I think I might have found a really big problem with them.

…and the thing that’s really got my jimmies rustled is how obvious the problem appears on the surface, and how I can’t find anyone else talking about it. So if you all don’t mind, I’ll go ahead and describe what I think could be the achilles heel of contemporary crypto currency thin clients. I'll be making some really strong assertions, but if anyone has any information that contradicts them, please share!
EDIT: By request from jdk, an abstract of sorts:
Light cryptocurrency wallets take absence of evidence as evidence of absence. Since they cannot verify that the nodes they are talking to have told them the full truth, it's possible that they will miss some incoming transactions.
I describe three attacks:
1. The simplest one don't tell the client about certain transactions. Because bitcoinj ignores block headers it has already seen, this attack is super effective! against it. Electrum, too, so long as all the nodes it's connected to all agree to not tell it. Once someone does tell it about a past transaction, it verifies it, and then adds it to your wallet. Unfortunately, this can be used to facilitate the third attack.
2. (This only applies to Electrum) A slightly more complicated attack has the attack nodes refuse to acknowledge a single outgoing transaction. Because Electrum always uses the oldest transactions to create new transactions, and because it takes absence of evidence as evidence of absence, you can freeze a user's wallet for as long as they are connected to you, or if they don't inspect older blocks. But, again, inspecting older blocks opens you up to the third attack.
3. A merchant and an attacker can conspire against you to trick you into sending your coins twice. They do this by running the second attack, then back-feeding older transactions so your client will attempt to spend those first. This will work as long as you, the user, try to re-initiate the transaction that supposedly failed.
If you haven’t already read the Bitcoin White Paper, I suggest you go ahead and read it, specifically Section 8 on Simplified Payment Verification. I found it to be fairly straightforward, and it should give you enough background to understand what’s going on. I'm also discussing Electrum and bitcoinj, the latter being a specific example of a client which, by default, relies on Simplified Payment Verification, henceforth known as SPV.
When people speak of "thin" clients, they are referring to clients that do not download all of the transactions in a block along with the block headers. Instead, they only download some of them. Because a block containing transactions links to its transactions by way of a Merkle tree, it is possible to omit a majority of transactions, yet still verify that the ones given were indeed present in the block. It is this property of Merkle trees that allows SPV to be possible.
Electrum came about just when the Bitcoin blockchain became too large for most people to stomach, a lot like what is happening with the Dogecoin blockchain now. The mechanics of SPV had been known in the community for as long as the white paper was released publicly, but the core protocol did not directly support it. Electrum was a series of cute, workable hacks that resulted in an SPV client, but also a client-server architecture and a completely different RPC protocol. At the time, it was necessary in order to receive the filtered transaction notifications necessary to efficiently implement SPV. However, the core Bitcoin Peer-to-Peer protocol now supports the capability of notifying peer nodes of what kinds of transactions of which you wish to be notified. The peers will always respond with blockchain headers, and in the event that any interesting transactions appear to be found, the Merkle branches of those transactions. The client then filters out the false positives (in order to efficiently implement this, the protocol uses a data structure called a Bloom Filter to encode the interesting wallets in a compact manner. It is susceptible to false positives, but that's OK, because you can safely ignore them) and verifies that the transactions sent were actually part of the block by rebuilding the Merkle root and comparing it to that of the block.
This is all well and good from an efficiency standpoint, but any sort of *coin being a type of currency, and thus demanding a high standard of security, I hold some gripes about both Electrum in particular and SPV in general that I feel make them unsuitable for the purposes for which they are currently being used.
The Electrum client begins its connection to the Bitcoin network through a series of hard-coded individual servers. There is a mechanism for describing more peers through IRC; the channels for which are provided by the servers contacted at start-up. I fear that this design empowers both the authors of the client and the owners of the seed servers far too much. In collusion, administrators of the seed servers could elect to not run IRC channels at all, or, alternatively, moderate out any servers from non-colluding parties. This could be used to facilitate something disastrous, particularly what I am about to describe.
In general, SPV provides excellent protection from false positives. Any transaction received with a Merkle branch must continue to hash to the proper child value until the Merkle root is reached. If the Merkle root is linked to a trusted block in the blockchain, its existence in the network is proved. But, it is computationally infeasible to protect from false negatives in a SPV scheme. All the peers need to do is refuse to pass on certain transactions. The client will be none the wiser for it, because the client never knew about them in the first place.
This can obviously be used to facilitate an “output garnishing” attack: simply ignore certain transactions outputting to a certain wallet when responding to the client. The client will not be able to see that there are more unspent outputs to its wallets, because he trusts and relies on his peers to do that instead.
"Output garnishing" can be reworked into a "wallet freezing" attack that completely locks the client out of the network. The attacking node may elect to pass an outgoing transaction to the network, but fail to relay the transaction’s status to the client. The client will believe that the transaction was unsuccessful, and because both Electrum and bitcoinjEDIT: bitcoinj marks outgoing transactions as "pending" and won't double-spend them deterministically attempts to spend the oldest transactions first, any further attempts to create transactions will be seen as a double-spend attempt by the network. As long as the client is only communicating with the attacking nodes, he is incapable of making any further purchases.
In Electrum, the solution may be trivial. Download the client source, modify the seed server list to be more trustworthy. Still, that there is now explicit trust in the network nodes is a far cry from the security of the original protocol design.
In bitcoinj, there is no solution. In fact, an attacker only needs to control one node; bitcoinj simply ignores all further communication about valid blocks it has seen only once before! The comments in the bitcoinj source code seem to suggest this was a performance optimization. However, not doing this would open bitcoinj up to another type of attack, to which Electrum is already vulnerable: a “double-purchasing” attack.
EDIT: The preceding paragraph doesn't completely apply as per the previous edit, but I'm leaving it in for consideration with regards to the first attack. Bitcoinj still ignores older blocks, even if they have new, relevant transactions in them.
Suppose a merchant M is in collusion with an attacker A who runs a series of nodes N0…Nn. Suppose also, that a client C, using a wallet Wc, wishes to purchase from M, using a wallet Wm, both of which are known to M and subsequently A.
A constructs N0…Nn such that certain transactions to Wc are silently ignored (call them Ti); valid in the network but never delivered to C. A waits until there are no more unspent transactions to Wc not in Ti older than some T in Ti. Upon an attempted transaction (Wc -> Wm)0, Nk with 0 <= k <= n sends the transaction to other peers but does not respond to C. Instead, Nk responds with some Ts0…Tsn in Ti such that the sum of outputs in Ts0…Tsn to Wc is greater than or equal to the outputs of (Wc -> Wm)0. C accepts these Ts0…Tsn. An unaware user may elect to begin a new transaction (Wc -> Wm)1 in lieu of a response regarding (Wc -> Wm)0. Because (Wc -> Wm)1 will use as inputs from unspent transaction outputs not used in (Wc -> Wm)0, indeed not yet used at all, the network will accept both transactions as valid! A may elect to continue this process for any (Wc -> Wm)n so long as the sum of all Tin in Ti is sufficient to cover the costs of all Tout in (Wc -> Wm)0…(Wc -> Wm)n. A has effectively coerced C into double-purchasing.
Even if Electrum and bitcoinj randomly chose unspent outputs as inputs for the new transaction, as does the reference Bitcoin client, the probability that such an attack could succeed at least once is directly proportional to the input activity of the target wallet, and the attacker would only need to withhold that particular outgoing transaction to succeed!
I’m looking for some peer review on this. If these scenarios are possible, the proliferation of SPV clients for Bitcoin (and perhaps in the future, Dogecoin) could make an adversary’s life very easy! Again, constructive hole-poking and educative discussion weakening this hypothesis are very, very welcome.
EDIT: And I'm all out of characters! More edits will end up in the comments.
submitted by chia_pet to dogecoin [link] [comments]

Tìm hiểu về công nghệ blockchain

Tìm hiểu về công nghệ blockchain
Mình sẽ bắt đầu bài viết này với một cái tên rất quen thuộc đối với mọi người trong những năm gần đây, đó là bitcoin. Được tạo ra vào năm 2009 bởi một người (nhóm?) có bí danh Satoshi Nakamoto, bitcoin nhanh chóng trở thành một cái tên hết sức nổi tiếng trong giới công nghệ cũng như trong giới tài chính.
Vậy bitcoin và blockchain có mối liên hệ gì với nhau? Bitcoin và blockchain có phải là một? Không. Tuy nhiên, chúng có mối liên hệ rất chặt chẽ. Khi bitcoin được phát hành dưới dạng mã nguồn mở, blockchain đã được gói cùng với bitcoin trong mã nguồn. Và vì bitcoin là ứng dụng đầu tiên của blockchain nên mọi người thường vô tình sử dụng "bitcoin" để có nghĩa là blockchain. Sự hiểu lầm này vẫn tồn tại phổ biến cho đến bây giờ, khi mà công nghệ blockchain đã được ứng dụng trong rất nhiều các ngành công nghiệp và công nghệ khác.
Lời tác giả (1): Bài viết được thực hiện dựa trên kiến thức cá nhân cũng như thông tin được tổng hợp từ nhiều nguồn (tham khảo nguồn ở cuối bài). Bài viết ảnh hưởng đến mình nhiều nhất là từ nguồn hackernoon, sẽ có rất nhiều thông tin và hình ảnh được trích dẫn, lược dịch từ nguồn này. Một số từ tiếng Anh sẽ không được dịch để đảm bảo ý nghĩa (hoặc người viết không biết dịch thế nào ^^). Trong trường hợp nội dung có sai sót rất mong có được góp ý dưới comment. Lời tác giả (2): Blog này mình viết về công nghệ, đôi khi là góc nhìn cá nhân về một vấn đề nào đó. Bài viết này mình cũng sẽ viết tập trung về công nghệ. Nếu bạn đang tìm một bài nói về việc đầu tư bitcoin thế nào cho có lãi, thị trường bitcoin tương lai ra sao, tham gia thị trường này như thế nào ... thì có lẽ bài viết này không phải là thứ bạn đang mong muốn. Tuy nhiên, nếu bạn là một nhà đầu tư chưa có kiến thức gì về bitcoin, và bạn không muốn đầu tư vào một thứ mà bạn không hiểu gì, mình hi vọng những kiến thức mình chia sẻ sau đây sẽ giúp các bạn có tâm lý tốt hơn khi đầu tư vào thị trường này.

Màn dạo đầu về vấn đề tiền tệ và lòng tin

Bitcoin là chủ đề yêu thích của các phương tiện truyền thông trong thời gian gần đây, lượng người biết đến bitcoin cũng như đầu tư vào thị trường này càng ngày càng nhiều. Ngay cả những người chưa bao giờ hiểu về công nghệ, về kỹ thuật mật mã hay về blockchain ... cũng đang bàn tán về nó.
Bitcoin được tạo ra với ý tưởng về một loại tiền tệ vượt qua kiểm soát của chính phủ và đơn giản hóa các giao dịch trực tuyến bằng cách loại bỏ các bên trung gian để xử lý quá trình giao dịch.
Các giao dịch bitcoin được lưu trữ và thực hiện sử dụng một cuốn sổ cái được phân tán trên mạng ngang hàng. Blockchain là công nghệ nền tảng duy trì sổ cái giao dịch của bitcoin.
Chúng ta sẽ bắt đầu với câu chuyện về blockchain bằng một ví dụ về tiền tệ và giao dịch, dĩ nhiên công nghệ blockchain giải quyết được nhiều vấn đề khác, nhưng rõ ràng ví dụ về tiền thì thường dễ hiểu và nhiều cảm hứng hơn.
Giả sử bạn nợ thằng Joe một khoản và nó thì đang hết tiền, dĩ nhiên là nó sẽ đòi tiền bạn, bạn quyết định sẽ thôi lầy lội và chuyển khoản cho nó. Bạn mở iBanking lên, thực hiện lệnh chuyển tiền, ngân hàng kiểm tra số dư tài khoản, thực hiện việc chuyển tiền. Xong.
Về cơ bản, sẽ có đâu đó một bản ghi như thế này:
Trong trường hợp này, cả bạn và Joe đều tin tưởng vào ngân hàng để quản lý tài khoản của mình. Chẳng ngân hàng nào thực sự cầm tiền của bạn và gửi shipper đem cho Joe cả (ít nhất là ở thời đại này). Tất cả những gì cần thiết là một mục nhập trong sổ đăng ký hoặc cơ sở dữ liệu của ngân hàng mà bạn và Joe đều không kiểm soát hoặc sở hữu.
Tiền là vật ngang giá chung có tính thanh khoản cao nhất dùng để trao đổi lấy hàng hóa và dịch vụ nhằm thỏa mãn bản thân và mang tính dễ thu nhận ... Thông qua việc chứng thực các giá trị này dưới dạng của một vật cụ thể (Ví dụ như tiền giấy hay tiền kim loại) hay dưới dạng văn bản (dữ liệu được ghi nhớ của một tài khoản) mà hình thành một phương tiện thanh toán được một cộng đồng công nhận trong một vùng phổ biến nhất định. - wiki
Như vậy đối với ngân hàng, trên khía cạnh quản lý, tiền của bạn thực sự cũng chỉ là những con số đại diện và chúng ta chấp nhận tin tưởng những con số đó cũng như tin tưởng vào ngân hàng. Nói một cách tổng quát hơn, để thiết lập giao dịch, chúng ta phụ thuộc vào cá nhân thứ ba. Và đó cũng là vấn đề của các hệ thống hiện tại.
Điều gì sẽ xảy ra trong trường hợp "người thứ 3" không đáng tin cậy và cuỗm số tiền thật của chúng ta đi? Nếu cuốn sổ cái chứa thông tin tài khoản của bạn bị mất, bị hư hỏng? Nếu thằng cha nào đó ở ngân hàng vô tình hay hữu ý ghi nhầm 1000$ của bạn thành 100$? Dĩ nhiên, đó là ví dụ, trên thực tế bạn có nhiều cách để chứng thực số tiền với ngân hàng, ở đây, chúng ta nhấn mạnh việc rủi ro khi thực hiện giao dịch thông qua sự tin tưởng ở "người thứ 3".
Như vậy, thứ chúng ta cần là một hệ thống mà chúng ta có thể chuyển tiền không cần ngân hàng. Chúng ta có thể xây dựng được một hệ thống như thế không? Dĩ nhiên là có rồi. Các bạn biết rõ là bài viết đang muốn nói đến blockchain. Tuy nhiên hãy để cho mọi thứ thi vị hơn chút bằng cách đi chầm chậm từ bản chất vấn đề. ^^
Thay vì trao đổi tiền thật, chúng ta cũng cần một hệ thống quản lý những con số, những bản ghi, giống như của ngân hàng.
Bằng công nghệ blockchain, chúng ta có thể tự quản lý cuốn sổ cái chứa tài khoản và giao dịch của mình và mọi người.

Thực hiện giao dịch như thế nào?

Điều mấu chốt ở đây là, muốn thực hiện giao dịch, chúng ta phải giao dịch với những người cùng không tin tưởng vào hệ thống ngân hàng và tạm cho rằng hội, nhóm này có khả năng tự quản lý cuốn sổ cái chung.
Cần bao nhiêu người cho một nhóm như trên? Tối thiểu là 3, dĩ nhiên. Nếu 2 người tin tưởng nhau rồi thì chẳng có chuyện gì để bàn cả.
Giả sử chúng ta có 10 người nhé. Trên cơ sở 1 thỏa thuận chung giữa 10 người, họ có chi tiết về tài khoản của nhau nhưng lại không biết danh tính của người giữ tài khoản đó. Nghe hơi khó hiểu chút nhưng bạn có thể tưởng tượng đơn giản là bạn đang cầm sổ tài khoản của ai đó có mã số NOTE7749 mà không biết đích xác cuốn sổ này là của ai trong 9 người còn lại.

1. Hộp đựng tài liệu rỗng

Mỗi người đều sẽ có một hộp đừng tài liệu rỗng để bắt đầu. Hộp này để khi các giao dịch được thực hiện, mười cá nhân này có thể lưu trữ các trang giấy đã ghi lại giao dịch vào các hộp đựng. Tập hợp các trang này sẽ tạo thành một cuốn sổ cái riêng để theo dõi các giao dịch.

2. Khi thực hiện giao dịch

Tiếp theo, tất cả mọi người ngồi với một trang giấy trắng và một cây bút, sẵn sàng để viết bất kỳ giao dịch xảy ra.
Bây giờ, nếu người số 2 muốn gửi $10 đến số 9. Để thực hiện giao dịch, người số 2 nói với tất cả mọi người: "Tôi muốn chuyển $10 đến số 9. Tất cả mọi người, xin vui lòng ghi vào giấy."
Vậy là tất cả mọi người kiểm tra tài khoản của người có số thứ tự 2, nếu tài khoản đó có đủ tiền, mọi người đồng loạt ghi vào tờ giấy của họ như sau:
Giao dịch hoàn thành.

3. Giao dịch tiếp theo

Khi thời gian trôi qua, số giao dịch được tăng lên. Bất cứ khi nào họ muốn thực hiện một giao dịch, họ thông báo nó cho tất cả mọi người khác và mỗi người sau đó lại cập nhật lại bản ghi của mình.
Giao dịch được thực hiện cho đến khi 'hết giấy'. Giả sử một trang chỉ có chỗ ghi mười giao dịch thì ngay khi giao dịch thứ mười được thực hiện, mọi người đều đang ở dòng cuối cùng.
Để tiếp tục thực hiện giao dịch, tất cả mọi người phải cất hết những tờ giấy cũ vào hộp và chuẩn bị giấy mới.

4. Niêm phong bản ghi cũ

Trước khi đưa những tờ giấy - bản ghi cũ vào hộp, chúng ta cần phải khóa nó với một chìa khóa duy nhất mà tất cả mọi người trong mạng đều đồng ý rằng chìa khóa đó là an toàn. Bằng cách niêm phong nó, chúng ta sẽ đảm bảo rằng không ai có thể thay đổi nội dung của các bản ghi. Một khi trong hộp, nó sẽ luôn luôn ở trong hộp và được niêm phong. Nếu mọi người tin tưởng vào chìa khóa đồng nghĩa với việc mọi người tin tưởng vào nội dung của của các bản ghi được cất trong hộp. Chìa khóa - con dấu ở đây chính là mấu chốt của vấn đề.
Việc niêm phong bản ghi ở trên còn được gọi là 'đào', tuy nhiên ở bài viết này, chúng ta sẽ vẫn gọi là hành động 'niêm phong' hay 'khóa'.
Như vậy, thay vì tin tưởng vào người trung gian để thực hiện giao dịch, bây giờ chúng ta sẽ tin tưởng vào chìa khóa - hay con dấu khi thực hiện giao dịch.

Vấn đề niêm phong các bản ghi

Trước khi chúng ta tìm hiểu làm thế nào chúng ta có thể niêm phong các bản ghi, chúng ta sẽ tìm hiểu cách thức hoạt động của con dấu nói chung.

Chiếc hộp kỳ diệu

Hãy tưởng tượng một chiếc hộp vô cùng bí ẩn. Nếu bạn gửi vào bên trái hộp một vật, nó sẽ đẩy ra bên phải một vật khác.
Bạn có thể biết về 'Hash Function' hay 'hàm băm' hay 'hàm mã hóa' hoặc đại loại thế, tuy nhiên chúng ta sẽ vẫn dùng 'chiếc hộp kỳ diệu' cho dễ hiểu.
Giả sử, chúng ta gửi vào hộp 1 cái xúc xích, con lợn sẽ chạy ra ở bên phải hộp. Làm thế nào để cái xúc xích thành con lợn, chẳng ai biết cả.
Lời người viết (3): Ở bài gốc trên hackernoon dùng các chữ số đầu vào và chữ cái đầu ra, mình không thích thế lắm nên dùng các đồ vật và con vật cho dễ hiểu, sau khi đã có cái nhìn cơ bản, mình sẽ chuyển về với chữ và số giống như trên hackernoon.
Thêm nữa, việc đoán cái gì được đưa vào trong hộp phải là không thể, chúng ta khi thấy con voi chạy ra thì không thể đoán cái gì đã được nhét vào hộp, nhưng cứ khi nào nhét cái xúc xích vào, sẽ vẫn là con lợn chạy ra.
Thử nhét vào cái bút.
Chúng ta có con gà chạy ra.
Bây giờ, chúng ta có một câu hỏi như sau:
Liệu có thể đoán được phải nhét cái gì vào bên trái để có 1 con vật 4 chân chạy ra từ bên phải hộp.
Vấn đề là, chúng ta không thể đoán được khi nhét cái gì vào thì con gì sẽ chạy ra. Cách duy nhất để tìm trả lời được đó là thử tất cả mọi thứ trên đời cho đến khi có một con vật 4 chân chạy ra: chả giò, nem chua, đồng hồ, bút, thước, ba con sói ...
Cứ giả sử, nếu may mắn, sau khi nhét hàng núi đồ vào, con chuột chạy ra và 1 đáp án của chúng ta là cái usb.
Rất khó để tính toán đầu vào cho đầu ra, chúng ta tạm coi việc đó là không thể. Tuy nhiên, rất dễ dàng để xác minh nếu đầu vào cho đầu ra đúng yêu cầu. Bạn nghĩ câu trả lời là gì nếu ta ném cái usb vào? Một con vật 4 chân có chạy ra không? Xác minh rất dễ, chỉ cần ném thử cái usb vào và đếm số chân của con chuột chạy ra.
Thuộc tính quan trọng của chiếc hộp kỳ diệu:
"Cho một đầu ra, rất khó để đoán đầu vào, nhưng rất dễ để xác minh đầu vào có cho ra chính xác thứ ta mong đợi ở đầu ra không"

Sử dụng chiếc hộp kỳ diệu

Bây giờ quay lại vấn đề các bản ghi, các bản ghi thì là chữ và số vì vậy ta tạm rời xa các con vật vậy, hộp kỳ diệu bây giờ sẽ làm việc với những con số.
Hãy tưởng tượng chúng ta có hai hộp chứa bản ghi. Hộp đầu tiên chứa số 20893. Yêu cầu bây giờ là: "Tìm một con số khi kết hợp số trong hộp đầu tiên và cho vào chiếc hộp kỳ diệu sẽ cho chúng ta một dãy bắt đầu bằng ba chữ số 0?"
Bạn còn nhớ cách chúng ta tìm ra chiếc usb? Phải vậy, chúng ta sẽ thử lần lượt từng số cho đến khi tìm được đầu ra đúng yêu cầu. Sau vài nghìn lần thử, có thể hàng vạn hoặc hơn, chúng ta gặp một số, giả sử 21191 đi, mà khi thêm vào 20893 (21191 + 20893 = 42084) và cho vào hộp kỹ diệu thì đầu ra sẽ cho chúng ta một dãy thỏa mãn.
Trong trường hợp này, con số 21191 trở thành con dấu cho số 20893. Giả sử có một trang có số 20893 viết trên đó. Để đóng dấu trang đó (nghĩa là không ai có thể thay đổi nội dung của nó), chúng ta sẽ đặt một khóa có số niêm phong '21191' và khóa nó lại. Việc niêm phong được hoàn thành.
Số niêm phong được gọi là 'Proof Of Work', con số này là bằng chứng cho thấy các nỗ lực đã được tính toán.
Nếu ai đó muốn xác minh xem bản ghi đã bị thay đổi hay không, tất cả những gì người đó phải làm là thêm nội dung của bản ghi với số niêm phong và nhét vào hộp kỳ diệu. Nếu chiếc hộp đưa ra một dãy với bắt đầu với ba chữ số 0 thì tức là nội dung không bị ảnh hưởng. Nếu dãy xuất hiện không đáp ứng được yêu cầu, chúng ta có thể hủy bỏ bản ghi vì nội dung của nó đã bị xâm nhập và không còn hiệu lực.
Chúng ta sẽ sử dụng cơ chế niêm phong tương tự để đóng dấu tất cả các bản ghi và sắp xếp chúng trong các hộp chứa tương ứng.
Ghi chú: Thực ra việc sử dụng "một dãy với bắt đầu với ba chữ số 0" hoàn toàn là để đơn giản hóa vấn đề, trên thực tế mọi thứ phực tạp hơn nhiều lần.
Bây giờ, giả sử ai đó muốn thay đổi nội dung của trang, số niêm phong sẽ cho phép chúng ta biết liệu trang đó có bị thay đổi hay chưa.
Chúng ta sẽ quay lại thời điểm mọi người bắt đầu cất bản ghi vào hộp lưu trữ, khi mà tờ giấy đã ghi đủ 10 giao dịch.
Khi mọi người đều hết giấy, họ sẽ bắt đầu việc đóng dấu bằng cách tính toán con số niêm phong, người đầu tiên tìm được con số này sẽ thông báo cho tất cả mọi người.
Ngay lập tức khi nghe thấy ai đó đọc số niêm phong, mọi người sẽ dừng việc tính toán lại và kiểm tra số niêm phong nghe được, nếu số này hợp lệ, tất cả mọi người sẽ niêm phong tài liệu lại bằng số này.
Vậy điều gì sảy ra nếu ai đó nói ra con số đầu tiên nhưng con số này không hợp lệ? Trường hợp như vậy xảy ra rất thường xuyên với những lý do có thể là:
  • Người đó nghe sai một giao dịch
  • Người đó ghi sai một giao dịch
  • Người đó cố ý làm sai lệch giao dịch
Dù lý do gì đi nữa, để tiếp tục thì người đó chỉ có một cách duy nhất đó là copy lại giấy của người khác. Nếu anh ta không đưa trang của anh vào hộp đựng tài liệu, anh ta không thể tiếp tục viết thêm các giao dịch nữa.
Bất kể con số niêm phong là gì, khi được đa số đồng ý, sẽ trở thành con số niêm phong hợp lệ.
Vậy tại sao tất cả mọi người lại bỏ công sức để tính toán khi họ biết ai đó sẽ tính toán và thông báo cho họ? Tại sao không ngồi im và đợi kết quả của người khác?
Câu trả lời đó là tiền thưởng. Tất cả mọi người là thành viên của nhóm đều đủ điều kiện nhận phần thưởng. Người đầu tiên tính số niêm phong được khen thưởng bằng tiền cho những nỗ lực của anh ta.
Đó là cách bitcoin ra đời và hoạt động như là đơn vị tiền tệ đầu tiên được giao dịch trên blockchain.
Để giữ cho mọi người làm việc, mọi người sẽ được trao thưởng bitcoin.
Coi một trang giấy để ghi giao dịch làm một khối (Block), hộp đựng tài liệu như một danh sách các bản ghi (Chain), chúng ta sẽ có một "BlockChain"
Chưa hết, chúng ta có một vấn đề cần phải giải quyết.
Bây giờ giả sử một ai đó muốn gian lận và quay lại thay đổi thông tin một giao dịch nào đó đã được cất trong hộp, dĩ nhiên con số niêm phong sẽ tố cáo việc bản ghi đã bị thay đổi, nhưng nếu anh ta tính toán lại cả con số niêm phong?
Để tránh việc con số niêm phong bị tính toán lại, thay vì chỉ đưa vào hộp kỳ diệu 2 thông số là mã giao dịch và con số niêm phong hợp lệ, bây giờ ta sẽ yêu cầu phải thêm một thông số nữa vào hộp kỳ diệu, đó là dãy đầu ra được tính toán của giao dịch trước đó.
Với thủ thuật này, chúng ta đảm bảo rằng mọi trang đều bị phụ thuộc vào trang trước của nó. Do đó, nếu ai đó muốn sửa đổi một trang thì cũng phải thay đổi nội dung và con số niêm phong của tất cả các trang sau đó để giữ cho toàn bộ chuỗi là hợp lệ.
Nếu một trong mười người cố lừa dối và sửa đổi nội dung của blockchain (thư mục chứa các trang có danh sách giao dịch), anh ta sẽ phải điều chỉnh rất nhiều trang và tương ứng với việc phải tính toán số niêm phong mới số cho tất cả các trang sau đó, anh ta có thể tạo ra một chuỗi giao dịch khác với mọi người. Tuy nhiên độ khó của việc tìm kiếm số niêm phong khiến cho chuỗi của anh ta sẽ không bao giờ đuổi kịp chuỗi của 9 người còn lại.
Như vậy, chúng ta có thể kết luận:
Chuỗi dài nhất là chuỗi hợp lệ
Vậy, điều gì xảy ra nếu thay vì một người có ý định xấu, có tới 6 người có ý định xấu?
Đây là một điểm yếu và là một lỗ hổng về mặt cấu trúc của bitcoin và blockchain. Khi mà phần lớn các cá nhân trong mạng quyết định không trung thực và ăn gian phần giao dịch còn lại của mạng, toàn bộ giao thức sẽ đổ vỡ.
Về cơ bản, mô hình bitcoin được xây dựng trên giả định rằng đa số đám đông luôn luôn là trung thực. Trong trường hợp một cuộc tấn công như thế diễn ra thành công, chắc chắn sự tin tưởng vào đồng tiền sẽ bị mất và giá trị của một đồng tiền sẽ giảm nhanh chóng.

51% attack - tấn công 51%

Làm thế nào để những người có ý định xấu có toàn quyền kiểm soát mạng?
Không hẳn toàn bộ. 51% mạng là đủ.
Như một hệ quả của mô hình tin tưởng đám đông đã trình bày ở các phần trước đó. Khi một nhóm người nắm được 51% mạng lưới, họ có thể ngăn các giao dịch mà họ chọn không xác nhận, làm cho chúng không hợp lệ, ngăn cản mọi người gửi bitcoin giữa các địa chỉ. Họ cũng có thể đảo ngược các giao dịch mà họ gửi trong thời gian họ kiểm soát được và họ có thể ngăn không cho các thợ mỏ khác tìm thấy bất kỳ khối bitcoin nào trong một khoảng thời gian.
Tuy nhiên họ vẫn không thể đảo ngược được những giao dịch từ đầu hay tạo ra những đồng tiền mới hoặc ăn cắp tiền từ ví của người khác. Dẫu vậy, việc này có thể gây ra một sự hoảng loạn trên thị trường và sẽ trực tiếp đe doạ việc sử dụng bitcoin như là một loại tiền tệ trực tuyến.
Một cuộc tấn công 51% là hoàn toàn khả thi, đặc biệt là với sự gia tăng của các mỏ khai thác bitcoin lớn. Ở mức độ khai thác và độ khó hiện tại, một chính phủ có thể dễ dàng tiến hành một cuộc tấn công 51%.
Trên thực tế thì những trường hợp tương tự đã từng xảy ra. đã nắm hơn 50% sức mạnh tính toán của mạng bitcoin vào tháng 7 năm 2014, sau đó họ có cam kết trong một tuyên bố rằng họ sẽ giảm năng suất xuống và sẽ không đạt 40% năng suất của toàn bộ hệ thống trong tương lai.
Krypton và Shift Krypton và Shift, hai blockchain dựa trên nền tảng ethereum, bị tấn công 51% vào tháng 8 năm 2016.

Genesis block

Tất cả các khối trong mạng lưới đều liên kết tới một khối được giao dịch trước đó. Vậy, khối đầu tiên thì liên kết với cái gì và nó được tạo ra như thế nào?
Thực tế thì các khối đầu tiên này thường được tạo bằng tay (hard-code). Trong trường hợp của bitcoin, khối này được gọi là Genesis Block. Genesis Block hầu như luôn luôn được mã hóa cứng trong các phần mềm. Đây là một khối đặc biệt vì nó không liên kết đến một khối trước nó.
Khối Genesis chứa một thông điệp ẩn trong giao dịch coinbase - nó nói rằng ""The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Đây rõ ràng là một thông điệp từ Satoshi Nakomoto với dụng ý chỉ ra những vấn đề với chính sách cứu trợ của chính phủ hiện nay đối với ngân hàng quá lớn cũng như vấn đề nguy hiểm về đạo đức.
Về cơ bản nó sẽ giống như sau:
00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 3B A3 ED FD 7A 7B 12 B2 7A C7 2C 3E ....;£íýz{.²zÇ,> 00000030 67 76 8F 61 7F C8 1B C3 88 8A 51 32 3A 9F B8 AA gv.a.È.ÈŠQ2:Ÿ¸ª 00000040 4B 1E 5E 4A 29 AB 5F 49 FF FF 00 1D 1D AC 2B 7C K.^J)«_Iÿÿ...¬+| 00000050 01 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070 00 00 00 00 00 00 FF FF FF FF 4D 04 FF FF 00 1D ......ÿÿÿÿM.ÿÿ.. 00000080 01 04 45 54 68 65 20 54 69 6D 65 73 20 30 33 2F ..EThe Times 03/ 00000090 4A 61 6E 2F 32 30 30 39 20 43 68 61 6E 63 65 6C Jan/2009 Chancel 000000A0 6C 6F 72 20 6F 6E 20 62 72 69 6E 6B 20 6F 66 20 lor on brink of 000000B0 73 65 63 6F 6E 64 20 62 61 69 6C 6F 75 74 20 66 second bailout f 000000C0 6F 72 20 62 61 6E 6B 73 FF FF FF FF 01 00 F2 05 or banksÿÿÿÿ..ò. 000000D0 2A 01 00 00 00 43 41 04 67 8A FD B0 FE 55 48 27 *....CA.gŠý°þUH' 000000E0 19 67 F1 A6 71 30 B7 10 5C D6 A8 28 E0 39 09 A6 .gñ¦q0·.\Ö¨(à9.¦ 000000F0 79 62 E0 EA 1F 61 DE B6 49 F6 BC 3F 4C EF 38 C4 ybàê.aÞ¶Iö¼?Lï8Ä 00000100 F3 55 04 E5 1E C1 12 DE 5C 38 4D F7 BA 0B 8D 57 óU.å.Á.Þ\8M÷º..W 00000110 8A 4C 70 2B 6B F1 1D 5F AC 00 00 00 00 ŠLp+kñ._¬.... 
Còn trong phiên bản ban đầu của bitcoin, nó được miêu tả như sau:
GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854 txNew.vout[0].nValue = 5000000000 txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG block.nVersion = 1 block.nTime = 1231006505 block.nBits = 0x1d00ffff block.nNonce = 2083236893 CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1) CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0) CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73) CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B) vMerkleTree: 4a5e1e 

Tài Liệu Tham khảo:

Header cover: Forexnewsnow
tags: blockchain, bitcoin
submitted by shibob89 to u/shibob89 [link] [comments]

Consent, Consensus, Karma, and Blockchains

First, a disclaimer: this is a shower thought, not a grant proposal or a dissertation. Some of the details may be half-baked (or, more precisely, very little is backed up with a bibliography containing only peer-reveiwed sources), but I want to explore this topic with others and not just roll it around in my own head.
As frequent C_S_T readers may know, I've been writing in this sub about reality-as-information and some of its implications. Here is one fully worked out model of reality-as-information. I have not yet invested the time to understand every last detail, but I present it as evidence that somebody (Christopher Langan in this case) has worked out a seemingly coherent model. Another, less fully worked out model has been suggested by Stephan Wolfram. There may be other, better models, or else smaller-scope models that have been linked more closely with established physical theories, but these are the ones I have encountered most recently. So a fundamental basis of this post is that our reality is simply a system of information being processed somehow (by itself, by a metaphysical computer, by God, who knows). As such, many computational metaphors apply and some may offer insight.
Today I had it on my list of things to contemplate two separate, seemingly unrelated concepts, each for separate reasons. The first was simply the blockchain, i.e. the mundane computing technology that makes bitcoin, ethereum, and other innovations possible. The second idea was that of consent as it applies to metaphysical dynamics. The latter emerged from various conversations I've had recently with folks around here, concerning the idea that predatory interests must gain your consent before being enabled to attack you. The reason given is that it is some kind of karmic law. However, I believe in neither a ledger-based system of quantitative karma (i.e. God or some more impersonal entity keeps a cosmic ledger of "good" and "bad" deeds) nor do I believe in any kind of central authority that enforces a karmic law. Though they are common enough in new-age circles, these are Western bastardizations of a more elegant concept that can essentially be characterized as metaphysical cause-and-effect. The flavor of karma, in this sense, is that it is enforced in a distributed manner, much the same way that the laws of physics, as we understand them, are enforced locally and (seemingly) not by a central authority. Maybe now you can see where I'm going with this...
On blockchains. From wikipedia:
A blockchain – originally block chain – is a distributed database that is used to maintain a continuously growing list of records, called blocks. Each block contains a timestamp and a link to a previous block. A blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. By design, blockchains are inherently resistant to modification of the data. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks and the collusion of the network.
(Note to academic purists: I realize Wikipedia is not an authoritative source, I link for convenience, ease-of-understanding for a lay person, and also personal laziness. I invite you to follow the bibliographies provided in the Wikipedia articles, these are usually pretty decent.)
You will note, if you read the Wikipedia article, that the foundational technology that makes blockchains possible is the hash tree:
In cryptography and computer science, a hash tree or Merkle tree is a tree in which every non-leaf node is labelled with the hash of the labels or values (in case of leaves) of its child nodes. Hash trees allow efficient and secure verification of the contents of large data structures.
You may also note that, topologically, trees are special cases of directed acyclic graphs, or DAGs. Finally, you may also note that DAGs are used to model causation (for more details see Judea Pearl's magnum opus). Wolfram's information-processing model seems to be consistent with a DAG formulation of causality.
While there is currently no mundane-world application, to my knowledge, for the idea of a hash-DAG, it doesn't take much imagination to see how such a data structure could generalize the concept of a hash-tree. Thus I propose that a metaphor for how causal reality is "processed" and resolved among different observers is something like a hash-DAG. In this metaphor, each "event" is a transaction, and the integrity of all transactions is maintained by a natural, distributed system which maintains the blockchain representing a particular timeline. I am acknowledging here the possibility of multiple timelines, but each such timeline must have its own blockchain. The cryptographic data-integrity check is important because there may be temporary "offshoots" that are inconsistent with a main chain and require resolution. For random examples, see Donnie Darko, this near-death-experience, or any good post in Glitch_in_the_Matrix. An excerpt from the NDERF story:
I knew that unless I soon selected one of these realities to slide back into, that the wheel would coerce the situation by deciding for me. One way or another, I WOULD be 'sorted' whether I liked it or not. If I didn’t choose for myself, I would simply be fitted into place at some nearest position on the wheel to the point where I failed to make the decision
However, the blockchain data structure does not confer a 100% guarantee against corrupton of a particular blockchain, only a guarantee that the probability of corruption is low. Also, a blockchain can be hard-forked by agreement, i.e. consensus (note the common root of consensus and consent). Also, what seems implicitly clear is that with enough collusion among a large enough consortium of parties, the probability of corruption (of course biased towards particular, favored transactions) can be increased.
An immediate application of the metaphor is this: a predatory interest must gain your consent on some level (usually unconscious) so that your transaction block harmonizes with theirs and is allowed to be recorded on blockchain of the central timeline. This obviously resolves the issue of consent being part of karmic law: karmic law is simply the rules for processing blockchains, and these rules require mutual consent for a valid transaction to be recorded.
But, there is a more insidious application: that of forks. One issue that comes up from time-to-time here in this sub or in the pit, is the issue of elite disclosure. I have heard it said that elites are required to "disclose" their intentions as part of karmic law. See this article for a reasonably balanced discussion of this idea. On its face, the idea makes no sense. However, if you apply the concepts above, it begins to appear more plausible. The disclosures are really attempts to secure unconscious consent. It occurs to me now that if a certain consortium of interests wishes to execute or even forge a particular set of transactions, possibly even forking the blockchain (timeline) in a direction to its advantage, it might attempt to secure the consent of a broader coalition of other interests, including those that stand to "lose" in the proposed set of transactions, to dramatically increase its odds of success. So this idea potentially also explains the karmic necessity of Revelation-of-the-Method.
If it seems like I'm just adding a lot of unnecessary structure to already servicable concepts like Jung's collective unconscious, you may be correct. But what I think I am doing is trying to understand the "laws of karma" using detailed metaphors that link back to mundane concepts for which we already have a great deal of knowledge, and see what these metaphors may tell us about the more abstract/metaphysical concept. Here, I may have explained why (at least to myself) consent is required in an attack, and why elites seem to broadcast their intentions, but always in as oblique a manner as possible. A practical application may be in a prospective reading of mainstream culture in order to infer sinister intentions (I realize many people are already doing this, Christopher Knowles comes to mind), but, more importantly, to assist in the discovery of methodologies that may thwart these intentions.
After all, this is all psychic warfare, at one level or another.
submitted by OsoFeo to C_S_T [link] [comments]

Electrum security/privacy model?

The Electrum homepage states that Electrum is:
Low trust: Information received from the servers is verified using SPV. Servers are authenticated using SSL [my emphasis]
However, I'm having a hard time finding documentation on how Electrum servers work and more specifically how they implement Simplified Payment Verification (SPV) as defined in Satoshi's white paper.
The Bitcoin Wiki states:
ThomasV claims that "Electrum, it is doing SPV since 2012".
I found a conversation between Greg Maxwell and Mike Hearn from late 2012. One of the messages included this passage:
I'm concerned about how the particular security model of electrum is being described; or rather— not being described. The electrum website appears to have no security discussion beyond platitudes like "Secure: Your private keys are not shared with the server. You do not have to trust the server with your money.", "No scripts: Electrum does not download any script at runtime. A compromised server cannot compromise your client."
Later Mike writes that he was able to contact ThomasV with his concerns, and that progress was made in addressing them.
A late 2013 question posted to Bitcoin StackExchange raises similar questions:
The answers seemed confusing at best.
I'm pretty clear on how SPV is supposed to work, but so far the documentation I've found suggests that Electrum does not fit the description.
Electrum clients apparently connect to a single trusted server. It's unclear to what extent that server logs traffic, how/if Bloom filters are used to increase privacy, or even how the client proves that transactions coming from the server are in fact in the the block chain.
Can anyone point me to some technical documentation on the Electrum security/privacy model?
I've seen this source repository (not sure it's the right one):
It's sparsely documented, there's no test suite to speak of, and there seems to be far too little code for a full SPV implementation.
Edit: after reading responses so far and digging around some more, it appears that Electrum is doing SPV as indicated in the Wiki. There seem to be two main differences between Electrum and BitcoinJ (another SPV implementation used in MultiBit and other wallets):
  1. Electrum clients connect to a single trusted server chosen by default at random from a list posted to irc. BitcoinJ nodes connect to multiple peers and compare responses to detect withholding attacks.
  2. BitcoinJ nodes use Bloom filters and Electrum does not. This feature is intended to obfuscate the exact transactions being requested by a node so as to avoid leaking the wallet's private public keys/addresses to peers.
Under both systems, the client obtains block headers, using Merkle roots/chains to match received transactions to the containing blocks.
submitted by BobAlison to Bitcoin [link] [comments]

A block hashing question.

In the bitcoin wiki on the block hashing algorithm, it states the following:
The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.
This statement makes sense only if you already have the merkle root, and maybe that is the intention of the statement. But, if you're a miner and trying to generate a block, when you add a transaction to the block you're working on, you still have to determine your merkle root, right? Assuming your block had 5 transactions and you've added a 6th you're going to have to do log(6) hashes to get your merkle root. Alternatively, assuming your block had 50,000 transactions and you've added one, you're looking at log(50,001) hashes to get your merkle root.
Granted, this probably isn't computationally significant, computing 3 hashes vs 15 to get the new merkle root, but it's not nothing. Am I understanding this correctly, or am I misunderstanding something about who / when the merkle root is calculated?
submitted by ddoomus to Bitcoin [link] [comments]

Extension block proposal by Jeffrey et al | Luke Dashjr | Apr 04 2017

Luke Dashjr on Apr 04 2017:
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but in light
of public interest, I think it is appropriate to open it to discussion, and
toward this end, I have reviewed the current revision.
For reference, the WIP proposal itself is here: 
==Overall analysis & comparison==
This is a relatively complicated proposal, creating a lot of additional
technical debt and complexity in comparison to both BIP 141 and hardforks. It
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to
consider at face value. In fact, it fits much better the inaccurate criticisms
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is for
the most part technically sound. While ill-fit to merely making blocks larger,
it may be an ideal fit for fundamentally different block designs such as
Rootstock and MimbleWimble in absence of decentralised non-integrated
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin
==Fundamental problem==
Extension blocks are a risk of creating two classes of "full nodes": those
which verify the full block (and are therefore truly full nodes), and those
which only verify the "base" block. However, because the extension is
consensus-critical, the latter are in fact not full nodes at all, and are left
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is
of course true of a softfork as well, but softforks are intentionally designed
such that all nodes are capable of trivially upgrading, and there is no
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, but
without the false expectation and pointless complexity.
==Other problems & questions==
These outpoints may not be spent inside the mempool (they must be redeemed
from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is
required for CPFP).
The extension block's transaction count is not cryptographically committed-to
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to
exploit in practice; however, exploiting it in an extension block may not be
as impractical, and it should be fixed given the opportunity.)
The merkle root is to be calculated as a merkle tree with all extension
block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txids
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and
wtxid trees built independently and merged at the tip?
Output script code aside from witness programs, p2pkh or p2sh is considered
invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other
various possible destinations. (While static address forms do not exist for
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create
unprovably-unspendable UTXOs. Is that intentional?
The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue as
BIP141, but even more extreme since it is planned to be used for future size
Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not just
say "8 points"?
Witness script hash v0 shall be worth the number of accurately counted
sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static counting,
or accurately counting sigops during execution?
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0
==Trivial & process==
BIPs must be in MediaWiki format, not Markdown. They should be submitted for
discussion to the bitcoin-dev mailing list, not social media and news.
Layer: Consensus (soft-fork)
Extension blocks are more of a hard-fork IMO.
License: Public Domain
BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Can you agree on one or more of these?


This specification defines a method of increasing bitcoin transaction
throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.


Bitcoin retargetting ensures that the time in between mined blocks will be
roughly 10 minutes. It is not possible to change this rule. There has been
great debate regarding other ways of increasing transaction throughput, with
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.
Extension blocks leverage several features of BIP141, BIP143, and BIP144 for
transaction opt-in, serialization, verification, and network services, and as
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally
incompatible with this one, so saying BIP 141 is activated is confusingly
This specification should be considered an extension and modification to
these BIPs. Extension blocks are not compatible with BIP141 in its current
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn’t appear to be
any justification for not making them compatible.
This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposal,
albeit in a mostly compatible manner.
Note that canonical blocks containing entering outputs MUST contain an
extension block commitment (all zeroes if nothing is present in the extension
Please explain why in Rationale.
Coinbase outputs MUST NOT contain witness programs, as they cannot be
sweeped by the resolution transaction due to previously existing consensus
Seems like an annoying technical debt. I wonder if it can be avoided.
The genesis resolution transaction MAY also include a 1-100 byte pushdata in
the first input script, allowing the miner of the genesis resolution to add a
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt with
no apparent purpose. Better to just have a consensus rule every input must be
The resolution transaction's version MUST be set to the uint32 max (`232 -
Transaction versions are signed, so I assume this is actually simply -1.
(While signed transaction versions seemed silly to me, using it for special
cases like this actually makes sense.)

Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not
the extblock's txid.
On the policy layer, transaction fees may be calculated by transaction cost
as well as additional size/legacy-sigops added to the canonical block due to
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of
doubt:" to be clear that miners may perform any fee logic they like.
Transactions within the extended transaction vector MAY include a witness
vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't this
be mandatory?
consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the
economy has updated to support segwit-native addresses.
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Please explain why 73 bytes in Rationale.
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
A consensus dust threshold is now enforced within the extension block.
If the second highest transaction version bit (30th bit) is set to to 1
within an extension block transaction, an extra 700-bytes is reserved on the
transaction space used up in the block.
Why wouldn't users set this on all transactions?
default_witness_commitment has been renamed to
default_extension_commitment and includes the extension block commitment
default_witness_commitment was never part of the GBT spec. At least describe
what this new key is.
Should be just extblk if backward compatibility is supported (and !extblk
when not).
The "deactivation" deployment'...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Using the Merkle Tree and root to prove transactions are in a block

Okay so I've read alot about this over the past days, including parts of the white paper, youtube videos and Wiki pages as well as different forums.
However, none of them seem to touch on how merkle trees are used for verifying transactions in practice.
Take this tree for example:
 ABCDEEEE .......Merkle root / \ ABCD EEEE / \ / AB CD EE .......E is paired with itself /\ /\ / A B C D E .........Transactions 
According to the Bitcoin developer guide, in order to verify a specific transaction D, we only need the AB, C and EEEE part. So these parts and our transaction D can be used to create the merkle root. Is that how it works?
How do I verify a given transaction in a block of say 1024 transactions? I've read somewhere that verifying is O(log(n)) for hash trees, does that mean that verifying any given transaction in a merkle tree of size 1024 is given by log(1024) =~ 3.01. I.e. 3 hashes?
Would really like some help and clarification on this! Regards.
submitted by IamAPrinter to Bitcoin [link] [comments]

I want to know what you think.

from here
I want to know what you think of my idea, and how I can improve it.
I'm working on something I'm calling the yip! meta-protocol (yes with the exclamation point) I'm not ready to release the details until I'm sure it works! but this is what I think I'll do:

How to tell if something is a yip!

There will be a header of 20 bytes in an output tx script. the first four bytes of the custom hash will be "yip!" in ASCII/UTF8, and then two bytes for the major version (v1.8) and minor version (v1.8). Then there will be some flags for encryption, compression (so you can pay less for the same message), etc.


As I've said before, this'll cost most likely 1.00000001 doge per 20 characters plus 1.00000001 doge for the header, which turns out, given average text lengths, to be waaaaayyyyyyyyy cheaper than any text plan I've heard of. This, while not free, will make communications so much easier for poorer people who can't stand around getting gouged by telecoms with their friggin' $0.20 per text pricing.


Public-key encryption (the same thing we do for https ssh etc.) of the recipient should be fine, and non-encrypted would be considered "public" and anyone can browse through it; think VM vs PM, tweets vs private messages, etc.


Without any new changes, it would still be a great deal of messages before you hit the 500kb cap per block (500,000/300 = 1,660 messages per minute, ~1,500 messages if you include how much transactions go through etc). It's not just forcing miners to work harder; if the network is maxed out purely by messages, you can earn an extra 3k~4k doge which might not be a lot but is an extra 30%~40% income on top of the 10k block reward. If prices ever reach the moon like we want them to, it could mean that there is an easier ROI for mining. It can potentially give back somewhat profitable mining to the average shibes again (although that's probs not going to last once the rich shibes get their paws on even more stuff). Perhaps if we remove the hardcap on Doge block size (not too unthinkable) we could potentially double, triple, quadruple the profits of Doge. Though by this point you know I'm just having a wet dream of being able to mine profitably again so don't bet too hard on it.
If we wanted real capacity a la Twitter or Facebook, we could make an extension protocol via a header backwards-compatible with all Doge past v1.8. This would mean a sudden hard-fork once activity on yip gets to max out the block size regularly. I don't know if people are willing to deal with all that, or if this will even be successful enough to warrant that.

How it to would work

A new version of Doge would have four options: full node/complete reference (all transactions plus messages), half node/public reference (all transactions plus public messages with no encrypted messages), light node/private chats (all transactions plus relevant/decodable messages), and feather node/empty reference (only financial transactions, no dust transactions headed with Yip! A transfer of more than one doge with Yip at the end is okay).

How would you get the full node, if some nodes don't have all the relevant information?

Well, for starters, you would make a merkle root and trim the unnecessary branches so that the tx size is smaller. Original whitepaper section 7~8 describes a way to trim blocks without breaking the hash; we could do this for "bloat" tx / yip! txs so they are essentially "discarded" for people who don't want or can't have lots of space taken up by the blockchain.
This naturally requires somewhat of a centralization (though it's not that bad – anyone can become one of the "centralized" nodes so it's not like we're trusting third-parties here), which means complete references must be kept around the world. I'm sure this wouldn't be too bad, considering we have sort of a "Node project" going on to establish a strong Dogecoin network anyways.
For those not willing to download an entire petabyte of what essentially amounts to inane bs, they can ping the networks for their version of the blockchain they want. Here is how the protocol pings the network. Referencing here we see that user-agent can be arbitrarily long ( up to around 18 exabytes, but I don't even have that much storage for torrents).
So, using this, adding a "yip!" argument to the end would say that you want all the yips. "yip?" (e.g.) would mean public, "yip." (e.g.) would mean private, and no yip! argument would give you the feather node.
If you send out no yip, then caught-up nodes will assume you're not up-to-date (i.e. v1.8) even if you are up to date, so they will weed out all the msg txs and send you only the trimmed trees. If you send out a "yip", then the nodes will assume the level (if they do not have enough information to send back the yips e.g. a private-reference node gets a request for a public-reference node, they will forward the alert to someone else).
I feel like this is a good idea but you know, I've never been a person to have good ideas.
submitted by droomph to dogecoin [link] [comments]

A few questions about the mining process

Hello all, random questions about how mining works. So my current understanding is:
Is this generally accurate? Other questions:
Thanks in advance for any insight!
submitted by 98731298 to Bitcoin [link] [comments]

Help a n00b: How often is the merkle root in the block header updated?

I've realized my title is misleading. I'm specifically interested in the merkle tree in the block header of a block that hasn't been solved yet. I keep going back to the bitcoin wiki page about the block hashing algorithm. I have a computer science background so I understand hash trees, however the table says the merkle tree is updated when a new transaction "is accepted". Does this mean that it is updated every single time a transaction happens anywhere? Wouldn't this mean it would have to change thousands or more times/second and get even worse as more people use bitcoins? I must be understanding this wrong (I'm not sure what it means when it says a transaction "comes in") because I don't think this would be feasible at all.
Edit; more info on what exactly I'm confused about:
The page about block header hashing states that the block header field values change from time to time. For example real life current time changes every second, but the current time value in the block header only needs to be updated every few seconds. The part I'm fuzzy on is initial merkle root, what triggers a change in the merkle root and how often that change happens: *What are the transactions that go into calculating the initial merkle root ('all recent transactions' or ' all of the transactions' is pretty ambiguous) *Where it says that the merkle root changes when 'a transaction is accepted' what does that mean? From the description of transactions I would assume that transactions happen very frequently, so wouldn't this cause the merkle root to change very often. As in mulitple times per millisecond often?
submitted by perfectfire to Bitcoin [link] [comments]


I'm working on enabling merge mining for the Prohashing mining pool. I've spent 45 hours trying to get the dogecoin daemon to accept a merge mined block, with no success. I'm posting my progress in this post, in the hopes that someone who has experience in merge mining can figure out what is wrong. I'll tip the first person $50 in DOGE (about 180,000 DOGE at current rates) who can tell me what is wrong with what I'm doing. If there are multiple issues, then I'll split the reward amongst all the helpers.
I simplified the procedure by removing the parts of the algorithm that are irrelevant.
Here is the procedure I used:
  1. Get the latest block from the litecoin testnet and store its data in memory.
  2. Call getauxblock against the dogecoin testnet. Since this example is only going to merge mine dogecoins, we ignore "chainid" and store only "hash" in memory. "Target" is obtained by calling getblocktemplate, because we need difficulty and other things from the full template for calculating payouts. "Target" in getauxblock and in getblocktemplate are reversed, so the appropriate conversion is made.
  3. When a block is found for the litecoin testnet, check to see whether the target is less than the dogecoin testnet's target. If so, we call getauxblock again, passing the "hash" exactly as provided in step 2, without any modification, and the serialized block data as the second parameter. The help for the command states that the parameters are "getauxblock [hash] [auxpow]."
The result is that the litecoin blocks are always accepted, and the dogecoin blocks are always rejected with the following errors:
2014-10-09 02:37:45 ERROR: Aux POW merkle root incorrect 2014-10-09 02:37:45 ERROR: AUX POW is not valid 
Here is an example "auxpow" serialized block that is submitted to the dogecoin damon. I annotated it as I think is correct, but keep in mind that the annotations could be incorrect and you shouldn't assume that I have identified the correct things to insert or the correct order. In the real submission, there are no spaces or characters between the separated sections.
Litecoin coinbase transaction:
Double-SHA-256 hash of the litecoin block header:
The length of the merkle branch from the litecoin block, which is the same as the branch sent out in the stratum protocol. Because this litecoin block has no transactions, the length of the merkle branch is zero:
The litecoin merkle branch, if there were one, would go here in a series of hashes. Since there are no transactions in the block other than the coinbase transaction, we append nothing here.
[There is nothing here] 
The "branch side mask" of the coinbase transaction, which is always zeroes:
The auxiliary branch count, which is zero because we are only mining dogecoins in this example:
The auxiliary branch index, which is also zero because we are only mining dogecoins:
The block header of the litecoin block, in full:
I'll also break down my understanding of what is supposed to be placed in the litecoin coinbase transaction to signify that we are merge mining dogecoins. Here is my understanding of the litecoin coinbase transaction's merge mining portion, which you can find embedded within the coinbase transaction printed above:
This string signifies that we are merge mining.
The "hash" parameter obtained from the dogecoin daemon's getauxblock command, verbatim:
The following are used for when multiple merge-mined coins are being sought at the same time, but since we are only merge-mining dogecoins, this is a 4-byte 1 followed by a 4-byte 0.
Here are some of the things I tried and the references I used.
  1. seems to be the primary source on merge mining. However, I noticed that some of the examples in the document don't work with dogecoins. For example, the "block hash" in the auxiliary proof of work that is submitted to namecoin in that document (the second field) looks like the proof of work hash for the block, since it ends in a string of zeroes. Looking at that, I tried placing the scrypt proof of work hash in that field, but it didn't work.
My understanding of the "block hash" is that when you call getblock from a daemon, you provide the double SHA-256 hash of the block header, not the scrypt proof of work hash. The "block hash" is not the scrypt proof of work hash.
  1. I tried reversing various hashes in the fields of the blocks on the theory that endianness was the problem, but 16 different permutations didn't work. I tried reversing the dogecoin auxiliary hash, the block hash, the merkle branch hashes (when there are transactions in the litecoin block, which there are not in this example), and even the block header of the litecoin block. None of these things worked. I couldn't find a permutation of reversed and non-reversed hashes that made any difference. Of course, it is possible that, since there are so many permutations, that I missed the correct one and the hashes are not in the correct endianness in the example.
  2. At, there is a poster who offers advice on how to submit merge mined blocks to getauxblock, although that information is specific to namecoin. I reviewed what I was doing and it appears to be identical to what he is suggesting.
  3. After reviewing the documentation for what a merkle tree is, it took me an entire day to figure out what happens when there are an odd number of transactions in the tree. It turns out that the algorithm is to hash the nodes with themselves. Seeing this, I took the example above and I tried specifying the length of the "merkle branch" for the coinbase transaction as "01," and then provided the hash of the coinbase transaction as the only hash in the "merkle branch." The long-shot idea was that perhaps the dogecoin daemon was looking to hash the coinbase transaction with itself, and use that as the root of the tree. It still returned the same error.
  4. In the litecoin coinbase transaction, the 44-byte merge mining part (fabe + "mm") is preceded by the length (44, or 2c) in some examples, but not in others. Apparently, this length is not necessary if the merge mining string is provided within the first 20 characters of the script, so I left it out in this example. However, in previous iterations, I added an additional byte of "2c" before the merge mining portion and it did not result in any difference in this error.
  5. In these examples, I always assumed that the merkle branches are double-sha256 hashes, even for scrypt coins. All the documentation I read seems to indicate that in scrypt, the only difference is the algorithm used to verify work. From what I can tell, the rest of the block still is stored using SHA-256 hashes, as is the hash of the block headers and even the hashes of the transactions. If there is some difference between scrypt and SHA-256 in how the merge mining headers are stored, that could be a clue.
Thanks to anyone who is willing to try to point out what is wrong here. We have about 15 features ready for release and merge mining is the only one that is holding back the release. Your help is greatly appreciated.
submitted by chris_sokolowski to test [link] [comments]

Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015

Wladimir on Feb 16 2015:
Bitcoin Core version 0.10.0 is now available from:
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
The whole distribution is also available as torrent:
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download (see further), the block files and databases are not
backwards-compatible with older versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes

Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
  • getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
  • getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
  • A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times. Fees are added by default unless the 'sendfreetransactions'
setting is enabled.
Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.
Statistics used to estimate fees and priorities are saved in the
data directory in the fee_estimates.dat file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
  • -txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
  • -sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0)
New RPC commands for fee estimation:
  • estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
  • estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
For the user this means that -rpcallowip takes a subnet specification, which can be
  • a single IP address (e.g. or fe80::0012:3456:789a:bcde)
  • a network/CIDR (e.g. or fe80::0000/64)
  • a network/netmask (e.g. or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address
matches one of them.
For example:
| 0.9.x and before | 0.10.x |
| -rpcallowip= | -rpcallowip= (unchanged) |
| -rpcallowip=192.168.1.* | -rpcallowip= |
| -rpcallowip=192.168.* | -rpcallowip= |
| -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
 Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g., a network/netmask (e.g. or a network/CIDR (e.g. 
REST interface
A new HTTP API is exposed when running with the -rest flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded
binary) or json.
For more details, see the doc/ document in the repository.
RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1
instead of OpenSSL. Libsecp256k1 is a cryptographic library
optimized for the curve Bitcoin uses which was created by Bitcoin
Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an
attacker on shared virtual machine hardware could extract a private
key if they could cause a target to sign using the same key hundreds
of times. While using shared hosts and reusing keys are inadvisable
for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization
and reduction in timing leaks that we've eagerly wanted to use for a
long time, but this functionality has still not made its
way into a released version of OpenSSL. Libsecp256k1 achieves
significantly stronger protection: As far as we're aware this is
the only deployed implementation of constant time signing for
the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a
possibly vulnerable system. In addition, it can help for (manual) construction
of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to
importprivkey, but instead takes an address or script (in hexadecimal) as
argument. After using it, outputs credited to this address or script are
considered to be received, and transactions consuming these outputs will be
considered to be sent.
The following RPCs have optional support for watch-only:
getbalance, listreceivedbyaddress, listreceivedbyaccount,
listtransactions, listaccounts, listsinceblock, gettransaction. See the
RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
-txindex, scales better, integrates better with the wallet, and is compatible
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is
critical to Bitcoin's consensus available to other applications, e.g. to language
bindings such as [python-bitcoinlib]( or
alternative node implementations.
This library is called (or, .dll for Windows).
Its interface is defined in the C header [bitcoinconsensus.h](
In its initial version the API includes two functions:
  • bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
  • bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
While the Bitcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
included many of the RPC "raw transaction" API functions, such as
bitcoin-tx is a newly introduced command line utility designed to enable easy
manipulation of bitcoin transactions. A summary of its operation may be
obtained via "bitcoin-tx --help" Transactions may be created or signed in a
manner similar to the RPC raw tx API. Transactions may be updated, deleting
inputs or outputs, or appending new inputs and outputs. Custom scripts may be
easily composed using a simple text notation, borrowed from the bitcoin test
This tool may be used for experimenting with new transaction types, signing
multi-party transactions, and many other uses. Long term, the goal is to
deprecate and remove "pure function" RPC API calls, as those do not require a
server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its getblocktemplate must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.
The prioritisetransaction RPC method has been added to enable miners to
manipulate the priority of transactions on an individual basis.
Bitcoin Core now supports BIP 22 long polling, so mining software can be
notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Bitcoin Core's
getblocktemplate method. This enables miners to check the basic validity of
their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
  • -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
  • -datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs.
The relay policy has changed to more properly implement the desired behavior of not
relaying free (or very low fee) transactions unless they have a priority above the
AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
consensus rule, which prohibits non-DER signatures. Such transactions have been
non-standard since Bitcoin v0.8.0 (released in February 2013), but were
technically still permitted inside blocks.
This change breaks the dependency on OpenSSL's signature parsing, and is
required if implementations would want to remove all of OpenSSL from the
consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
sequence of 1001 blocks have version number 3 or higher, the new consensus
rule becomes active for those blocks. When 951 out of a sequence of 1001
blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current mining software is NOT provided, thus miners
should read the first paragraph of "Mining and relay policy enhancements" above.
0.10.0 Change log

Detailed release notes follow. This overview includes changes that affect external
behavior, not code moves, refactors or string updates.
  • f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
  • b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
  • 171ca77 estimatefee / estimatepriority RPC methods
  • b750cf1 Remove cli functionality from bitcoind
  • f6984e8 Add "chain" to getmininginfo, improve help in getblockchaininfo
  • 99ddc6c Add nLocalServices info to RPC getinfo
  • cf0c47b Remove getwork() RPC call
  • 2a72d45 prioritisetransaction
  • e44fea5 Add an option -datacarrier to allow users to disable relaying/mining data carrier transactions
  • 2ec5a3d Prevent easy RPC memory exhaustion attack
  • d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
  • 83f3543 Added argument to listaccounts to include watchonly addresses
  • 952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
  • d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses
  • f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation
  • 0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account
  • 6c37f7f getrawchangeaddress: fail when keypool exhausted and wallet locked
  • ff6a7af getblocktemplate: longpolling support
  • c4a321f Add peerid to getpeerinfo to allow correlation with the logs
  • 1b4568c Add vout to ListTransactions output
  • b33bd7a Implement "getchaintips" RPC command to monitor blockchain forks
  • 733177e Remove size limit in RPC client, keep it in server
  • 6b5b7cb Categorize rpc help overview
  • 6f2c26a Closely track mempool byte total. Add "getmempoolinfo" RPC
  • aa82795 Add detailed network info to getnetworkinfo RPC
  • 01094bd Don't reveal whether password is <20 or >20 characters in RPC
  • 57153d4 rpc: Compute number of confirmations of a block from block height
  • ff36cbe getnetworkinfo: export local node's client sub-version string
  • d14d7de SanitizeString: allow '(' and ')'
  • 31d6390 Fixed setaccount accepting foreign address
  • b5ec5fe update getnetworkinfo help with subversion
  • ad6e601 RPC additions after headers-first
  • 33dfbf5 rpc: Fix leveldb iterator leak, and flush before gettxoutsetinfo
  • 2aa6329 Enable customising node policy for datacarrier data size with a -datacarriersize option
  • f877aaa submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
  • e69a587 submitblock: Support for returning specific rejection reasons
  • af82884 Add "warmup mode" for RPC server
  • e2655e0 Add unauthenticated HTTP REST interface to public blockchain data
  • 683dc40 Disable SSLv3 (in favor of TLS) for the RPC client and server
  • 44b4c0d signrawtransaction: validate private key
  • 9765a50 Implement BIP 23 Block Proposal
  • f9de17e Add warning comment to getinfo
Command-line options:
  • ee21912 Use netmasks instead of wildcards for IP address matching
  • deb3572 Add -rpcbind option to allow binding RPC port on a specific interface
  • 96b733e Add -version option to get just the version
  • 1569353 Add -stopafterblockimport option
  • 77cbd46 Let -zapwallettxes recover transaction meta data
  • 1c750db remove -tor compatibility code (only allow -onion)
  • 4aaa017 rework help messages for fee-related options
  • 4278b1d Clarify error message when invalid -rpcallowip
  • 6b407e4 -datadir is now allowed in config files
  • bdd5b58 Add option -sysperms to disable 077 umask (create new files with system default umask)
  • cbe39a3 Add "bitcoin-tx" command line utility and supporting modules
  • dbca89b Trigger -alertnotify if network is upgrading without you
  • ad96e7c Make -reindex cope with out-of-order blocks
  • 16d5194 Skip reindexed blocks individually
  • ec01243 --tracerpc option for regression tests
  • f654f00 Change -genproclimit default to 1
  • 3c77714 Make -proxy set all network types, avoiding a connect leak
  • 57be955 Remove -printblock, -printblocktree, and -printblockindex
  • ad3d208 remove -maxorphanblocks config parameter since it is no longer functional
Block and transaction handling:
  • 7a0e84d ProcessGetData(): abort if a block file is missing from disk
  • 8c93bf4 LoadBlockIndexDB(): Require block db reindex if any blk*.dat files are missing
  • 77339e5 Get rid of the static chainMostWork (optimization)
  • 4e0eed8 Allow ActivateBestChain to release its lock on cs_main
  • 18e7216 Push cs_mains down in ProcessBlock
  • fa126ef Avoid undefined behavior using CFlatData in CScript serialization
  • 7f3b4e9 Relax IsStandard rules for pay-to-script-hash transactions
  • c9a0918 Add a skiplist to the CBlockIndex structure
  • bc42503 Use unordered_map for CCoinsViewCache with salted hash (optimization)
  • d4d3fbd Do not flush the cache after every block outside of IBD (optimization)
  • ad08d0b Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
  • 5734d4d Only remove actualy failed blocks from setBlockIndexValid
  • d70bc52 Rework block processing benchmark code
  • 714a3e6 Only keep setBlockIndexValid entries that are possible improvements
  • ea100c7 Reduce maximum coinscache size during verification (reduce memory usage)
  • 4fad8e6 Reject transactions with excessive numbers of sigops
  • b0875eb Allow BatchWrite to destroy its input, reducing copying (optimization)
  • 92bb6f2 Bypass reloading blocks from disk (optimization)
  • 2e28031 Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
  • ab15b2e Avoid copying undo data (optimization)
  • 341735e Headers-first synchronization
  • afc32c5 Fix rebuild-chainstate feature and improve its performance
  • e11b2ce Fix large reorgs
  • ed6d1a2 Keep information about all block files in memory
  • a48f2d6 Abstract context-dependent block checking from acceptance
  • 7e615f5 Fixed mempool sync after sending a transaction
  • 51ce901 Improve chainstate/blockindex disk writing policy
  • a206950 Introduce separate flushing modes
  • 9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
  • 868d041 Remove coinbase-dependant transactions during reorg
  • 723d12c Remove txn which are invalidated by coinbase maturity during reorg
  • 0cb8763 Check against MANDATORY flags prior to accepting to mempool
  • 8446262 Reject headers that build on an invalid parent
  • 008138c Bugfix: only track UTXO modification after lookup
P2P protocol and network code:
  • f80cffa Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
  • c30329a Add testnet DNS seed of Alex Kotenko
  • 45a4baf Add testnet DNS seed of Andreas Schildbach
  • f1920e8 Ping automatically every 2 minutes (unconditionally)
  • 806fd19 Allocate receive buffers in on the fly
  • 6ecf3ed Display unknown commands received
  • aa81564 Track peers' available blocks
  • caf6150 Use async name resolving to improve net thread responsiveness
  • 9f4da19 Use pong receive time rather than processing time
  • 0127a9b remove SOCKS4 support from core and GUI, use SOCKS5
  • 40f5cb8 Send rejects and apply DoS scoring for errors in direct block validation
  • dc942e6 Introduce whitelisted peers
  • c994d2e prevent SOCKET leak in BindListenPort()
  • a60120e Add built-in seeds for .onion
  • 60dc8e4 Allow -onlynet=onion to be used
  • 3a56de7 addrman: Do not propagate obviously poor addresses onto the network
  • 6050ab6 netbase: Make SOCKS5 negotiation interruptible
  • 604ee2a Remove tx from AlreadyAskedFor list once we receive it, not when we process it
  • efad808 Avoid reject message feedback loops
  • 71697f9 Separate protocol versioning from clientversion
  • 20a5f61 Don't relay alerts to peers before version negotiation
  • b4ee0bd Introduce preferred download peers
  • 845c86d Do not use third party services for IP detection
  • 12a49ca Limit the number of new addressses to accumulate
  • 35e408f Regard connection failures as attempt for addrman
  • a3a7317 Introduce 10 minute block download timeout
  • 3022e7d Require sufficent priority for relay of free transactions
  • 58fda4d Update seed IPs, based on crawler data
  • 18021d0 Remove from dnsseeds.
  • 6fd7ef2 Also switch the (unused) verification code to low-s instead of even-s
  • 584a358 Do merkle root and txid duplicates check simultaneously
  • 217a5c9 When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
  • f74fc9b Print input index when signature validation fails, to aid debugging
  • 6fd59ee script.h: set_vch() should shift a >32 bit value
  • d752ba8 Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
  • 698c6ab Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
  • ab9edbd script: create sane error return codes for script validation and remove logging
  • 219a147 script: check ScriptError values in script tests
  • 0391423 Discourage NOPs reserved for soft-fork upgrades
  • 98b135f Make STRICTENC invalid pubkeys fail the script rather than the opcode
  • 307f7d4 Report script evaluation failures in log and reject messages
  • ace39db consensus: guard against openssl's new strict DER checks
  • 12b7c44 Improve robustness of DER recoding code
  • 76ce5c8 fail immediately on an empty signature
Build system:
  • f25e3ad Fix build in OS X 10.9
  • 65e8ba4 build: Switch to non-recursive make
  • 460b32d build: fix broken boost chrono check on some platforms
  • 9ce0774 build: Fix windows configure when using --with-qt-libdir
  • ea96475 build: Add mention of --disable-wallet to bdb48 error messages
  • 1dec09b depends: add shared dependency builder
  • c101c76 build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
  • e432a5f build: add option for reducing exports (v2)
  • 6134b43 Fixing condition 'sabotaging' MSVC build
  • af0bd5e osx: fix signing to make Gatekeeper happy (again)
  • a7d1f03 build: fix dynamic boost check when --with-boost= is used
  • d5fd094 build: fix qt test build when libprotobuf is in a non-standard path
  • 2cf5f16 Add libbitcoinconsensus library
  • 914868a build: add a deterministic dmg signer
  • 2d375fe depends: bump openssl to 1.0.1k
  • b7a4ecc Build: Only check for boost when building code that requires it
  • b33d1f5 Use fee/priority estimates in wallet CreateTransaction
  • 4b7b1bb Sanity checks for estimates
  • c898846 Add support for watch-only addresses
  • d5087d1 Use script matching rather than destination matching for watch-only
  • d88af56 Fee fixes
  • a35b55b Dont run full check every time we decrypt wallet
  • 3a7c348 Fix make_change to not create half-satoshis
  • f606bb9 fix a possible memory leak in CWalletDB::Recover
  • 870da77 fix possible memory leaks in CWallet::EncryptWallet
  • ccca27a Watch-only fixes
  • 9b1627d [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
  • a53fd41 Deterministic signing
  • 15ad0b5 Apply AreSane() checks to the fees from the network
  • 11855c1 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
  • c21c74b osx: Fix missing dock menu with qt5
  • b90711c Fix Transaction details shows wrong To:
  • 516053c Make links in 'About Bitcoin Core' clickable
  • bdc83e8 Ensure payment request network matches client network
  • 65f78a1 Add GUI view of peer information
  • 06a91d9 VerifyDB progress reporting
  • fe6bff2 Add BerkeleyDB version info to RPCConsole
  • b917555 PeerTableModel: Fix potential deadlock. #4296
  • dff0e3b Improve rpc console history behavior
  • 95a9383 Remove CENT-fee-rule from coin control completely
  • 56b07d2 Allow setting listen via GUI
  • d95ba75 Log messages with type>QtDebugMsg as non-debug
  • 8969828 New status bar Unit Display Control and related changes
  • 674c070 seed OpenSSL PNRG with Windows event data
  • 509f926 Payment request parsing on startup now only changes network if a valid network name is specified
  • acd432b Prevent balloon-spam after rescan
  • 7007402 Implement SI-style (thin space) thoudands separator
  • 91cce17 Use fixed-point arithmetic in amount spinbox
  • bdba2dd Remove an obscure option no-one cares about
  • bd0aa10 Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
  • 94e1b9e Re-work overviewpage UI
  • 8bfdc9a Better looking trayicon
  • b197bf3 disable tray interactions when client model set to 0
  • 1c5f0af Add column Watch-only to transactions list
  • 21f139b Fix tablet crash. closes #4854
  • e84843c Broken addresses on command line no longer trigger testnet
  • a49f11d Change splash screen to normal window
  • 1f9be98 Disable App Nap on OSX 10.9+
  • 27c3e91 Add proxy to options overridden if necessary
  • 4bd1185 Allow "emergency" shutdown during startup
  • d52f072 Don't show wallet options in the preferences menu when running with -disablewallet
  • 6093aa1 Qt: QProgressBar CPU-Issue workaround
  • 0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true)
  • ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
  • e7876b2 [Wallet] Prevent user from paying a non-sense fee
  • c1c9d5b Add Smartfee to GUI
  • e0a25c5 Make askpassphrase dialog behave more sanely
  • 94b362d On close of splashscreen interrupt verifyDB
  • b790d13 English translation update
  • 8543b0d Correct tooltip on address book page
  • b41e594 Fix script test handling of empty scripts
  • d3a33fc Test CHECKMULTISIG with m == 0 and n == 0
  • 29c1749 Let tx (in)valid tests use any SCRIPT_VERIFY flag
  • 6380180 Add rejection of non-null CHECKMULTISIG dummy values
  • 21bf3d2 Add tests for BoostAsioToCNetAddr
  • b5ad5e7 Add Python test for -rpcbind and -rpcallowip
  • 9ec0306 Add CODESEPARATOFindAndDelete() tests
  • 75ebced Added many rpc wallet tests
  • 0193fb8 Allow multiple regression tests to run at once
  • 92a6220 Hook up sanity checks
  • 3820e01 Extend and move all crypto tests to crypto_tests.cpp
  • 3f9a019 added list/get received by address/ account tests
  • a90689f Remove timing-based signature cache unit test
  • 236982c Add skiplist unit tests
  • f4b00be Add CChain::GetLocator() unit test
  • b45a6e8 Add test for getblocktemplate longpolling
  • cdf305e Set -discover=0 in regtest framework
  • ed02282 additional test for OP_SIZE in script_valid.json
  • 0072d98 script tests: BOOLAND, BOOLOR decode to integer
  • 833ff16 script tests: values that overflow to 0 are true
  • 4cac5db script tests: value with trailing 0x00 is true
  • 89101c6 script test: test case for 5-byte bools
  • d2d9dc0 script tests: add tests for CHECKMULTISIG limits
  • d789386 Add "it works" test for bitcoin-tx
  • df4d61e Add bitcoin-tx tests
  • aa41ac2 Test IsPushOnly() with invalid push
  • 6022b5d Make script_{valid,invalid}.json validation flags configurable
  • 8138cbe Add automatic script test generation, and actual checksig tests
  • ed27e53 Add coins_tests with a large randomized CCoinViewCache test
  • 9df9cf5 Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
  • dcb9846 Extend getchaintips RPC test
  • 554147a Ensure MINIMALDATA invalid tests can only fail one way
  • dfeec18 Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
  • 2b62e17 Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
  • 16d78bd Add valid invert of invalid every numeric opcode tests
  • f635269 tests: enable alertnotify test for Windows
  • 7a41614 tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
  • 5122ea7 tests: fix on windows
  • fa7f8cd tests: remove old pull-tester scripts
  • 7667850 tests: replace the old (unused since Travis) tests with new rpc test scripts
  • f4e0aef Do signature-s negation inside the tests
  • 1837987 Optimize -regtest setgenerate block generation
  • 2db4c8a Fix node ranges in the test framework
  • a8b2ce5 regression test only setmocktime RPC call
  • daf03e7 RPC tests: create initial chain with specific timestamps
  • 8656dbb Port/fix regression test
  • ca81587 Test the exact order of CHECKMULTISIG sig/pubkey evaluation
  • 7357893 Prioritize and display -testsafemode status in UI
  • f321d6b Add key generation/verification to ECC sanity check
  • 132ea9b miner_tests: Disable checkpoints so they don't fail the subsidy-change test
  • bc6cb41 QA RPC tests: Add tests block block proposals
  • f67a9ce Use deterministically generated script tests
  • 11d7a7d [RPC] add rpc-test for http keep-alive (persistent connections)
  • 34318d7 RPC-test based on invalidateblock for mempool coinbase spends
  • 76ec867 Use actually valid transactions for script tests
  • c8589bf Add actual signature tests
  • e2677d7 Fix smartfees test for change to relay policy
  • 263b65e tests: run sanity checks in tests too
  • 122549f Fix incorrect checkpoint data for testnet3
  • 5bd02cf Log used config file to debug.log on startup
  • 68ba85f Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
  • e5ee8f0 Remove -beta suffix
  • 38405ac Add comment regarding experimental-use service bits
  • be873f6 Issue warning if collecting RandSeed data failed
  • 8ae973c Allocate more space if necessary in RandSeedAddPerfMon
  • 675bcd5 Correct comment for 15-of-15 p2sh script size
  • fda3fed libsecp256k1 integration
  • 2e36866 Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
  • cd01a5e Enable paranoid corruption checks in LevelDB >= 1.16
  • 9365937 Add comment about never updating nTimeOffset past 199 samples
  • 403c1bf contrib: remove getwork-based pyminer (as getwork API call has been removed)
  • 0c3e101 contrib: Added systemd .service file in order to help distributions integrate bitcoind
  • 0a0878d doc: Add new DNSseed policy
  • 2887bff Update coding style and add .clang-format
  • 5cbda4f Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
  • b4a72a7 contrib/linearize: split output files based on new-timestamp-year or max-file-size
  • e982b57 Use explicit fflush() instead of setvbuf()
  • 234bfbf contrib: Add init scripts and docs for Upstart and OpenRC
  • 01c2807 Add warning about the merkle-tree algorithm duplicate txid flaw
  • d6712db Also create pid file in non-daemon mode
  • 772ab0e contrib: use batched JSON-RPC in linarize-hashes (optimization)
  • 7ab4358 Update bash-completion for v0.10
  • 6e6a36c contrib: show pull # in prompt for github-merge script
  • 5b9f842 Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
  • 4e7c219 Catch UTXO set read errors and shutdown
  • 867c600 Catch LevelDB errors during flush
  • 06ca065 Fix CScriptID(const CScript& in) in empty script case

Thanks to everyone who contributed to this release:
  • 21E14
  • Adam Weiss
  • Aitor Pazos
  • Alexander Jeng
  • Alex Morcos
  • Alon Muroch
  • Andreas Schildbach
  • Andrew Poelstra
  • Andy Alness
  • Ashley Holman
  • Benedict Chan
  • Ben Holden-Crowther
  • Bryan Bishop
  • BtcDrak
  • Christian von Roques
  • Clinton Christian
  • Cory Fields
  • Cozz Lovan
  • daniel
  • Daniel Kraft
  • David Hill
  • Derek701
  • dexX7
  • dllud
  • Dominyk Tiller
  • Doug
  • elichai
  • elkingtowa
  • ENikS
  • Eric Shaw
  • Federico Bond
  • Francis GASCHET
  • Gavin Andresen
  • Giuseppe Mazzotta
  • Glenn Willen
  • Gregory Maxwell
  • gubatron
  • HarryWu
  • himynameismartin
  • Huang Le
  • Ian Carroll
  • imharrywu
  • Jameson Lopp
  • Janusz Lenar
  • JaSK
  • Jeff Garzik
  • JL2035
  • Johnathan Corgan
  • Jonas Schnelli
  • jtimon
  • Julian Haight
  • Kamil Domanski
  • kazcw
  • kevin
  • kiwigb
  • Kosta Zertsekel
  • LongShao007
  • Luke Dashjr
  • Mark Friedenbach
  • Mathy Vanvoorden
  • Matt Corallo
  • Matthew Bogosian
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • mruddy
  • ntrgn
  • Otto Allmendinger
  • paveljanik
  • Pavel Vasin
  • Peter Todd
  • phantomcircuit
  • Philip Kaufmann
  • Pieter Wuille
  • pryds
  • randy-waterhouse
  • R E Broadley
  • Rose Toomey
  • Ross Nicoll
  • Roy Badami
  • Ruben Dario Ponticelli
  • Rune K. Svendsen
  • Ryan X. Charles
  • Saivann
  • sandakersmann
  • SergioDemianLerner
  • shshshsh
  • sinetek
  • Stuart Cardall
  • Suhas Daftuar
  • Tawanda Kembo
  • Teran McKinney
  • tm314159
  • Tom Harding
  • Trevin Hofmann
  • Whit J
  • Wladimir J. van der Laan
  • Yoichi Hirai
  • Zak Wilcox
As well as everyone that helped translating on [Transifex](
Also lots of thanks to the website team David A. Harding and Saivann Carignan.
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

2 Simple explanation of code - Merkle Tree Bitcoin HACK 2020 BITCOIN GRATIS What is MERKLE TREE? What does MERKLE TREE mean? MERKLE TREE meaning & explanation How to Import Recovery Phrase Trust Wallet #️⃣ Wie machen Hashes die Bitcoin Blockchain unveränderlich? Merkle Trees!

The Bitcoin wiki Vocabulary article explains why the Merkle root exists:. Every transaction has a hash associated with it. In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. Merkle Trees. Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a double SHA-256, the SHA-256 hash of the SHA-256 hash of something. If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of ... The Bitcoin wiki Vocabulary article explains why the Merkle root exists:. Every transaction has a hash associated with it. In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. Bitcoin merkle tree []. Hash trees can be used to verify any kind of data stored, handled and transferred in and between computers. Currently the main use of hash trees is to make sure that data blocks received from other peers in a peer-to-peer network are received undamaged and unaltered, and even to check that the other peers do not lie and send fake blocks. Partial Merkle branch format. A Merkle tree is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the Merkle root. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions.

[index] [28807] [17193] [23164] [2483] [22101] [6798] [21641] [17817] [6732] [7802]

2 Simple explanation of code - Merkle Tree

All Token & Coin Cryptocurency. Extract Private Keys from Trust Wallet - works for Bitcoin, Ethereum, Litecoin and other cryptos - Duration: 5:48. Crypto Coin Investor 4,292 views The Merkle hash root does not indicate the tree depth, enabling a second-preimage attack in which an attacker creates a document other than the original that has the same Merkle hash root. Proof-of-work in Bitcoin's mining takes an input consists of Merkle Root, timestamp, previous block hash and few other things plus a nonce which is completely random number. Links used in the video: Wiki link to the current topic: Other resources: PROFITT... Part 1 in a series of videos that will take you through setting up your computer to mine burstcoins from scratch. htt...