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


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

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


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

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 '["...


3

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


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

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.


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


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

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

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


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

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.


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

You need to be running a full bitcoin node like Bitcoin Core, or use a wallet that connects to a bitcoin node. Bitcoin nodes connect to multiple other nodes and distribute the transaction and block data between each other according to the Bitcoin protocol. Blockchain.com is also running a bitcoin node, and will receive the transaction through the network ...


1

The first input of your transaction spends a P2SH 2-of-3 multisig output, but only contains 1 signature. It needs 2.


1

it is more like 3. The client would send the tx to a full node (let aside the complexities of SPV clients), and this full node would verify the tx by some pre defined rules. If ok, this full node transmits to other full nodes. The transaction only gets valid, if it was mined into a block. So the server you mention can be several blocks behind, but still can ...


1

So the issue you describe is that half of nodes consider chain+A valid and half consider chain+B valid. The situation gets resolved when the first subsequent block is mined, let's say it happens to be the one from the miners on the chain+A. Now we have the situation: chain+A+1 vs chain+B. At this point all the nodes switch to longer chain: chain+A+1. EDIT:...


1

The main disadvantages, are you are trusting the third party to actually relay the transaction, that third party can now link you to the bitcoin being moved in your transaction, and you are trusting other people running full nodes to verify your transaction. Your most secure and privacy-centric option would be to use a wallet which relays your transactions ...


1

When a transaction is orphaned it usually means that it is part of an orphaned block. This happens occasionally so there is no reason to panic :) According to Anonymous in this answer, orphaned transactions are not lost and are returned to the memory pool where miners can pick it up again and attempt to confirm it. In short, as long as the transaction ...


1

I found what I was looking for. Blockr.io has a good service for publishing transactions to the network. This is the url that you would send a post request to http://btc.blockr.io/api/v1/tx/push Make sure to send it the transaction as a post request like this: {"hex" : your transaction in hex}


1

Coinbase has been hit-and-miss for me for the past month. For example I've had: 1 "instant transfer/buy" that took 23 hours for the coins to arrive. The next day, before my original purchase arrived I needed to make a small additional order to compensate for a rate drop and that one went through right away. More recently I've had outgoing transfers that ...


1

Yes. All the data you need to assemble it is there on blockchain.info. Just follow the TX format and you can do it. I did it myself, so I can assure you that it would work. https://en.bitcoin.it/wiki/Protocol_specification#tx


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