9

Yes, Bitcoin Core will try resending the transaction until it confirms or is replaced. You can make it forget the transaction by starting Bitcoin Core with the option -zapwallettxes=<mode> Then, be sure to use the inputs in another transaction, because the transaction is still valid and might yet be confirmed. The only way to invalidate it is by ...


9

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


7

In theory, that would be ideal if your goal is solely getting the transaction to mine. Hurts permissionless mining However it does require knowing how to reach miners directly. Mining is designed to be a permissionless business, accessible for anyone with the right hardware. Your solution would require publishing the IP addresses of miners to all ...


7

Given some time for network latency, do messages reach absolutely all connected peers and how long it takes for them to do that? Usually, standard transactions that pay a sufficient fee to be acceptable to most mempools, without any conflicts on the network will reach almost all nodes within a minute or so. However, there is no guarantee whatsoever that it ...


7

The version of the mined block is 0x2fffe000 instead of 536870912. Many miners employ a strategy known as overt Asicboost. This strategy requires modifying the version number like the nonce, so we often see blocks that have strange version numbers. Only 194 transactions from the block template are in the mined block, e.g. ...


5

Bitcoin is a peer-to-peer gossip flood network. Whenever a Bitcoin participant creates a transaction, their wallet software submits it to its peer nodes. These peers then relay it to their peers in turn. The transaction floods through the network and reaches most nodes. Eventually, the transaction is included in a block which makes the transaction part of ...


4

They don't, essentially, the numbers given for this sort of thing are generally meaningless. Many of these services attempt to connect to a large portion of the listening network and gain insight into the chance of a transaction confirming, however this is not a measure of safety for transactions. A transaction having been announced by many nodes does not ...


4

It is propagated server-to-server and, with luck, eventually gets to a bunch of miners who will include it in a block. There is no central authority -- individual servers are free to propagate transactions using whatever rules they wish.


4

The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are many good changes that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just ...


4

Going out on a limb here, but I would guess that your node is not running 24/7. Full nodes only rebroadcast transactions once when they first hear about them. If your node is only online intermittently, it would only hear about new transactions getting submitted to the network. However, each node builds its block templates from the mempool that it locally ...


3

There are also the 'standardness rules', which are separate from 'validity rules'. So this means a transaction can be either valid and standard, valid but non-standard, or invalid. A node can choose to broadcast any transaction it would like to the network, or none at all. If a node broadcasts invalid transactions, then it is likely that its peers will ...


3

Blockchain explorers run nodes which have connections to other nodes. They may have hundreds of connections. They likely also run multiple nodes for both redundancy (in case one node fails, they are still online) and to ensure that they are receiving transactions from as many sources as possible. So they will be connected to hundreds, maybe thousands of ...


3

The sender, recipient and transferred amount are already public information and readily available in the blockchain. The only special access that miners have is that they could log the ip address of users that directly submit transactions for mining, if such a direct access is offered. Besides that there is no special information available to miners.


3

Adding more advanced prediction of what transactions are useful to prefill was probably intended as a TODO when Compact Blocks were implemented, but to the best of my knowledge, nobody has worked on it since. It is worth pointing out that Compact Blocks in practice (and in non-adverserial situations) works extremely well. On my own long-running node, as of ...


2

Verify() verifies if the transaction is properly signed. Since Verify() doesn't really tell us if a transaction will successfully propagate It is either untrue or you found a bug. node.SendMessage(new TxPayload(tx)); should be perfect. However Stratis is currently building a Bitcoin .NET fullnode, with the lead of Nicolas Dorier, NBitcoin's creator,...


2

Generally, all full nodes should receive your transaction within a few minutes easily. There are a few exceptions, though. Non-standard transactions will only be propagated once they are included in a block. That also means that if you're sending a segwit transaction, non-segwit nodes will not add it to their mempool or propagate it as it appears non-...


2

You cannot reliably get such information. The best that you can do is ask individual nodes whether they have seen your transaction (by sending getdata messages and seeing if they respond) but even then, not all nodes will respond. It is impossible to ask all nodes (as not all nodes are listening so you cannot connect to all of them) nor is it possible to "...


2

Yes, there is what is called transaction trickling. This is a mechanism to select a random peer for immediate forwarding of all transactions, while others receive the transaction after a random timeout. This is done in order to reduce the chances of fingerprinting the origin of a transaction. Similar to the proposed dandelion paper, it forwards a transaction ...


2

Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well. When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (...


2

How does bitcoin prevent accidental forks like this? It doesn't. Bitcoin make little effort to prevent forks at a technical level, instead relying on the fact that when a fork does happen, it can be resolved by waiting for additional blocks and picking the chain with the most work. As Pieter mentioned, the mining mechanism itself prevents long term forks. ...


1

Each full Bitcoin node has what is known as "mempool". mempool is where transactions are stored in preparation for propagation into a proposed block during the mining process. It's somewhat counter-intuitive but each node has it's own mempool and transactions (as they are posted by BTC users), will be propagated throughout the network and be stored ...


1

Miners are incentivized to always mine at the longest valid chain tip. If there were incentives to not mine on the longest known chain, then we would expect the network to be unable to maintain consensus on the blockchain's state. And without that, it would be impossible to build a reliable financial system. So it isn't about 'miners conceding a shorter ...


1

In the case of confirming that a transaction has been successfully submitted, failure to use mempool as a distributed pool means you'd have to query that one "mining node". Example: I send a transaction with my wallet directly to that 1 node to pay for a service. The service gives 10 minutes to see the transaction before invalidating the entire thing. Unless ...


1

Such Transactions cannot be proceeded without output from their parents. Hence they are also removed from the mempool


1

What does bitcoin-cli getmempoolinfo spit out? You may want to increase the maxmempool config value.


1

how do you determine if that peer created the transaction or if it is simply relaying the transaction You cannot, at least not with absolute certainty. This is by design: it helps preserve the privacy of users on the network. That said, if you decided to run a whole bunch of nodes, and positioned them carefully in the network graph, then you could start ...


1

Bitcoin uses a gossip protocol to transmit blocks and transactions. When you connect to the Bitcoin network, your wallet becomes a node on that network. It maintains one or more connections to other nodes. When you send a transaction, you send it to all of the nodes that you are connected to. Then they check the transaction against their node policy rules (...


1

Can we take for granted that if in time period t there were 10,000 connected peers (no new peers connecting, no peers disconnecting), all with good internet connection and hardware, then if every of those 10,000 peers originated one transaction (or any kind of message) to his peers, can we take for absolutely granted that eventually every single one of those ...


1

In order for a node to relay a transaction, the transaction must satisfy the node's minRelayTxFee. This fee rate cut off is by default set to 1000 satoshi per kvB (= 1 satoshi per vbyte). Your first transaction could get included in a block if the miners were aware of it, but likely it doesn't reach them. You should try to either broadcast the first ...


1

Used Bitcoin protocol over TCP/IP protocol. You can read more on this link https://en.bitcoin.it/wiki/Protocol_documentation#Message_types


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