BrandonT42

Keybase proof

I hereby claim:

• I am brandont42 on github.
• I am canti (https://keybase.io/canti) on keybase.
• I have a public key ASALc60vCb3XKPgqe7vMQ2yChxYbFCPtatLEhHgeBFfS3Ao

To claim this, I am signing this object:

BrandonT42

Levin Commands

A breakdown of Levin Protocol's P2P-specific commands

1001 - COMMAND_HANDSHAKE

Request Data:

• Node Data
  • Version
• Local Time

BrandonT42

CS Daemon Logs

9:00 PM [DEBUG] Peer connection formed with 127.0.0.1:64874

9:00 PM [DEBUG] [IN] Received "Handshake" Request:

9:00 PM [DEBUG] - Response Requested: True

9:00 PM [DEBUG] - Node Data:

BrandonT42

Working on researching block serialization to work on genesis block creation and hashing... Taking notes:

Create genesis block and make a cached block of it https://github.com/turtlecoin/turtlecoin/blob/1eab20ffb619c2cf24327c57ec0180bd9bf72638/src/CryptoNoteCore/Currency.cpp#L78

Get block hash from genesis block using this https://github.com/turtlecoin/turtlecoin/blob/bed86cf521df1040e2b6f9a3c03696859321e4e5/src/CryptoNoteCore/CachedBlock.cpp#L35

Somehow needs to use this to serialize the header and transactions

BrandonT42

        // Gets a user's balance from the database
        public static decimal GetBalance()
        {
            // Connect to Database
            SqliteConnection Database = new SqliteConnection("Data Source=" + databaseFile);
            Database.Open();
            
            // Create Sql command
            SqliteCommand Command = new SqliteCommand("SELECT balance FROM users WHERE paymentid = @paymentid", Database);

BrandonT42

First Data Set - 832 bytes

015be710ada83397322b717fa25abeffb718c9d47a3e07be788ca3f0c44dbb8d051c01300a01013462323730303135663230643562313664353334373238666466373066346331633665666437313230323334643366303634303639396233653531333966633901310200000000013202020000000133020000000001340a250235786d487a724d7a42417a466e77735a33446b35726a3579586432315a7850745354686a33333577394d6f39726d77443452524731357738434135576a5834435170703876345a3378524b6d6a55777445735077374c61377333317774417448356e47775168387639344851465469684452716b73387a72777954557a586e7155395532324655326301350ab0436b5036537a754a705552565877467374444435533970516d32334d426d4b6f43784139363266666d32375001360a05081bcf0600c437f796df0baf1096e1b2653dd970ebf5c25caf178a826808ccc4cd340d0413dc8bd6e431b18ba2300c3cb0f51b1fec816cd1933ed9eb367404449071b84f9dc7037f0c8dcc300cc6aecb6ec998147a4bd172a5d4ab2c287208b1380f49e65a2a8586bfba5649ad67f69933d7dc4a734d5c0790b3e1a5bfd3bb7d1cfd7e6c3e9f1c9e9e7f2ddede6733398acf070f8e77260f5b4fd3ef7184ebfdc1e9bef1a3611806234bc6c412b3f345a

BrandonT42

NOTIFY_REQUEST_CHAIN

This is a request chain packet, sent directly after handshaking with another node.

This is what the OG source says about it: /*IDs of the first 10 blocks are sequential, next goes with pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block */

Received a [NOTIFY_REQUEST_CHAIN] packet:
[block_ids]:
c41668b341d6c1704feb41bf1f95152df93d85395da961b950d0003583310824
62e57d380156c8851c545977d2021860ebbbdf2a9706420fa924aea9a4108b7b

BrandonT42

Below, I will attempt to explain each packet's purpose, and break down an example packet. Stay close, make sure you have a working lantern, because we're diving in...

HANDSHAKE - Request

Purpose:

A handshake request is sent when first connecting to another node. This packet serves to deliver information on where our node is at on the blockchain, as well as serving to prove we are a valid node in general. Without this packet, we will be ignored by another node, as we won't be seen as a valid node on the network. If a valid response isn't received in a specified amount of time, this peer connection is killed. This amount of time is 5 seconds by default, and is defined by P2P_DEFAULT_HANDSHAKE_INVOKE_TIMEOUT in the cryptonote config file.

Entries:

• node_data: An object containing basic data about the node that is attempting to connect
  • network_id: The network's hex-string identifier, as defined by CRYPTONOTE_NETWORK in the cryptonote config file
• version: The version of the con

BrandonT42

There are a number of objects within the CryptoNote protocol packets that don't follow the standard serialization scheme. On this page, I will attempt to layout what they types are an how to deserialize them.

Peer List

Description:

The peer list sent in a few packets is an array of individual peer list entries, each of which contain the following information:

• ip: The network ip of the peer, serialized as an unsigned integer
• port: The network port of the peer, serialized as an unsigned integer
• id: A unique identifier given to each peer, represented by an unsigned long value
• last_seen: A unix timestamp of the last time this peer communicated with the node, represented by an unsigned long value

BrandonT42

//
// Copyright (c) 2018-2019 Canti, The TurtleCoin Developers
// 
// This is but a piece of a larger codebase, please see the following license for more information:
// https://github.com/turtlecoin/cs-turtlecoin/blob/master/LICENSE

using System;

namespace Canti
{