Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

16

First the "why it matters": Fibre (Fast Internet Bitcoin Relay Engine) is a protocol which attempts to deliver Bitcoin blocks around the world with delays as close to the physical limits as possible. This is very important because Bitcoin mining is intended to be a fair lottery: If you have x% of the hashrate you should find x% of the blocks, on average. ...


14

As long as the block reward is much higher than the transaction fees, this is totally not an issue: mining isn't an incremental process, it's a bruteforce probabilistic one. I.e. in a single moment your chance of solving a block isn't higher if you have been mining that same block for some time: the chance is always the same. Hence, once a block is relayed ...


11

Bitcoin is a so-called gossip network. They announce any new object to all of their peers (just the hash of the data). If the peer doesn't know the object yet, it asks for the full object. So it's certainly not a DHT or any smart organisation of data: every (full) node (eventually) learns about every block and transaction. They have to, there is no other way ...


9

There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating. In fact, this idea is part of BIP 37, which ...


9

Blockchain.info lists the first IP address it sees a new transaction from. If you aren't the one creating the transaction, and aren't accidentally the node right in between the node that does and blockchain.info, it's unlikely that you're the first to do so. Furthermore, they may not even be connected to you the whole time. To see what transactions are ...


8

There benefit is that you operate a full node in the Bitcoin network. Yes, this is your premise but it's also the consequence of it. You merely seem to not understand what operating a full node means. If you don't operate a full node, you put trust in others. How much trust you put in others depends on the specifics. For example, a person who uses a web ...


7

When a node discovers a new block, it will send an (unsolicited) inv (inventory message) to announce the new block to its peers. The peers should then respond by sending a getdata message requesting either the header, or the complete block. The Developer Reference describes the exchanged messages in more detail. The nodes will then check the header, and ...


6

A transaction can go in a block if it's valid (references inputs that are already in the same or previous blocks, scripts are legal and return success, and signatures validate ok), regardless of whether any other nodes have ever seen it before or not. So if a "selfish" node associated with a particular miner receives a transaction, it's perfectly free to ...


6

get set of UTXO. Note: nodes don't download the UTXO set directly, they download the entire blockchain and build their own UTXO set as they verify the blockchain. How does a node tell other nodes these requests? Like git, are there commands like 'pull requests'? Nodes communicate with each other directly via a P2P protocol, sending different types of ...


6

The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it. BIP ...


5

The core problem with hoarding is risking work on an orphan chain. If you horde a block and start working on its successor you risk the network finding another legitimate block and forking the master block chain. If that is the case (unless you have significant processing power behind you) you will be working on a branch that will be orphaned in favor of a ...


5

The Bitcoin protocol specification can be found on the Bitcoin Wiki. The Network wiki page has information on how information is relayed using the protocol. Clients exchange messages over TCP/IP. With this messages, they can express their state of the blockchain and request others to send them parts they do not yet own. When you want to broadcast a new ...


5

To submit a valid block to the block chain you don't use the hash, just the block. That's the block header plus the transactions. Use bitcoind's submitblock RPC call. > bitcoind help submitblock submitblock <hex data> [optional-params-obj] [optional-params-obj] parameter is currently ignored. Attempts to submit new block to network. See https://en....


5

Bitcoin will run over Tor. There an article on the Bitcoin wiki that explains the process. Just install Tor and let it set up a proxy on its default IP (127.0.0.1) and port (9050). For bitcoind, use the flag --proxy=127.0.0.1:9050. For the GUI client, under Options, check Connect through socks4 proxy. Set the proxy IP to 127.0.0.1 and the port to 9050.


5

Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history. The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a ...


4

By simply adding addnode=68.168.105.168 to your bitcoin.conf file then any transaction you send will automatically be broadcast and eventually make it into a block. No one but you has to add this node and nothing special needs to be done beyond this one configuration. Now it may be true that the bitcoin-qt client will not actually allow you to send a ...


