Witholding transactions

[asdf]

I'm not sure if this has been discussed. I couldn't find anything in the forums.

What is to stop miners from withholding transactions from their peers to keep the transactions fees for themselves? They could keep transactions with high fees and only transmit them after they solve a block, thus gaining an advantage.

Sure, any single transaction is transmitted to multiple miners, but if lots of miners start engaging in this behavior, then it's conceivable that honest miners will be missing out on lucrative transaction fees.

How do you guys see this scenario playing out?

[1713544110]

1713544110

[1713544110]

1713544110

[1713544110]

1713544110

[theymos]

The transactions are unlikely to be completely blocked. The sender broadcasts to at least eight peers, and the miner probably gets transactions from ~30 peers. Even if every miner blocked transactions, the non-miner relays would probably be enough to spread the transaction to many miners.

[Gavin Andresen]

What theymos said.  Miners have a strong incentive to be well-connected (as do big merchants and exchangers and anybody else who generates or processes lots of transactions).

[Hal]

I have an even better idea. My transactions compete with those of others for free space in the blocks, so clearly I should forward only my own transactions and block everybody else's. Profit! Off to make a pull request...

[asdf]

What you guys seem to be saying is that there isn't anything to stop (no disincentive) miners from withholding transactions, but it's okay, because they will be well connected and get the transactions anyway. Won't this result in bottlenecks at the nodes that do actually transmit all transactions?

What are these non-miner relays?

[MoonShadow]

What are these non-miner relays?

Basicly every other client that the owner doesn't have enough incentive to bother with making this kind of low-level code change in order to potentially nab a few extra bitcoins.  Any regular client, whether they are generating or not.  Any future 'lightweight' client that can't generate.  And any future client modified as a clearinghouse service for commerce, which would have a vested interest in undermining such self-serving behavior.

[asdf]

What are these non-miner relays?

Basicly every other client that the owner doesn't have enough incentive to bother with making this kind of low-level code change in order to potentially nab a few extra bitcoins.  Any regular client, whether they are generating or not.  Any future 'lightweight' client that can't generate.  And any future client modified as a clearinghouse service for commerce, which would have a vested interest in undermining such self-serving behavior.

That's true now, but in the future I expect code that provides an easy interface to managing the withholding of transactions to be ubiquitous.

Also, it seems to me that in the future, any node that relays all transactions would almost certainly be generating. If you're going to invest in bandwidth and hardware to maintain a copy of the blockchain, you'd be crazy to not also generate.

Will there be any non-miner relays?

Sorry to belabor the point. I may be way off target here.

[MoonShadow]

What are these non-miner relays?

Basicly every other client that the owner doesn't have enough incentive to bother with making this kind of low-level code change in order to potentially nab a few extra bitcoins.  Any regular client, whether they are generating or not.  Any future 'lightweight' client that can't generate.  And any future client modified as a clearinghouse service for commerce, which would have a vested interest in undermining such self-serving behavior.

That's true now, but in the future I expect code that provides an easy interface to managing the withholding of transactions to be ubiquitous.

Also, it seems to me that in the future, any node that relays all transactions would almost certainly be generating. If you're going to invest in bandwidth and hardware to maintain a copy of the blockchain, you'd be crazy to not also generate.

Will there be any non-miner relays?

Sorry to belabor the point. I may be way off target here.

I still think that there will be non-generating clients.  I've been working on a project that would put a client on a Pirate Box (http://wiki.daviddarts.com/PirateBox) that would function in all respects just like any other piratebox, but have an Internet connection for the blockchain.  The point of it all would be to update smartphones over wifi.  The point being to test the possibility of smartphone clients like BitcoinJ in a production environment for the ability to do POS type transactions with the aid of a vendor provided wifi connection, without providing for a complete Internet connection.  I've got a router for the purpose, but have yet to put a pirate box system upon it, much less figure out how to redirect wlan side bitcoin connections to the local client.  In this case, generating is futile, but full handling of transactions are critical.  IF Bitcoin takes off, and then makes the jump to brick&morter vendors, such clients would be everywhere; and very well might outnumber generating clients.

[theymos]

It will never be too hard to just send the transaction to most generators. Right now you can send your transaction to three of the biggest generators and get >50% of the network's CPU working on your transaction. I don't think this will be necessary, though.

[asdf]

I'm still not convinced.

If a client transmits a new transaction to a bunch of miners, isn't it in the interest of each of those miners to not forward that transaction to other nodes, keeping the fees for himself for when he finally solves a block? Yes, miners have an incentive to be "well-connected", but that's not gonna make their peers forward transactions.

What's worse: the bigger the txfee, the more incentive to not forward the transaction.

Can someone chime in on this please. I feel that none of these responses have adequately addressed the issue. Is there some market based mechanism which will counter this behavior?

