DERO Homomorphic Encryption Blockchain Protocol

Related tags

Cryptography derohe
Overview

Welcome to the DEROHE Testnet

Explorer Source Twitter Discord Wiki Github DERO CryptoNote Mainnet Stats Mainnet WebWallet

DERO HE [ DERO Homomorphic Encryption]

From Wikipedia:

Homomorphic encryption 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.

Homomorphic encryption 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, homomorphic encryption can 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.

DERO is pleased to announce release of DERO Homomorphic Encryption Protocol testnet. DERO will migrate from exisiting CryptoNote Protocol to it's own DERO Homomorphic Encryption Blockchain Protocol(DHEBP).

Table of Contents [DEROHE]

  1. ABOUT DERO PROJECT
  2. DERO HE Features
  3. DERO HE TX Sizes
  4. DERO Crypto
  5. DERO HE PORTS
  6. Technical
  7. DERO blockchain salient features
  8. DERO Innovations
    1. Dero DAG
    2. Client Protocol
    3. Dero Rocket Bulletproofs
    4. 51% Attack Resistant
  9. DERO Mining
  10. DERO Installation
    1. Installation From Source
    2. Installation From Binary
  11. Next Step After DERO Installation
    1. Running DERO Daemon
    2. Running DERO wallet
      1. DERO Cmdline Wallet
      2. DERO WebWallet
      3. DERO Gui Wallet
  12. DERO Explorer
  13. Proving DERO Transactions

ABOUT DERO PROJECT

        DERO is decentralized DAG(Directed Acyclic Graph) based blockchain with enhanced reliability, privacy, security, and usability. Consensus algorithm is PoW based on DERO AstroBWT: ASIC/FPGA/GPU resistant CPU mining algorithm . DERO is industry leading and the first blockchain to have bulletproofs, TLS encrypted Network.
        DERO is the first crypto project to combine a Proof of Work blockchain with a DAG block structure and fully anonymous transactions based on Homomorphic Encryption. The fully distributed ledger processes transactions with a sixty-seconds average block time and is secure against majority hashrate attacks. DERO will be the first Homomorphic Encryption based blockchain to have smart contracts on its native chain without any extra layers or secondary blockchains. At present DERO has Smart Contracts on old CryptoNote protocol testnet.

DERO HE Features

  1. Homomorphic account based model [First privacy chain to have this.](Check blockchain/transaction_execute.go line 82-95).
  2. Instant account balances[ Need to get 66 bytes of data only from the blockchain].
  3. No more chain scanning or wallet scanning to detect funds, no key images etc.
  4. Truly light weight and efficient wallets.
  5. Fixed per account cost of 66 bytes in blockchain[Immense scalability].
  6. Perfectly anonymous transactions with many-out-of-many proofs [bulletproofs and sigma protocol]
  7. Deniability
  8. Fixed transaction size say ~2.5KB (ring size 8) or ~3.4 KB (ring size 16) etc based on chosen anonymity group size[ logarithmic growth]
  9. Anonymity group can be chosen in powers of 2.
  10. Allows homomorphic assets ( programmable SCs with fixed overhead per asset ), with open Smart Contract but encrypted data [Internal testing/implementation not on this current testnet branch].
  11. Allows open assets ( programmable SCs with fixed overhead per asset ) [Internal testing/implementation not on this current testnet branch]
  12. Allows chain pruning on daemons to control growth of data on daemons.
  13. Transaction generation takes less than 25 ms.
  14. Transaction verification takes even less than 25ms time.
  15. No trusted setup, no hidden parameters.
  16. Pruning chain/history for immense scalibility[while still secured using merkle proofs].
  17. 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 = 66 bytes
Assumming storage overhead per account of 128 bytes ( constant )
Total requirements = (66 + 128)GB ~ 200GB
Assuming we are off by factor of 4 = 800GB
  1. 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.
  2. Senders can prove to receiver what amount they have send (without revealing themselves).
  3. Entire chain is rsyncable while in operation.
  4. Testnet released with source code.

DERO HE TX Sizes

Ring Size DEROHE TX Size
2 1553 bytes
4 2013 bytes
8 2605 bytes
16 3461 bytes
32 4825 bytes
64 7285 bytes
128 11839 bytes
512 ~35000 bytes

NB: Plan to reduce TX sizes further.

