xelis-project / xelis-blockchain Goto Github PK

$ cargo run --bin daemon
error: no bin target named `daemon`.
Available bin targets:
    xelis_daemon
    xelis_miner
    xelis_wallet

Please correct README.md
cargo run --bin daemon
To
cargo run --bin xelis_daemon

At the time of writing, Xelis is using SHA3/Keccak for block hashes.

Since block time will be very small (blockDAG), it may be interesting to explore faster hash functions for the use in Xelis.
Especially considering Keccak is slower than SHA256. Synchronization times can be slowed down significantly by the hashing.

Some notable alternatives:

• Blake2 (especially blake2b, maybe a truncated version?)
• Blake3

Both Blake2b and Blake3 have been successfully used in mainnet in several crypto projects.

Xelis-daemon's peerlist is only saved on graceful shutdown.

This can cause loss of peers data, if the daemon is shut down abruptly, and significant load to seed nodes.

Consider saving the peerlist more frequently during the normal operation of daemon.

Perhaps moving peerlist to a safer, faster database than full JSON rewrites, which can cause corruption.

Hey all, trying to start mining on an Apple M1 laptop.
Running into this error when starting xelis_daemon:

[2024-04-20] (21:26:14.252) INFO                    xelis_daemon > XELIS Blockchain running version: 1.9.0-3c8af1a
[2024-04-20] (21:26:14.253) INFO                    xelis_daemon > ----------------------------------------------
[2024-04-20] (21:26:14.277) INFO  xelis_daemon::core::blockchain > Initializing chain...
[2024-04-20] (21:26:14.277) INFO  xelis_daemon::core::blockchain > De-serializing genesis block for network Mainnet...
Error: Error while generating pow hash

Caused by:
    Error while hashing

This is caused by running the daemon on a Mac laptop. I've successfully built the executables and created a wallet, but cannot start the daemon.

As seen on https://github.com/xelis-project/xelis-blockchain/blob/dev/xelis_common/src/block/mod.rs#L50 , Xelis seems to be using an unsigned 128-bit value for representing millisecond timestamps.

The necessity of this is dubious.
An unsigned 64-bit integer (uint64 aka u64) can store 2^64 (18446744073709551616) values.
It means that it can store 584942417 years in milliseconds.

So, I think an uint64 is more than enough for the scope of this project.

8 bytes per block, with an average of 2 blocks per second, is around 504 MB a year.

EDIT:
8 bytes per block, with an average of 1 block every 15 seconds, is around 2.1 MB a year.