In order to make nodes have as precise a time as possible and to increase the number of honest nodes reporting a correct time in their blocks, either:

• check the local time against any available timeserver and refuse to start unless the diff is more than X seconds; ot
• periodically check the time in the background and simply have a correction value that's added to the local time reports upon necessity, thus having fixed many possible local time issues both deliberately and unknowingly incurred.

Maybe for this purpose implement a time server into the Kaspa DNS servers functionality, to a) decrease the internet time servers load and 2) to increase the chance of having the source of correct time in the case of time servers being firewalled out.

Probably (for a case when there are multiple nodes behind a firewall for redundancy, most of which are only aware of each other, and only 1 of them have the full internet access) also implement a time server functionality into the nodes p2p protocol as a fallback and last resort option.

Describe the bug
Was using the Build.ps1 in the \rusty-kaspa\kos\ directory and noticed the following...

Original with parameters inside the quote - not working:

& "wasm-pack build --dev --target web --out-name kaspa --out-dir app/wasm"

Move the quote to only around wasm-pack and parameters after quote - Working:

& "wasm-pack" build --dev --target web --out-name kaspa --out-dir app/wasm

I think it's because PowerShell treats everything inside the quote as a single command. Parameters should follow the quotes. These quotes will need to change on all wasm-pack commands. The above is just a single example.

To Reproduce
Steps to reproduce the behavior:
1,) install prerequisites from "https://github.com/kaspanet/rusty-kaspa#readme"
2.) Verify that the running of scripts is allowed on your system and if not, use the Set-ExecutionPolicy command to allow them per your system security requirements.
3.) Perform the following from elevated PowerShell Window

git clone https://github.com/kaspanet/rusty-kaspa
cd .\rusty-kaspa\kos
.\build.ps1

4. See error

Expected behavior
The .\build.ps1 script should begin to build the solution, instead of erroring out due to an invalid command.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 Pro

blocked by #111 and #108

Address all unresolved comments on #118 and cover txscript with many tests: Each opcode has to be tested

This issue being opened to brainstorm possible use cases which "could" become possible if there was a layer bridging internet packets into the browser.

Link to starting discord convo:
https://discord.com/channels/599153230659846165/1001242675942531132/1059520395721584670

lmdb vs rocksdb and more

Describe the bug
When using \rusty-kaspa\kos\Build.ps1, the build errors out as it is not able to find "clang", even though LLVM is installed. I had to add "C:\Program Files\LLVM\bin" directly to the Path environment variable and reboot or the build process couldn't find clang. This is not mentioned in the Readme...it says only to "set LIBCLANG_PATH env var pointing to the bin dir of the llvm installation" and I did already have the LIBCLANG_PATH set. Once I added "C:\Program Files\LLVM\bin" to the "Path" environment variable and rebooted, it was able to find clang and proceed.

To Reproduce
Steps to reproduce the behavior:
Starting from a clean install of Windows, follow the Kaspa Readme to install prerequisites and clone the rusty-kaspa directory.
Navigate down to the rusty-kaspa/kos directory and open an elevated PowerShell window at this location. execute \rusty-kaspa\kos\Build.ps1 after applying the fix discussed in issue "#245"

the script should fail as it cannot find "clang"

Expected behavior
When executing \rusty-kaspa\kos\Build.ps1, it should build successfully.

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Kaspad version: [e.g. 0.12.11]

Additional context
Add any other context about the problem here.

blocked by #53

Would be much useful for exchanges & data analysis etc.

https://docs.rs/serde_bytes/latest/serde_bytes/

The above crate promises faster serde Serialization / Deserialization on byte vectors and byte slices, as it claims standard serde is not optimized for variable length sequences already in byte format.

Some examples in our current codebase where this could be included are the fields script inconsensus_core::tx::ScriptPublicKey, paylod in consensus_core::tx::Transaction, signature_script in consensus_core::tx::TransactionInput.

I would like to transfer the following issue to the rusty-kaspa repo:

Currently, many nodes have RPC ports potentially open to the world
Some manner of authentication should be implemented to mitigate it

Suggested solution: gRPC supports authentication out-of-the-box: https://grpc.io/docs/guides/auth/

Source: kaspanet/kaspad#1893

Only the auth method should probably ideally support wRPC, gRPC and all potential future protocols in a generic manner.

Blocked by #50