DERO Crypto

        Secure and fast crypto is the basic necessity of this project and adequate amount of time has been devoted to develop/study/implement/audit it. Most of the crypto such as ring signatures have been studied by various researchers and are in production by number of projects. As far as the Bulletproofs are considered, since DERO is the first one to implement/deploy, they have been given a more detailed look. First, a bare bones bulletproofs was implemented, then implementations in development were studied (Benedict Bunz,XMR, Dalek Bulletproofs) and thus improving our own implementation.
        Some new improvements were discovered and implemented (There are number of other improvements which are not explained here). Major improvements are in the Double-Base Double-Scalar Multiplication while validating bulletproofs. A typical bulletproof takes ~15-17 ms to verify. Optimised bulletproofs takes ~1 to ~2 ms(simple bulletproof, no aggregate/batching). Since, in the case of bulletproofs the bases are fixed, we can use precompute table to convert 64*2 Base Scalar multiplication into doublings and additions (NOTE: We do not use Bos-Coster/Pippienger methods). This time can be again easily decreased to .5 ms with some more optimizations. With batching and aggregation, 5000 range-proofs (~2500 TX) can be easily verified on even a laptop. The implementation for bulletproofs is in github.com/deroproject/derosuite/crypto/ringct/bulletproof.go , optimized version is in github.com/deroproject/derosuite/crypto/ringct/bulletproof_ultrafast.go

        There are other optimizations such as base-scalar multiplication could be done in less than a microsecond. Some of these optimizations are not yet deployed and may be deployed at a later stage.

DEROHE 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:

  1. DAG: No orphan blocks, No soft-forks.
  2. BulletProofs: Zero Knowledge range-proofs(NIZK)
  3. AstroBWT: This is memory-bound algorithm. This provides assurance that all miners are equal. ( No miner has any advantage over common miners).
  4. P2P Protocol: This layers controls exchange of blocks, transactions and blockchain itself.
  5. 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.
  6. 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.).
  7. Homomorphic Ring Confidential Transactions: Gives untraceability , privacy and fungibility while making sure that the system is stable and secure.
  8. Core-Consensus Protocol implemented: Consensus protocol serves 2 major purpose
    1. Protects the system from adversaries and protects it from forking and tampering.
    2. Next block in the chain is the one and only correct version of truth ( balances).
  9. 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.
  10. 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.
  11. Serialization/De-serialization of blocks: Capability to encode/decode/process blocks .
  12. Serialization/De-serialization of transactions: Capability to encode/decode/process transactions.
  13. Transaction validity and verification: Any transactions flowing within the DERO network are validated,verified.
  14. Socks proxy: Socks proxy has been implemented and integrated within the daemon to decrease user identifiability and improve user anonymity.
  15. Interactive daemon can print blocks, txs, even entire blockchain from within the daemon
  16. status, diff, print_bc, print_block, print_tx and several other commands implemented
  17. GO DERO Daemon has both mainnet, testnet support.
  18. Enhanced Reliability, Privacy, Security, Useability, Portabilty assured.

DERO blockchain salient features

DERO Innovations

        Following are DERO first and leading innovations.

DERO DAG

        DERO DAG implementation builds outs a main chain from the DAG network of blocks which refers to main blocks (100% reward) and side blocks (8% rewards).

DERO DAG stats.dero.io
DERO DAG Screenshot Live

DERO DAG network.dero.io
DERO DAG Screenshot Live

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.

DERO Rocket Bulletproofs

  • Dero ultrafast bulletproofs optimization techniques in the form used did not exist anywhere in publicly available cryptography literature at the time of implementation. Please contact for any source/reference to include here if it exists. Ultrafast optimizations verifies Dero bulletproofs 10 times faster than other/original bulletproof implementations. See: https://github.com/deroproject/derosuite/blob/master/crypto/ringct/bulletproof_ultrafast.go

  • DERO rocket bulletproof implementations are hardened, which protects DERO from certain class of attacks.

  • DERO rocket bulletproof transactions structures are not compatible with other implementations.

        Also there are several optimizations planned in near future in Dero rocket bulletproofs which will lead to several times performance boost. Presently they are under study for bugs, verifications, compatibilty etc.

