Topic: Chinese miners rejecting transactions from the US? - page 2. (Read 7738 times)
I don't think it is realistic. I don't think Trump will really make some sanctions connected to China or that China will reject transactions. I am not sure if it's even possible. Isn't TOR supposed to deal with the problem of tracing transactions?
Let's cut the crap, this is absolutely not what I've been told before. I've been told that miners are validating transactions that they are going to add to the new block they found, not transactions in the previous block.
They do both, in fact. I'll make one more attempt to try and explain it, but after this, if you're still not satisfied, I'm afraid I'll have no alternative to declaring you a lost cause. It's really not that complicated.
Roughly every ten minutes, a new block is created and added to the blockchain through the mining process. This block verifies and records any new transactions. Once that block is created and the new transaction is verified and included in that block, the transaction will have one confirmation. Approximately every ten minutes thereafter, a new block is created and the transaction is reconfirmed (or validated again) by the Bitcoin network. While some services are instant or only require one confirmation, many Bitcoin companies will require more as each confirmation greatly decreases the likelihood of a payment being reversed. It is common for six confirmations to be required which takes about an hour.
So, not only do miners validate transactions in the mempool to include in the new block, they also validate (or "confirm" if drawing a distinction helps make it clearer) the transactions from the previous block. You seem to be under the impression that "validate" applies purely to tx in the mempool, but this is not the case, hence no exploding mempools. Confirmations are a repeated validation
Now try to explain how half empty blocks pop up on the blockchain now and then. I have to repeat that I don't mean empty blocks which some miners might specifically aim at (e.g. to speed up block confirmation times). I see that most blocks are filled up to the hilt, even if they are only 750k, which just reflects obsolete configurations used by some negligent or careless miners. I talk about blocks which may have, for example, only 82 or 243 transactions in them. That's what this recent discussion basically started with. And so far I haven't seen a viable explanation for this...
Apart from miners deliberately discarding other transactions (to speed up block generation or whatever)
Let's cut the crap, this is absolutely not what I've been told before. I've been told that miners are validating transactions that they are going to add to the new block they found, not transactions in the previous block.
They do both, in fact. I'll make one more attempt to try and explain it, but after this, if you're still not satisfied, I'm afraid I'll have no alternative to declaring you a lost cause. It's really not that complicated.
Roughly every ten minutes, a new block is created and added to the blockchain through the mining process. This block verifies and records any new transactions. Once that block is created and the new transaction is verified and included in that block, the transaction will have one confirmation. Approximately every ten minutes thereafter, a new block is created and the transaction is reconfirmed (or validated again) by the Bitcoin network. While some services are instant or only require one confirmation, many Bitcoin companies will require more as each confirmation greatly decreases the likelihood of a payment being reversed. It is common for six confirmations to be required which takes about an hour.
So, not only do miners validate transactions in the mempool to include in the new block, they also validate (or "confirm" if drawing a distinction helps make it clearer) the transactions from the previous block. You seem to be under the impression that "validate" applies purely to tx in the mempool, but this is not the case, hence no exploding mempools. Confirmations are a repeated validation.
Again, I'm done trying to explain this, so if it still isn't sinking in, either someone else can take it from here, or alternatively you can loiter in the mining subforums and educate yourself there.
To anyone else reading this thread, it should be clear by now that there is no conspiracy and that this is simply a misunderstanding from those who don't correctly grasp how mining works.
Chinese miners rejecting transactions from the US? Is this true that China can take control of BTC transactions from now on. And it is possible to them to block transactions from users specifically form US. It this happens or if it is true, then it can seriously affect the usage of the said cryptocurrency. Well, its their decision, we can't disagree about that.
Thereby miners don't have to validate these transactions again, right? If so, this is in direct conflict with what has been said before. Namely, that a miner after solving a block "is busy validating transactions to add to the block before he releases it". If these transactions have already been included in the previous block, why would the miner have to validate them again and add them to the new block? Why doesn't he validate them before (if he really has to), that would be more logical and efficient, wouldn't it?
I guess you should first come to an agreement between yourselves which transactions are validated and when exactly
I guess you should first come to an agreement between yourselves which transactions are validated and when exactly
We do agree between ourselves, we're just having some difficulty in getting you to comprehend it
We are not on the exams where two teachers contradict each other and then start claiming that they have difficulty in getting the examinee understand what they are saying. Sounds familiar? But this is not that case and thus won't work
When a mining pool receives a new block from a competitor, it needs to perform a few actions: download the full block, validate its transactions and define a new block to mine on. During this - albeit short -interval, so as not to waste hashing power, they start mining a new block. Only the coinbase transaction is included, so the previous block does not invalidate theirs with a duplicate transaction
Let's cut the crap, this is absolutely not what I've been told before. I've been told that miners are validating transactions that they are going to add to the new block they found, not transactions in the previous block. Do you have trouble understanding or reading yourself? And that could potentially explain the half empty blocks (and I don't mean empty blocks, forget about them already), but that would necessarily mean that there should be thousands of new transactions every second hitting the network, with mempools exploding, network shutting down, and the consequences stated earlier (with higher load, more half empty blocks on the blockchain). If what you say is true, this still doesn't in the least explain why there are half empty blocks around...
Also, miners are not mining on PCs, so I can't possibly see how there can be any delays altogether
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain.
Err, no. That's not what he said.
That's not what he said, but I never claimed otherwise in the first place. That's what it comes down to.
Again, no. that's not "what it comes down to". Stop reading what isn't there to warp the meaning into whatever you want it to say. Higher loads on the network do not, in any way, shape or form, result in more empty blocks. It's down to which transactions were included in the previous block, network topology and fees. Volume is not relevant
Thereby miners don't have to validate these transactions again, right? If so, this is in direct conflict with what has been said before. Namely, that a miner after solving a block "is busy validating transactions to add to the block before he releases it". If these transactions have already been included in the previous block, why would the miner have to validate them again and add them to the new block? Why doesn't he validate them before (if he really has to), that would be more logical and efficient, wouldn't it?
I guess you should first come to an agreement between yourselves which transactions are validated and when exactly
We do agree between ourselves, we're just having some difficulty in getting you to comprehend it. Try this article if the wording is clearer:
When a mining pool receives a new block from a competitor, it needs to perform a few actions: download the full block, validate its transactions and define a new block to mine on. During this - albeit short -interval, so as not to waste hashing power, they start mining a new block. Only the coinbase transaction is included, so the previous block does not invalidate theirs with a duplicate transaction.
Read more: http://www.nasdaq.com/article/why-do-some-bitcoin-mining-pools-mine-empty-blocks-cm648094
It's fair enough if you want to raise concerns over potential issues, but what you're doing here is rapidly approaching anonymint levels of 'chicken little' kookery. Just calm it down a bit, please.
//EDIT: And looking at the other, equally paranoid, China thread, I can see jbreher also tried to explain this phenomenon to you, but again you wouldn't listen to reason.
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain.
Err, no. That's not what he said.
That's not what he said, but I never claimed otherwise in the first place. That's what it comes down to.
Again, no. that's not "what it comes down to". Stop reading what isn't there to warp the meaning into whatever you want it to say. Higher loads on the network do not, in any way, shape or form, result in more empty blocks. It's down to which transactions were included in the previous block, network topology and fees. Volume is not relevant
Thereby miners don't have to validate these transactions again, right? If so, this is in direct conflict with what has been said before. Namely, that a miner after solving a block "is busy validating transactions to add to the block before he releases it". If these transactions have already been included in the previous block, why would the miner have to validate them again and add them to the new block? Why doesn't he validate them before (if he really has to), that would be more logical and efficient, wouldn't it?
I guess you should first come to an agreement between yourselves which transactions are validated and when exactly
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain.
Err, no. That's not what he said.
That's not what he said, but I never claimed otherwise in the first place. That's what it comes down to.
Again, no. that's not "what it comes down to". Stop reading what isn't there to warp the meaning into whatever you want it to say. Higher loads on the network do not, in any way, shape or form, result in more empty blocks. It's down to which transactions were included in the previous block, network topology and fees. Volume is not relevant. Neither of us can understand how you could have possibly inferred such a belief from what's been stated here. I'm starting to wonder if you're even reading the posts and instead just launch off in random tangents that sound vaguely related to what's being said.
Mining is fiercely competitive and miners aren't going to risk squeezing in more tx than they have to if that means jeopardising their block reward and allowing someone else to beat them to it
Forget about Boogeyman, you just said essentially the same
Essentially the same as what? Your supposed miner collusion conspiracy? In what possible scenario is not including transactions because you want to prioritise winning the block reward evidence of collusion? If the proof-of-work environment we operate in is going to leave you jumping at shadows for the rest of forever, perhaps you should consider looking at some altcoins instead. Maybe proof-of-stake is more your thing.
You simply can't buy me into that
I don't have motivation to have you buy into that. You prefer to reject a technical explanation in favor of a conspiracy theory
So far I haven't seen any viable explanation, technical or not
The speed of one tx validation may be 1 millisecond or faster, this depends on CPU power of the mining pool node, it was just an example that no one does it manually. Again, this has no connection with your strange conclusion of millions of unconfirmed transactions.
I guess we can safely expect that it is by far faster than 1 millisecond in the majority of cases. Even if it is exactly 1 millisecond that basically means that the new transactions should arrive faster than they are validated to make the backlog start growing faster than it can be processed, as you yourself state. Do you understand this means that thousands of new transactions should be generated every second?
And we would have many millions of them by now, with mempools exploding all over the place?
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain.
Err, no. That's not what he said.
That's not what he said, but I never claimed otherwise in the first place. That's what it comes down to. Nevertheless, now to your own words:
Mining is fiercely competitive and miners aren't going to risk squeezing in more tx than they have to if that means jeopardising their block reward and allowing someone else to beat them to it
Forget about Boogeyman, you just said essentially the same
[snip] then what you say doesn't sound persuading
It does when you aren't looking for conspiracies and/or boogeymen. If you still believe it's some sort of Chinese hive mind acting nefariously after all these pages, them I'm afraid there's little anyone can say to convince you of the truth. Confirmation bias is clouding your view. Everything freshman777 said seems perfectly reasonable in my eyes. Mining is fiercely competitive and miners aren't going to risk squeezing in more tx than they have to if that means jeopardising their block reward and allowing someone else to beat them to it.
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain.
Err, no. That's not what he said.
You simply can't buy me into that
I don't have motivation to have you buy into that. You prefer to reject a technical explanation in favor of a conspiracy theory.
Quote
...the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty blocks we will see on the blockchain
This makes no sense. I don't understand how you've drawn this conclusion from my explanations.
The speed of one tx validation may be 1 millisecond or faster, this depends on CPU power of the mining pool node, it was just an example that no one does it manually. Again, this has no connection with your strange conclusion of millions of unconfirmed transactions.
Mining pool software automates transaction validation. Noone does it manually, the speed of validation is a few millisecond per transaction. I don't see how the blocks you have linked to defy the explanation I have given. As been said there is a number of factors in the state of network: the last blocks, transactions are changing all the time, nodes observe previous blocks, some blocks may have been already solved and are propagating, block orphaning.
Bottom line: all blocks can never be 1 MB, blocks can be considered full when backlog starts growing faster than it can be processed. It's been happening in the past few days.
Bottom line: all blocks can never be 1 MB, blocks can be considered full when backlog starts growing faster than it can be processed. It's been happening in the past few days.
You simply can't buy me into that
What you say effectively comes down to stating that the higher the load on the Bitcoin network (i.e. more transactions coming in) the more empty or half empty blocks we will see on the blockchain. This is something which I can't possibly accept as having any connection to reality. Further, if the speed of validation is actually a few milliseconds per transaction (I think it should be on the order of microseconds if not nano, with the mempool fully cashed), and the backlog started growing faster than it could be processed, that would mean that a few thousand new transactions would be hitting network every second, and we would have had a few dozen millions of unconfirmed transactions by now
...The Black Friday holidays have made the problem more acute, but this is far from the first backlog of 2016.
If black Friday has helped to increase the number of half-filled blocks, I wonder how many of such blocks we will have when more people start using bitcoin
How do you plan on determining a transaction is from the US? This is such a ridiculous idea that would never happen. China doesn't control every single pool and mining operation. How did you make this stuff up?
Yes that is a fact that it is not possible to detect that from where the bitcoin is going to transfer and to whom it is going to transfer. Blockchain nor mining process are not usually do not care transaction's IP address as it is not recorded/not included any where. I believe we should avoid giving such kind of statement that is really affecting the image of bitcoin.
Mining pool software automates transaction validation. Noone does it manually, the speed of validation is a few millisecond per transaction. I don't see how the blocks you have linked to defy the explanation I have given. As been said there is a number of factors in the state of network: the last blocks, transactions are changing all the time, nodes observe previous blocks, some blocks may have been already solved and are propagating, block orphaning.
Bottom line: all blocks can never be 1 MB, blocks can be considered full when backlog starts growing faster than it can be processed. It's been happening in the past few days.
Bottom line: all blocks can never be 1 MB, blocks can be considered full when backlog starts growing faster than it can be processed. It's been happening in the past few days.
I also strongly suspect that it doesn't make much difference if you include 82 transactions or 820, or the max number, provided the mempool is not empty (which is obviously not the case). I can only explain such behavior by deliberate choice not to include other transactions into the block. If someone was in a hurry, as you suggest, he would most certainly choose to keep the block completely empty, right?
A miner has solved a block and is busy validating transactions to add to the block before he releases it. While doing this the miner receives a block from the network with some of transactions he'd been working on already added to it. Scared that his block may be orphaned if he spends more time on validating new pending transactions from the pool, he discards txs that the other miner has already validated and releases his block with whatever txs he had validated up to this point in time which aren't yet in any of the previous blocks
So, does this miner validate them manually? if not, then what you say doesn't sound persuading
The number and choice of transactions in these empty to barely filled blocks depends on factors such as network topology which affects transactions and blocks propagation, on the choice of transactions the previous block's miner had validated. Default choice for miners if based on the fee/size ratio, the more you pay for a byte of transaction size, the sooner your transaction is mined. I read that some Chinese pool sells a subscription to one Chinese exchange to prioritize their transactions which is also a profit-based approach to mining transactions, not a politically motivated one. I hope my explanation of empty to barely filled blocks makes sense. If it doesn't you should find a more technical explanation in the Technical and Mining subforums. This is where I got it from, I didn't make it up, but my wording may be confusing. Since these empty to barely filled blocks are out of service to users, for any practical purposes we can only count other blocks and most of those are 1MB. The Black Friday holidays have made the problem more acute, but this is far from the first backlog of 2016.
But I guess you can't possibly say that yesterday these factors were working perfectly but today and the day before yesterday they all of a sudden stopped working. Besides that, yesterday there were a few transactions which were only half full, even for a 750Kb block, but still had a few hundred transactions included in them (for example, this and this blocks), but today and before yesterday there were none such...
As you can see, some miners for some obscure reason were particularly choosy yesterday
I also strongly suspect that it doesn't make much difference if you include 82 transactions or 820, or the max number, provided the mempool is not empty (which is obviously not the case). I can only explain such behavior by deliberate choice not to include other transactions into the block. If someone was in a hurry, as you suggest, he would most certainly choose to keep the block completely empty, right?
A miner has solved a block and is busy validating transactions to add to the block before he releases it. While doing this the miner receives a block from the network with some of transactions he'd been working on already added to it. Scared that his block may be orphaned if he spends more time on validating new pending transactions from the pool, he discards txs that the other miner has already validated and releases his block with whatever txs he had validated up to this point in time which aren't yet in any of the previous blocks.
The number and choice of transactions in these empty to barely filled blocks depends on factors such as network topology which affects transactions and blocks propagation, on the choice of transactions the previous block's miner had validated. Default choice for miners is based on the fee/size ratio, the more you pay for a byte of transaction size, the sooner your transaction is mined. I read that some Chinese pool sells a subscription to one Chinese exchange to prioritize their transactions which is also a profit-based approach to mining transactions, not a politically motivated one. I hope my explanation of empty to barely filled blocks makes sense. If it doesn't you should find a more technical explanation in the Technical and Mining subforums. This is where I got it from, I didn't make it up, but my wording may be confusing. Since these empty to barely filled blocks are out of service to users, for any practical purposes we can only count other blocks and most of those are 1MB. The Black Friday holidays have made the problem more acute, but this is far from the first backlog of 2016.
Okay, that's what we need, and what do we see there?
Today there are only a few blocks which are not filled to the full, but yesterday their number was much bigger. I found a few blocks which are half empty at ~300Kb, and a dozen at around 750k. One block has only 82 transactions in it. The day before yesterday, there were only 5 such blocks at ~750k, and no blocks below that (just in case, I completely excluded empty blocks from consideration). The inference is that yesterday we had a significantly lower fill-up ratio than today and the day before yesterday (you guess what it means), and that seems to be the straw that is breaking the camel's back
Today there are only a few blocks which are not filled to the full, but yesterday their number was much bigger. I found a few blocks which are half empty at ~300Kb, and a dozen at around 750k. One block has only 82 transactions in it. The day before yesterday, there were only 5 such blocks at ~750k, and no blocks below that (just in case, I completely excluded empty blocks from consideration). The inference is that yesterday we had a significantly lower fill-up ratio than today and the day before yesterday (you guess what it means), and that seems to be the straw that is breaking the camel's back
750 kb blocks are an old configuration setting in the mining pool software, some pools keep using it because incompetence, laziness or both.
I've explained the reason for blocks that hardly have transactions in them here, very often such a barely filled block comes shortly after a previous block, indicating the miner is in a hurry to release it to acquire the coin base block reward. It's pure profit motive to release early including few or no transactions, not a conspiracy. Some day censoring transactions could be a thing, this isn't the case yet.
As I noted, I excluded empty transactions from consideration altogether
Other than that, I can't rationally explain why the miner would include only 82 transactions. Has he picked them up manually? I guess no. I also strongly suspect that it doesn't make much difference if you include 82 transactions or 820, or the max number, provided the mempool is not empty (which is obviously not the case). I can only explain such behavior by deliberate choice not to include other transactions into the block. If someone was in a hurry, as you suggest, he would most certainly choose to keep the block completely empty, right?
A simple check-up of blockchain.info shows blocks are full with the exceptions I've explained above
I have already posted the chart which basically shows that the blocks are not full. And if you somehow missed my post (or just chose to ignore it), I also showed what the fill-up ratio would be if we discarded the empty blocks altogether. The real value is still a far cry from what I got. In any case, there are only around 144 new blocks mined daily, so it shouldn't be a big deal to post exact data with actual block sizes that have been mined since this congestion has started...
These stats would answer the matter in question in a most definite manner, wouldn't they?
https://blockchain.info/blocks
Exact data with actual block sizes with convenient pagination links all the way to how long ago you need.
Okay, that's what we need, and what do we see there?
Today there are only a few blocks which are not filled to the full, but yesterday their number was much bigger. I found a few blocks which are half empty at ~300Kb, and a dozen at around 750k. One block has only 82 transactions in it. The day before yesterday, there were only 5 such blocks at ~750k, and no blocks below that (just in case, I completely excluded empty blocks from consideration). The inference is that yesterday we had a significantly lower fill-up ratio than today and the day before yesterday (you guess what it means), and that seems to be the straw that is breaking the camel's back
750 kb blocks are an old configuration setting in the mining pool software, some pools keep using it because incompetence, laziness or both.
I've explained the reason for blocks that hardly have transactions in them here, very often such a barely filled block comes shortly after a previous block, indicating the miner is in a hurry to release it to acquire the coin base block reward. It's pure profit motive to release early including few or no transactions, not a conspiracy. Some day censoring transactions could be a thing, this isn't the case yet.
A simple check-up of blockchain.info shows blocks are full with the exceptions I've explained above
I have already posted the chart which basically shows that the blocks are not full. And if you somehow missed my post (or just chose to ignore it), I also showed what the fill-up ratio would be if we discarded the empty blocks altogether. The real value is still a far cry from what I got. In any case, there are only around 144 new blocks mined daily, so it shouldn't be a big deal to post exact data with actual block sizes that have been mined since this congestion has started...
These stats would answer the matter in question in a most definite manner, wouldn't they?
https://blockchain.info/blocks
Exact data with actual block sizes with convenient pagination links all the way to how long ago you need.
Okay, that's what we need, and what do we see there?
Today there are only a few blocks which are not filled to the full, but yesterday their number was much bigger. I found a few blocks which are half empty at ~300Kb, and a dozen at around 750k. One block has only 82 transactions in it. The day before yesterday, there were only 5 such blocks at ~750k, and no blocks below that (just in case, I completely excluded empty blocks from consideration). The inference is that yesterday we had a significantly lower fill-up ratio than today and the day before yesterday (you guess what it means), and that seems to be the straw that is breaking the camel's back
Jump to: