deroproject/derohe

DERO Homomorphic Encryption Blockchain Protocol

Welcome to DERO

Twitter Discord GitHub Explorer Wiki Web Wallet

DERO is a blockchain with Smart Contracts preserving your privacy through multiple features while staying fast, secure, and accessible to all people easily.

DERO is running since December 2017 and was previously running on a unique implementation of CryptoNote protocol with blockDAG and as migrated to this unique version for Smart Contracts, Services, better performance, better privacy and more security.

DERO Homomorphic Encryption

What is "Homomorphic Encryption" ?

Homomorphic encryption (HE) is a form of encryption allowing one to perform calculations on encrypted data without decrypting it first. The result of the computation is in an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.

It can be used for privacy-preserving outsourced storage and computation. This allows data to be encrypted and out-sourced to commercial cloud environments for processing, all while encrypted. In highly regulated industries, such as health care, and can also be used to enable new services by removing privacy barriers inhibiting data sharing. For example, predictive analytics in health care can be hard to apply via a third party service provider due to medical data privacy concerns, but if the predictive analytics service provider can operate on encrypted data instead, these privacy concerns are diminished.

For more details of what is Homomorphic Encryption, please see Wikipedia.

Summary

• Welcome to DERO
  • DERO Homomorphic Encryption
    • What is "Homomorphic Encryption" ?
  • Summary
  • About DERO Project
    • Features
  • Transactions Sizes
  • Network Ports
    • Mainnet
    • Testnet
  • Technical
  • DERO blockchain salient features
    • Erasure Coded Blocks
    • Client Protocol
    • Proving DERO Transactions
  • DERO Installation
    • Installation From Source
    • Installation From Binary
    • Running DERO Daemon
    • DERO CLI Wallet
    • DERO Explorer

About DERO Project

DERO is running since December 2017 and was previously running on a unique implementation of CryptoNote protocol with blockDAG and as migrated to this unique version for Smart Contracts, Services, better performance, better privacy and more security.

Consensus algorithm is PoW based on AstroBWT, a ASIC/FPGA/GPU resistant CPU mining algorithm to improve decentralization and lower the barrier of joining the network.

DERO is industry leading and the first blockchain to have Homomorphic Encryption, bulletproofs and a fully TLS encrypted network.

The fully distributed ledger processes transactions with a 16s (sixty-seconds) average block time and is secure against majority hashrate attacks.

DERO is the first Homomorphic Encryption based blockchain to have Smart Contracts contracts on its native chain without any extra layers or secondary blockchains.

At present DERO has implemented Smart Contracts for previous mainnet implementation running on CryptoNote protocol which can be found here.

Features

• Homomorphic account based model Check blockchain/transaction_execute.go line 82-95

• Instant account balances It need only 66 bytes of data from the blockchain.

• DAG/MINIDAG with 1 miniblock every second NOTE: This as been replaced by a mini block system. Each block has 10 mini blocks to rewards up to 10 differents miners at the same time for each block, by splitting the difficulty and the result of the final block.

• Mining Decentralization No more mining pools needed, with a daily ~54000 mini blocks. Solo Mining is much more available than any others blockchains.

• Erasure coded blocks Worlds first Erasure Coded Propagation protocol, which allows 100x block size without increasing propagation delays, lower bandwidth requirements and provide very low propagation time.

• Light weight and efficient wallets No more chain scanning or wallet scanning the whole chain to detect funds, no key images. By connecting to a synchronized node, you will retrieve your available funds in few seconds.

• Small disk cost for blockchain account Fixed per account cost of 66 bytes in blockchain only which allow a immense scalability.

• Anonymous Transactions Provide completely anonymous transactions and deniability thanks to Many-Out-Of-Many Proofs using Bulletproofs and Sigma Protocol, nobody except you and the receiver account will know the real parties of the transaction.

• Fixed Transaction Size Only ~2.5KB for a transaction using ring size set to 8, or ~3.4 KB with ring size set to 16. Transactions size have a logarithm growth based on the anonymity set and must be chosen in powers of 2.

• Homomorphic Assets programmable Smart Contracts with fixed overhead per asset. Your Smart Contract is open source but its data related to balances are completely encrypted like the native coin.

• Pruning Blockchain Allows chain pruning on daemons to control growth of data on daemons and keep a low disk usage. This allows immense scability as you can reduce a blockchain of few hundred GBs to only few GBs while still being secure using merkle proofs.
  Example: disk requirements of 1 billion accounts (assumming it does not want to keep history of transactions, but keeps proofs to prove that the node is in sync with all other nodes)
  Requirement of 1 account is only 66 bytes Assumming storage overhead per account of 128 bytes (which is constant) Total requirements = (66 + 128)GB ~ 200GB Assuming we are off by factor of 4, its only 800GB.
  Note that, Even after 1 trillion transactions, 1 billion accounts will consume 800GB only, If history is not maintained, and everything still will be in proved state using merkle roots. And so, Even Raspberry Pi can host the entire chain.

• Low Transaction Generation Time Generating a transaction takes less than 25 ms.

• Low Transaction Verification Time Transaction verification takes even less than 25ms.

• No trusted setup, no hidden parameters Everything is open-source, available, to anyone to provide trustless and fully decentralized blockchain.

• Provability Senders of a transaction can prove to receivers what amount they have send without revealing themselves.

Transactions Sizes

Ring Size	Transaction Size (in bytes)
2	1553
4	2013
8	2605
16	3461
32	4825
64	7285
128	11839
512	~35000

NOTE: Plan to reduce TX sizes further.

Network Ports

Mainnet

• P2P Default Port: 10101
• RPC Default Port: 10102
• Wallet RPC Default Port: 10103

Testnet

• P2P Default Port: 40401
• RPC Default Port: 40402
• Wallet RPC Default Port: 40403

Technical

For specific details of current DERO core (daemon) implementation and capabilities, see below:

• DAG: No orphan blocks, No soft-forks. NOTE: This feature has been disabled for mainnet to reduce load for small devices.

• BulletProofs: Non Interactive Zero-Knowledge Range-Proofs (NIZK)

• AstroBWT: This is memory-bound algorithm. This provides assurance that all miners are equal. ( No miner has any advantage over common miners).

• P2P Protocol: This layers controls exchange of blocks, transactions and blockchain itself.

• Pederson Commitment: (Part of ring confidential transactions): Pederson commitment algorithm is a cryptographic primitive that allows user to commit to a chosen value while keeping it hidden to others. Pederson commitment is used to hide all amounts without revealing the actual amount. It is a homomorphic commitment scheme.

• Homomorphic Encryption: Homomorphic Encryption is used to to do operations such as addition/substraction to settle balances with data being always encrypted (Balances are never decrypted before/during/after operations in any form.).

• Homomorphic Ring Confidential Transactions: Gives untraceability, privacy and fungibility while making sure that the system is stable and secure.

• Core-Consensus Protocol implemented: Consensus protocol serves 2 major purpose:

  • Protects the system from adversaries and protects it from forking and tampering.
  • Next block in the chain is the one and only correct version of truth (balances).

• Proof-of-Work(PoW) algorithm: PoW part of core consensus protocol which is used to cryptographically prove that X amount of work has been done to successfully find a block.

• Difficulty algorithm: Difficulty algorithm controls the system so as blocks are found roughly at the same speed, irrespective of the number and amount of mining power deployed.

• Serialization/De-serialization of blocks: Capability to encode/decode/process blocks.

• Serialization/De-serialization of transactions: Capability to encode/decode/process transactions.

• Transaction validity and verification: Any transactions flowing within the DERO network are validated, verified.

• Socks proxy: Socks proxy has been implemented and integrated within the daemon to decrease user identifiability and improve user anonymity.

• Interactive daemon: can print blocks, txs, even entire blockchain from within the daemon

  • version, peer_list status, diff, print_bc, print_block, print_tx and several other commands implemented

• Networks: DERO Daemon has both mainnet and testnet support.

• Enhanced Reliability, Privacy, Security, Useability, Portabilty assured.

DERO blockchain salient features

• 16 Second Block time.
• Extremely fast transactions with one minute/block confirmation time.
• SSL/TLS P2P Network.
• Homomorphic: Fully Encrypted Blockchain
• Ring signatures.
• Fully Auditable Supply.
• DERO blockchain is written from scratch in Golang.
• Developed and maintained by original developers.

Erasure Coded Blocks

