You can tell parity to avoid scanning private IPs by simply running:
parity --allow-ips public
You can even fine-tune parity to do less aggressive peering:
parity --allow-ips public --no-discovery --max-pending-peers 4 --min-peers 4 --max-peers 8
Or just block reserved IPs via iptables:
iptables -A OUTPUT -p tcp -s 0/0 -d 0.0.0.0/8 -j DROP
iptables -A ...
UDP-based discovery is one of the main paradigms of peer discovery.
For example, Universal Plug and Play (UPnP) uses the UDP-based Simple Service Discovery Protocol (SSDP), and BitTorrent has a UDP-based Local Peer Discovery protocol.
The general method is to multicast (broadcast?) over UDP and see who responds. The fact that UDP is unreliable - i.e. in ...
I had a similar problem like you. Hetzner noticed that the abuse warning was triggered because the host tried to send tpc/udp packets to private network addresses (RFC1918). In order to avoid getting flagged, you can setup firewall rules blocking outgoing packets to RFC1918 networks.
Example using iptables:
iptables -A OUTPUT -p tcp -s 0/0 -d 10.0.0.0/8 -...
With Ethereum alone it's not possible (yet), unless you implement a custom solution.
You should look into:
raiden network: is a lightning network style transaction channel network which allows payments to be securely routed across multiple peer-to-peer payment channels.
polkadot project: is a multi-chain framework that supports interoperability between ...
By using the same blockchain you can interact with a single contract. Make sure that the applications use the same contract address by using for example var meta = MetaCoin.at("0x1234..."). You can find out where the contract is deployed with MetaCoin.deployed_address.
The only challenge is to tell the second application where the deployed address of the ...
I don't know if this is the correct answer, but it might be an idea.
Can you map the public address to the private one with some iptables rules?
I would just open one random port to the public address and redirect all the traffic to the private one.
On the remote machine run geth with the following arguments:
--rpc --rpcapi "admin,personal,db,eth,net,web3" --rpcport "8080"--rpcaddr "0.0.0.0"
They are detailed here, here and here.
On the local machine run:
$ geth attach rpc:http://<remote_ip>:8080
(More) Secure Approach
Connect to the VPS via SSH and run geth locally (...
https://ethereum.stackexchange.com/a/5931/4575 is answer to my question. My main problem was my local time was incorrect.
"Ethereum nodes (regardless of mining) need to have an accurate time, otherwise they will not be able to connect to peers and to the network "
"Common problems with connectivity
Sometimes you just can’t get connected. The most common ...
Ethereum clients use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.
Which TCP and UDP ports are required to run an Ethereum client?
as a firt try use the option
--nat value NAT port mapping mechanism (any|none|upnp|pmp|extip:<IP>) (default: "any")
I am currently using the following UFW rules in addition to --allow-ips public
ufw deny out on eth0 to 0.0.0.0/8
ufw deny out on eth0 to 10.0.0.0/8
ufw deny out on eth0 to 100.64.0.0/10
ufw deny out on eth0 to 169.254.0.0/16
ufw deny out on eth0 to 172.16.0.0/12
ufw deny out on eth0 to 192.0.0.0/24
ufw deny out on eth0 to 192.0.2.0/24
ufw deny out ...
From the Ethereum help:
API AND CONSOLE OPTIONS:
--rpc Enable the HTTP-RPC server
--rpcaddr value HTTP-RPC server listening interface (default: "localhost")
--rpcport value HTTP-RPC server listening port (default: 8545)
if you add --rpc the Geth Ethereum client will activate the rpc client. By default it'll use localhost so it's only ...
If all N nodes connected to all N-1 others, that would require a lot of bandwidth and work managing all these connections. There is a whole field of research dedicated to optimal connections distribution given a desired "network diameter".
Not to forget that certain network topologies, think NAT and port-forwarding, do not allow all nodes to connect to each ...
To establish the connection between two applications, you need a smart contract. This smart contract will be deployed at one end .
The deploying application will use it as contractname.deployed() to create an instance of contract.
As we know that to access any contract on the blockchain, we need :Contract's AbiDefinitionContract Address
Second application ...
Are you trying to connect with code or with a Geth node?
If you just want to connect use:
$ geth attach http://[ipaddress]:8545
If you want to add a node to the Azure based blockchain you will have to use the same Genesis JSON file which can be found here:
This is the default Genesis block used by Azure to provision the Ethereum blockchain.
I have figured this out. I was not using an --engine-signer, so no one was sealing the transactions. Once I specified this flag, I got an error saying the account was not associated with the specified chain. Although I seeded accounts on the chain with ether in the genesis, this is not the same as having accounts on Parity itself. Thus, I needed to set a --...
Found some more information:
nodeId is the secp256k1 public key corresponding to the node's private key.
So the node has a private key and the node ID is the corresponding public key. As the private key is chosen randomly the public key has no significance by itself....
I'm not sure how deep into geth you want to go, but p2p/Server contains a property called "NetRestrict" that allows you to restrict connections to particular IP networks.
cmd/bootnode/main.go is a working example that accepts the "netrestrict" flag. It looks like Geth hasn't quite implemented this yet, but it should be fairly easy to implement yourself.
Yes, you enable tracing on the node for the sync module, like that:
parity -l sync=trace
This will produce a lot of noise, but you will be able to see why nodes are talking to each other, or why not... :p
...if I reboot my router (not closing the console with geth process)
If you want to do this, ensure that you stop the geth process first, then reboot your router. If you reboot your routing while geth is running, there's no guarantee you'll invoke any of its signal handing to close gracefully. This could result in a corrupt database.
See: Is it safe to ...
Most (all?) mining pools will not show your worker until it has generated at least 1 share.
If you are CPU mining, you will probably have to wait an eternity before you get a share.
CPU mining is very, very slow.
You need at least 1 GPU, and even then it might take several hours before you get a share and the pool displays your miner.
In addition to galahad's answer if you are running more instances (nodes) on the same host use distinct ports for each instance. Otherwise you'll only get one peer listening on 30303.
All subsequent peers will fail to bind to 30303. Always specify an IPv4 address for the peer. To my knowledge, (at least in pyethapp) ethereum clients do not support network ...
You're not running on a private blockchain here. Two important things for starting a private blockchain are the genesis file and a separate network. You can mention the path to genesis file with the init command and work on a separate network by using the --networkid command.