Ordinarily transactions are broadcasted to the entire network for anyone to process. The miner who first finds a solution will get the fee for that transaction.
I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.
Ordinarily there would be no advantage to give your transactions privately to just one miner; if you broadcast it publicly there will be many more miners working on it, so it will commit faster. So unless you are deliberately trying to overpay (like here) it would be a waste of money.
> I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.
That's not really a good description of how this will work. Each miner maintains a transaction pool of transactions that have been broadcasted across the network. Think of it as a priority queue. Transactions are of different sizes and fees, and the miner is trying to maximize their total fee up to the 1 MB block size limit. These transaction pools are largely the same across all miners, with of course some differences owing to time delays and network propagation issues.
So all that would happen in miner tumbling is that the miner maintains its transaction pool as normal, but then additionally adds in the special transaction that it does not rebroadcast. The end result is you end up mining a block that has almost the same transactions in it as any other miner would, except with that one extra special transaction, and a low priority one being bumped.
I might be wrong, but I feel you gave a lower-level (more detailed) description of "the idea here is that you instead privately give the transaction to only your favoured miner".
The comment I replied to said several things that are wrong. I understand that it was attempting to give a higher-level overview, but it did so in a way that made things inaccurate. Let me break it down.
> Ordinarily transactions are broadcasted to the entire network for anyone to process.
Process is sort of inaccurate here (it implies mining). Transactions are broadcast across the network in a P2P manner amongst all full Bitcoin nodes, so long as they validate anyway. Miners themselves are running full nodes, and find out about transactions because they come across the P2P network.
> The miner who first finds a solution will get the fee for that transaction.
Miners aren't trying to "find a solution" to transactions. That description isn't accurate. What miners are trying to do is figure out what nonce to insert into a block (which includes a lot of transactions, along with metadata) such that the hash of the entire block is less than some very small target number. Understandably, this takes a large amount of tries, to the point where you have mining pools that distribute ranges of nonces across a large number of workers to pool their effort (i.e. distributed computing).
> I think the idea here is that you instead privately give the transaction to only your favoured miner.
This part is correct.
> He will then try to hash it
Nope. Transactions are static. They always hash to the same value. What the miner is doing is trying to find a valid block. The miner isn't doing anything to specific transactions other than validating them, which any full node does.
> and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.
Nope. All valid transactions are broadcast by all full nodes as part of the normal P2P operation. What the comment was trying to talk about was broadcasting a valid block. There is no "solution" per se -- there's no guarantee that a nonce even exists that yields a hash below the target for any given set of transactions and block metadata. However, the transaction pool is constantly changing as more transactions are received, so constant churn in the transaction set as well as being able to run through the entire range of nonces each time guarantees that, with enough hashing, you will eventually find a combination that yields a hash that is sufficiently low enough. And then the block is broadcast.
Thank you for this clear explanation, but it leads me to another question (which, I realize, is probably based on a misunderstanding): first the miner finds a valid block that includes the high-reward transaction before the latter is broadcast, then the conspirators broadcast the transaction, followed closely by the valid block including it. But is it not possible that at about the same time, another miner finds a valid block containing one or more of the same transactions used in the special block (though obviously not the so-far private high-reward one) and broadcasts that? If so, then it is my understanding that there will be a race to see which block becomes accepted, and if the block containing the special transaction falls by the wayside, that transaction could be included in another valid block by any miner?
> first the miner finds a valid block that includes the high-reward transaction before the latter is broadcast, then the conspirators broadcast the transaction, followed closely by the valid block including it.
Negative on the second part. The only reason that the P2P network exists is to (a) get blocks (which all nodes do), and (b) share transactions so that they can be included in blocks. Once a transaction is in a block, that's it, it's on the chain. It isn't transmitted separately. Once a node gets a new block over the P2P network, it validates it, and removes all of the transactions included in it from its transaction pool.
> But is it not possible that at about the same time, another miner finds a valid block containing one or more of the same transactions used in the special block (though obviously not the so-far private high-reward one) and broadcasts that
Yes, conflicts can and do happen (this is called a fork). It's actually quite likely, when you think about it; if blocks are found an average of once every ten minutes, and say it takes a few seconds for the P2P network to transfer the latest 1 MB block to all nodes, then you can have a situation were two mining pools find blocks simultaneously that conflict. The longest chain always wins out, otherwise it's whatever block you mined first. Absent an adversarial situation, the odds of having a fork that lasts even two blocks is so low that it should happen on average well less than once a month.
I want to point out an incorrect understanding in this one particular statement though:
> another miner finds a valid block containing one or more of the same transactions
Blocks don't conflict because they have the same transactions, they conflict because each block has a parent, and multiple blocks with the same parent is a conflict. Even if two blocks had no duplicate transactions between them at all, if they topologically form anything other than a straight line on the blockchain (i.e. sharing a parent) then they conflict, and only one will win out.
> if the block containing the special transaction falls by the wayside, that transaction could be included in another valid block by any miner?
Yes, it could be, but I do not believe that the Bitcoin software by default adds transactions to its transaction pool from orphaned blocks. That might be an optimization you could make if you wanted to take advantage of high-fee transactions that end up being orphaned that aren't broadcast to the network before inclusion into a block.
I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.
Ordinarily there would be no advantage to give your transactions privately to just one miner; if you broadcast it publicly there will be many more miners working on it, so it will commit faster. So unless you are deliberately trying to overpay (like here) it would be a waste of money.