When will nodes forward doublespends based on fee?

[mustyoshi]

Miners should be viewed as profit driven entities.

They have a negative incentive to relay transactions, which means you can't depend on being peered with them to hear about transactions. A doublespend is as easy as sending one tx to the miner, and one to the merchant, the miner has no incentive to relay the transaction, so the merchant may never hear about it until it is in the blockchain, and they are out of a payment.

It is for this reason that it should be a standard to break trust in 0conf transactions, because eventually miners will stop relaying transactions so they alone are able to mine the fees.

[1714030180]

1714030180

[1714030180]

1714030180

[1714030180]

1714030180

[1714030180]

1714030180

[Peter R]

To sum up:

The order of transactions is exactly the problem that bitcoin was invented to solve.

The order presented in the blockchain is the only order with any meaning.
 - If you disagree with the order in the blockchain, you are wrong, not the chain.

If you are relying on the order of things not yet in the chain, you are wrong.
 - Bitcoin is not a coercive system.  No one can stop you from being wrong, but you do so at your own risk, and inevitably to your own peril.

If you have an opinion on what order things should be in when they are eventually included in the block chain, you are wrong.
 - Even if you guessed right.
 - Bitcoin is not a coercive system.  No one can force a miner to prefer any ordering over any other.


Not that one can't or even necessarily shouldn't take risks based on undefined future ordering.  The real problem is that some people don't understand the risks they are taking right now.  The network is fairly polite right now and it usually does what you think it will do.  But that politeness is not a property of the system, but an accident of history.

So you would vote "NO" to my poll question here?: https://bitcointalk.org/index.php?topic=502571.0

[gmaxwell]

Nodes? why would they?

Miners— well maybe some already are. How could you tell?

[mustyoshi]

Nodes? why would they?

Miners— well maybe some already are. How could you tell?

In case you had a legitimate reason to change the destination of your coins.

I just think there should be an official feature of the protocol that breaks trust in unconfirmed txs.

Because if mining nodes don't already behave this way, they most certainly will eventually. Better to ween the network off 0 confs early rather than later.

[StarfishPrime]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which was implemented but is 'disabled' in BitcoinQT.

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would not only be considered broken by Satoshi, it would introduce a huge and entirely unnecessary vulnerability to 0-conf transactions.

Replace-by-fee is a very bad idea.

[flower1024]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which was implemented but is 'disabled' in BitcoinQT.

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would not only be considered broken by Satoshi, it would introduce a huge and entirely unnecessary vulnerability to 0-conf transactions.

Replace-by-fee is a very bad idea.

but we cant force miners to do it. if i where still a miner i'd try to maximize my profits.

[StarfishPrime]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which was implemented but is 'disabled' in BitcoinQT.

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would not only be considered broken by Satoshi, it would introduce a huge and entirely unnecessary vulnerability to 0-conf transactions.

Replace-by-fee is a very bad idea.

but we cant force miners to do it. if i where still a miner i'd try to maximize my profits.

On the other hand, the possibility of being disconnected as a rogue/misbehaving node should be sufficient incentive to follow the protocol. Nothing minimizes profits like mining in your own little network of one.

[BTC_Learner]

Satoshi actually included a very useful mechanism in the protocol specifications and data structures which was implemented but is 'disabled' in BitcoinQT.

Using the sequence and lock_time fields prevents a tx from being replaced by another tx after the specified time (or block number, or ever if sequence = UINT_MAX). Essentially all transactions being broadcast have sequence == UINT_MAX, so they should never be replaced if the protocol is followed.

Any "replace-by-fee" mechanism that ignores the sequence and lock_time fields would not only be considered broken by Satoshi, it would introduce a huge and entirely unnecessary vulnerability to 0-conf transactions.

Replace-by-fee is a very bad idea.

but we cant force miners to do it. if i where still a miner i'd try to maximize my profits.

On the other hand, the possibility of being disconnected as a rogue/misbehaving node should be sufficient incentive to follow the protocol. Nothing minimizes profits like mining in your own little network of one.

How does that happen in practice? How do the other nodes in the network decide to ostracize a particular miner or node? And how is this done in a concerted fashion?

[BTC_Learner]

Miners should be viewed as profit driven entities.

They have a negative incentive to relay transactions, which means you can't depend on being peered with them to hear about transactions. A doublespend is as easy as sending one tx to the miner, and one to the merchant, the miner has no incentive to relay the transaction, so the merchant may never hear about it until it is in the blockchain, and they are out of a payment.

It is for this reason that it should be a standard to break trust in 0conf transactions, because eventually miners will stop relaying transactions so they alone are able to mine the fees.

This was helpful. I'm trying to understand better how transactions get propagated on the network, and how that can be controlled.

How does one control who the transactions get relayed to, e.g., deliberately choosing to only send a transaction to a specific miner? Can this be done on any wallet application, or do most wallet apps automatically control the propagation of the transaction on the network? Also, is there a drawback to this, e.g., the fewer nodes that you send the transaction to, the lower the likelihood that the transaction gets picked up in the next block?

What you're describing almost makes double spends seem too easy! It's a little disconcerting, but agreed with your point about the importance of getting that first confirm. I suppose that's the lesson.