[Gavin Andresen]

Is there some market based mechanism which will counter this behavior?

Thinking out loud:

If miners (or other nodes) not relaying transactions starts to become an issue, "we" could write code to detect and discourage it.

Detecting: the node says it is a full node but you get many fewer 'inv' messages from it compared to your other peers.

Discouraging: you refuse to relay or build on any new-block messages that you get from that node.

See https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks for a framework for the 'discourage' part.

[Maged]

This might not even need a technical solution; it can easily be solved by the market.

Yes, miners have an incentive to be "well-connected", but that's not gonna make their peers forward transactions.

On the other hand, clients have an incentive to be connected with as many miners as possible to get their transaction mined quickly. If this ever becomes an issue, here's what would happen:
Subscription-based relay network businesses would appear. Clients would use them because it means that they only need to send their transaction once, instead of to each miner individually (I'm assuming that in the future, mining will be more distributed than it is now). Miners would be stupid not to also subscribe to these networks, since it would be the fastest way to learn of new transactions. Plus, the barrier of entry to these businesses would be so low that there would be plenty of competition, meaning low prices for all.

BAM! The market just solved the withholding transactions issue AND the lack of economic incentive to help the network by relaying transactions in one go.

A smart miner would realize that by withholding transactions, they would eventually create this middleman, reducing their own cut of the profits. A smarter miner would be running both a pool AND a relay service.

[pc]

I believe that some people have posited that in the future, the norm will be for transactions to get submitted directly to one's preferred miner, for which one already knows the expected fee schedule. While miners may not have an incentive to relay transactions to other miners, miners do have an incentive to make it easy for people to submit transactions directly to them, so I doubt it will be difficult for people with transactions that they want processed to connect to the miners they want working on the transaction. I don't think this'll become a real problem, although one never knows for certain.

[ByteCoin]

If a client transmits a new transaction to a bunch of miners, isn't it in the interest of each of those miners to not forward that transaction to other nodes, keeping the fees for himself for when he finally solves a block?

Correct!

The current block reward scheme and fees schedule incentivizes miners to implement schemes which arguably harm the network. Similarly, some helpful activities like transaction relaying without mining go unrewarded.  There have been forum posts on this topic before but I'm not surprised that they're difficult to find. I touch on a similar issue in the Most transaction relaying is currently pointless and wastefull thread.

What's worse: the bigger the txfee, the more incentive to not forward the transaction.

Indeed. Also, if the fee is large compared to the block reward then it makes sense for miners to ignore blocks from other miners which include the transaction and try to build a block chain in which they claim the large fee themselves.

If the miners see a double-spent transaction in which the later version includes a very large fee then it would be in their interest to throw away the blocks containing and confirming the first version and build a new chain including the double spend and gaining the fee. Miners who had their blocks orphaned could be reimbursed from the large fees of the double spend.

I'm particularly concerned that there's an incentive for the formation of a mining cartel in which the miners insure that non-cartel miners' blocks become orphaned. The mining cartel could engage in behaviour detrimental to the other users such as refusing to incorporate transactions lacking fees (or lacking inflated fees) into the blocks.

This is just a quick recapitulation of some previous discussions on this topic.

ByteCoin

[Steve]

Merchants (and really anyone using bitcoin) have a strong incentive to get transactions into the hands of many miners...if this ever became a real problem, they could take steps to ensure their nodes remain well connected with miners and relay transactions to them...others could ensure they maintain good connections with those merchant nodes that ensure transactions are relayed.  It seems like it's such an easy issue to work around, and there's such a strong incentive to work around it, that it would be pretty pointless for miners to engage in this behavior.  I'm not sure it would be worth the time to code something special into the client for this.  (also, seeing how fast transactions propagate through the network, I think a few miners engaging in this behavior would have almost no effect)

[DeathAndTaxes]

I believe that some people have posited that in the future, the norm will be for transactions to get submitted directly to one's preferred miner, for which one already knows the expected fee schedule. While miners may not have an incentive to relay transactions to other miners, miners do have an incentive to make it easy for people to submit transactions directly to them, so I doubt it will be difficult for people with transactions that they want processed to connect to the miners they want working on the transaction. I don't think this'll become a real problem, although one never knows for certain.

Why would a client want that.  While I can see making sure your preferred miner gets your transaction it is still in the client's best interest to ensure every single miner sees their transaction.

Say I am sending a transaction w/ a fee of X.
Say also my preferred miner has 20TH of capacity, the entire network has 100TH of capacity, and 80TH worth of miners will accept my transaction at the fee I offered.

Same fee.  I can either have 20TH or 80TH including my transaction in the next block.  I would rather have the option with 1/4th the expected confirmation time.

I can't ever see a situation where a client would *only* want one group of miners to hash their transaction.  They want higher fees with slower confirmations?