available in The LLVM Compiler Infrastructure (https://llvm.org/)

Is your feature request related to a problem? Please describe.
Yes - a user that only wants to use the node as an API does not need to receive tx messages. Not having to deal with txs will reduce mempool use.

Describe the solution you'd like
Implement the disable_relay_tx flag. When enabled, this lets a node's peers that it doesn't want to receive transactions. The peers will not send txs to this node.

Describe alternatives you've considered
N/A

Additional context

One consideration is the issue of starvation: What if a node that wants to receive txs is only connected to peers that have DisableRelayTx=false?

Notes

• Rust code: in flow_context.rs the line // TODO: disable_relay_tx from config/cmd is where this would go
• Go code: this was BlockOnly in config, and DisableRelayTx in the rest of the codebase.

Mutagen(https://github.com/llogiq/mutagen) is a cool tool that modify constants and control flows and checks if the tests actually fail under the modification, this allows to check how good are the tests, even if you have "full coverage" you might not actually test a lot of conditions and mutagen helps you find those

Generally we should check which bucket takes the most space and consider storing it outside the main db

See #131
And #131 (comment)

1. Change Block to have Arc<Header> and pass block around w/o an arc
2. Switch BlueWorkType to Uint192
3. Consider the DAA window average optimization by Tiram
4. Remove fee param from Tx output
5. Remove many Arcs from within Tx structs
6. Use BlockHashMap/BlockHashSet type defs where ever possible
7. Add prefix support to logs trace macro and perhaps add debug/info macros
8. Consider switching from saving the mergeset DAA blocks to saving the complementary set, i.e. the mergeset non-DAA blocks. On average this means moving from saving O(mergeset) to 0
9. Apply DbWriter as a generalization of Batch writing and use it to cleanup remaining caching.rs code duplications
10. Add genesis block to config
11. Take cache sizes from kaspa-go + give it more thought
12. Rename rust files with a single convention

Table of Contents

1. Monivation
   1.1. Context
   1.2. Wallets
2. IANA URI Scheme
   2.1. Application
   2.2. Process

Motivation

Context

The Kaspa cryptocurrency project launched in November 2021, and is growing quickly.
It is a community governed OSS project.

Kaspa's value proposition is to fulfil Satoshi Nakamoto's original vision with Bitcoin, to become a peer to peer electronic cash system. Kaspa is powered by a proof of work network of miners that produce 1 block per second, onto a blockDAG governed by the GHOSTDAG consensus engine. It is under the final stages to upgrade the network to 32 blocks per second by rewriting the peer to peer network node in rustlang. This allows Kaspa to scale down confirmation times to several seconds.

The outcome is a currency that is as secure as Bitcoin under similar network hashrate or more secure considering Kaspa doesn't orphan blocks, as decentralized as Bitcoin or more considering the block rewards are much more granular than Bitcoin making solo-mining more viable, and much more usable as a medium of exchange than Bitcoin considering the network can house at least 8,000 transactions each second, and those transactions can get settled on the network with probabilistic finality in a scale of seconds, eliminating long wait times.

As of writing these lines, Kaspa has a $130.8M market cap, a $224.5M fully dilluted market cap, and $2.7M daily volume.

Wallets

Kaspa has several different self-custidy wallets developed by different community members:

• Kaspa CLI wallet
• Kaspa PWA web wallet
• KDX wallet
• Kaspium iOS and Android wallets

There are projects for adding support of Kaspa by hardware wallets such as Ledger, Tangem, and OneKey.
Finally there are custodial wallets for community memberrs to tip each other on Discord and Telegram.

There is a need to establish a standard scheme for sending Kaspa currency between all wallets.
In order to establish a standard, I propose to register a scheme in accordance with IANA URI Schema RFC 7595 as described in Section 7.2 Registration Process.

IANA URI Scheme

Application

Scheme name:
   kaspa

Status:
   Provisional

Applications/protocols that use this scheme name:
   Transfer of Kaspa coins, marked as $KAS, by Wallets that 
   implement the Kaspa protocols.

Contact:
   Registegin party: Eyal Yablonka <[email protected]>; 
   Eyal Yablonka <[email protected]>
   Scheme creator: Kaspa URI Scheme

Change controller:
    Either the registering party or someone who is verified to 
    represent the scheme creator.  See previous answer.
    E.g.: Kaspa core developers.

References:
   [1] https://github.com/kaspanet/kaspad
   [2] https://kaspawiki.net
   [3] https://discord.gg/kaspa
   [4] https://kaspa.org

Scheme syntax:
   kaspa:<bech32_address>[?[amount=<size>][&][label=<label>][&][message=<message>][&][payload=<payload_hex>]]
   Example:
   kaspa:qpqtq6r0r0v2mwm4txcd756m27lm33azq5f7epyhgl5tyjny5et854lazvrjn?amount=0.12345678&label=label&message=message&payload=1A2B3C4D5E6F


Scheme semantics:
   Send money to a Kaspa address.

Encoding considerations:
   The address is bech32 encoded.
   The payload is hex encoded.
   The labels and message are utf-8 encoded.

Interoperability considerations:
   None.

Security considerations:
   None.

Process

When pre-approved by Kaspa core developers and wallet developers, this proposal should be sent to [email protected]

Existing schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
Bitcoin scheme: https://www.iana.org/assignments/uri-schemes/prov/bitcoin
Bitcoin Cash scheme: https://www.iana.org/assignments/uri-schemes/prov/bitcoincash
Registration process: https://www.rfc-editor.org/rfc/rfc7595.html#section-7.2

The append only code should throw an error if the same key is inserted twice.
The only exception for such code is if the store has additional compact data form.

Overview

The current gRPC server in the Golang implementation operates in FIFO mode (It is my understanding that different types of responses can return out of order, but for the sake of this proposal, let's refer to this as FIFO). This processing mode currently trickles down into rusty-kaspa gRPC implementation.

Wallet instances operating on behalf of different users make multiple requests via RPC, however, if interfacing with a system that operates in a FIFO mode, requests have to be queued, which interferes with parallelism. The solution to this is to establish a dedicated connection for each user "context", however, this results in additional resource consumption in the form of open sockets. In the current JS WebSocket/gRPC proxy implementation, each WebSocket connection results in a dedicated gRPC connection, yielding 2x open sockets.

Proposal

It would be desirable to modify Kaspa gRPC protocol messages to support an id field supplied by the user during the request, carried throughout the RPC call execution, and returned with the response.

Having a dedicated id property for each request would allow a single gRPC connection to post requests on behalf of different clients and match responses with the corresponding requests. This would in turn allow a proxy server to establish a single dedicated connection to rusty-kaspa reducing the number of open sockets and also reducing the CPU load required to handle large amounts of sockets.

Adding this would also significantly simplify the gRPC Matcher that was put together by @tiram88 which would, instead of checking the request queue head and then doing a linear search through pending gRPC requests would be able to maintain a simple HashMap of requests, resolving them by id.

NOTE: This should apply strictly to gRPC .proto messages, not internal RPC message structures (they should be agnostic to RPC channels).

For backward compatibility with the Golang client, it would be ideal if the Golang implementation also supports id propagation. This would allow the Rust gRPC client to interop with Golang via a single socket channel.

Considerations

The FIFO mechanism currently used, imposes what sums up to be the processing queue for each client. This, at expense of multiple sockets, creates a per-client "pacing" mechanism. Removal of this queue requirement by introducing id-based processing can result in heavier processing bursts as this would allow wallets/clients to execute multiple requests in parallel. I don't think this is an issue, but this could result in a different CPU load patterns and should be taken into consideration.

Go over all TODOs and fix any TODO that is necessary for the official release

Blocked by #50

Rusty kaspad (possibly other executables as well) logs to stderr instead of stdout, on Linux at least.

This adds complexity when processing output using command line tools.

Reproduce:
Can easily be reproduced with: ./kaspad | grep kaspad <- all output will be shown instead of only the lines containing kaspad
However, kaspad -h actually outputs to stdout: ./kaspad --help | grep kaspad <- only one line is output.

Fix:
Correct logging facility to always do console output to stdout.

Describe the bug
If a Windows user is starting from a clean system, git for windows will not be present and when a user executes the git command to clone the repo, it will fail

To Reproduce
Steps to reproduce the behavior:
Start from a clean Windows OS, follow the Getting Started section in the readme file exactly "https://github.com/kaspanet/rusty-kaspa#getting-started" and when you try to run "git clone https://github.com/kaspanet/rusty-kaspa" it will fail.

Expected behavior

When starting from a clean install of Windows OS and following the Getting Started section in the readme file exactly "https://github.com/kaspanet/rusty-kaspa#getting-started", executing "git clone https://github.com/kaspanet/rusty-kaspa" should succeed and clone the repo to the local directory.

Perhaps adding a section after the "Install the rust toolchain" step to install "Git for Windows". This would be an ideal place to put this step, as the "Install the rust toolchain" step does allow for the automatic installation of Visual Studio. Git for Windows can be installed using the "Visual Studio Installer". Once Visual Studio is installed, simply navigate to the Windows start menu, locate the "Visual Studio Installer" and open it. Once the Visual Studio Installer menu has appeared, select "Modify". On the next menu, select the tab "Individual Components" and search for "git"

Check the check box for "Git for Windows" and install.

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Kaspad version: [e.g. 0.12.11]

Describe the bug
Syncing during a pruning point shift may result in the node not accepting blocks, idling in an endless progression of ibd header sync.

To Reproduce
Steps to reproduce the behavior:
sync a node and make sure it is in the ibd header syncing stage when a pruning point shift occurs.

Expected behavior
A node that accepts blocks from peers

Desktop (please complete the following information):
OS:

PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Kaspad:

v. 0.1.0

commit 7f26aa6cac1086e8ac5dc4ed9e1d0f12710d4c89 (HEAD -> prune, origin/prune)
Author: Michael Sutton <[email protected]>
Date:   Mon May 29 18:17:08 2023 +0000

    add lock yield logic to semaphore and rwlock

Additional context
Logs:

2023-05-30 15:11:44.192Z [INFO ] kaspad v0.1.0 is when i restarted
...
2023-05-30 15:12:03.723Z [INFO ] Validating level 225 from the pruning point proof
...
2023-05-30 15:12:34.984Z [INFO ] Validating level 0 from the pruning point proof
2023-05-30 15:12:44.285Z [INFO ] Setting d706324b72daf8aa92f008f22d5a336a58fa333ff6572f99b820e84821d8d971 as the current pruning point
2023-05-30 15:12:44.285Z [INFO ] Building the proof which was just applied (sanity test)
2023-05-30 15:12:44.653Z [INFO ] Proof was locally built successfully
2023-05-30 15:12:44.898Z [INFO ] Starting to process 2644 trusted blocks
2023-05-30 15:12:45.898Z [INFO ] Processed 2471 trusted blocks in the last 1.00s (total 2471)
2023-05-30 15:12:45.937Z [INFO ] Done processing trusted blocks
2023-05-30 15:12:54.475Z [INFO ] Processed 3 blocks and 4184 headers in the last 10.00s (6 transactions; 7387 parent references; 0 UTXO-validated blocks; 2.00 avg txs per block; 34046 avg block mass)
2023-05-30 15:12:58.605Z [INFO ] IBD: Processed 3071 block headers (1%)
...
2023-05-30 15:32:48.207Z [INFO ] IBD: Processed 271508 block headers (100%)
2023-05-30 15:32:48.517Z [INFO ] Processed 0 blocks and 1697 headers in the last 10.00s (0 transactions; 2886 parent references; 0 UTXO-validated blocks; 0.00 avg txs per block; 0 avg block mass)
2023-05-30 15:32:49.355Z [INFO ] Received 99 UTXO set chunks so far, totaling in 99000 UTXOs
...
2023-05-30 15:34:19.916Z [INFO ] Finished receiving the UTXO set. Total UTXOs: 8117830
2023-05-30 15:34:19.917Z [INFO ] Importing the UTXO set of the pruning point d706324b72daf8aa92f008f22d5a336a58fa333ff6572f99b820e84821d8d971
2023-05-30 15:34:58.818Z [INFO ] Resyncing the utxoindex...
2023-05-30 15:35:36.515Z [INFO ] Registering p2p flows for peer 49.0.240.99:45994 for protocol version 5
2023-05-30 15:35:36.515Z [INFO ] P2P Connected to incoming peer 49.0.240.99:45994
2023-05-30 15:36:01.118Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 38.242.139.17:16111
2023-05-30 15:36:04.434Z [INFO ] IBD with peer 38.242.139.17:16111 completed with error: ConnectionClosed
2023-05-30 15:36:04.813Z [INFO ] IBD started with peer 51.91.82.136:50408
2023-05-30 15:36:08.575Z [INFO ] Processed 0 blocks and 424 headers in the last 10.00s (0 transactions; 762 parent references; 0 UTXO-validated blocks; 0.00 avg txs per block; 0 avg block mass)
2023-05-30 15:36:12.375Z [INFO ] IBD: Processed 1025 block headers (74%)
2023-05-30 15:36:15.451Z [INFO ] IBD: Processed 1387 block headers (100%)
...
2023-05-30 15:38:41.209Z [INFO ] IBD: Processed 6 block headers (100%)
2023-05-30 15:38:43.077Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 77.37.202.136:16111
2023-05-30 15:38:43.078Z [INFO ] IBD with peer 77.37.202.136:16111 completed with error: ConnectionClosed
2023-05-30 15:38:43.230Z [INFO ] IBD started with peer 193.198.102.245:16111
2023-05-30 15:38:43.382Z [INFO ] IBD: Processed 1 block headers (100%)
2023-05-30 15:38:45.153Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 193.198.102.245:16111
2023-05-30 15:38:45.154Z [INFO ] IBD with peer 193.198.102.245:16111 completed with error: ConnectionClosed
2023-05-30 15:38:45.349Z [INFO ] IBD started with peer 54.39.129.199:40084
2023-05-30 15:38:45.713Z [INFO ] IBD: Processed 3 block headers (100%)

Note: Buggy Behavior is consistent when restarting the node without the --reset-db flag

An issue for gathering any possible feature wished to be implemented during the rewrite of Kaspa to Rust. This might help guiding the developers to design things in a specific way, even if the actual feature is yet to be implemented.