4

Nothing. That's why you send your TXs to several nodes. Non mining nodes do it "to keep the whole thing working" as long as it is very cheap. Because of this miners can't keep TXs for themselves and thus do not even bother to try and keep TXs secret. Maybe they also have a better conscience that way. :)


4

There's no need for an additional incentive. It's enough that the sender wants to send it and the recipients want to receive it. The miner who found the block wants to get it to as many people as possible so they get the reward. The other miners want to receive it so they can build on a longer chain. That is sufficient. If it ever got to be an issue, which ...


4

Stale and orphan blocks are confusing terms with many meanings, depending on whom you ask. If by stale blocks you mean "blocks that are on branches off the main chain, but are otherwise valid", yes, those still exist. They are inherent to proof-of-work chains, as you can't avoid the case where occasionally two miners produce a competing block. Necessarily, ...


4

Whomever originates the transaction (the sender) wants their transaction completed as quickly as possible, especially if they attached a big "incentive" (fee) to it. So they will announce their transaction to many other nodes. Nothing really forces those nodes to share the transaction with all other nodes, although they are supposed to share it. But the ...


4

BIP 62 proposed to make transaction malleability impossible. No it didn't. It would have outlawed a limited number of known and addressable forms of malleability. In particular, it did not prevent multisig transaction participants from just creating a new signature, malleating the transaction without invalidation. This type of malleability is trivial to ...


4

It isn't as simple as "sending sequentially" or "sending in parallel". Each connection is its own socket and the kernel performs packet scheduling. The Bitcoin protocol doesn't have any acknowledgement. When a node sends a message it hands it to the TCP stack which often will just immediately accept the whole message. It's then up to the kernel to send it ...


4

Will the miner simply ignore that block? Yes, the block will be just ignored by the miner. how will the miner update to A-B-C-D-E (step by step)? When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a version message, which contains all basic identifying information, including BestHeight (the ...


3

This allows the bitcoin node to operate similar to a SPV client. These nodes advertise their capabilities to other nodes as they peer with them. A node running in blocksonly mode will indicate that it does not want to receive inv messages from any other peers. Nodes can supply a bloom filter if they are interested in messages for specific address(es), ...


3

Miners have spent money on mining hardware. The value they are able to get out of that mining hardware is tied directly to the price of Bitcoins and the mining difficulty. If the price goes up, that will incentivize some additional miners and if the price goes down, more people will mine. But this doesn't happen immediately nor does it cancel out perfectly. ...


3

No, that is not correct. Transactions can happen in parallel, asynchronously, and do not need to wait their turn. When someone creates a transaction, they send the transaction statement to their peers. Those peers verify the validity of the transaction, i.e. they check whether it adheres to the rules of the protocol, then in turn will inform their peers ...


3

The waste ratio you are talking about is different from the one mentioned there. What you are talking about is the difficulty: if the network's total hash rate is X hashes/second, then the difficulty is set such that it requires 600*X hashes to create a block on average. This does not mean that separate miners are wasting their work, because if the ...


3

Without verifying the transactions themselves, there's no guarantee that the transactions you get from either method are valid. Nodes can lie about what transactions they have in their mempool, for example, and send you gibberish. On the flip side, nodes also don't have any obligation to send you transactions that they have. There are non-standard ...


3

There are a few issues with this proposal: No transaction could ever be confirmed in less than ten minutes. We already have plenty people up in arms that choose to rely on zero confirmation transactions. Waiting at least ten minutes would increase confirmation times. Every node has their own mempool and they don't necessarily match. Every node receives ...


3

Surveillance nodes in the Bitcoin network that mass-connect to many nodes within the network could pin-point and identify your node as the first relay for some of your transactions with some degree of confidence. Receiving is not so much of an issue. But spending from the same address consistently will enable surveillance nodes to figure out that a ...


Only top voted, non community-wiki answers of a minimum length are eligible