No, a node cannot steal your seed
When you send a transaction to the node you are connected to, you don't send the seed to it. The tx (=transaction) gets created locally on your PC/Smartphone/other device and it also gets digitally signed with the seed*.
So it doesn't matter if you trust the node you are connected to or not. The only thing that could happen ...
Core Client a.k.a. Full Node
Full Nodes store all transactions since the last snapshot. It is required to be online (= available to its neighbours) 24/7
A Permanode is a Full Node that doesn't do snapshots and stores all transactions since the genesis transaction.
A Light Client does not store any transactions. To make transactions, ...
A Static IP is the best solution if you can get one. If not, a workaround could be using a dynamic DNS service that creates a (sub)domain that always points to your IP address and is automatically updated using a tool on your computer/server. Some of the Dynamic DNS services you could use are:
freedns.afraid.org (if you wish to use your own domain name)...
Cannot think of any problems. Obviously the database dump should be created while your node is down, and the new node should be down too, while you are copying the database.
The database might contain stale (unreferenced) transactions which would not get synced when you did not use a database, but those should not hurt either (if you have the disk space).
After looking into code of IRI : all incoming transactions that aren't known yet (i.e. not already stored in the local tangle) are immediately stored in the local tangle and broadcasted to all neighbors.
There is a send_limit parameter that can be used to reduce the broadcast rate, but the default behavior is the broadcast every new transaction ASAP (...
The wallet doesn't keep an open connection to the full node. Here is the flow :
get the tips (connection required)
do the pow (offline)
post the transaction (connection required)
transaction is pending (no connection required)
Changing the node when you have a pending transaction has no impact on anything.
If you do not own this server, there is nothing you can do other then contact the server owner, then choose a different node to connect to.
A CONNECTION_REFUSED error means that the packet was properly forward to a host, but there was not a process bound to the port on the other end ready to accept that packet.
If this is your server, simply put, IRI is ...
If you are asking about nodes as "client" this is the answer.
Any information about Swarm nodes has not been disclosed though "Nelson" is something different from Swarm, which is a wrapper library for Full nodes that let you use the auto peer discovery feature to make maintaining neighbors easy.
Headless nodes also known as Full nodes are the core backbone ...
First of all, I do not believe you can currently, software wise.
Second of all, this would be a bad idea. Why? You need to ensure that your node is synced and online as much as possible in order to be an ideal neighbor. Your phone will be bottlenecked by data, unless you have an unlimited data plan, as well as times where it runs out of battery and dies, ...
Currently, other than supporting the community (or if you're a business implementing the Tangle internally) there is little incentive to run a full node. The expectation is that the introduction of Qubic (no ETA) will also bring incentives to run full nodes.
you can find a #testnet channel on the new IOTA Discord https://discord.gg/5spymQ, ask there and you will probably find people to connect with.
There is a #testnet channel on the IOTA Slack also, but this tchat will be closed and people are currently migrating on the Discord.
IRI works in simplex mode, meaning that one TCP connection is used for receiving and another for sending.
Your IRI TCP and UDP receivers are automatically bound to both IP addresses via "catch-all" 0.0.0.0 address. This means that your neighbours can select which IP they prefer (provided that both are open to the public, of course). TCP and UDP receiver ...
In a transaction there is no field referring to the node which issued it and I don't think you're able to reconstruct the history of a transaction.
I think you cannot know in any way where a transaction comes from (but I'm not sure, I never tried anything like this)
Considering how the Internet and its routing mechanisms work the hop count is not necessarily a stable metric and would have to be re-evaluated from time to time. Generally speaking though, the hop count is a decent metric to choose peers.
If you look at this paper for example the hop count is considered one of the better of eight metrics to rate "peer ...
The default Maximum Transmission Unit (MTU) for most networks is 1500 (1472 excluding headers). The IOTA paket size is 1650 (transaction + hash(request_tx) represented in bytes (1604 + 46)). To be able to send UDP pakets larger than the MTU, paket fragmentation is used. If fragmentation is disabled (DontFragment DF bit is set to 1) either on your machine or ...
Nodes will not be in different states regarding your balance as long as you don‘t sign bundles.
So you can be 100% sure that you have X Iotas on ADDRESS9 and you can be 100% sure that you have X-Y Iotas on ADDRESS9 after you sign and publish a bundle that spends Y Iotas from ADDRESS9
It makes no difference, if a node does 7 or 700 snapshots a day or if ...
According to the document:
In contrast to
any data stored in the Tangle, the communication layer, therefore, does not
necessarily require the use of post-quantum cryptography right now, but it can
be swapped when quantum attacks become more imminent in the future.
In case of quantum computer attacks become feasible, a dishonest node ...
By verifying a transaction that is invalid, a transaction itself becomes invalid and will never be verified by other honest transactions (i.e. the transaction is on an "invalid path" that others do not recognize so its X Iotas are worthless).
What happens next?
Nothing. The transaction that happens to verify an invalid one will never be confirmed.
No you can't. The only implementation of the protocol so far is IRI and it needs java and quite a bit of RAM to run. You can't even run it reliably on a Raspberry Pi atm. It would also drain your battery to the ground on no time and require constant connectivity with the network.
Since this question is still getting upvotes, here is an answer (more of an approximation) by myself, having kind of a solid knowledge about it as of now, running a node and actively developing stuff for the iri.
When I fire a lot of requests to my node, it here and there crashes. It's not denial of service or anything, but maybe 2 requests per second.
I found the reason of this outlining behaviour.
It was an indication of the issue in communication. Basically my VPS was dropping UDP packets due to their MTU1650 and so it was sending and not receiving anything back.
So for those having the same issue. Try to switch completely to TCP.
It's just the opposite. Your node is sending to these nodes but not receiving anything from them.
Either these nodes have not added your as a neighbor, or you are the only neighbor for them who provides new transactions (in other words, you are the only link of them to the live tangle), meaning that you are "feeding" these nodes with all your transactions ...
It seems to be a client error, because of a large request size. Besides, publishing large files as transactions requires a large amount of Proof-of-Work, which may take time or cause the connection to close depending on remote node settings. It might be a good idea to split file contents into multiple chunks and attach to tangle in a more granular manner.
Using the IRI API, you can use getNeighbors to get the addresses and then getNodeInfo to obtain the latestSolidSubtangleMilestoneIndex and latestMilestoneIndex.
Only works if the neighbors have open APIs.
cURL examples, courtesy of https://iota.readme.io:
curl http://localhost:14265 \
-X POST \
-H 'Content-Type: application/json' \
You want those two nombers to be the same but they also need to be synced with the last Milestone issued by the Coordinator. We used to have a channel in Slack to see this number but I think it is no longer working since the migration to Discord (#botbox). You can check the list of nodes in IOTA Dance Nodes to see the milestone they are at (they will be a ...
Not sure about what could be wrong. You might want to delete the complete database and redownload it by following the Step6 of that guide. Before doing so, my advice is to locate your mainnetdb folder and delete all its contents. Assuming you have it at /opt/iri/mainnetdb you should do.
rm -rf *
Once the mainnetdb folder is empty and ...
The seed is required to generate a private key. The private key is used to sign the transaction. All of this can be done offline.
Finally you send the signed transaction to the node and the node broadcast it the the network. A wallet (except a malicious one) will never send your seed over the network.
I wouldn't call a C++ IRI "better", but more memory efficient. And yes there are more IRI implementations planned, like Go or C#. A real boost will be provided by the Curl-P algorithm. This will make POW faster and more efficient.
Just check the Roadmap:Roadmap