idena-network / idena-go Goto Github PK

Prize Title

• [$4000 in DNAs] - Use Sign-In with Idena function on a website to give extra privileges to Idena validated users

Prize Bounty

• $4k total in DNAs:
  • First place gets $1.5k
  • Second place gets $1k
  • Third place gets $500
  • Fourth place gets $500
  • Fifth place gets $500
• Hackers receive prizes only if they meet the submission requirements.

Challenge Description

• In this challenge, we would like to see that your website or application can authenticate users with the Idena app (read about sign-in with Idena protocol here) using the Idena cryptoidentity address and give them useful privileges depending on their cryptoidentity status on the Idena blockchain.
• Be creative and show how the cryptoidentity can be used.

Background

Idena is a novel way to formalize people on the blockchain. It does not collect or store personally identifiable information. Idena proves the humanness and uniqueness of its participants by running an AI-hard Turing test at the same time for everyone around the globe. The Idena blockchain is driven by proof-of-person consensus: Every node is linked to a cryptoidentity, one single person with equal voting power.

The Idena validated participants registry is a list of addresses with proven semi-uniqueness of their owners (see examples in the Idena blockchain explorer). Each Idena participant can own one valid cryptoidentity address, it is difficult to have two or more.

The uniqueness of participants is proven by the fact that they provide answers for flip-puzzles synchronously. A single person is not able to validate herself multiple times because of a very limited timeframe for submission of the answers. The validation status of a participant is not forever. It expires when the next epoch starts. Participants should prolong their validation status for every new epoch. Read more in the Idena website FAQ section.

Submission Requirements

• All code must be open source.
• Submissions must use the Sign-in with Idena protocol (see here)
• The website must authenticate users with the Idena app (see example in Idena blockchain explorer)
• The website must provide something useful for Idena users with a validated cryptoidentity (Newbie, Verified, Human): voting rights, sybil-protected polls, QV, QF, oracle function, etc.

Submission Deadline

• Official end date of the hackathon

Judging Criteria

• How likely is the application to be used by Idena users.
• How does the website or the application use Idena user address (e.g. age or cryptoidentity status: Not validated, Candiate, Newbie, Validated, Human, Suspended, Zombie).
• Novelty of the use case.
• The potential positive impact for the Idena ecosystem.

Winner Announcement Date

• June 22nd, 2020

Resources

• https://idena.io Idena website
• https://idena.io/?view=faq FAQ
• https://idena.io/?view=download Idena app download page
• https://github.com/idena-network/idena-desktop Idena app github repo
• https://github.com/idena-network/idena-desktop/wiki/DNA-url Sign-in with Idena standard
• http://rpc.idena.io Idena node RPC
• https://api.idena.io/api Idena indexer public API (e.g. identity status, identity age)
• https://scan.idena.io Idena blockchain explorer with the sign-in function
• https://github.com/idena-network/idena-explorer Idena blockchain explorer repo

this request leads to an exception that will shutdown the node

{
  "method": "dna_sendTransaction",
  "params": [
    {
      "from": "0xcaff4f51e73639d7426a98adf5c53ffaa02f49e5",
      "to": "0x18a5eb84dc215a2f170ff1f78dc1873ed8d04d74",
      "amount": "-10000000000000000000000000000000000"
    }
  ],
  "id": 5,
  "key": "some_key"
}
{
  "jsonrpc": "2.0",
  "id": 5,
  "result": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
}

node log

panic: rlp: cannot encode negative *big.Int

goroutine 273928 [running]:
github.com/idena-network/idena-go/protocol.makeMsg(0x5, 0x50c0d00, 0xc00d08bf80, 0x0, 0xc000c09e78, 0x4042ff4)
        /Users/travis/gopath/src/github.com/idena-network/idena-go/protocol/peer.go:155 +0x188
github.com/idena-network/idena-go/protocol.(*protoPeer).broadcast.func1(0xc00abf5c00, 0x0, 0x0)
        /Users/travis/gopath/src/github.com/idena-network/idena-go/protocol/peer.go:99 +0x6f
github.com/idena-network/idena-go/protocol.(*protoPeer).broadcast(0xc003b222a0)
        /Users/travis/gopath/src/github.com/idena-network/idena-go/protocol/peer.go:143 +0x26b
created by github.com/idena-network/idena-go/protocol.(*IdenaGossipHandler).runPeer
        /Users/travis/gopath/src/github.com/idena-network/idena-go/protocol/gossip.go:374 +0x7f5

Generated invites can be, and are being, sold. To prevent this as much as possible, the whole invite generation process could be discarded. Leaving only the possibility in client to activate a node address.

The user that wants to be invited, tells the user that invites, only his node address. The user that invites, inputs that address into his client and activates the identity of the user that wants to be invited.

That way it's more likely that a new user is already running a node and will not simply waste an invite and you can't sell an invite because you could only sell the nodekey and that does not make any sense since the seller of course knows it.

From Rayyan from discord
https://discord.com/channels/634481767352369162/634481933803585546/729340598967861258

"I completed my 6 flips 30 seconds in advance. My long test 15 minutes in advance. Everything was working fine.
My validation failed cause it said: Late submission
Validation answers are all there.
Got all the questions right with strong consensus.
In addition the transactions took place."

Rayyan.zip

Since flips quality is an important thing for functioning of the whole network I suggest using following formula for Score calculation:

Score = ( (Right_answers / Solved_flips) + (Good_flips / Total_flips) ) / 2

The first part (in left brackets) of this formula is the current method of Score calculation, and the second one takes flips quality into account.

These two parts may have different weight in the overall Score, but I personally like this simple method with equal weights for both parts. Also these two parts may be separate scores, something like Solving Score and Flips Score. But in this case Flips Score also should be used for statuses distribution somehow.

When calculating Good_flips, flips with weak consensus may be considered as half of a good flip. Flips without consensus and reported flips should be considered as bad flips (i.e. 0 points).