51% Attack Resistant

        DERO DAG implementation builds outs a main chain from the DAG network of blocks which refers to main blocks (100% reward) and side blocks (8% rewards). Side blocks contribute to chain PoW security and thus traditional 51% attacks are not possible on DERO network. If DERO network finds another block at the same height, instead of choosing one, DERO include both blocks. Thus, rendering the 51% attack futile.

DERO Mining

Mining

DERO Installation

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

Installation From Source

  1. Install Golang, Golang version 1.12.12 required.
  2. In go workspace: go get -u github.com/deroproject/derohe/...
  3. Check go workspace bin folder for binaries.
  4. For example on Linux machine following binaries will be created:
    1. derod-linux-amd64 -> DERO daemon.
    2. dero-wallet-cli-linux-amd64 -> DERO cmdline wallet.
    3. 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 etc. operating systems.
Most users required following binaries:
Windows 7-10, Server 64bit/amd64
Windows 32bit/x86/386
Linux 64bit/amd64
Linux 32bit/x86
FreeBSD 64bit/amd64
OpenBSD 64bit/amd64
Mac OS
Contact for support of other hardware and OS.

Next Step After DERO Installation

        Running DERO daemon supports DERO network and shows your support to privacy.

Running DERO Daemon

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

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

DERO Daemon
DERO Daemon Screenshot

Running DERO Wallet

Dero cmdline wallet is most reliable and has support of all functions. Cmdline wallet is most secure and reliable.

DERO Cmdline 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 Wallet
DERO Cmdline Wallet Screenshot

DERO Explorer

