We changed our privacy policy. Read more.
7

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 ...


5

Do all the miners have one global pool filled with transactions Different full nodes have a different version of the mempool. Transactions are broadcasted to the bitcoin network on a best effort basis. If a transaction never reaches a node, it would not include it in the mempool. It would not learn about this transaction until it is included in the block by ...


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

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 ...


4

Brian from Coinbase here. Sorry you experienced delays! There have been some issues in the past that we are working to improve. Coinbase sends a high volume of bitcoin transactions (often in parallel across many machines), and as a result we sometimes encounters issues that are uncommon elsewhere. In this case, I believe the root of the issue was around ...


4

You can use the ZMQ interface to receive a ZMQ notification when a new transaction is received. You can have it give you the txid, the raw transaction, or both.


4

To transact in Bitcoin you will need to broadcast the transaction to the Bitcoin network. At this time an internet connection on your phone is going to be a requirement, a wifi hotspot at the cafe is all you need. In theory there are other ways to get the transaction to the network for example sending the transaction directly from your phone to the point ...


4

The transaction you're trying to send spends from an segwit input, but BitPay Insight does not currently support segwit. On segwit-supporting software, the transaction is valid: $ bitcoin-cli testmempoolaccept '["...


4

You can only broadcast transactions if your node has synced to the point that it knows the outputs that were spent. This is because your node will always validate a transaction before it broadcasts it. If it has not synced to the point that it knows the outputs that your transaction spent, then it won't have the information necessary in order to validate the ...


4

So far, Bitcoin Core rebroadcasting is a wallet-level responsibility. Transactions that aren't relevant to any of the Bitcoin Core's internal wallet are not rebroadcast at all. There is work to change that: https://github.com/bitcoin/bitcoin/pull/21061. This makes sense, as right now, observing a rebroadcast is a very clear sign that the transaction belongs ...


3

Nodes communicate by gossiping about new data to their peers. For example, whenever a new block is found, a node that hears about it, will tell all its peers "Hey, I've got a new block with the identifier , you want it?". These announcement take the form of "Inventory messages". They consist of two elements: The type of data being offered (i.e. transaction, ...


3

It doesn't seems to be a better solution than waiting. The original transaction (the 4 inputs 2 outputs one) has been relayed by the Electrum node that received it and spread over the network, therefore, it's in the mempool of the network nodes. Every transaction that tries to spend the same UTXO referred by the first transaction will be marked as double-...


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

You should not use an online service for broadcasting transaction. This online-service would have full control (censor?) over your transaction. The service could analyze your data behavior and/or decide to not broadcast your transaction regarding some rules. Wladimir van der Laan (current bitcoin-core project maintainer) has written a neat tool: https://...


3

If a solution is found by a miner, does the miner have the control to which nodes is it broadcasted? Certainly, they can control the first level of peers they broadcast a solution to. However, they have no control over which peers will receive the block from the peers they have sent it to. It is in a miner's best interests to broadcast it to as many nodes ...


3

When a node shuts down cleanly, it does flush the mempool to disk and reloads it upon startup. It will not rebroadcast the transactions. A node will only relay transactions once, when it first learns about them. Your wallet will cause its own transactions to be rebroadcast. There is currently no mempool-based mechanism that rebroadcasts any foreign ...


2

Because it doesn't re-broadcast any non confirmed transaction, it re-broadcast only your own non-confirmed transactions. So you will be the only node on the entire network who is doing the re-broadcast every exact 30 minutes and based on this anyone can get what IP is originating that transaction. A few lines below your code example you find this: ...


2

Multicast just doesn't work very well over the Internet. Relaying just works better. One big problem is that multicast provides no way to police emitters of junk while relaying allows each relayer to verify information prior to relaying it, preventing an attacker from getting amplification.


2

All nodes will delete the shortest block-tip before they even hear about the other broadcast. This assumption is incorrect. For Bitcoin Core (and since all full nodes are either Bitcoin Core, modeled off of Bitcoin Core, or forked from it, this applies to basically all nodes), all blocks which have a valid Proof of Work and a few other things are written ...


2

Transactions are not directly sent to the node that holds the private keys for the addresses involving it. Rather transactions are broadcast to all nodes on the network and then recorded on the blockchain. When a node rejoins the network, it downloads and verifies the blockchain from its peers. When it does that, it scans the blockchain for transactions that ...


2

We can find all instances in the code where the client will send a block message by searching for PushMessage("block". This is the only match: void static ProcessGetData(CNode* pfrom) { [...] pfrom->PushMessage("block", block); (Source.) This means that the standard client only ever sends a block message when specifically asked for it. That ...


2

You cannot simply rebroadcast a bitcoin transaction on the bcash chain, due to replay protection. You need to sign the transaction using the SIGHASH_FORKID as the error message says, which means you will need to use a BCH wallet to resign the transaction


2

What i was looking for is submitblock RPC call.


2

Since OP has asked for a specific reference, I'll copy some relevant text from the Mastering Bitcoin reference book. I cut some of the less relevant info out, and added bolded emphasis that is relevant to OP's question: From chapter 8 - Transaction Pool: Transaction Pools Almost every node on the bitcoin network maintains a temporary list of unconfirmed ...


2

Compressing a more-or-less random number is futile. Your best option is simply to use a more compact encoding. Base64 is better than Hex but there exists may other encodings that prform better Wikipedia lists many and ranks them in order of efficiency Encoding Data type Efficiency yEnc Arbitrary, mostly non-text ...


2

What you describe happens normally and is not an issue in practice. Even if one eventually wins out wouldn't a lot of people lose money because of how many transactions were invalidated? No, those transactions are included in later blocks. I'm not sure of the exact method but I think it must be either that nodes return transactions from stale blocks to ...


2

mockscheduler is a hidden RPC. This means that it will not be displayed when using the help command, but you can still use it by just calling it as usual. E.g. to do the same thing as this line in the test, you would do bitcoin-cli -regtest mockscheduler 900 sync_mempools() is a function which just waits for the getrawmempool results of multiple nodes to ...


1

It depends. If your UTXO is a segwit UTXO, then yes. You will have everything that you need to know to calculate the txid before you signed the transaction. If your UTXO is not a segwit UTXO, then no, you cannot know the txid until you sign the transaction. This is because with spending non-segwit UTXOs, the signature is part of data that is hashed to ...


1

You need to wait for the transactions to be confirmed in a block. The limit is on the number of unconfirmed transactions that can be chained together and is completely unrelated to how quickly the transactions were received. The chain can only be extended once the unconfirmed transaction chain shrinks, and that can only happen as transactions are confirmed. ...


1

All peers are treated equally when relaying chain-extending blocks (as James C. stated in a comment on another answer). The node will announce the block to all of its peers and since that block was just found, all of the peers should request the new block. Many miners will also announce new blocks on Fast Internet Bitcoin Relay Engine (FIBRE) in addition. ...


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