5 ms·

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.

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.

CydeWeys 10y ago
> 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.
- nandemo 10y ago
  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".
  - CydeWeys 10y ago
    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. Hope that clears things up.
    - mannykannot 10y ago
      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?

CydeWeys 10y ago

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

nandemo 10y ago
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".
- CydeWeys 10y ago
  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. Hope that clears things up.
  - mannykannot 10y ago
    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?