DERO Explorer is used to check and confirm transaction on DERO Network.
DERO testnet 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.
DERO Explorer DERO EXPLORER Screenshot

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 Explorer Proving Transaction DERO Explorer Proving Transaction

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

    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.

    opened by Peppinux 7
  • derod crash

    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

    opened by bn999 7
  • JSON-RPC bug and wallet registration issues

    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.

    opened by JamesDDaniel 5
  • Daemon Miner Automatically Restarts Itself Without Input

    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.

    opened by downystreet 4
  • Malicious miners are not getting banned

    Malicious miners are not getting banned

    It seems that a malicious miner can just spam wrong shares to a node without getting banned. This causes an insane amount of log flooding an is extremely annoying. Being able to use the derod console is pretty important to operate a node and such flooding makes it almost impossible. Enough flooding can also cause quite some load on the CPU. So the fact that these miners are not getting banned makes the node easily vulnerable to ddos attacks.

    To recreate the problem, you can simply use a miner pre v96 fork and start mining. A modification of the software isn't required.

    opened by jon4hz 3
  • Dero wallet continues to show 0 as a balance

    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?

    opened by JeffGwi 3
  • STUCK AT BLOCK 29012/29012 block rejected by chain error

    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

    opened by garzeth 3
  • MAX_STORAGE_GAS_ATOMIC_UNITS is not big enough

    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.

    https://github.com/deroproject/derohe/blob/3acbbee23416e24cc07b33de91a46c2ecc1a8ade/config/config.go#L43

    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.

    opened by g45t345rt 3
  • feature request: external IP change causes delay in re-building peer node list

    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?

    opened by davidj-android 3
  • Cannot use the wallet

    Cannot use the wallet

    Hi,

    Config :

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

    Daemon looks fine : daemon

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

    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

    opened by Sovxx 3
  • Transfer command when exited from menu mode doesn't work.

    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.

    opened by downystreet 3
  • DVM: Function SIGNER() [3.5.2-114.DEROHE.STARGATE] --testnet

    DVM: Function SIGNER() [3.5.2-114.DEROHE.STARGATE] --testnet

    {"Version": "3.5.2-114.DEROHE.STARGATE+01102022"} on --testnet Use this sample smart contract:

          Function Tsign() Uint64
          10 STORE("signer", SIGNER())
          20 RETURN 0
          End Function
    
          Function InitializePrivate() Uint64
          10 STORE("owner", SIGNER())
          60 STORE("signer", SIGNER())
          70 RETURN 0 
          End Function 	
    

    At Initialization the Key "signer" will correctly stored. But by calling "Tsign" the Key "signer" will only written as "000000000000000000000000000000000000000000000000000000000000000000". Tested with different Wallets.

    Test commands (40402 daemon,40403 wallet1,40404 wallet2):

    curl --request POST --data-binary @t.bas http://127.0.0.1:40403/install_sc curl http://127.0.0.1:40402/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getsc","params":{ "scid":"xxx" , "code":false, "variables":true}}' -H 'Content-Type: application/json' curl http://127.0.0.1:40403/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"scinvoke","params":{ "scid":"xxx", "sc_rpc":[{"name":"entrypoint","datatype":"S","value":"Tsign"}] }}' -H 'Content-Type: application/json' curl http://127.0.0.1:40404/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"scinvoke","params":{ "scid":"xxx", "sc_rpc":[{"name":"entrypoint","datatype":"S","value":"Tsign"}] }}' -H 'Content-Type: application/json'

    opened by pcbreflux 4
  • Elliptic curve fails to achieve 128 bits of security

    Elliptic curve fails to achieve 128 bits of security

    The cryptographic primitives used by "derohe" are not documented, but based on the source code, the implementation seems to be using a pairing-friendly Barreto-Naehrig-type elliptic curve with a field size of 256 bits.

    These curves do not actually provide 128 bits of security. Their security is currently estimated to be just below 100 bits due to new attacks that were published in 2016 (see references below).

    There is a comment in the code noting this fact, but I think it should be stated explicitly in the readme that the users of Dero should only expect ~100 bits of security for their funds.

    References: https://moderncrypto.org/mail-archive/curves/2016/000740.html https://eprint.iacr.org/2017/334.pdf (chapter 5.2) https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-00#section-4

    opened by tevador 0
  • Extremely slow TXs with a lot of transfers

    Extremely slow TXs with a lot of transfers

    As mentioned in #102, TXs with a lot of transfers often fail. However this isn't the only problem we encountered with high batch sizes. The following graph shows the request duration of transactions with at most 10 transfers. As you can see, some of these calls took more than 1.33 min(!).

    image

    The yellow lines you see here are all from the transfer calls. According to the legend DERO.GetBlockTemplate is also yellow, however these calls usually took ~8ms.

    opened by jon4hz 0
  • TXs with more than 10 transfers often fail

    TXs with more than 10 transfers often fail

    Several times we've experienced the issue that transactions with more than 10 transfers fail. The error returned by the walletrpc is Cancelled code -500. There's no indicator in the wallet log or daemon log why the transfer actually failed, "it just doesn't work".

    opened by jon4hz 0
  • Non-Dero asset transfer fails due to low transaction fee

    Non-Dero asset transfer fails due to low transaction fee

    When transferring a non-Dero asset via RPC to the wallet, it will silently fail if the "Priority" is set to 1.0 in the wallet. If debug statements are added to the wallet code, you can find that the failure reason is such:

    25/09 10:10:28	ERROR	walletrpc	Error sending tx	{"error": "[-32098] Transaction 3d55dcff7eaac3c6f263bfd013a4bb6d1cb9079c851a95fdcd90c8f19fa37a01 rejected by daemon err 'TX  3d55dcff7eaac3c6f263bfd013a4bb6d1cb9079c851a95fdcd90c8f19fa37a01 rejected due to low fees  provided fee 81 calculated fee 120'"}
    

    The underlying reason is that for non-Dero asset transfers, the wallet decides to silently add a zero value Dero transfer to the transaction yet does not account for the increased transaction size.

    This can be worked around by either setting the transaction ringsize to a value of 2, or by increasing the Priority setting to something larger (like 1.5) so that a larger transaction fee is calculated and submitted by the wallet to the daemon. The wallet RPC does not expose a method to modify the Priority, so this option is not available for a Dapp.

    The wallet needs to be fixed such that it does not add an unnecessary zero value Dero transfer to non-Dero asset transfer transactions.

    opened by deroholic 0
Releases(Release114)
Owner
null
Lattigo: lattice-based multiparty homomorphic encryption library in Go

Lattigo: lattice-based multiparty homomorphic encryption library in Go Lattigo i

null 1 Aug 17, 2022
Blockchain-go - A repository that houses a blockchain implemented in Go

blockchain-go This is a repository that houses a blockchain implemented in Go. F

Onyeka 1 May 1, 2022
Go language implementation of a blockchain based on the BDLS BFT protocol. The implementation was adapted from Ethereum and Sperax implementation

BDLS protocol based PoS Blockchain Most functionalities of this client is similar to the Ethereum golang implementation. If you do not find your quest