Let's take a random identity with low quality flips here to show an example of such Score calculation:(https://scan.idena.io/identity/0xd55002165a54355a5DCBc0680BC921B58FB80748#flips)

The previous method gives you: Score = 14 / 15 = 93.33%
The new formula gives you: Score = ( (14 / 15) + (6.5 / 10) ) / 2 = 79.17%

Where:
Good_flips = 6.5 = 6 Qualified flips with strong consensus + 0.5*(1 WeaklyQualified flip with weak consensus),
Total_flips = 10 = 6 Qualified flips with strong consensus + 1 WeaklyQualified flip with weak consensus + 2 NotQualified flips without consensus + 1 Bad reported flip.

PS: For some unknown reason Flip counters in the blockexplorer do not reset to 0 after killing of an identity. Also, Reported flips counter do not work properly. This may cause wrong calculation results for old identities.

Hi,

On validation day my nodes that I support, which are hosted on a 1GB ram + 1GB swap, ubuntu 18.04 server gets offline.
What happens, in node log, and htop i see:

• error writing to stream
• peers connecting/disconecting like crazy
• it's trying to sync but can't for a period over 5-10 minutes
• about 880MB of ram is used
• about 250MB of swap is used

After node restart, ram goes down to 500MB and node syncs in 10 seconds.

Is there a way to introduce memory garbage collector to keep ram usage under 750MB or so?
Or we currently depend on a IPFS optimisation regarding this situation?
I can introduce restart script 1 day before validation, as I am recommending this allready.
I'm wondering, can node restart itself when it loads up memory? But if(validaition=yes) don't restart :D

idena critizises, that projects like btc/eth or eos gave too much power into the hands of too few people. On the other side the cryptonomics of the idena-testnet would mean that possible wealth distribution within idena will be even more inequal than in btc/eth or eos for at last a decade to come, because the ammoumt of premined coins is that high.

Even if you promise to distribute it, that doesnt make it better, because that could result only in two different possible outcomes: 1. idena devs stuck with too many tokens (creating a hurdle for investors trust)
or 2. idena devs stuck with too few tokens (creating a hurdle for developement.)

Idena.io did chose the way to go with premined token, okay - that may look to some like legit, but to others like a risk for potential exit scam.

You could still change that by adjusting the distribution ammount (for example by widening the block reward by factor 10 or more) as soon as you start your official promoted "mainnet". But i think there are better ways - on the other hand you wouldnt want to completly restart tokeneconomics at mainnet, because you would loose a lot of participants that way.

what if idena would give up on the high premine and better create itself starting with mainnet a resonable high constant dev-Ubi instead, written in the code?

Like UBIC proposed that for example: https://bitcointalk.org/index.php?topic=3021063.0

Hi,

I’m on idena since last Week.
idena-node 0.19.6 installed on an Ubuntu docker hosted by a Synylogy NAS.
Idena client 0.9.4 is installed on my Mac.
Ma Syno is a DS716+ With 2GB RAM. The ubuntu Docker does not have RAM limitation and use less than 400Mb.
Everything worked well until tonight.

Idena-node seems to have been disconnected from the network, between 2:38 AM and 6:26 AM,
where it seems to have been freezed

The Docker was not down, I have been able to log on it (ssh) but the console showing (channel 3: open failed: connect failed: Connection refused) multiple times.

Idena client couldn’t connect to node.

Finally I restart the docker and relaunch idena-node.
The synchronisation started but it was slow.
When sync was OK, my mining status have been reset.

I had over 6 DNA penalty.

Dont know why ?

Here is Full Logs:
output.log

Thks ;)

Who is Travis?
I'm running Client(0.1.4) with built in Node(0.15.0) on Win10 Pro 64bit. Mining is on.
Windows updates are paused for next 35 days, no restarts. No sleep is set.
Node stoped for some reason and I need to click on a button to restart the node.
Is there way to setup autorestart of node?

Here are node logs, hope this is usefull:
output.zip

In addition to invite links each user should have an ability to issue a peers link with the info about locations of his peers. This info (containing IPs of the peers) should be encrypted somehow.

These links can be one-off (disposable) as invites or temporary because the network is always changing. Some nodes go offline, some new nodes go online instead.

For example if I want to share my peers with some other guy in order to help him get connected to the network, I take his address and encrypt the list of my peers with it. Then I send it to him via telegram or discord message. He inputs the link in his client, decrypts it and then tries to connect to the network via my peers.

Otherwise these bootstrap peers list seem to be a bottleneck for incoming new users. The problem is very distinct right before validation sessions.

After HF, deleting a submitted flip takes exaggerated amount of DNA as a fee.

From 0.0000000000614635 DNA before to 26.793374019211176 DNA after.

Generated invites can be, and are being, sold. To prevent this as much as possible, the whole invite generation process could be discarded. Leaving only the possibility in client to activate a node address.

The user that wants to be invited, tells the user that invites, only his node address. The user that invites inputs that address into his client and activates the identity of the user that wants to be invited.

That way it's more likely that a new user is already running a node and will not simply waste an invite and you can't sell an invite because you could only sell the nodekey and that does not make any sense since the seller of course knows it.

https://discord.com/channels/634481767352369162/634481767843364866/729248184290902066

I'm on Mac, I downloaded new app version 14.2 and with it I can't switch off mining status, once trying to switch off-it starts synchronizing, then after complete synchro-again status is on. And again and again. Tried 3 times and got success on 3d time, but after mining got switched off, again synchro.
It started when I downloaded 14.2.

mr_bubbles.zip

Rioda: I'm not sure where to open which issue, desktop, or node repo...

Node was restarted before validation period 5 minutes (red warning message appeared in idena-desktop), peers found in 20-30 seconds and blocks sync ok

node version 0.19.4

When validation starts, in log was error messages:

WARN [04-22|13:30:01.485] flip is not ready err="flip private key is missing" cid=bafkreigjyqexk6hc4xm2wusou3dswb5epuaqib6w2vlbbld5g4dpkgcpku

i think ipfs network need more time to connect? may be idena-desktop must show warning about it?

I guess you wont give up but adjust the turing test as soon as AI shows up that is able to solve flips (will happen, because many participants create too easy flips). I think there should be not only a reward for those who create a AI able to target Idena, but there should also be a reward for those who create flips that stay AI-resistant afterwards in a test-setting - or call it a penalty for those participants, whos flips get solved by that AI too easy and too often later on. People need incentives to do better than "1,2,3,4" oder "baby,young,adult,dead" or "flower,flower,flower,banana" or "spring,summer,autumn,winter". I think that will be much harder in the future to come up with AI-resistant flips.

During the validation the 18th July 2020, the following error came up, it prevented me from completing the consensus.

0|idena-node-linux-0.21 | ERROR[07-18|13:57:12.936] cannot send short answers tx err="state nonce: 7, state epoch: 49, tx nonce: 7, tx epoch: 49: invalid nonce"

Things I tried:

• Restart the node (idena-node-linux-0.21.3) and the client
• Use the previous version of the node (idena-node-linux-0.21.2)

Here's my identity if you need to investigate https://scan.idena.io/identity/0x9007f3427f63ca3b031ec8cb01979bc4ef71592c

I did the following steps on a Raspberry Pi4 Model B:

1. git clone https://github.com/idena-network/idena-go
2. cd idena-go
3. go build
4. then replaced the ~/datadir/keystore/nodekey with the one on my laptop in %appdata%\idena\node\datadir\keystore\nodekey
5. copied the ~/datadir/api.key and paste it into the field of "Node api key" in the idena client(click on settings and then connect to remote node) and press save.
6. Get the ip address of my raspberry pi
7. Then type http://MY_IP:9009 into the field of "Node address" over the "Node api key" in the idena client and press save.
8. Then start the node on the pi in the folder ~/idena-go with ./idena-go --rpcaddr MY_IP
9. Now the client synchronizes and runs and mines dna.
10. You can see the Node version being 0.0.1
11. Is that just a display problem or how do I actually download the newest Version of the node?
12. Also if you activate "connect to remote node" button, the "run built-in node" doesn't turn off automatically. Only one of them should be turned on, but I think this is also only a display issue.
    

If you stop your node right after flips are created and submitted via a Tx, then wait for example several days and run new node with the same nodekey on another PC will your flips ever be available to the network? How flips become distributed throughout the network? Will they be available if you delete your IPFS directory?

Hi , Is there a way to get a flip details ? Like who solved it and did he report or not ? And if that is in the short and long answers hash then how to parse it ? ..I hope that the rpc can get these details

The module path gopkg.in/urfave/cli.v1 found in your /go.mod doesn't match the actual path github.com/urfave/cli found in the dependency's go.mod.

Updating the module path in your go.mod to github.com/urfave/cli should resolve this issue.

View the update logs.

I send 18 decimal places, but only the chain data only shows 16 digits, and the balance is also 16 digits

At the moment, old transactions are periodically pruned from the blockchain.

Are there any plans to create an option for nodes to retain historic transactions.

For my specific use case I am trying to prove historic votes on idenavoice. I'm considering all options ( using an alt immutable chain, a second layer ), but a core solution would be preferred.

In general, I believe it would also enable (non-smart contract) dapps, that just need a 'comment' field.

Prize Title

• [$5000 DNAs] Idena Ethereum Relay: How the registry of validated cryptoidentities could be relayed from the Idena blockchain to Ethereum

Prize Bounty

• $5k paid in DNAs
• The prize can be split into pieces according to the agreement of the collaborating hackers.
• Hackers receive prizes only if they meet the submission requirements.

Challenge Description

We expect to see two parts of the project that can be implemented by different hackers in collaboration:

• An Idena Ethereum Relay smart contract on the Ethereum blockchain that mirrors the list of cryptoidentities validated on the Idena blockchain
• Idena node improvements to provide data for an Ethereum smart contract (see details below)

Background

Idena is a novel way to formalize people on the blockchain. It does not collect or store personally identifiable information. Idena proves the humanness and uniqueness of its participants by running an AI-hard Turing test at the same time for everyone around the globe. The Idena blockchain is driven by proof-of-person consensus: Every node is linked to a cryptoidentity, one single person with equal voting power.

The Idena validated participants registry is a list of addresses with proven semi-uniqueness of their owners (see examples in the Idena blockchain explorer). Each Idena participant can own one valid cryptoidentity address, it is difficult to have two or more.

The uniqueness of participants is proven by the fact that they provide answers for flip-puzzles synchronously. A single person is not able to validate herself multiple times because of a very limited timeframe for submission of the answers. The bigger the network is, the less frequently the validation sessions happen. The validation status of a participant is not forever. It expires when the next epoch starts. Participants should prolong their validation status for every new epoch. Read more in the Idena website FAQ section.

Possible implementation

The Idena cryptoidentity address is fully compatible with the Ethereum address. In order to use Idena cryptoidentities in the Ethereum blockchain, it is necessary to create a protocol to relay the list of Idena’s cryptoidentities into an Ethereum smart contract without trusted parties.

The relay can be done in two ways:

A. Trusted oracle (not considered)

A special agent/organization authorized to record information to a special smart contract on Ethereum acts as a trusted Oracle. Whenever the cryptoidentity list changes, the trusted Oracle updates the list of valid identities:

