21
The Bitcoin system doesn't have just one network protocol: Any way of obtaining the blocks is equally valid-- blocks over freenet, over satellite broadcast, over the P2P network, all work just as well and are used in practice. UDP is used with bitcoin too, by the Fibre protocol.
As far the common Bitcoin P2P protocol goes UDP is not an especially good ...
7
I wanted to start mining bitcoin from the genesis block
I'm pretty sure regtest will let you do that.
why wouldn't the peer just let me mine on my own chain and not broadcast my results to anybody?
Because that would be pointless. You're not confirming transactions, and you won't get rewarded for your mining. Your chain will probably be overwritten the ...
6
When a node requests one of it's neighbours for a list of it's peers, that node responds with a list of all of it's neighbours.
No it doesn't. It responds with list of nodes that its aware of being claimed exist. It likely isn't connected to any of the nodes it returns and probably has never connected to many of them. Many of them may not even be real. (...
5
Old question, but answer might be helpful for someone.
To get a raw transaction append:
?format=hex
to the transaction URL.
For example:
https://blockchain.info/tx/1b087a7aebdd06740bd4ffefba076562b582a97f02cedf2cd32f53f7eb0b3c8c?format=hex
5
Node1 announces block B3, using an 'inv' message with B3's gash.
Node2 does not know about B3, or its parent B2, but does know the grandparent B1. It sends a getblocks message, starting from B1, but stopping at B3.
Node1 replies with an inv for B2, but not with B3 or any potential successor B4 thay may have appeared.
The purpose is just avoiding sending ...
4
Bitcoin only connects to them specially when you don't have enough nodes, and then it will disconnect as soon as the seednodes give you a nodelist. Bitcoin might choose to connect to seednodes as regular peers as well, but they're not given any preference.
4
You only see the balance of blocks that have at least another 100 on top. This is because coinbase outputs only become spendable after 101 confirmations (the maturity period).
After the nodes reconnect, and one block is mined by node0, node1's previous chain is reorganized away, and from that point on, both nodes work on the same chain.
However, whenever a ...
4
I got the answer myself. Sorry!
The src/net.cpp has this logic which explains all:
void CNode::BeginMessage(const char* pszCommand) EXCLUSIVE_LOCK_FUNCTION(cs_vSend)
{
ENTER_CRITICAL_SECTION(cs_vSend);
assert(ssSend.size() == 0);
ssSend << CMessageHeader(Params().MessageStart(), pszCommand, 0);
LogPrint("net", "sending: %s ", ...
4
When your node is not accepting inbound connections (either because there's NAT in the way or because you passed -listen=0 to Bitcoin) it still makes "outbound connections." These are connections to other Bitcoin nodes that are listening on a public port. Your node makes a maximum of 8 outbound connections. (Source.)
When you make an outbound connection, ...
4
Just use a testnet dns seeder.
Type this into your terminal:
dig A testnet-seed.bitcoin.jonasschnelli.ch
or
dig A seed.tbtc.petertodd.org
for IPv6
dig AAAA testnet-seed.bitcoin.jonasschnelli.ch
4
It returns some plausible peers, not all of its peers.
You have no way of knowing any specific details about them, if they’re sybil, not operational, or not useful. The software tries to work out what is most optimal for outgoing connections based on its own criteria, and doesnt trust this information for anything besides a hint towards where other peers ...
3
Bitcoind will never make more than 8 outgoing connections. By default, it will allow up to 128 connections (see -maxconnections), but that includes incoming ones.
Available connection slots of fully synchronized nodes are a limited resource on the network, so they shouldn't be wasted. As long as you have enough connections to be sure that at least one is ...
3
The easiest way to get peer information is via the JSON RPC interface has a command getpeerinfo. Each peer returns a JSON object containing peer IP address info, connection time, version and subversion of the client.
You would probably be interested in this: Bitcoind API
Edit: Although this is not a way to read the database I presume that the data ...
3
My current real-time estimate using https://github.com/ayeowch/bitnodes is 8000 to 10000 nodes that are reachable at any one time with churn rate of 300 to 500 nodes every 5 minutes. The churn could be due to several factors, e.g.
Node went offline
Node reached max. allowed connections
Time of day, e.g. more nodes are online during US working hours
Network ...
3
Does anyone know where to find a reliable source for finding out a total amount of active bitcoin nodes?
http://getaddr.bitnodes.io/ tracks listening peers on IPv4 and IPv6 only. The number is subject to gaming if people desire, there's no assurance that any of the nodes there are actually useful to connect to. At least some of the nodes listed will be ...
3
Proof of work is what makes Sybil attacks very difficult. Put simply, you trust the chain with the most proof-of-work on it. This cannot easily be faked (at least without significant mining power). It is possible that all the peers you happen to connect to give you false information, but at any time, if you have even one peer that tells the truth, this can ...
3
You can add them to each other nodes bitcoin config file. If you want to connect to a specific node among others, use addnode=IP:PORT in your config. If you'd like to only connect to your own nodes and not other nodes on the network, you can use connect instead of addnode, but of course you should have at least one outgoing connection to get blocks, etc :)
3
Does freshly installed bitcoin-core node have genesis block included in the installation?
Yes.
This fresh node contacts some peer for downloading blockchain. Can malicious peer give node wrong chain? Is this attack possible and how is it mitigated in bitcoin?
There is no way for the chain to be "wrong" that would not be detectable to the node. If it's ...
3
... it needs to fetch peers from a centralized source.
Not exactly. Once you are connected to the network, you will begin to receive lists of IP addresses and ports of known clients.
There is a list of seednodes built into Bitcoin. These addresses are only used as a last resort.
After you connect to the network once, you won't need to use the DNS seeds, ...
3
either I broke some rule, or the other person did; In this case, how does my client find a trusted peer
Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the ...
3
Within the data directory for your coin (/dir/for/yourcoin/.yourcoin) you will have a configuration file. Within this configuration file, you will want to place the line connect=IP ADDRESS:PORT
This will make your client automatically attempt to establish a connection with the node(s) you specify.
Example: within myaltcoin.conf place the line connect=192....
3
The list is just for bootstrapping, no need to manually list peers unless you have others you specifically want to maintain connectivity with.
2
No, very little of the time for downloading new blocks is actually related to network transmission.
Most of the work being done is the I/O against your hard drive as the program writes data to the BDB database storage. If you are on an encrypted filesystem, the problem is exacerbated. There is some CPU work as the elliptic curve encryption is used when ...
2
Use the getpeerinfo RPC command (available since v0.7.0).
2
First, setup add the following to your bitcoin.conf to enable RPC (of course, you can use other values):
rpcuser=user
rpcpassword=Pa55w0rd
rpcport=8333
server=1
After that, restart bitcoin and use following command to get IPs of all peers connected (you can probably make the parser part shorter by using perl instead of grep/sed):
USER=user
PASSWORD=...
2
The client connects to peers in its database randomly (?) so even if given a set of IPs of peers in which all IPs are invalid (connection fails), the client will only be slightly disrupted by this.
A node with a lot of invalid IPs in its list of peers may take longer to find a peer that it can connect to, but at the same time that lack of connectivity ...
2
All that is needed is a number of miners sufficient so that a consensus of bad actors gains control to disrupt the blockchain doesn't happen.
Transaction fees are a tiny fraction of the level of the block reward subsidy ( still not exceeding 1% ) but as bitcoin is more widely used, the fees will eventually make up for the lowered subsidy. That's what is ...
2
You can hover over the "Online" indicator to see the number of peers.
It should only take a few seconds to find more peers. This is dependent on the Bitcoin network though. You can force MultiBit to attempt to connect to a whole new set of peers by restarting it.
2
Have a look into the specifications https://en.bitcoin.it/wiki/Protocol_specification
Check the "inv" --> "getdata" --> "tx" sequence of transaction distribution
2
Having control over BGP and being able to split the Internet in two pieces can indeed be used to carry out an attack against some Bitcoin users. It might not even be that economically infeasible as you may think.
The adversary does not necessary need to have a control over a big portion of the Internet backbone infrastructure - he only needs to cut off a (...
Only top voted, non community-wiki answers of a minimum length are eligible
