Created at 7am, Jan 5
bedirhan.ertsCrypto
0
THE BİTCOİN WHİTEPAPER
Ky3eOg0Kg6Hyoji_sxkrk2J1aNax4moI1wN3ic8ABbI
File Type
PDF
Entry Count
31
Embed. Model
jina_embeddings_v2_base_en
Index Type
hnsw

The Bitcoin Whitepaper titled 'Bitcoin: Peer-to-Peer Electronic Cash System' was published on October 31, 2008 by an anonymous author or group known as Satoshi Nakamoto. It is a nine-page document covering the evolution of the Bitcoin network and the development of the decentralized digital currency. The white paper explains the weak scheme of the current electronic payment system and proposes an unreliable system for making payments without the need for a reliable third part.

Nonce Root Hash Root Hash Hash01 Hash23 Hash01 Hash23 Hash0 Hash1 Hash2 Hash3 Hash2 Hash3 Tx0 Tx1 Tx2 Tx3 Tx3 Transactions Hashed in a Merkle Tree After Pruning Tx0-2 from the Block A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. 4 8.
id: 4d3116b9a912b5dc8f824fb176243be6 - page: 4
Simplified Payment Verification It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. Longest Proof-of-Work Chain Block Header Block Header Block Header Prev Hash Nonce Prev Hash Nonce Prev Hash Nonce Merkle Root Merkle Root Merkle Root Hash01 Hash23 Merkle Branch for Tx3 Hash2 Hash3
id: d823a93cfe3411e7a166e8c113a888bd - page: 5
Tx3 As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification. 9. Combining and Splitting Value
id: 5435949a994bdfc693851e13d26bd909 - page: 5
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender. Transaction In Out
id: 0e60117f737e18985c027d207c712562 - page: 5
How to Retrieve?
# Search

curl -X POST "https://search.dria.co/hnsw/search" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"rerank": true, "top_n": 10, "contract_id": "Ky3eOg0Kg6Hyoji_sxkrk2J1aNax4moI1wN3ic8ABbI", "query": "What is alexanDRIA library?"}'
        
# Query

curl -X POST "https://search.dria.co/hnsw/query" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"vector": [0.123, 0.5236], "top_n": 10, "contract_id": "Ky3eOg0Kg6Hyoji_sxkrk2J1aNax4moI1wN3ic8ABbI", "level": 2}'