Yongge Wang 1 Oct 14, 2022
Eunomia is a distributed application framework that support Gossip protocol, QuorumNWR algorithm, PBFT algorithm, PoW algorithm, and ZAB protocol and so on.

Introduction Eunomia is a distributed application framework that facilitates developers to quickly develop distributed applications and supports distr

Cong 2 Sep 28, 2021
The minilock file encryption system, ported to pure Golang. Includes CLI utilities.

Go-miniLock A pure-Go reimplementation of the miniLock asymmetric encryption system. by Cathal Garvey, Copyright Oct. 2015, proudly licensed under the

Cathal Garvey 172 Sep 21, 2022
An easy-to-use XChaCha20-encryption wrapper for io.ReadWriteCloser (even lossy UDP) using ECDH key exchange algorithm, ED25519 signatures and Blake3+Poly1305 checksums/message-authentication for Go (golang). Also a multiplexer.

Quick start Prepare keys (on both sides): [ -f ~/.ssh/id_ed25519 ] && [ -f ~/.ssh/id_ed25519.pub ] || ssh-keygen -t ed25519 scp ~/.ssh/id_ed25519.pub

null 25 Nov 9, 2022
Sekura is an Encryption tool that's heavily inspired by the Rubberhose file system.

It allows for multiple, independent file systems on a single disk whose existence can only be verified if you posses the correct password.

null 52 Oct 16, 2022
A document encryption solution for the reMarkable 2 ePaper tablet.

Remarkable 2 Encryption This repository contains multiple tools to encrypt the home folder of the reMarkable 2 epaper tablet using gocryptfs. Detailed

RedTeam Pentesting GmbH 32 Nov 7, 2022
A super easy file encryption utility written in go and under 800kb

filecrypt A super easy to use file encryption utility written in golang ⚠ Help Wanted on porting filecrypt to other programing languages NOTE: if you

Flew Software 82 Nov 10, 2022
Encryption Abstraction Layer and Utilities for ratnet

What is Bencrypt? Bencrypt is an abstraction layer for cryptosystems in Go, that lets applications use hybrid cryptosystems without being coupled to t

null 16 Nov 9, 2022
Go implementation of the Data At Rest Encryption (DARE) format.

Secure IO Go implementation of the Data At Rest Encryption (DARE) format. Introduction It is a common problem to store data securely - especially on u

Object Storage for the Era of the Hybrid Cloud 305 Nov 26, 2022
A simple, semantic and developer-friendly golang package for encoding&decoding and encryption&decryption

A simple, semantic and developer-friendly golang package for encoding&decoding and encryption&decryption

null 319 Nov 21, 2022
Encryption & Decryption package for golang

encdec Encryption & Decryption package for golang func main() { startingTime := time.Now() privKey, pubKey := GenerateRsaKeyPair() fmt.Println("Priva

MD MOSTAIN BILLAH 3 Feb 11, 2022
A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

Filippo Valsorda 12.1k Nov 24, 2022
Easy to use encryption library for Go

encryptedbox EncryptedBox is an easy to use module for Go that can encrypt or sign any type of data. It is especially useful when you must serialize y

Jesse Swidler 17 Jul 20, 2022
A tool for secrets management, encryption as a service, and privileged access management

Deploy HCP Vault & AWS Transit Gateways via Terraform https://medium.com/hashicorp-engineering/deploying-hcp-vault-using-the-hcp-terraform-provider-5e

Temur Yunusov 0 Nov 23, 2021
TTAK.KO-12.0223 Lightweight Encryption Algorithm with Galois/Counter Mode (LEA-GCM)

LEACrypt The Lightweight Encryption Algorithm (also known as LEA) is a 128-bit block cipher developed by South Korea in 2013 to provide confidentialit

Pedro F. Albanese 0 Dec 28, 2021
Functional encryption for images

ImageFE Functional encryption for images. Introduction In the traditional cryptography framework, a decryptor either recovers the entire plaintext fro

null 3 Mar 8, 2022
Attempts to make attribute based encryption work, particularly trying out bn256 pairing curve

EC Pairings over bn256 This is an attempt to solve the core problem of attribute based encryption, where the goal is to be able to use CA-issued attri

Robert Fielding 1 Jan 5, 2022