# 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": "2KxNbEb040GKQ1DSDNDsA-Fsj_BlQIEAlzBNuiapBR0", "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": "2KxNbEb040GKQ1DSDNDsA-Fsj_BlQIEAlzBNuiapBR0", "level": 2}'
        

Bash

# Search

response = requests.post(
    "https://search.dria.co/hnsw/search",
    headers={'x-api-key': '<YOUR_API_KEY>', 'Content-Type': 'application/json'},
    json={
    "rerank": True,
    "top_n": 10,
    "contract_id": "2KxNbEb040GKQ1DSDNDsA-Fsj_BlQIEAlzBNuiapBR0",
    "query": "What is alexanDRIA library?"
}
)
print(response.status_code)
print(response.json())
        
# Query

response = requests.post(
    "https://search.dria.co/hnsw/query",
    headers={'x-api-key': '<YOUR_API_KEY>', 'Content-Type': 'application/json'},
    json={
    "vector": [
        0.123,
        0.5236
    ],
    "top_n": 10,
    "contract_id": "2KxNbEb040GKQ1DSDNDsA-Fsj_BlQIEAlzBNuiapBR0",
    "level": 2
}
)
print(response.status_code)
print(response.json())
        

Python

The Bitcoin Whitepaper, titled \'Bitcoin: A Peer-to-Peer Electronic Cash System,\' was released on October 31, 2008, by an anonymous author or group known as Satoshi Nakamoto. It is a nine-page document that laid the groundwork for the development of the Bitcoin network and the concept of a decentralized digital currency. The whitepaper explains the weaknesses of the existing electronic payment systems and proposes a trustless system for making payments without the need for a trusted third party. 

The Bitcoin Whitepaper

The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. 7. Reclaiming Disk Space Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree , with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. Block Block Header (Block Hash) Block Block Header (Block Hash) Prev Hash Nonce Prev Hash

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.

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

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