[DannyHamilton]

On the other hand, the possibility of being disconnected as a rogue/misbehaving node should be sufficient incentive to follow the protocol. Nothing minimizes profits like mining in your own little network of one.

How does that happen in practice? How do the other nodes in the network decide to ostracize a particular miner or node? And how is this done in a concerted fashion?
[/quote]

Miners broadcast their solved blocks to the peers that they are connected to and rely on those peers to validate the block and relay it to additional peers.  Those additional peers validate the block before they relay it, and so on until the entire network has received and validated the block.

Contrary to popular misconception, bitcoin is a consensus system not a democracy.  Every block and every transaction is validated by every node on the system before sharing it with anybody else.  This means it is very difficult for a rogue miner or group of miners to modify how everyone else uses the system.

If a particular peer that you are connected to sends you an invalid block, your node should discard it and not relay it.  Nobody will hear about the block that the rogue miner created, and their block won't make it into the blockchain. If that same node repeatedly sends you bad blocks or bad transactions, why would you maintain a connection to a peer that clearly is not validating the information before relaying it?  Instead, your node can simply drop the connection to that node, and establish a new connection to a node that behaves properly.  If all nodes do this, eventually that rogue node is isolated.  Meanwhile, eve when not isolated from communicating, his blocks are isolated since no peers will relay them.

[DannyHamilton]

How does one control who the transactions get relayed to, e.g., deliberately choosing to only send a transaction to a specific miner?

The average user currently relies on their wallet to handle this for them.

The typical wallet connects to peers and broadcasts the transaction to all connected peers. Then it relies on those peers to relay that transaction until the entire network has heard about it.

Can this be done on any wallet application, or do most wallet apps automatically control the propagation of the transaction on the network?

Some wallets will allow you to configure a specific list of peers to connect to.  Most wallets will search for peers automatically of you don't configure any.  Once you send a transaction, you have no control over whether or not the peer will relay it or who they will relay it to.

Also, is there a drawback to this, e.g., the fewer nodes that you send the transaction to, the lower the likelihood that the transaction gets picked up in the next block?

If you create a wallet that only sends the transaction to specific mining pools, and if you have an agreement with those mining pools such that they will not relay the transaction, then you are left waiting for your first confirmation until one of those specific pools happen to be lucky enough to solve a block. Meanwhile, the merchant will likely relay the transaction (he has no incentive not to).  So any pool that you don't have an agreement with will be trying to confirm the merchant's transaction.  If the merchant's transaction is confirmed before your secret transaction, then the merchant's transaction becomes valid, and your colluding miners will stop trying to confirm the secret transaction.

What you're describing almost makes double spends seem too easy!

At the moment, most miners and pools seem to relay transactions. Therefore, it would require some conspiracy between yourself and the operators of the pools to pull off the double spend described.  There are no mainstream wallets that assist users in attempting to perpetrate such a fraud either, so you'd have to create your own wallet to do it. If you can convince the mining pool to risk the damage to their reputation for the increase in profit that you will share with them from your crime, and you can create a wallet that will give you the necessary control over the peers that you send the transactions to, then yes it is quite easy.  For this reason it is best to only accept 0 confirmation transactions if you have a trust relationship with the person you are receiving from, or you are willing to accept the risk of loss.

[mustyoshi]

Miners should be viewed as profit driven entities.

They have a negative incentive to relay transactions, which means you can't depend on being peered with them to hear about transactions. A doublespend is as easy as sending one tx to the miner, and one to the merchant, the miner has no incentive to relay the transaction, so the merchant may never hear about it until it is in the blockchain, and they are out of a payment.

It is for this reason that it should be a standard to break trust in 0conf transactions, because eventually miners will stop relaying transactions so they alone are able to mine the fees.

This was helpful. I'm trying to understand better how transactions get propagated on the network, and how that can be controlled.

How does one control who the transactions get relayed to, e.g., deliberately choosing to only send a transaction to a specific miner? Can this be done on any wallet application, or do most wallet apps automatically control the propagation of the transaction on the network? Also, is there a drawback to this, e.g., the fewer nodes that you send the transaction to, the lower the likelihood that the transaction gets picked up in the next block?

What you're describing almost makes double spends seem too easy! It's a little disconcerting, but agreed with your point about the importance of getting that first confirm. I suppose that's the lesson.

I've given thought on how to determine mining nodes, over the course of a couple hundred transactions and blocks, you should be able to determine with great confidence if a node is a miner or not.
By both listening for blocks and sending transactions, you should be able to determine a path of peers back to a mining node.

Like, listen for a few blocks and see which peer gives you blocks the fastest on average, then peer with their peers and repeat. Eventually you will have to start sending transactions (this part is under the assumption that mining nodes do not relay transactions) and see when they don't always get included in a block (telling you that you found a mining node, but it wasn't the one that mined the block).

This process would most certainly take more than a few days to complete, the more nodes you put out into the wild attempting it, the faster it would be accomplished.

Or, you could just assume that a miner's getwork is done directly on their node.

But either way, once you are peered directly with a miner, you are very likely to be able to doublespend under the current implementation of not relaying conflicting transactions.