Traditional Blockchains process blocks as single unit of computation(if a double-spend tx occurs within the block, entire block is rejected). As soon as a block is found, it is sent to all its peers.DERO blockchain erasure codes the block into 48 chunks, dispersing and chunks are dispersed to peers randomly.Any peer receiving any 16 chunks( from 48 chunks) can regerate the block and thus lower overheads and lower propagation time.

Client Protocol

Traditional Blockchains process blocks as single unit of computation(if a double-spend tx occurs within the block, entire block is rejected). However DERO network accepts such blocks since DERO blockchain considers transaction as a single unit of computation.DERO blocks may contain duplicate or double-spend transactions which are filtered by client protocol and ignored by the network. DERO DAG processes transactions atomically one transaction at a time.

Proving DERO Transactions

DERO blockchain is completely private, so anyone cannot view, confirm, verify any other's wallet balance or any transactions.

So to prove any transaction you require TXID and deroproof. deroproof can be obtained using get_tx_key command in dero-wallet-cli.

Enter the TXID and deroproof in DERO Explorer

DERO Installation

DERO is written in golang and very easy to install both from source and binary.

Installation From Source

First you need to install Golang if not already, minimum version required for Golang is 1.17.

In go workspace, execute: go get -u github.com/deroproject/derohe/...

When the command has finished, check go workspace bin folder for binaries. For example, on Linux machine the following binaries will be created:

• derod-linux-amd64: DERO Daemon
• dero-wallet-cli-linux-amd64: DERO CLI Wallet
• explorer-linux-amd64: DERO Explorer (Yes, DERO has prebuilt personal explorer also for advance privacy users)

Installation From Binary

Download DERO binaries for ARM, INTEL, MAC platform and Windows, Mac, FreeBSD, OpenBSD, Linux (or any others availables platforms) operating systems.

Running DERO Daemon

Run derod.exe or derod-linux-amd64 depending on your operating system. It will start syncing.

• DERO daemon core cryptography is highly optimized and fast.
• Use dedicated machine and SSD for best results.
• VPS with 2-4 Cores, 4GB RAM,15GB disk is recommended.

DERO CLI Wallet

DERO cmdline wallet is menu based and very easy to operate.

Use various options to create, recover, transfer balance etc.

NOTE: DERO cmdline wallet by default connects DERO daemon running on local machine on port 20206.

If DERO daemon is not running start DERO wallet with --remote option like following:

./dero-wallet-cli-linux-amd64 --remote

DERO Explorer

DERO Explorer is used to check and confirm transaction on DERO Network.

DERO users can run their own explorer on local machine and can browse on local machine port 8080.

derohe's Issues

Support for new Apple M1 ARM architecture

The Derod miner executables do not work on the Apple M1 architecture. It throws a seg fault.

Block Rewards is missing

01/03 13:59:53 INFO CORE will use {"integrator_address": "dero1qyt2dmhwn44murc84nsrfyvj74tccnqgej24fua6zwwnaaluk33n5qgkx9r8z"}

--integrator-address

if this node mines a block,Integrator rewards will be given to address.default is dev's address.

Integrator address not working. I mined more than 70 block and I tried every option. What's the problem? Why dev address is default and why we should find from --help? Is premine not enough? Is it so hard to print from danger integrator address is default address?

RPC methods do not properly handle / validate invalid inputs

Summary

Both Wallet and Daemon RPC interfaces seem to lack proper input validation. I tried a few broken JSON inputs and it gives either 500 Server Error, or 200 OK with a stacktrace in the body. Neither should be expected but rather give some suitable error code such as 400 Bad Request with some details on error if available.

Following are just a few quick examples I tried, I expect all methods and inputs should be checked.

Daemon RPC Examples

Examples for daemon RPC (listening on localhost:9999):

missing parameters:

curl -v -X POST http://localhost:9999/json_rpc -d '{"jsonrpc": "2.0", "id":"0", "method": "getgasestimate"}' -H 'content-type: application/json'