• When an identity in Idena is terminated (see Kill identity and Kill invitee methods)
• Upon the end of each validation (see validation results for epoch #44)
• The Oracle does not provide any evidence of the changes’ accuracy and is a potential point of failure. We do not consider this approach for the challenge.

B. Trustless Idena Ethereum Relay

A possible alternative solution does not imply a trusted Oracle (or numerous Oracles).

Initially, an Idena Ethereum Relay smart contract has to be created, in which the current list of Idena validated identities’ addresses are included by the contract developer. This initial list of addresses is the genesis of the registry and is manually verified by other participants.

Anyone in the Ethereum network can change the identity list, while providing proof of correctness of the change to this contract:

• When an identity in Idena is terminated, a transaction taken from the Idena blockchain is provided as evidence into the Idena Ethereum Relay smart contract. The smart contract analyzes the signature of this transaction and the type of transaction. If the signature is valid the change is accepted by the contract.
• Upon the end of each validation, along with the list of newly validated participants, signatures of old validated participants confirming correctness of the new list are provided as evidence. These signatures are to be published automatically by Idena nodes.
• The Idena Ethereum Relay smart contract checks the provided list of new participants, calculates the hash of this list. Then it checks the provided signatures of the old participants. Each signature must match the hash of the new participant list. If there are more than 2/3 valid signatures provided to the contract, the contract goes into a new state with a new list of valid addresses.

Availability assumption

The mechanism will work only if a large share of participants of the old registry keep the nodes up and running after the validation and provide their signatures for the new state.

Possible problems: Relay costs

1. When validating 10,000 members in Idena, all the 10,000 entries must be provided to the contract. Relaying such an array of data to Ethereum smart contracts may be expensive.
   Possible optimization: Only the difference between the new and the old lists are relayed to the contract.
2. In order to switch to a new state from the list of participants with 10,000 addresses, 6666 signatures must be relayed. Relaying such an array of data to an Ethereum smart contract and verifying signatures may be expensive.
   Possible optimization:
   As a list of signatories, a committee of a smaller size can be formed in a deterministic manner.
   Using BLS signatures aggregation
3. Due to the high cost of the changes relay, there will be no economically motivated participants to transfer changes to the Idena Ethereum Relay smart contract.
   Possible solution: socialization of transaction costs in the business models of participants paying for the relay of Idena identity registry changes.

Submission Requirements

• All the code must be open source
• Idena Ethereum Relay smart contract requirements:
  • The Idena Ethereum Relay smart contract should be deployed in the Ethereum testnet. A test set of cryptoidentities should be saved in the smart contract.
  • The Idena Ethereum Relay smart contract should provide an up-to-date list of cryptoidentities
  • The Idena Ethereum Relay smart contract should provide secure public methods of updating the list of valid cryptoidentities in case of registry changes on the side of the Idena blockchain
  • The smart contract should consume the lowest possible amount of gas to solve the problem
• Required Idena Node improvements:
  • To calculate the hash of the new list of participants as the Idena Ethereum Relay contract does it
  • To produce a signature for the new set of cryptoidentities required for the Idena Ethereum Relay smart contract

Submission Deadline

• Official end date of the hackathon

Judging Criteria

• The following tests should be available:
  • Test 1: The Idena Ethereum Relay smart contract should be robust and fully-functional. It must be deployed in the Ethereum testnet. Initial test set of cryptoidentities should be saved in the smart contract.
  • Test 2: Pushing a new list of cryptoidentities into the smart contract
  • Test 3: Pushing a set of signatures which is sufficient to change the smart contract state
  • Test 4: Applying the new set of cryptoidentities in the Idena Ethereum Relay smart contract
• The Idena Ethereum Relay smart contract should consume the lowest possible amount of gas to solve the problem.
• The Idena node improved version should produce a signature for the new set of cryptoidentities required for the Idena Ethereum Relay smart contract

Winner Announcement Date

• June 22nd, 2020

Resources

• https://idena.io Idena website
• https://idena.io/?view=faq Idena FAQ
• https://idena.io/?view=download Idena app and Idena node download page
• http://rpc.idena.io Idena node RPC
• https://scan.idena.io Idena blockchain explorer
• https://scan.idena.io/epoch/44 list of validated identities for epoch #0044
• https://github.com/idena-network/idena-go Idena node github repo

I first installed 1 day before 10.0. Perhaps 20.0 node was installed midway through that first day. Was high bandwidth use, but it did sync whole chain.

After 10.0, it doesn't seem to fully sync, but does manage slowly/sporadically to sync jump by exactly 1000 ... block xxxx333

Errors include:

error while writing to stream, id, err="connection write timeout"

Post consuming error component=downloader err="snapshot's downloading has been failed: ipfs load: context canceled"

process batch - timeout was reached component=downloader

I tried the "mining not stable" workaround at https://rioda.org/idena/faq_tutorials.php with longer timeouts, but no help

Address 0x5b0566cc6702e0476c6f265b5fdba4c6251ee115 created transactions that are stuck in mempool. I'm retrieving pending transactions using bcn_pendingTransactions rpc endpoint.

Request

{
	"method": "bcn_pendingTransactions",
	"id": 1,
	"key": "",
	"params": [{ "address": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115" }]
}

Result

{
    "jsonrpc": "2.0",
    "id": 2,
    "result": {
        "transactions": [
            {
                "hash": "0xad34cc7a3210907e53936b1c72c9889782e83e08218aa14d31284dc3869a96d7",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0x1515411439f80988bcecfef8794baeb732afc494",
                "amount": "10",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x006d0069007300740065007200730068006f007000700069006e0067",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x4c6f11eec7493520cfc78c4f019980588f94bf88ee8b662516d17339fe5bf93d",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0x1515411439f80988bcecfef8794baeb732afc494",
                "amount": "234",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x006d0069007300740065007200730068006f007000700069006e0067",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x4cb7f8c8d8118264b621c7555bd7c1b3404176e4df9a89de45de0f244749bc95",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0x1515411439f80988bcecfef8794baeb732afc494",
                "amount": "234",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x6c226e49fd726916de33e80c56dadc5e495b81c990e9a7329cc4ff2806d6dc4f",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0x1515411439f80988bcecfef8794baeb732afc494",
                "amount": "200",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x850408bec79e31a586e52f0054532505c91b6d8f7ca6a7d0e8133c806e39d101",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0xf07e86ac97d67e6fb12064e38dbb78a74eda672d",
                "amount": "235",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x0daa73d3c28ac8b2b1c0b50597f968b91c8a93a9108baa44bafe12152e3acec4",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0xf07e86ac97d67e6fb12064e38dbb78a74eda672d",
                "amount": "234",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x6a7f903cfdd6aa55b19c389bd81d141b986682461bbe39f60c32e1e5c38e49cf",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0xf07e86ac97d67e6fb12064e38dbb78a74eda672d",
                "amount": "234",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x006d0069007300740065007200730068006f007000700069006e0067",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            },
            {
                "hash": "0x8005f46ad9fe3083809cc8ef36139977eea6939ea472eea67d17030ec9823153",
                "type": "send",
                "from": "0x5b0566cc6702e0476c6f265b5fdba4c6251ee115",
                "to": "0xa775ad4405cf4da48c4b7353e5e42f6f203d96db",
                "amount": "235",
                "tips": "0",
                "maxFee": "0.00000000000003",
                "nonce": 3,
                "epoch": 44,
                "payload": "0x00610020006d0065002000730074006500730073006f",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "usedFee": "0",
                "timestamp": 0
            }
        ],
        "token": null
    }
}

1. Do transactions stuck in mempool have an expiration time?
2. Can I send a transaction with same nonce (=3) and higher maxFee overwriting old ones?

Every now and then, we have members that are doing the same thing. They terminate identity and try to send stake coins directly to qtrade address. As qtrade does not scan blokcs for KillTx, they don't receive coins. Luckly qtrade guys are very nice and resolve this issues.
Can we consider changing funcionality of a Terminate button to automatically send coins from stake to main balance (with some confirmation dialog ofc.)?
With that, we (members, support and qtrade support) would not have issues and would have better expirience overall.

There were plans to add Webhook to Idena Discord server. Is this possibility still open?

https://discordapp.com/api/webhooks/701078917674696724/7xJsS5udRoFsItdykBUaIpivOHVwYlR1uUftiRmQIM6QA_SQkUCjaoXtqw5pfvAFlh6g

https://superuser.com/questions/1189901/can-i-integrate-a-discord-channel-with-github-pull-requests

While spamming with SendTx transactions to test the network i found that i quite often ran into this error. it for example happened at the first try after 514 sent transactions.

i guess this is because i've send the same data over and over pretty fast but i have the feeling that this could also happen to a regular transaction which would be unfortunate.

could this be an issue once the network grows in size?

It seems that current invites distribution is clogging the network growth. Indeed, it concentrate all invites in hands of best and fastest flip solvers. Initially it was made for preventing bots from collecting invitations and solving flips randomly (https://medium.com/idena/idena-security-model-update-7d624ef3298f). But I don't think it is a big problem anymore due to discrimination of Newbies and Lottery-based rewards for non-spent invitations.

I suggest to distribute invites the way it was before humans were introduced, 1 invite to every account with Verified status or higher. Human's overall rewards should be 1.5x higher than Verified's one in order to keep Human as desirable status. It means that reward for flips, invites and validation is 1.5 times higher for Human than for Verified or Newbie.

I want to add that main purpose of the protocol should be filtering out people from bots and not individuals who manage to solve flips better and quicker than the others. For example I am 14 epochs old and yet stay Verified (I created 48 out of 48 good flips with strong consensus). I even know identities (https://scan.idena.io/identity/0x8b8C0607c9AE92B567ADef452e79DC673C3c180D) who break this table here (https://miro.medium.com/max/1400/1*oD89Jqp0yfa8K6B5MKBcSA.png) being Verified for 43 epochs already. I know some other people with the same problem of not being able to get this 92% Score managing strictly 1 node. I don't mind to stay Verified forever as it probably will happen but I think that privileges of two invites for humans with corresponding rewards are too huge, let alone more easy multi-accounting for them.

I got this flip during short validation:
https://scan.idena.io/flip?flip=bafkreihi4md4zwprkwqo2hdqwewxo5acekzsrlk7khxvggff2ld5no3e4e

It is marked as reported, but It still counted on my short session.

Even though the flip is marked as reported, it has strong consensus on right. Is this the right behaviour?

This feature is needed for multi-accounting preventing and increase of vertical mobility in old identities status. As far as I know 'human' now became a status with the highest number of multi-accounts holders. Indeed, 'human' status gives you huge privileges over 'verified' in terms of rewards, invites and immunity to validation fail (humans are almost immortal in that sense). So in my opinion being 'human' you need to constantly prove that you deserve these privileges. And this should not depend on your previous 40 epochs history. That's why I suggest to calculate Score as trailing average for last 5 epochs only.

This will make multi-accounting harder for everyone, not only humans. Because the most frequent result of multi-node validation passing is not identities killing but rather some dips in one of your identities' Score. Currently if you have old enough identity these dips becomes negligible and you can continue your multi-accounting thing easily.

This measure will also make old identities pay more attention to quality of flips in the network.

Distribution of invites will be more up to date with the actual Scores of identities and not with their past long ago results.

Hi, I'm trying to inject a signed tx using the dna_sendRawTx endpoint but an "insufficient funds" error is raised (even if there are sufficient funds).

How to reproduce

1. First of all I retrieve the nonce of my address:

{
	"method": "dna_getBalance",
	"id": 2,
	"params": ["0xfE3F5744116B71C9b61Af772C6535A1829d7f2Ac"]
}

{
    "jsonrpc": "2.0",
    "id": 2,
    "result": {
        "stake": "0",
        "balance": "0.8799999999999046",
        "nonce": 9
    }
}

2. Then I forge tx:

{
	"method": "bcn_getRawTx",
	"id": 2,
	"params": [{
	    "nonce": 10,
	    "epoch": 41,
	    "type": 0,
	    "to": "0xCF979F9472e38d45C577394747a3028ea7433Bb5",
	    "amount": 0.01,
	    "maxFee": 0.000000000000021,
	    "tips": 0,
	    "payload": "0x"
	}]
}

{
    "jsonrpc": "2.0",
    "id": 2,
    "result": "0xe60a298094cf979f9472e38d45c577394747a3028ea7433bb5872386f26fc10000825208808080"
}

3. Then I sign the tx:

{
	"method": "dna_sign",
	"id": 2,
	"params": ["0xe60a298094cf979f9472e38d45c577394747a3028ea7433bb5872386f26fc10000825208808080"]
}

{
    "jsonrpc": "2.0",
    "id": 2,
    "result": "0x4b65694247b2519c4c897d94adbeb7309ecc34efd1844c91d086ab9e1de60ef7764464c5e3f8ee234625811a577aa1aa2802789fc1afada8ae2d644a75f822f700"
}

4. Concatenate forged tx and signature

I'm using javascript for this purpose and the RLP module.

const RLP = require("rlp");
const format0x = (buffer: Buffer) => "0x" + buffer.toString("hex");
const forgeSignedTx = data => RLP.encode([
            data.nonce,
            data.epoch,
            data.type,
            data.to,
            data.amount*10**18,
            data.maxFee*10**18,
            data.tips*10**18,
            data.payload || "0x",
            data.signature || "0x",
]);
console.log(format0x(forgeSignedTx));

0xf8680a298094cf979f9472e38d45c577394747a3028ea7433bb5872386f26fc100008252088080b8414b65694247b2519c4c897d94adbeb7309ecc34efd1844c91d086ab9e1de60ef7764464c5e3f8ee234625811a577aa1aa2802789fc1afada8ae2d644a75f822f700

5. Inject signed tx

{
	"method": "bcn_sendRawTx",
	"id": 2,
	"params": ["0xf8680a298094cf979f9472e38d45c577394747a3028ea7433bb5872386f26fc100008252088080b8414b65694247b2519c4c897d94adbeb7309ecc34efd1844c91d086ab9e1de60ef7764464c5e3f8ee234625811a577aa1aa2802789fc1afada8ae2d644a75f822f700"]
}

{
    "jsonrpc": "2.0",
    "id": 2,
    "error": {
        "code": -32000,
        "message": "insufficient funds"
    }
}

p.s. I know that I can use the dna_sendTransaction endpoint, but I'd like to be able to inject an offline forged and signed tx.

I have done my first validation and after that node cannot sync:

ERROR[06-22|14:30:07.637] invalid flip err="tx can't be accepted due to validation ceremony" WARN [06-22|14:30:08.936] Do not have requested block id=QmfC818tNe3vDmsnaViyHcdfWYevcPPArAw8gxB1sQrdcW height=1450956
from block explorer I see that I passed:
https://scan.idena.io/address/0xf4c8f91cbc59d3193886447a9cb5f06097ef2305

Maybe seems stupid but "Missing" implies something is lost that can be found or needs to be found. "Missed" implies more that something failed and it is gone - which I think will help people understand what actually happened.

cryptovigi had a short session late submission, node is on vps/ubuntu

cryptovigi.zip

Hi there, I’m having trouble connecting the MacOS client to a remote node. Seems like the remote node only accepts locals connections, even though I’ve prepared the config.json file as such:

{ "IpfsConf": { "Profile": "server" } }

I’m using a VPN, I can ping the "remote" node so I’m sure that networking is fine.
I can also telnet from the Mac to a test port open with netcat.
I can’t telnet to the 9009 port though nor the mac os client can. Am I missing something ?

Currently, anyone can run many nodes with the same nodekey, I think this will seriously affect network security, especially when idena become sharding network.

Add the possibility to notify the user if his balance changed. Basically scanning for new SendTx transactions.

Node downloaded automatically in idena-desktop 0.18.1, windows version (windows 10 x64)
Only full resync helped

logs part (this shown after manual start node):
https://pastebin.com/wWkX0Ubh

OS version: Mac Catalina 10.15.4 (19E287)
Idena Client version: 0.14.2
Idena Node version: 0.21.2

panic(cpu 1 caller 0xffffff80158c310f): assertion failed: NETNS_REF_COUNT(res, flags) != 0, file: /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.101.6/bsd/skywalk/namespace/netns.c, line: 830
Backtrace (CPU 1), Frame : Return Address
0xffffff9b001ab950 : 0xffffff80151215cd 
0xffffff9b001ab9a0 : 0xffffff801525a3c5 
0xffffff9b001ab9e0 : 0xffffff801524bf7e 
0xffffff9b001aba30 : 0xffffff80150c7a40 
0xffffff9b001aba50 : 0xffffff8015120c97 
0xffffff9b001abb50 : 0xffffff8015121087 
0xffffff9b001abba0 : 0xffffff80158c2c7c 
0xffffff9b001abc10 : 0xffffff80158c310f 
0xffffff9b001abc20 : 0xffffff801571d387 
0xffffff9b001abc80 : 0xffffff801571e130 
0xffffff9b001abce0 : 0xffffff8015513bda 
0xffffff9b001abd20 : 0xffffff80155563b3 
0xffffff9b001abdc0 : 0xffffff8015556f35 
0xffffff9b001abe20 : 0xffffff80156d45c5 
0xffffff9b001abe60 : 0xffffff80156e672e 
0xffffff9b001abf40 : 0xffffff80157875f7 
0xffffff9b001abfa0 : 0xffffff80150c8206 

BSD process name corresponding to current thread: idena-go

Mac OS version:
19E287

Kernel version:
Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
Kernel UUID: AB0AA7EE-3D03-3C21-91AD-5719D79D7AF6
Kernel slide:     0x0000000014e00000
Kernel text base: 0xffffff8015000000
__HIB  text base: 0xffffff8014f00000
System model name: iMac17,1 (Mac-B809C3757DA9BB8D)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 537706108758438
last loaded kext at 533136966516161: >!AXsanScheme	3 (addr 0xffffff7f99e14000, size 32768)
last unloaded kext at 533222837152290: >!AXsanScheme	3 (addr 0xffffff7f99e14000, size 32768)
loaded kexts:
com.boxcryptor.BCFS.filesystems.bcfs	3.10.4
com.box.filesystems.osxfuse	303.10.2
org.virtualbox.kext.VBoxNetAdp	6.1.8
org.virtualbox.kext.VBoxNetFlt	6.1.8
org.virtualbox.kext.VBoxUSB	6.1.8
org.virtualbox.kext.VBoxDrv	6.1.8
>!UTopCaseDriver	3430.1
@filesystems.afpfs	11.2
@nke.asp-tcp	8.1
@filesystems.smbfs	3.4.2
>AudioAUUC	1.70
>!ATopCaseHIDEventDriver	3430.1
@fileutil	20.036.15
>AGPM	111.4.4
>!APlatformEnabler	2.7.0d0
>X86PlatformShim	1.0.0
>!AMikeyHIDDriver	131
@filesystems.autofs	3.0
>!AMikeyDriver	283.15
>!AHDA	283.15
@kext.AMDRadeonServiceManager	3.0.8
>!AUpstreamUserClient	3.6.8
@kext.AMDFramebuffer	3.0.8
@kext.AMDRadeonX4000	3.0.8
>!AGraphicsDevicePolicy	5.1.16
@AGDCPluginDisplayMetrics	5.1.16
>!AHV	1
|IOUserEthernet	1.0.1
|IO!BSerialManager	7.0.4f6
>!A!ISKLGraphics	14.0.5
>eficheck	1
@kext.AMD9000!C	3.0.8
>!A!IPCHPMC	2.0.1
>pmtelemetry	1
@Dont_Steal_Mac_OS_X	7.0.0
>!ASMCLMU	212
>!A!ISKLGraphicsFramebuffer	14.0.5
>!AMCCSControl	1.11
>!AThunderboltIP	3.1.4
>!A!ISlowAdaptiveClocking	4.0.0
|Broadcom!B20703USBTransport	7.0.4f6
>!AVirtIO	1.0
@filesystems.hfs.kext	522.100.5
@!AFSCompression.!AFSCompressionTypeDataless	1.0.0d1
@BootCache	40
@!AFSCompression.!AFSCompressionTypeZlib	1.0.0
>AirPort.BrcmNIC	1400.1.1
>!ASDXC	1.7.7
|!ABCM5701Ethernet	10.3.5
@filesystems.apfs	1412.101.1
@private.KextAudit	1.0
>!AAHCIPort	341.0.2
>!ARTC	2.0
>!AACPIButtons	6.1
>!AHPET	1.8
>!ASMBIOS	2.1
>!AACPIEC	6.1
>!AAPIC	1.7
$!AImage4	1
@nke.applicationfirewall	303
$TMSafetyNet	8
@!ASystemPolicy	2.0.0
|EndpointSecurity	1
>usb.IOUSBHostHIDDevice	1.2
$SecureRemotePassword	1.0
>!AMultitouchDriver	3440.1
>!AInputDeviceSupport	3440.8
>!AHS!BDriver	3430.1
>IO!BHIDDriver	7.0.4f6
|IOUSBUserClient	900.4.2
>!AHIDKeyboard	209
@kext.triggers	1.0
>DspFuncLib	283.15
@kext.OSvKernDSPLib	529
@kext.AMDRadeonX4070HWLibs	1.0
@kext.AMDRadeonX4000HWServices	3.0.8
>!AGraphicsControl	5.1.16
|IOAVB!F	840.3
>!ASSE	1.0
|IONDRVSupport	575.1
|IOAccelerator!F2	438.4.5
>!AThunderboltEDMSink	4.2.3
@!AGPUWrangler	5.1.16
|IOSlowAdaptiveClocking!F	1.0.0
>X86PlatformPlugin	1.0.0
>IOPlatformPlugin!F	6.0.0d8
|Broadcom!BHost!CUSBTransport	7.0.4f6
|IO!BHost!CUSBTransport	7.0.4f6
|IO!BHost!CTransport	7.0.4f6
|IO!B!F	7.0.4f6
|IO!BPacketLogger	7.0.4f6
@kext.AMDSupport	3.0.8
@!AGraphicsDeviceControl	5.1.16
>!ASMBus!C	1.0.18d1
>!AHDA!C	283.15
|IOGraphics!F	575.1
|IOHDA!F	283.15
>!ASMBusPCI	1.0.14d1
@plugin.IOgPTPPlugin	840.3
>usb.!UHub	1.2
>usb.networking	5.0.0
>usb.!UHostCompositeDevice	1.2
|IOAudio!F	300.2
@vecLib.kext	1.2.0
|IOSerial!F	11
|IOSurface	269.11
@filesystems.hfs.encodings.kext	1
>!AThunderboltDPOutAdapter	6.2.6
>!AThunderboltDPInAdapter	6.2.6
>!AThunderboltDPAdapter!F	6.2.6
>!AThunderboltPCIDownAdapter	2.5.4
>!AThunderboltNHI	5.8.6
|IOThunderbolt!F	7.6.0
|IO80211!F	1200.12.2b1
>corecapture	1.0.4
|IOSkywalk!F	1
|IOEthernetAVB!C	1.1.0
>mDNSOffloadUserClient	1.0.1b8
|IOAHCIBlock!S	316.100.5
|IOUSB!F	900.4.2
|IOAHCI!F	290.0.1
>usb.!UXHCIPCI	1.2
>usb.!UXHCI	1.2
>!AEFINVRAM	2.1
>!AEFIRuntime	2.1
|IOSMBus!F	1.1
|IOHID!F	2.0.0
$quarantine	4
$sandbox	300.0
@kext.!AMatch	1.0.0d1
>DiskImages	493.0.0
>!AFDEKeyStore	28.30
>!AEffaceable!S	1.0
>!AKeyStore	2
>!UTDM	489.101.1
|IOSCSIBlockCommandsDevice	422.101.1
>!ACredentialManager	1.0
>KernelRelayHost	1
>!ASEPManager	1.0.1
>IOSlaveProcessor	1
|IOUSBMass!SDriver	157.101.3
|IOSCSIArchitectureModel!F	422.101.1
|IO!S!F	2.1
|IOUSBHost!F	1.2
>!UHostMergeProperties	1.2
>usb.!UCommon	1.0
>!ABusPower!C	1.0
|CoreAnalytics!F	1
>!AMobileFileIntegrity	1.0.5
@kext.CoreTrust	1
|IOTimeSync!F	840.3
|IONetworking!F	3.4
|IOReport!F	47
>!AACPIPlatform	6.1
>!ASMC	3.1.9
>watchdog	1
|IOPCI!F	2.9
|IOACPI!F	1.4
@kec.pthread	1
@kec.corecrypto	1.0
@kec.Libm	1

Using 0.21.0
My config.json:

    "MaxInboundPeers": 50,
    "MaxOutboundPeers": 50

Node repeatably accumulating peers to about 60-70 and than dropping it to 36.
Is it normal behavior?

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

go: github.com/idena-network/[email protected]: invalid version: unknown revision 041d1524315e

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Hello, I have setup node on a$5 Vultr VPS. Idea was to leave it running to help the network out with peering and bandwidth.

• it has no identity attached to it
• no mining
• BlockPinThreshold 1, FlipPinThreshold 1, Profile: server, MaxInboundPeers 18, MaxOutboundPeers 18, FastSync true
• latest node version
• ubuntu 18.04
• clean VPS, just that one node is running, nothing else

Latest entry in the log is:
INFO [07-04|20:14:42.502] Node is synchronized component=downloader

I guess at that time people are starting syncing their nodes (new people, people that are mining on one pc and then validating on second 🤦‍♂️) and the network gets busy.
Here are full logs.zip

I guess this is simmilar thing to a long forgotten #232
After that fix, i did not run node in a loop, it just was rock stable. Now we need to run node in a loop until this is fixed. I won't run my node in loop so i get notification about when this happen and to see how often it happens. It was not just my one node, it happened to others that I'm monitoring for family members.
If people run node on VPS by my guide they were in problem without loop, if they used idena-manager, it auto restarted it. Im not sure how it acts in client, does it auto restart's it.

Explorer did show lot of offline penalties yesterday before validation

Graphs from vultr console that are showing its activity...

And even more graphs 😄 luckly these 2 did not crash, just went out of sync from time to time on validation day

Node1 with identity, mining on, Digital ocean, $5 droplet

Node2 with identity, mining on, Digital ocean, $5 droplet

I have been looking for the code since 3 weeks, I went to various communities to get the invitation code
I am a developer and want to try to participate in the project, can you give me an invitation code

Peer search are never successful when using config.json provided in Readme.md with latest 0.19.6 node on Linux.
Looks like problem is IpfsConf, sync was started after this section was removed:

  "IpfsConf": {
    "Profile": "server",
    "IpfsPort": 40405,
    "BootNodes": [],
    "BlockPinThreshold": 0.3,
    "FlipPinThreshold": 0.5
  }

Checking the explorer for online-miners, there are several identities being offline for more than 1 hour, having mining-status on and no penalty. Burnt coins amount is 0 in explorer.
This seems to be wrong.

Hei, i have issue about how to get other wallet transaction view in my node is return NULL value after i try to send it. I have try to view last transaction with generated address from node. It get clear result about it.

1. Body JSON from Internal node wallet

{
  "method": "bcn_transactions",
  "params": [
    {
      "address": "0xbd5ca7ee8b302deb0a1a7f72b02efb52ed7fe86e",
      "count": 1
    }
  ],
  "id": 1
}

2. Result JSON from Internal Wallet is OK

{
  "jsonrpc": "2.0",
  "id": 25,
  "result": {
    "transactions": [
      {
        "hash": "0xaf317c97e2ec6d1e56eefa5cead314816864d6cac0003bdac6d1835738024352",
        "type": "send",
        "from": "0x203d4fe4b4ba9c496bafe376603aada1004817f1",
        "to": "0xbd5ca7ee8b302deb0a1a7f72b02efb52ed7fe86e",
        "amount": "0.19999988888",
        "tips": "0",
        "maxFee": "0.000000000000021",
        "nonce": 1,
        "epoch": 42,
        "payload": "0x",
        "blockHash": "0xb5fe9ac1c82838a0bebf6595906fe8a07866a668e6af9bce1d413293a1fc8823",
        "usedFee": "0.0000000000000107",
        "timestamp": 1586795532
      }
    ],
    "token": "0x6f7469bd5ca7ee8b302deb0a1a7f72b02efb52ed7fe86e000000005e94573400000001"
  }
}

3. Body JSON from other wallet

{
  "method": "bcn_transactions",
  "params": [
    {
      "address": "0x203d4fe4b4ba9c496bafe376603aada1004817f1",
      "count": 1
    }
  ],
  "id": 2
}

4. Result JSON from Other Wallet is NULL

{
  "jsonrpc": "2.0",
  "id": 26,
  "result": {
    "transactions": null,
    "token": null
  }
}

please take a look to this or you may give me solution about it, thanks

This is collected from a user FlanelBigMac on discord:
"-latest update
-synchronized an hour before validation
-running off my laptop, not vps
-i have 1000mb internet

A minute or two before validation, there was another synchronization out of nowhere, i heard this happened to a couple people, and then when validation started, nothing was loading for me"

FlanelBigMac.zip

if the key is compromised or you do not like the avatar anymore it might make sense to transfer an identity to a new address/key. Seems there is currently no way to do this.