* Connected to localhost (127.0.0.1) port 9999 (#0)
> POST /json_rpc HTTP/1.1
> Host: localhost:9999
> User-Agent: curl/7.68.0
> Accept: */*
> content-type: application/json
> Content-Length: 56
> 
* upload completely sent off: 56 out of 56 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 2179
< Content-Type: application/json
< Date: Sun, 30 Jan 2022 22:08:07 GMT
< 

{"jsonrpc":"2.0","id":"0","error":{"code":-32098,"message":"panic occured. stack trace r interface conversion: interface {} is nil, not uint64 goroutine 12820 [running]:\nruntime/debug.Stack()\n\t/snap/go/9028/src/runtime/debug/stack.go:24 +0x65\ngithub.com/deroproject/derohe/cmd/derod/rpc.GetGasEstimate.func1()\n\t/root/derohe/cmd/derod/rpc/rpc_dero_estimategas.go:42 +0x45\npanic({0x9c34c0, 0xc001f77ef0})\n\t/snap/go/9028/src/runtime/panic.go:1038 +0x215\ngithub.com/deroproject/derohe/dvm.(*Simulator).RunSC(0xc001f77e60, 0x3736, {0x0, 0x0, 0x0}, 0x34f2, 0xc00353fe17)\n\t/root/derohe/dvm/simulator.go:126 +0x758\ngithub.com/deroproject/derohe/cmd/derod/rpc.GetGasEstimate({0xc0000b35d0, 0x465b0d}, {{0x0, 0x0, 0x0}, {0x0, 0x0}, 0x0, {0x0, 0x0}, ...})\n\t/root/derohe/cmd/derod/rpc/rpc_dero_estimategas.go:79 +0x44b\nreflect.Value.call({0x9b5b20, 0xada180, 0xc0002ded18}, {0xa52249, 0x4}, {0xc001f77dd0, 0x2, 0xc00253ad28})\n\t/snap/go/9028/src/reflect/value.go:556 +0x845\nreflect.Value.Call({0x9b5b20, 0xada180, 0xc001f77da0}, {0xc001f77dd0, 0x2, 0x2})\n\t/snap/go/9028/src/reflect/value.go:339 +0xc5\ngithub.com/creachadair/jrpc2/handler.(*FuncInfo).Wrap.func10({0xb85840, 0xc001f77da0}, 0xf3d270)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/handler/handler.go:233 +0xed\ngithub.com/creachadair/jrpc2/handler.Func.Handle(0xf3d270, {0xb85840, 0xc001f77da0}, 0x1)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/handler/handler.go:24 +0x2f\ngithub.com/creachadair/jrpc2.(*Server).invoke(0xc0003ec000, {0xb85798, 0xc002dec700}, {0xb78f20, 0xc00037f420}, 0xc002dec6c0)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:350 +0x17e\ngithub.com/creachadair/jrpc2.(*Server).dispatch.func1.1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:229 +0xbe\ngithub.com/creachadair/jrpc2.(*Server).dispatch.func1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:234 +0x17d\ngithub.com/creachadair/jrpc2.(*Server).serve.func1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:155 +0x5a\nc* Connection #0 to host localhost left intact
reated by github.com/creachadair/jrpc2.(*Server).serve\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:153 +0x29\n"}}

extra curly brace:
curl -v -X POST http://localhost:9999/json_rpc -d '{"jsonrpc": "2.0", "id":"0", "method": "getheight"}}' -H 'content-type: application/json'

* Connected to localhost (127.0.0.1) port 9999 (#0)
> POST /json_rpc HTTP/1.1
> Host: localhost:9999
> User-Agent: curl/7.68.0
> Accept: */*
> content-type: application/json
> Content-Length: 52
> 
* upload completely sent off: 52 out of 52 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Sun, 30 Jan 2022 22:06:54 GMT
< Content-Length: 31
< Content-Type: text/plain; charset=utf-8
< 
[-32700] invalid request value

Wallet RPC Examples

Examples for Wallet RPC (listening on localhost:40003):

Missing parameters / parameters in wrong place:

curl -v -X POST http://localhost:40003/json_rpc -d '{"jsonrpc": "2.0", "id":"0", "method": "transfer", "params": {"burn": 0, "amount": 100, "destination": "deto1qy0qygek8vm9qumxmttxv2us3ztrpd0nt5f3ejzreq2y3ep8m602cqg774elx"}' -H 'content-type: application/json'

* Connected to localhost (127.0.0.1) port 40003 (#0)
> POST /json_rpc HTTP/1.1
> Host: localhost:40003
> User-Agent: curl/7.68.0
> Accept: */*
> content-type: application/json
> Content-Length: 172
> 
* upload completely sent off: 172 out of 172 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Sun, 30 Jan 2022 22:18:32 GMT
< Content-Length: 31
< Content-Type: text/plain; charset=utf-8
< 
[-32700] invalid request value

Extra curly:

curl -v -X POST http://localhost:30003/json_rpc -d '{"jsonrpc": "2.0", "id":"0", "method": "transfer", "params": {"burn": 0, "amount": 100, "destination": "deto1qy0qygek8vm9qumxmttxv2us3ztrpd0nt5f3ejzreq2y3ep8m602cqg774elx"}}' -H 'content-type: application/json'

* Connected to localhost (127.0.0.1) port 40003 (#0)
> POST /json_rpc HTTP/1.1
> Host: localhost:40003
> User-Agent: curl/7.68.0
> Accept: */*
> content-type: application/json
> Content-Length: 173
> 
* upload completely sent off: 173 out of 173 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 2157
< Content-Type: application/json
< Date: Sun, 30 Jan 2022 22:16:50 GMT
< 
{"jsonrpc":"2.0","id":"0","error":{"code":-32098,"message":"panic occured. stack trace goroutine 47 [running]:\nruntime/debug.Stack()\n\t/snap/go/9028/src/runtime/debug/stack.go:24 +0x65\ngithub.com/deroproject/derohe/walletapi/rpcserver.Transfer.func1()\n\t/root/derohe/walletapi/rpcserver/rpc_transfer.go:36 +0x35\npanic({0x7cf900, 0xc000364360})\n\t/snap/go/9028/src/runtime/panic.go:1038 +0x215\ngithub.com/deroproject/derohe/walletapi.(*Wallet_Memory).TransferPayload0(0xc0003f0000, {0x0, 0x0, 0x0}, 0x0, 0x0, {0x0, 0x2, 0x0}, 0x0, ...)\n\t/root/derohe/walletapi/wallet_transfer.go:233 +0x30e5\ngithub.com/deroproject/derohe/walletapi/rpcserver.Transfer({0x8ae060, 0xc0004d7560}, {{0x0, 0x0, 0x0}, {0x0, 0x0}, 0x0, {0x0, 0x0}, ...})\n\t/root/derohe/walletapi/rpcserver/rpc_transfer.go:69 +0x7b7\nreflect.Value.call({0x7924e0, 0x830ce8, 0xc00023fd18}, {0x7f2c84, 0x4}, {0xc0004d7830, 0x2, 0xc0003e0528})\n\t/snap/go/9028/src/reflect/value.go:556 +0x845\nreflect.Value.Call({0x7924e0, 0x830ce8, 0xc0004d7560}, {0xc0004d7830, 0x2, 0x2})\n\t/snap/go/9028/src/reflect/value.go:339 +0xc5\ngithub.com/creachadair/jrpc2/handler.(*FuncInfo).Wrap.func10({0x8ae060, 0xc0004d7560}, 0xb771e0)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/handler/handler.go:233 +0xed\ngithub.com/creachadair/jrpc2/handler.Func.Handle(0xb771e0, {0x8ae060, 0xc0004d7560}, 0x1)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/handler/handler.go:24 +0x2f\ngithub.com/creachadair/jrpc2.(*Server).invoke(0xc0000de000, {0x8adfb8, 0xc000065440}, {0x8a5ea0, 0xc00036a480}, 0xc000065400)\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:350 +0x17e\ngithub.com/creachadair/jrpc2.(*Server).dispatch.func1.1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:229 +0xbe\ngithub.com/creachadair/jrpc2.(*Server).dispatch.func1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:234 +0x17d\ngithub.com/creachadair/jrpc2.(*Server).serve.func1()\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:155 +0x5a\ncreated by github.com/c* Connection #0 to host localhost left intact
reachadair/jrpc2.(*Server).serve\n\t/root/derohe/vendor/github.com/creachadair/jrpc2/server.go:153 +0x29\n"}}

error own daemon with mining.

API Suggestions

RPC API:

• instead of returning the stacktrace in the error message, why not return the missing fields ?
• DERO.GetBlock return this:

{
    "jsonrpc": "2.0",
    "id": "1",
    "result": {
        "blob": "01010000017e9e872cb1a403010000021f9bcc1208dee302769931ad378a4c0c4b2c21b0cfb3e752607e12d2b6fa6425000000000000000000000000000000000000000000000000000000000000000000016a6856b51e9ffd5b07c6c33ca635d984910f3b7fbbaaaebbb61a99780629e4490a41ee3400000001a46a6856b500000000eec07ce3efc1425bc0ad7e8c72d13b0500000000940d24de2854e800a2da520141f38100000001a46a6856b500000000c3443540c243d11f706b6836d516a95500000000d0bd228895e3da00ef774a0441f49600000001a46a6856b500000000eec07ce3efc1425bc0ad7e8c72d13b050000000064bdff4901054101003a190041fdd400000001a46a6856b500000000eec07ce3efc1425bc0ad7e8c72d13b05000000000cf2b45163efe300a2efe6014105a100000001a46a6856b500000000c3443540c243d11f706b6836d516a95500000000e57c84673a12fe00ef9e52044105ca00000001a46a6856b500000000eec07ce3efc1425bc0ad7e8c72d13b0500000000acb0839b3a13a400a2f8010141082a00000001a46a6856b500000000c3443540c243d11f706b6836d516a955000000006d01841f72304000efa43e0441086d00000001a46a6856b500000000c3443540c243d11f706b6836d516a955000000003fd27e20d1ab8800efca2901410d7200000001a46a6856b500000000c3443540c243d11f706b6836d516a955000000000b1fb80d5442e400a29c8e02712cb100000001a46a6856b500000000a063e24bc973c78fd057fec97cacd720000000006bb830fa72959300eff8080400",
        "json": "{\"major_version\":1,\"minor_version\":1,\"timestamp\":1643337166001,\"height\":420,\"miner_tx\":{\"version\":1,\"source_network\":0,\"dest_network\":0,\"txtype\":2,\"value\":0,\"miner_address\":[31,155,204,18,8,222,227,2,118,153,49,173,55,138,76,12,75,44,33,176,207,179,231,82,96,126,18,210,182,250,100,37,0],\"c\":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],\"s\":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],\"height\":0,\"blid\":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],\"scdata\":null,\"Payloads\":null},\"tips\":[\"6a6856b51e9ffd5b07c6c33ca635d984910f3b7fbbaaaebbb61a99780629e449\"],\"miniblocks\":[{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":60980,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"eec07ce3efc1425bc0ad7e8c72d13b0500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[2483889374,676653056,2732216833]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":62337,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"c3443540c243d11f706b6836d516a95500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[3502056072,2514737664,4017572356]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":62614,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"eec07ce3efc1425bc0ad7e8c72d13b0500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[1690173257,17121537,3807488]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":64980,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"eec07ce3efc1425bc0ad7e8c72d13b0500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[217232465,1676665600,2733630977]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":1441,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"c3443540c243d11f706b6836d516a95500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[3850142823,974323200,4020130308]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":1482,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"eec07ce3efc1425bc0ad7e8c72d13b0500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[2897249179,974365696,2734162177]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":2090,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"c3443540c243d11f706b6836d516a95500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[1828815903,1915764736,4020518404]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":2157,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"c3443540c243d11f706b6836d516a95500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[1070759456,3517679616,4023003393]},{\"Version\":1,\"HighDiff\":false,\"Final\":false,\"PastCount\":1,\"Timestamp\":3442,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"c3443540c243d11f706b6836d516a95500000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[186628109,1413669888,2728168962]},{\"Version\":1,\"HighDiff\":true,\"Final\":true,\"PastCount\":1,\"Timestamp\":11441,\"Height\":420,\"Past\":[1785222837,0],\"KeyHash\":\"a063e24bc973c78fd057fec97cacd72000000000000000000000000000000000\",\"Flags\":0,\"Nonce\":[1807233274,1922405120,4026009604]}],\"tx_hashes\":null}",
        "block_header": {
            "depth": 35589,
            "difficulty": "15743",
            "hash": "60e7e9f73a4a0f2c1b4a97976150ef6f53f0253f8552c6b2e7e4a010929d8259",
            "height": 420,
            "topoheight": 420,
            "major_version": 1,
            "minor_version": 1,
            "nonce": 0,
            "orphan_status": false,
            "syncblock": true,
            "sideblock": false,
            "txcount": 0,
            "reward": 0,
            "tips": [
                "6a6856b51e9ffd5b07c6c33ca635d984910f3b7fbbaaaebbb61a99780629e449"
            ],
            "timestamp": 1643337166001
        },
        "status": "OK"
    }
}

returns the "json" field as a valid json, and not as a string that contains the json.

• DERO.GetTxPool: doesn't include TX registration, if possible to add all TXs from regpool also.
• DERO.SendRawTransaction: returns the TX Hash of this TX.
• GetTransaction_Params have a "Decode" field that is not used/useless.
• suggestion for walletapi Transfer`function: if no SCID provided, set the DERO one by default.

Can't call a SC function from another SC

The docs
Function name should be alpha-numeric. If the first letter of the function is Upper case alphabet, it can be invoked by blockchain and other smart-contracts. Otherwise the function can only be called by other functions within the smart contract.

From what I understand it is not implemented yet.

STARGATE TESTNET issues.

Please discuss StarGate testnet issues here.

Issues releated DERO HE Stargate Testnet Release 16

Please use this thread to report the issues for Testnet Release 16 issues.
All previous issues are closed.

derod arm7 not syncing mainnet locally

I can successfully run derod-linux-amd64 with connected peers and the mainnet folder populating over time (see 635/635 below):

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 21.04"

$ ./derod-linux-amd64
derod   DERO HE daemon :  It is an alpha version, use it for testing/evaluations purpose only.
derod   Copyright 2017-2021 DERO Project. All rights reserved.
derod           {"OS": "linux", "ARCH": "amd64", "GOMAXPROCS": 4}
derod           {"Version": "3.4.141-66.DEROHE.STARGATE+26022022"}
derod           {"MODE": "mainnet"}
derod           {"Daemon data directory": "/home/example/dero_linux_amd64/mainnet"}
CORE    Initialized     {"path": "/home/example/dero_linux_amd64/mainnet"}
CORE    will use        {"integrator_address": "dero1qykyta6ntpd27nl0yq4xtzaf4ls6p5e9pqu0k2x4x3pqq5xavjsdxqgny8270"}
MEMPOOL Mempool started
REGPOOL Regpool started
P2P     P2P is in turbo mode
P2P     P2P started
RPC     RPC/Websocket server started
RPC     RPC will listen {"address": "127.0.0.1:10102"}
GETWORK GETWORK will listen     {"address": "0.0.0.0:10100"}
P2P     P2P is listening        {"address": "[::]:51145"}
GETWORK Job will be dispatched every    {"time": "500ms"}
RPC     GETWORK/Websocket server started
DERO HE: 635/635 [209001/209001] P 8 TXp 0:0 NW 1.318 MH/s >Miners 0  MAINNET 0 0s|0s|-7ms>>

However, derod-linux-arm7 does not appear to be working. Here's an example ARM device on the same network as above (note the 0/0):

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Debian GNU/Linux 10 (buster)"

$ ./derod-linux-arm7
derod   DERO HE daemon :  It is an alpha version, use it for testing/evaluations purpose only.
derod   Copyright 2017-2021 DERO Project. All rights reserved.
derod           {"OS": "linux", "ARCH": "arm", "GOMAXPROCS": 4}
derod           {"Version": "3.4.141-66.DEROHE.STARGATE+26022022"}
derod           {"MODE": "mainnet"}
derod           {"Daemon data directory": "/root/example/mainnet"}
CORE    Initialized     {"path": "/root/example/mainnet"}
CORE    will use        {"integrator_address": "dero1qykyta6ntpd27nl0yq4xtzaf4ls6p5e9pqu0k2x4x3pqq5xavjsdxqgny8270"}
MEMPOOL Mempool started
REGPOOL Regpool started
CORE    Genesis block not in store, add it now
P2P     P2P is in turbo mode
P2P     P2P started
RPC     RPC/Websocket server started
RPC     RPC will listen {"address": "127.0.0.1:10102"}
GETWORK GETWORK will listen     {"address": "0.0.0.0:10100"}
P2P     P2P is listening        {"address": "[::]:58955"}
GETWORK Job will be dispatched every    {"time": "500ms"}
RPC     GETWORK/Websocket server started
DERO HE: 0/0 [208959/208959] P 23 TXp 0:0 NW 10.000 MH/s >Miners 0  MAINNET 0 0s|0s|0s>>

And here's another ARM example from a cloud instance (note the 0/0):

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04"

$ ./derod-linux-arm7
derod   DERO HE daemon :  It is an alpha version, use it for testing/evaluations purpose only.
derod   Copyright 2017-2021 DERO Project. All rights reserved.
derod           {"OS": "linux", "ARCH": "arm", "GOMAXPROCS": 4}
derod           {"Version": "3.4.141-66.DEROHE.STARGATE+26022022"}
derod           {"MODE": "mainnet"}
derod           {"Daemon data directory": "/opt/dero/mainnet"}
CORE    Initialized     {"path": "/opt/dero/mainnet"}
CORE    will use        {"integrator_address": "dero1qykyta6ntpd27nl0yq4xtzaf4ls6p5e9pqu0k2x4x3pqq5xavjsdxqgny8270"}
MEMPOOL Mempool started
REGPOOL Regpool started
P2P     P2P is in turbo mode
P2P     P2P started
RPC     RPC/Websocket server started
RPC     RPC will listen {"address": "127.0.0.1:10102"}
GETWORK GETWORK will listen     {"address": "0.0.0.0:10100"}
P2P     P2P is listening        {"address": "[::]:35431"}
RPC     GETWORK/Websocket server started
GETWORK Job will be dispatched every    {"time": "500ms"}
DERO HE: 0/0 [209031/209031] P 7 TXp 0:0 NW 10.000 MH/s >Miners 0  MAINNET 0 0s|0s|0s>>

Firewalls were all disabled.

Thoughts?

Vulnerability i fount in the test net || Tynorn

Is there any tips for the genuine Vulnerability

what is hardfork.md

21400 hardfork
what is mean?
@CaptainDero

Vulnerability Findings

Please find the vulnerability finding as attachment and promote me like vulnerability testers
if u are interest me like testers please promote
My dero address : dERoaGTABmXUFqNCLMDtxAeF6kTgVnYpwjnZqSDKr72wA8nkaji2M9e1zyogd8pFYtX4bZKeybEvfP2y82heRKpW5GeRpNBc6K
derosecuritybug.pdf

STUCK AT BLOCK 29012/29012 block rejected by chain error

why am I stuck at this block height and when I run derod the node shows me that a block was rejected by chain
DERO HE: 29012/29012 [144875/144875] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144875/144875] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144875/144875] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144875/144875] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:17 ERROR CORE.blid_e842d3678c48632cf0598bc53ddbd026b0268beaf82d462790591400e94ad569 tx verification failed {"txid": "1eb36aecb6ae0fbbaa59742ab0a92e3aa8428332b23011dbcd7ceea9a0388f90", "error": "Tx statement roothash mismatch ref blid bd654a98035e66bb1e8ab937682c3a5e484dba356e0aa07b7ca5ea1a939345ba expected 3cad11f170e6f31d06a62c1fad272d66b07606e9885539c66c96d083d6b38cbc actual f1e41c2f7aa2c433b3338a1415f9976148d06cdc85abe7b8138af50cad45750e"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:17 ERROR CORE.blid_e842d3678c48632cf0598bc53ddbd026b0268beaf82d462790591400e94ad569 rejecting block {"error": "TX verification failed"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:17 ERROR CORE Block rejected by chain {"BLID": "e842d3678c48632cf0598bc53ddbd026b0268beaf82d462790591400e94ad569", "error": "Invalid TX"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:17 ERROR CORE Block rejected by chain {"BLID": "c2cd74454c6cca6383b4b62e05eecc865482c16c8a563b0d5802b6dbd4babc5e", "error": "Past blocks are missing"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:18 ERROR CORE Block rejected by chain {"BLID": "bb1a98192269714c178c966325d20f55105c2294c598fefbaa40294aa76ea97c", "error": "Past blocks are missing"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine29/03 22:05:18 ERROR CORE Block rejected by chain {"BLID": "6da06e3b282259407cca20844e11f2613e8a1328d5d84563997d62546f39373b", "error": "Past blocks are missing"}
DERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >MineDERO HE: 29012/29012 [144876/144876] P 3 TXp 0:0 NW 773.546 MH/s >Mine

Reporting the hash total of all miners on the connected daemon.

All miners connected on the derod daemon. It should be reported to Derod. derod total these hashes

">miners derodrpc.CountMiners()"

derohe/cmd/derod/main.go

Line 328 in 63f1884

l.SetPrompt(fmt.Sprintf("\033[1m\033[32mDERO HE: \033[0m"+color+"%d/%d [%d/%d] "+pcolor+"P %d TXp %d:%d \033[32mNW %s >Miners %d %s>>\033[0m ", our_height, topo_height, best_height, best_topo_height, peer_count, mempool_tx_count, regpool_tx_count, hash_rate_string, derodrpc.CountMiners(), testnet_string))

It would be good to report it in the next column.

example: assuming I have (N) miners. Collecting the total hash rate manually is very cumbersome.

x86

any support x86

stuck 2040/2102

testnet.zip
windows 10 x64

Feature Request: DVM Helper Functions (namehash, string length)

I am thinking through a smart contract where names can be registered (similar to ENS). A couple helper functions I think would be nice:

• NAMEHASH(string) or similar hashing function (https://docs.ens.domains/contract-api-reference/name-processing)
• LENGTH(string) or similar function (for tiered pricing based on length)

cannot find module providing package etcd.io/bbolt

Error in Linux when compiling from source.

go get -u github.com/deroproject/derohe/...
github.com/deroproject/derohe/cmd/rpc_examples/pong_server imports
etcd.io/bbolt: cannot find module providing package etcd.io/bbolt

If adding

go mod edit -replace github.com/deroproject/derohe/cmd/rpc_examples/pong_server=github.com/deroproject/derohe/cmd/rpc_examples/pong_server Release50

then

go get -u github.com/deroproject/derohe/...
go: errors parsing go.mod:
./dero/derohe-Release50/go.mod:5: replace github.com/deroproject/derohe/cmd/rpc_examples/pong_server/pong_server.go: version "v0.0.0-20220318155233-63f1884e1caa" invalid: missing github.com/deroproject/derohe/cmd/rpc_examples/pong_server/pong_server.go/go.mod at revision 63f1884

Already compiled executables release 50 run smoothly though.

DVM BLOCK_TIMESTAMP() is in milliseconds when using the simulator

Here its using unix seconds bl_current.Timestamp/1000

derohe/blockchain/blockchain.go

Line 948 in b660adf

tx_fees, err = chain.process_transaction_sc(sc_change_cache, ss, bl_current.Height, uint64(current_topo_block), bl_current.Timestamp/1000, bl_current_hash, tx, balance_tree, sc_meta)

On the simulator its using milliseconds time.Now().UnixMilli()

derohe/dvm/simulator.go

Line 155 in b660adf

gascompute, gasstorage, err = s.common(w_sc_tree, w_sc_data_tree, scid, s.height, s.height, uint64(time.Now().UnixMilli()), blid, scid, sc, entrypoint, 1, balance, signer_addr, incoming_values, SCDATA, fees, true)

Cannot import packages from derohe into an external project because of Graviton module error

Version: DERO-HE STARGATE Testnet Release36

I'll try and make this issue as reproducible as I can using a practical example.

Let's say I want to build a little test service for Dero using Golang. As shown in the pong_server example, I may need to import some packages like github.com/deroproject/derohe/rpc, github.com/deroproject/derohe/walletapi, github.com/deroproject/derohe/transaction, etc.

So I go ahead, create my test_service dir inside my ~/Projects dir, cd into it and create a dummy file main.go:

package main

import (
	"fmt"

	"github.com/deroproject/derohe/rpc"
)

func main() {
	fmt.Println(rpc.RPC_COMMENT)
}

I now initialize my module:
go mod init test_service
go mod tidy
And try to build it
go build
but here's where I get the error:

# github.com/deroproject/derohe/cryptography/crypto
../../go/pkg/mod/github.com/deroproject/[email protected]/cryptography/crypto/protocol_structures.go:65:18: undefined: graviton.Sum

I understand this is caused by the fact that graviton.Sum is, indeed, undefined in the official Graviton library, whereas it is defined in the special.go file of the vendorized Graviton library that derohe uses internally. Therefore, there is a mismatch between the library that go mod tidy fetches from GitHub, and the internal library that derohe uses.

So I try and run go mod vendor and then go build again, but this only causes a difference in the path where the error occurs:

# github.com/deroproject/derohe/cryptography/crypto
vendor/github.com/deroproject/derohe/cryptography/crypto/protocol_structures.go:65:18: undefined: graviton.Sum

Now, this issue is bypassable by replacing the contents of ~/Projects/test_service/vendor/github.com/deroproject/graviton with the manually downloaded ones from https://github.com/deroproject/derohe/blob/main/vendor/github.com/deroproject/graviton, which include the special.go file and, therefore, the wanted graviton.Sum function. Now my build doesn't fail and I get my working test_service binary.

But this is just a hack, useful to keep my work going, but still an inelegant hack.
That's why I think it needs a real solution, that will also help other developers not get stuck with the same problem without knowing what to do.
I don't know what the best fix is, maybe updating the official Graviton repo, maybe something else, but, as minor as the issue is, the devs should look into it.

Note: this issue doesn't present itself with the pong_server example only because that's built from within the derohe project, so it knows what's the right graviton library to use.

feat: `getsc` api call with prefix, limit & cursor

I'm strugling on how to scale a dapp/sc.
If I have a function that is called by a lot of users and everytime it stores the signer + a bunch of metadata. After a while, the getsc is going to return a huge amount of data that I have to process on the client side.

I propose a prefix with cursor and limit params.

With this data (100000 records)
user_1_firstname roger
user_1_lastname moore
user_2_firstname anna
user_2_lastname bing
...

Calling getsc with params -> { "scid": "", "code": false, "variables": false, "prefix": "user_1_", "limit": 10 }
would return result -> { "stringkeys": { "user_1_firstname": "roger", "user_1_lastname": "moore", "cursor": "2u34fn502845bfg34058gb34058gb304586y" } }

No idea if this can be implement with the Graviton DB.

Dero wallet continues to show 0 as a balance

New version does not let me import wallet.db coins.

I tried using "Wallet Seed" and I get nothing and no coins population from previous wallet.db.

Regardless of how many times I rescan my blockchain my Dero balance comes up as 0.

I realize that Dero is using a different wallet but this shouldn't be that difficult to get your coins over to the new wallet.

I have been at this for days and still a 0 balance.

What do you suggest?

DERO:>>> panic: Invalid Major Version in Block

Why after ver 78 I have that error. not in 1 Node I have it in 2...

DeroHe Testnet issues.

Please log all DeroHe Testnet issues/bugs here with screenshot and as much info as possible.

derod crash

INFO[0000] OS:darwin ARCH:amd64 GOMAXPROCS:32
INFO[0000] Version v3.2.15-1.DEROHE.STARGATE+08082021

While running derod-darwin-amd64 the following was observed. A simple restart continued successfully.

DEBU[29241] We need to resync with the peer height 14641 DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29241] Reloaded Chain Tips map[6ceb427fd3ccde76267d6a703c7806b2971c108435d8edce5edbaaf35d984f3a:6ceb427fd3ccde76267d6a703c7806b2971c108435d8edce5edbaaf35d984f3a] Height 14633 com=CORE
DEBU[29242] sync done DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29243] We need to resync with the peer height 14641 DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29243] Reloaded Chain Tips map[6ceb427fd3ccde76267d6a703c7806b2971c108435d8edce5edbaaf35d984f3a:6ceb427fd3ccde76267d6a703c7806b2971c108435d8edce5edbaaf35d984f3a] Height 14633 com=CORE
DEBU[29246] sync done DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29283] Received an ultra compact block c059d230b2b9fdf45d1ccd8c55c2f85f85594eed9188d696ded382fd08ad298d, total 60 contains 0 skipped 60 transactions DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29283] We need to resync with the peer height 14642 DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29283] Reloaded Chain Tips map[c059d230b2b9fdf45d1ccd8c55c2f85f85594eed9188d696ded382fd08ad298d:c059d230b2b9fdf45d1ccd8c55c2f85f85594eed9188d696ded382fd08ad298d] Height 14642 com=CORE
DEBU[29283] sync done DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29304] Received an ultra compact block f30557b80328a31525ebb3675cae437a7fa6fa45a0051f0e1e209d8b3aaa84ac, total 6 contains 0 skipped 6 transactions DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29308] Received an ultra compact block a370687ee8668d3199334c84d10c9ead9013ff5a4cb8f6432a5a2a09b0e251a8, total 30 contains 0 skipped 30 transactions DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29330] Received an ultra compact block 131e001c827b84b935a6df024f8a0a0f7389d800912ce0be24557832ddce6829, total 19 contains 0 skipped 19 transactions DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29356] Received an ultra compact block 0578f1c8c667e7e9dd707880b12d65bb7772ecb34967361c2ffbe44d75ccc33d, total 310 contains 0 skipped 310 transactions DIR=OUT RIP="212.8.242.60:40401" com=P2P
DEBU[29357] We need to resync with the peer height 14646 DIR=OUT RIP="212.8.242.60:40401" com=P2P
DERO HE: 14646/15090 [14646/15090] P 1 TXp 0:38 NW 950 H/s > TESTNET>> panic: cannot query clean block

goroutine 773849 [running]:
github.com/deroproject/derohe/p2p.fill_common(0xc0000aa730)
/usr/home/github/gowork/src/github.com/deroproject/derohe/p2p/common.go:25 +0x2ab
github.com/deroproject/derohe/p2p.(*Connection).NotifyINV(0xc00009e000, 0x3936, 0x3af2, 0x0, 0xc002ad86b0, 0x9, 0x3a102808aceb9c4f, 0xc784687fb5ee008d, 0xfdfa02a82f3cdb3d, 0x2ac4869c2885c17a, ...)
/usr/home/github/gowork/src/github.com/deroproject/derohe/p2p/rpc_notifications.go:74 +0x657
reflect.Value.call(0xc00058fd40, 0xc00000e8f8, 0x13, 0x1690b14, 0x4, 0xc0038aff08, 0x3, 0x3, 0x1012642, 0xc000ae76a8, ...)
/home/github/local/go/src/reflect/value.go:476 +0x8e7
reflect.Value.Call(0xc00058fd40, 0xc00000e8f8, 0x13, 0xc000ae7708, 0x3, 0x3, 0xc000387680, 0x4, 0xc000ae7708)
/home/github/local/go/src/reflect/value.go:337 +0xb9
net/rpc.(*service).call(0xc000530080, 0xc00053a280, 0xc0006170d0, 0xc0006170e0, 0xc000260580, 0xc00226aca0, 0x1632f20, 0xc003910100, 0x199, 0x15bda20, ...)
/home/github/local/go/src/net/rpc/server.go:377 +0x189
created by net/rpc.(*Server).ServeCodec
/home/github/local/go/src/net/rpc/server.go:474 +0x44d

Simulator in testnet is using **dero** mainnet address instead of **deto** inside smart contract

ADDRESS_STRING always assumes you're on mainnet, even if you're not
https://github.com/deroproject/derohe/blob/main/dvm/dvm_functions.go#L367

derohe/rpc/address.go

Line 198 in f0d3e7a

Mainnet: true,

This makes it hard to develop dapp because I cannot match the signer() address string with the wallet address outside of smart contract.

thanks to @Peppinux for pointing where the bug is

Simulator and Smart Contracts: error interpreting line

Version: DERO-HE STARGATE Testnet Release36

Trying to install the token example SC using the simulator returns the following error:

interpreting line [STORE ( "owner" , SIGNER ( ) )]   err:'%!s(<nil>)'
interpreting line [SEND_ASSET_TO_ADDRESS ( SIGNER ( ) , 1600000 , SCID ( ) )]   err:'%!s(<nil>)'
interpreting line [RETURN 0]   err:'%!s(<nil>)'

Then the contract actually gets deployed to the chain, but calling any function produces the same behavior.
Example calling IssueTOKENX:

interpreting line [SEND_ASSET_TO_ADDRESS ( SIGNER ( ) , DEROVALUE ( ) , SCID ( ) )]   err:'%!s(<nil>)'
interpreting line [RETURN 0]   err:'%!s(<nil>)'

Fortunately, this behavior DOES NOT happen when installing/using smart contracts with the actual testnet daemon. The fact that that works correctly is more important.
Still, a 100% working simulator would be ideal for developers.

New address registration not happening

Windows daemon, blockchain fully synced, have tried to register 2 separate new addresses, neither have sucessfully registered after about 12 hours so far.

derod crash

Console:

DERO HE: 1897/1992 [1895/1989] P 6 TXp 0:0 NW 1.1 KH/s > TESTNET>> sync_info
Connection info for peers
Remote Addr PEER ID PORT State Latency H/T DIR QUEUE IN OUT IN SPEED OUT SPEED Version
190.2.135.219 d22d3095be9b1ccd 40401 ACTIVE 62ms 1895/1989 OUT 0 1.5 MB 239 kB 10 kB 62 B 3.0.0-10.DEROHE.alph
212.8.242.60 af141763b7bb9392 40401 ACTIVE 929ms 1895/1989 OUT 0 1.1 MB 238 kB 9.2 kB 62 B 3.0.0-10.DEROHE.alph
212.8.250.158 f3a803820c211a94 40401 ACTIVE 4ms 1895/1989 OUT 0 1.1 MB 298 kB 6.6 kB 62 B 3.0.0-10.DEROHE.alph
52.136.112.140 d1bf5b01af3c6b3c 40401 ACTIVE 904ms 1895/1989 OUT 0 1.2 MB 298 kB 7.7 kB 62 B 3.0.0-10.DEROHE.alph
67.205.145.73 5d810f79bdbaa9e0 40401 ACTIVE 1.079s 1895/1989 OUT 0 1.0 MB 298 kB 6.7 kB 62 B 3.0.0-10.DEROHE.alph
85.217.170.60 4206c9ced097c2da 40401 ACTIVE 1.492s 1895/1989 OUT 0 622 kB 325 kB 2.9 kB 62 B 3.0.0-10.DEROHE.alph
WARN[0445] fError deserialiing block, block id bda4dc6b8c6b37b638520f2c46fc5e1be48fcedc04dc8f69263dd405d8265b63 len(data) 0 data err Block Header could not be parsed Invalid Major Version in Block

com=CORE
DERO HE: 1897/1992 [1895/1989] P 6 TXp 0:0 NW 1.1 KH/s > TESTNET>> panic: Block Header could not be parsed Invalid Major Version in Block

goroutine 64 [running]:
github.com/deroproject/derohe/blockchain.(*Blockchain).Calculate_Height_At_Tips(0xc00052c0f0, 0xc0002ea000, 0x4, 0x4, 0xc0009602e8)
/usr/home/github/gowork/src/github.com/deroproject/derohe/blockchain/store.go:188 +0xff
github.com/deroproject/derohe/blockchain.(*Blockchain).Get_Difficulty_At_Tips(0xc00052c0f0, 0xc0002ea000, 0x4, 0x4, 0x0)
/usr/home/github/gowork/src/github.com/deroproject/derohe/blockchain/difficulty.go:175 +0x1a3
github.com/deroproject/derohe/blockchain.(*Blockchain).Get_Difficulty(0xc00052c0f0, 0x0)
/usr/home/github/gowork/src/github.com/deroproject/derohe/blockchain/blockchain.go:1039 +0x39
github.com/deroproject/derohe/blockchain.(*Blockchain).Get_Network_HashRate(...)
/usr/home/github/gowork/src/github.com/deroproject/derohe/blockchain/blockchain.go:1053
main.main.func4(0xc00052c0f0, 0xc0003a2ec0)
/usr/home/github/gowork/src/github.com/deroproject/derohe/cmd/derod/main.go:313 +0x317
created by main.main
/usr/home/github/gowork/src/github.com/deroproject/derohe/cmd/derod/main.go:254 +0x9b7

derod.log:

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="85.217.170.60:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="212.8.250.158:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="67.205.145.73:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="52.136.112.140:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="212.8.250.158:40401" com=P2P

2020-12-20T17:41:36-05:00 DEBUG : Mining block will give reward to deto1qxqzvxue5y9mk9shw3sspj6kpc5tc7w8c330dtqlgyzr2skyq0p930q8gagzv
2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="67.205.145.73:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Chain extended but height is same 1897 blid 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0
2020-12-20T17:41:36-05:00 INFO : Full order [a4da32724910c5feef49d571d7eb6777704fc53c5889e5b898b05b06b4fb39c6 ecce142b5e250d92e2df67855e083142eaca52e960cce788fb6763d821205bbc 5d2dfd4b825a6f9faac7135d86fc0b055e3784b38fc70684f8c957d7f310fbf6 7477fb0f4b5f2f515b9bd2d52d93a9f5785e2f38fd0dfeac36da9c29d96f2b9a 796aa3c242463b2143d70cc2cde707ac33c53e319a973e3477903ed92ba832bf 52190517a2d70c8b8a3cbf5f70ac8d26ba4cd759c250fc0a0da00fbce2a206e0 8263ede49bc1087d338d683fd523e3af49a32248a4170a2864d48eae89961a11 c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a 525638fee32c777506b6268c203801016ef9bb1da2e9224ed59a06da25fa0504 34705d71bbf0cc52b3de88f6005f9dd0ad3653c59ea1dd8a6c5c55d0a4781741] base a4da32724910c5feef49d571d7eb6777704fc53c5889e5b898b05b06b4fb39c6 base topo pos 1983
2020-12-20T17:41:36-05:00 INFO : New tips(after adding 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0) map[251b2a01fcf44c5fdd19dc1086081b27ad4e186ee52c5ba1cc39c2fea5b8fb7a:251b2a01fcf44c5fdd19dc1086081b27ad4e186ee52c5ba1cc39c2fea5b8fb7a 34705d71bbf0cc52b3de88f6005f9dd0ad3653c59ea1dd8a6c5c55d0a4781741:34705d71bbf0cc52b3de88f6005f9dd0ad3653c59ea1dd8a6c5c55d0a4781741 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0:8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0 bda4dc6b8c6b37b638520f2c46fc5e1be48fcedc04dc8f69263dd405d8265b63:bda4dc6b8c6b37b638520f2c46fc5e1be48fcedc04dc8f69263dd405d8265b63]
2020-12-20T17:41:36-05:00 INFO : Block successfully acceppted by chain 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0
2020-12-20T17:41:36-05:00 INFO : Broadcasted block 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0 to 5 peers
2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash 8deda124f698e75f5b942e727ad951251a677e11e186ad83eecdb591dcd807d0 level=debug DIR=OUT RIP="212.8.242.60:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="52.136.112.140:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="85.217.170.60:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="212.8.250.158:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="67.205.145.73:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="52.136.112.140:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="52.136.112.140:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : Incoming block Notification hash c929aa435185ef4da0bb12cddb968c57f92f72b19bac13089457f5cef1369c8a level=debug DIR=OUT RIP="212.8.250.158:40401" com=P2P

2020-12-20T17:41:36-05:00 INFO : level=warning msg="fError deserialiing block, block id bda4dc6b8c6b37b638520f2c46fc5e1be48fcedc04dc8f69263dd405d8265b63 len(data) 0 data err Block Header could not be parsed Invalid Major Version in Block\n\n" com=CORE
2020-12-20T17:41:36-05:00 INFO : Chain extended but height is same 1897 blid bda4dc6b8c6b37b638520f2c46fc5e1be48fcedc04dc8f69263dd405d8265b63

Issues with retrieving token's balance and transfers from wallet and RPC

Version: DERO-HE STARGATE Testnet Release36

What I did: installed a token SC (SCID: b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba) and played around sending tokens between wallets.

My issues:

Trying getting my token balance

✔️ Typing balance b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba inside the CLI wallet prompt returns the correct amount:
SCID b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba Balance : 1.60000

❌ Calling the wallet RPC curl http://127.0.0.1:40403/json_rpc -d '{"jsonrpc": "2.0","id": "0","method": "GetBalance","params": {"scid": "b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba"}}' -H 'Content-Type:application/json' returns the wrong amount:
{"jsonrpc":"2.0","id":"0","result":{"balance":0,"unlocked_balance":0}}

Trying getting my token transfers

❌ Typing show_transfers b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba insde the CLI wallet returns NO transfers (there should be plenty):
ERROR wallet No transfers available

❌ Calling the wallet RPC curl http://127.0.0.1:40403/json_rpc -d '{"jsonrpc": "2.0","id": "0","method": "GetTransfers","params": {"scid": "b2e6122e52850a79fa997023ee713d47882002b94b99c4da4a385ec374ec27ba","in": true,"out": true}}' -H 'Content-Type:application/json' returns no transfers as well:
{"jsonrpc":"2.0","id":"0","result":{}}

➕ Nice to have additional features:

• Wallet CLI:
  • New option, like number "13", but for tokens: "Show tokens transaction history".
  • New option that shows both DERO and tokens transaction history. A mix between "13" and the new proposed one.
  • New prompt command show_all_transfers that shows both DERO and tokens transaction history.
• RPC
  • New method, GetAllTransfers, that fetches ALL of the DERO and tokens transactions, without the need to specify any token SCID. Like show_all_transfers but for RPC.

derosuite to derohe?

Can I transfer derosuite wallet address coins to derohe wallet address?

GetGasEstimate for InstallSC might be incorrect

The gas estimate when installing a SC is only applying Initialize function and not the SC bytes.

derohe/cmd/derod/rpc/rpc_dero_estimategas.go

Line 75 in 63f1884

if _, result.GasCompute, result.GasStorage, err = s.SCInstall(p.SC_Code, incoming_values, p.SC_RPC, signer, 0); err != nil {

I believe the SCDATA is empty in Execute_sc_function when using
{"jsonrpc":"2.0","id":"0","method":"getgasestimate","params":{ "sc":"'$code'" }}

derohe/dvm/sc.go

Lines 254 to 260 in 63f1884

	var scdata_bytes []byte
	if scdata_bytes, err = SCDATA.MarshalBinary(); err != nil {
	return
	}
	scdata_length := len(scdata_bytes)
	state.ConsumeStorageGas(int64(scdata_length))

An alternative would be to pass a dummy entrypoint
"method":"getgasestimate","params":{ "sc":"'$code'", "sc_rpc": [{ "name": "entrypoint", "datatype": "S", "value": "'$code'" }]

Not very a problem since the fees are automatically taken from your account but it's good know how much it will cost before installing the Smart Contract.

Wallet.db not recognizing old wallet.db

New version does not let me import wallet.db coins.

I tried using "Wallet Seed" and I get nothing and no coins population from previous wallet.db.

Is the new DeroHe Core fork eliminating coins from previous Dero wallet.db versions?

Last version used was 2.1. 6..... Derosuite.

This issue is happening under Linux OS.

Version 2.1.6....... Dersuite is able to display my coins.

How do I proceed in fixing the issue?

MAX_STORAGE_GAS_ATOMIC_UNITS is not big enough

Updating a bigger Smart Contract does not work.
The gas storage fee exceeds the default config limit.

derohe/config/config.go

Line 43 in 3acbbee

const MAX_STORAGE_GAS_ATOMIC_UNITS = 20000

I'm sending the code as hex string because I need to escape characters in json but I need unescape characters in the sc code.

Function UpdateCode(hexCode String) Uint64
10 IF LOAD("sc_owner") == SIGNER() THEN GOTO 30
20 RETURN 1
30 UPDATE_SC_CODE(HEXDECODE(hexCode))
40 RETURN 0
End Function

Right now, I'm building my own derod node with a higher config number but I don't know if this is going to work in production if other nodes have the default config limit.

--min-peers

A suggestion:
why don't we put max-peers parameter like min-peers?
I think it might work.

Daemon Miner Automatically Restarts Itself Without Input

Version 3.2.14-1.DEROHE.STARGATE+28022021 OS:linux ARCH:amd64

After using the start_mining command to start the miner the command prompt displays Mining X H/s. When using the command stop_mining the Mining X H/s is removed from display like it has stopped but after approximately 10 seconds the miner resumes automatically with the Mining X H/s displayed again.

The parameter --socks-proxy=<socks_ip:port> does not work

Use version Release66.
For example, if I add --socks-proxy=192.1.1.11:30808 to the startup parameters, I will get some errors.
Information is as follows:

# ./derod-linux-amd64 --rpc-bind=0.0.0.0:31090  --socks-proxy=192.1.1.11:30808
30/04 22:32:22  INFO    derod   DERO HE daemon :  It is an alpha version, use it for testing/evaluations purpose only.
30/04 22:32:22  INFO    derod   Copyright 2017-2021 DERO Project. All rights reserved.
30/04 22:32:22  INFO    derod           {"OS": "linux", "ARCH": "amd64", "GOMAXPROCS": 8}
30/04 22:32:22  INFO    derod           {"Version": "3.4.141-66.DEROHE.STARGATE+26022022"}
30/04 22:32:22  INFO    derod           {"MODE": "mainnet"}

30/04 22:32:22  INFO    MEMPOOL Mempool started
30/04 22:32:22  INFO    REGPOOL Regpool started
30/04 22:32:22  INFO    derod   Disabling P2P server since we are using socks proxy
30/04 22:32:22  INFO    P2P     P2P is in turbo mode
30/04 22:32:22  INFO    P2P     P2P started
30/04 22:32:22  INFO    RPC     RPC/Websocket server started
30/04 22:32:22  INFO    P2P     P2P server is disabled, No ports will be opened for P2P activity
30/04 22:32:22  INFO    RPC     RPC will listen {"address": "0.0.0.0:31090"}
30/04 22:32:22  INFO    GETWORK GETWORK will listen     {"address": "0.0.0.0:10100"}
30/04 22:32:22  INFO    GETWORK Job will be dispatched every    {"time": "500ms"}
30/04 22:32:22  INFO    RPC     GETWORK/Websocket server started
30/04 22:32:23  ERROR   P2P     Not suported    {"server": "192.1.1.11:30808", "error": "socks proxying is not supported"}
30/04 22:32:23  ERROR   P2P     Not suported    {"server": "192.1.1.11:30808", "error": "socks proxying is not supported"}

Can I confirm that my socks5 can be used by this machine, is there something missing in the parameters?

Feature request: DVM hash functions

Can I please request the following functions be added to the DVM:

SHA-256: input bytes, return bytes32
Keccak-256: input bytes, return bytes32
Also functions for encoding string to bytes, and bytes32 to string (for compatibility with input types and LOAD/STORE functions)

changelog

Why isn't there any change log? It is difficult to understand what changes have been made.

problem syncing Derod using Mac (blockheigh stucked at 114656)

Hello I set up my Dero wallet 2 weeks ago it was veryfied after syncing. Also sent some Dero there allready.
Today I tried to sent some more from TO to the CLI wallet, but I can not sync my wallet. It gets stuck at Block 114656, and error messages of missing blocks appear. What can I do?
Thanks in advance.

JSON-RPC bug and wallet registration issues

I have a couple questions regarding the JSON-RPC and command line tools.

derohe Release66

Why is it that my daemon (connected to a miner) in testnet only mines miniblocks at one topoheight endlessly? When restarting the miner and the daemon it instantly mines at the next height.
This makes it impossible for me to register new accounts needed to test smart contracts.
Could this be the same issue as #46?

derohe Release62

On this version registering new accounts works fine, but the daemon JSON-RPC handles getsc requests incorrectly:

I am using the stargate RPC documentation, please correct me if that is not the right API.

When requesting multiple keys using the "keysstring" parameter, the response always only contains the value of the last key requested.
Eg. request body:

{
	"id": "1",
	"method": "getsc",
	"jsonrpc": "2.0",
	"params": {
		"scid": "my_scid",
		"variables": false,
		"code": false,
		"keysstring": ["key_1", "key_2"]
	}
}

response:

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "valuesstring": [
      "value_of_key_2"
    ],
    "balance": 0,
    "code": "",
    "status": "OK"
  }
}

In the source code it uses Golang’s append() function, so this should not be the problem? I am not proficient in Golang, so I cannot do any proper code analysis.

Sadly, this makes the JSON-RPC unusable to efficiently obtain smart contract variables.

I am aware that I could obtain all the key-value pairs using the parameter "variables": true, but that seems to be highly inefficient because my use case is fetching few keys often (basically this).

If this method is not inefficient because of some graviton-magic, please let me know and I’ll base my project on that.

apparent smart contract size limit

I could not find any information on whether there actually is a size limit for smart contracts (in testnet).
I have a smart contract that is ca. 19.17kb.
I ensured that it is correct and parseable. However, when adding an arbitrary (correct) line, it won’t be accepted by the daemon. The code can be seen using the explorer (SC Arguments: [...]). The explorer does not show any values, neither does it list the code in a structured way. The smart contract does not contain any values (Initialize() is not called) and cannot be invoked.

All this does not happen when staying below ca. 19.17kb smart contract size.
I have enough unlocked funds in my testnet wallet, so that is no concern.

What is my problem here and is there a limit to a smart contract’s size?

I already posted on the DERO community forum, but did not get any help.
This post is about a potential bug, so I assume this to be the right place to ask.

Faster generation of TX registration

For the generation of the registration transaction, it would be interesting to make a multi thread version using the go routines to be registered faster.

A couple of little issues with rpc.RPC_COMMENT

Version: DERO-HE STARGATE Testnet Release36

1. The most important of them: this one still hasn't been fixed #3 (comment)
   It means the Integrated Message (Comment) of an Integrated Address generated by a service will be ignored when the TX is sent.
   Proof with screenshots:
   https://media.discordapp.net/attachments/726125778533875742/832030175918030908/Transfer.png
   https://media.discordapp.net/attachments/726125778533875742/832030238715936788/NoMessageInTX.png
   IMO, still easily fixable by adding arguments = append(arguments, rpc.Argument{rpc.RPC_COMMENT, rpc.DataString, a.Arguments.Value(rpc.RPC_COMMENT, rpc.DataString)}) to https://github.com/deroproject/derohe/blob/main/cmd/dero-wallet-cli/easymenu_post_open.go#L245

2. I think "arguments = append(arguments, rpc.Argument{"Comment", rpc.DataString, a.Arguments.Value(rpc.RPC_COMMENT, rpc.DataString)})" should be replaced with "arguments = append(arguments, rpc.Argument{rpc.RPC_COMMENT, rpc.DataString, a.Arguments.Value(rpc.RPC_COMMENT, rpc.DataString)})" on line https://github.com/deroproject/derohe/blob/main/cmd/dero-wallet-cli/easymenu_post_open.go#L319 in order to save bytes and allow for longer messages (since len("C") < len("Comment").

Cannot use the wallet

Hi,

Config :

• DERO-HE STARGATE Mainnet Release45 (dero_windows_amd64.zip)
• Windows 10
• GIT bash

Daemon looks fine :

But when I open the wallet, it looks like this (messy) :

Also, I cannot type more than one character in the prompt.
And when I type "2" + Enter, I just get another prompt ; it does not seem to create a new wallet.

Thx

Account registration to blockchain in Liunx very high CPU

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
70719 root 20 0 711204 46444 6852 S 189.0 2.4 11:12.63 dero-wallet-cli

DERO-HE STARGATE Testnet Release21 memory leak

memory leak when CORE.blid ERR
derod-windows-amd64.exe.log
OR

Transfer command when exited from menu mode doesn't work.

Version 3.2.14-1.DEROHE.STARGATE+28022021 OS:linux ARCH:amd64

When exited from menu mode the transfer command doesn't work. When entering transfer (address) (amount) into the command prompt, upon hitting (enter) nothing happens and it returns to the command prompt.

Wallet RPC/WebSocket doesn't care about --rpc-login parameter

Version: DERO-HE STARGATE Testnet Release35

Title pretty much sums it up.

When --rpc-login=username:password is set as a wallet parameter, RPC/WebSocket requests receive successful responses even if no (or wrong) Basic Auth params are provided in the request.

This poses a - minor, no need to panic for anyone reading here, but developers should solve this - security risk, since any wallet with an --rpc-server online could receive unwanted calls from malicious locally running software without being able to protect itself with working password authentication.

As a bonus, I would add a feature where critical RPC methods like "transfer" should require manual confirmation from the user from within the wallet.

derod pegs one thread at 100% cpu utilization

When upgrading to the latest derod (rel 74) from what I was running (rel 48) I notices that one thread of the derod process is always pegged at 100% cpu utilization. This was not true in prior versions. I tested each version from 48 => 74 and found that the last version which did not do this was rel 62. Something changed between 62 & 66 which caused this problem.

This happens after the node is fully synced with very almost no transaction activity on the testnet. Command line:

./derod-linux-amd64 --testnet

The system has 4 CPUs & 8 GB RAM. Nothing else is running on the host.

feature request: external IP change causes delay in re-building peer node list

I lost power to my modem which caused an IP change. I noticed that the peer list in my node dropped way down.

Is it possible to adda domain-name param to the node start up, e.g.

--p2p-domain=my.domain.name

So that if there's an IP change to a node, the peer list can be quickly loaded back up?