Nop, can not start mining block N before everybody else knows about block N-1 ( ignoring network delays for certain nodes), block timestamps mean nothing in regards to the chain order. 



That is not what anybody else is thinking, you see having negative times between blocks only means 1 of 3

1- The clock is off (behind)
2-The clock of the miner who mined the previous block is off (ahead)
3- The miner doing that on purpose to

 a- hide the fact that they had enough time to include transactions but refused doing so. (this is what people are suspecting)

b- The miner wants to artificially increase the difficulty by tricking the protocol as if blocks were mined faster than they actually were (no logical reason for any miner to do so)

I am not good at C++ too, but I know it can't be 64 bit both singed and unsigned because 64 bits is 8 Bytes and thus it won't fit into the block header, so it must be 32, by quickly skimming the public class code


So no negatives here, only 0 and above, all the way to 4294967295 and that so happen to be equivalent to 02/07/2106 @ 6:28am (UTC) according to https://www.unixtimestamp.com/index.php, so in 86 years, some work and a fork will be needed to keep the blockchain going.

Given the context i think it is pretty clear what i mean is the quoted part, however you brought up an interesting point,
 the timestamps in the header are the seconds elapsed since 1st jan 1970, can unix timestamp be negative? I don't know.

Let's assume you managed to sequeze in a negative value and kept it at 4bytes, what will actually happen? Is there any piece in the code that specifically checks that?  The only issue is that timestamps - - timestamps will result in a timestamps that way far into the future, which then will be invalidated by this rule.

"Hope for the Best. Expect the worst".

I want nothing more than seeing BTC rise in value, but there is a reason why I think we are more likely to go down than up.


Don't count on your wallet to tell you the fees you need to pay, last night I was making a transaction and Coinomi suggested a bit over 70 sats per byte if I am not mistaken, I checked the unconfirmed transactions and figured out I could get away with just 5 sats, and it went through in no time, but hey, you should support miners, they are the backbone of BTC, tip them with high fees.

And why would any mod close a topic that is active and fits the board's rules and requirements? the fact that they haven't responded to your questions doesn't give any mod the right to close the topic, even if they personally tell you "We are not going to answer any of your questions" that will change nothing.

If you think they are doing something against the law - sue them. And if you think they are doing something against the community you can add a flag to their profile and ask DT members to support your flag.

You are right, he only rule that stops miners from mining blocks with timestamp in the past is the MPT rule, which states that timestamp of any given block must be > than the median time of the last 11 blocks, since the median of 11 blocks is block 6, this means

Timestamp of block 12 can be

less than block 11
less than block 10
less than block 9
less than block 8
less than block 7

can NOT be less than block 6 timestamp, provided block 1 to 11 didn't have any negative timestamps, if they do, the calculation method will be different, the code simply takes the past 11 timestamps and get the median of those, which is always the 6 blocks back if they all had positive timestamp differences, I might be mistaken, would love to be corrected.

so timestamps can be negative, not only if the miner's clock is off, it could be done intentionally, but to miners best interest (assuming they are not purposely mining empty blocks and trying to hide it) is to fake the time to be LONGER and not shorter, because that gives the miners a decrease in difficulty while the latter causes an increase in difficulty and thus reducing their rewards in the future.

Without being 100% sure the PSU is not causing the issue, all we can do is speculate, and since the miner does power up, it means the PSU isn't complelty dead, simply something is wrong with it, so it would work one time and fail at another, as for the temperature the kernel log shows

2020-05-05 21:00:36 temperature.c:450:temp_statistics_show:   pcb temp 41~56  chip temp 57~80

Antminer T17 has a max pcb temp of 75, your gear is 20 degrees far from that, also suspecting the PSU being the underlying cause of all this, doesn't negate the fact that chain 2 might be "dying" and is causing all the issues, you could disconnect chain 2 to see if the miner acts differently, but the proper way of troubleshooting IMO is top to bottom, you start with the PSU, Control Board, Network Cable, Wiring and etc. and THEN dig deeper into each hashbarods, you might think that there is no difference between the two approaches, but there is, there is a chance that your PSU is not able to supply enough power to all 3 boards despite that fact that all 3 boards are good, so you remove chain 2, everything looks great and you think your PSU is fine and board is bad when the fact is the exact the opposite.

After having read the kernel log again, I am almost sure it's a PSU issue, and thus increasing the fan speed won't really fix it, you could try to clean the PSU but I suggest replacing it with a working one just to see if it works, don't jump into conclusions and waste money buying a new PSU until it's confirmed.

As for where can you buy those PSUs in Canada, I can't help you with that sadly, I live a few thousand miles away  , but IIRC Steamtyme is in Canada and he has been involved in mining for long, maybe he knows of good sources there.

You are 100% right, however, explaining it this way will also create another confusion that even some "experienced" members will fall for, there is this myth that by reconstructing the block and adding the transactions, you will have to start all over again, in other words, you have wasted x amount time, were in fact, reconstructing the block does not affect your chances of finding the block by any means, while your explanation is more accurate than mine it still contains somehow a wrong piece of information which is:


This is not exactly right, you can start guessing BEFORE adding any transactions but if you fail to find the block and then added the transactions that will involve another small work which has no effect on your chances of finding a block, I know you understand this very well, but you see there is really no perfect way of explaining this in a very simple manner without creating any confusion, now that you have all the piece together, try to construct a perfect and simple explanation again. 

I think I made a mistake trying to explain the process in regards to the problem we are trying to solve, this is very simple yet very hard to explain, for now, I hope tranthidung got the point since he is the one who is going to do the analysis.

They don't have to be mined by the same miner, you would have to exclude the mining pool (miner) from the block n-1, you don't need it, I think if you fully understand the purpose of this analysis it will be very easy to understand what data you will need.

Phill is trying to investigate if Bitmain did not include transactions on purpose, first let's understand how do empty blocks come by:

When miner A tells other miners that he found block number say 10, the other miners will start working on block 11 immediately, while doing so, they will download block number 10 and check it's transactions, then they will delete those transactions from their mempool because if they happen to include a transaction which was already included in block 10, their block will be invalid, so they need to delete the old transactions and only include those transactions that were not mined in block 10, now while doing that sometimes miner B finds the solution to the block, but because of the fear of someone else finding the answer too, they will rush to send the block as fast as they can, and since they are not done with checking all transactions form the previous block they will not risk adding any transaction and they will send it empty with only 1 transaction which is the block rewards.

Now the above is pretty normal, anyone will do it, nobody will blame them for it, but the issue is, what if miner B found the block AFTER checking the previous transactions, cleared his mempool, was able to add new transactions, then he finds the solution, refuses to add transactions and send an empty block? this is the core difference, miner B is excused when the time between block 10 and 11 is too short, they will say okay 10 seconds are not enough to check the previous transactions, he rushed to mine an empty block all good, if the time is 50 seconds for instance, that will immediately a flag, people will question miner B and say you had 50 bloody seconds!! which is more than enough to include new transactions, why did you NOT include them? are you trying to delay transactions to make bitcoin seem too slow?

That's what the analysis is all about, hope it's clear now.



It's highly unlikely that you will find variance in minutes, timestamps in seconds are crucial.



You can use https://blockstream.info/

Try to type my full user name, that way I get notified about it here, if not it will take me sometime to notice your post.

You don't have to remove any wires, I made a simple guide on how to set a fixed speed for the fans, read about it here.


Have you tried a different PSU for this miner?

لا يجب ان يكون مصدر البتكوين مشبوه لاغلاق الحساب, يكفي استخدامك ل CoinJoin من الاساس, الموضوع اشبه بشخص يدخل للبنك مرتدي قناع لاخفاء ملامحه, حتى ان كان القناع لغرض اضحاك الناس او لاسباب صحية سيتم الاشتباه فيه, لان القاعدة تقتضي انه لايوجد سبب يجعلك تحاول اخفاء اثر اموالك الا ان كنت قد تحصلت عليها بطريقة غير شرعية, ولان الحكومات لا تريد للناس ان يخفو اي اثر لهم فيقومو بالتشديد حول هده المسائل وبدورها المنصات المركزية تنصاع لتعليمات الحكومة, وعند تجميد حسابك سيتم سؤالك عن سبب استخدام الCoinjoin واين تحصلت على تلك الاموال وووو.


المقصود ب DOS في Coinjoin هوا ان شخص ما يقوم بارفاق تحويله مع ناس اخرين ومن ثم يقوم بعرقلة التحويل, اعطيك مثال, يمكن ان ادخل في تحويل مع 100 شخص, واقوم بتحويل 0.1 بتكوين, قبل ان يتم التحقق من ذلك اقوم باارسال نفس المبلغ مباشرة بدون Coinjoin وادفع fees اعلا, سيتم تأكيد تحويلي الجديد, عند ارسال تحويل Coinjoin وبمجرد ان تطلع عليه Node حوض التعدين مثلا, سوف تجد ان ذلك التحويل يوجد به input واحدة بقيمة 0.1 قد تم انفاقها وهنا يصبح التحويل كله (100 input) كانها محاولة Double-spend وسيتم رفض التحويل كله وهدا يتسبب في عرقلة تحويلات Coinjoin , طبعا يوجد طرق للتقليل من مثل هده الاشياء ولكن لايمكن ان نقضي عليها تماما.

I understand exactly what you are trying to conclude, I can do that analysis if someone provides the data tranthidung or LoyceV will probably do it, i just hope tranthidung would provide me with a proper format I can use, I tried copying his format to excel and it doesn't come out as proper tables, in fact, if he understands what you want, he can do the analysis himself.

All he needs is filter Blocks that have 1 transaction (n) and every n-1 block,  he will end up with 20186 blocks, half are empty blocks and the other half are the once that preceded them, he then can do;

Time difference = Timestamp of n - timestamp of n-1 , that will get him 10093 results, he then can take the average time difference for both Antpool and BTC.com and compare them against other large pools that are independent of Bitmain such as Slushpool and F2pool, Viabtc should be excluded since Bitmain is the largest shareholder of it.

I think block timestamp variance is normal, some explore to use the "mined at" timestamp, they extract that from the block itself, others use the "received" time which is the time that their node became aware of that block, and it takes time to propagate the block, so it's there is no problem with that.

The strange thing, however, with block 628,427 is that Antpool reported 2020-05-01 15:15:53 while explorers  (including those oweded by Bitmain) reported 2020-05-01 18:15:47, one would think that the pool's time should be less since the pool first finds a block and  THEN sends it out, I think the status on the pool pages are not accurate.

You should keep in mind that the time displaying on every other explorer is under the control of antpool anyway, since they are the once who put it, they also own btc.com so they could change the status there too, I think this is only a bad input on the pool side, they might very well be counting on the miner's time and just so happened that miner's clock was off by a few seconds, since we don't know how does the pool itself gets it's timestamps, we can't conclude anything.

I know what phill wants, he wants the time between every empty block and the block the came right before it, in other words, if you have a total of 10093 blocks you will need to scrape 10093*2 blocks.

An example:

The latest empty block by Antpool is block 628428 , you will need the timestamp of that block and the timestamp of that block-1 which is block 628427.

The problem with using blockchair is that the timestamp excludes the two digits that represent seconds, this means the time difference between those two blocks will be identical either 0 or 1 minute.

What phill wants is to see if Antpool/BTC.com aka bitmian was trying to obstruct transactions by not including transactions on purpose, for that to be proven, the time between those two blocks needs to somewhat "long", anything above average probably means the empty block was mined empty on purpose IF that happens quite often.

Another problem is, you are counting on Bitmain's stupidity leaving you such a trace, I haven't done any analysis in that regards but I am sure even if bitmain took 2 minutes to find the block, they could still alter the time in the block header and submit it as if it was a 1-second block, but by all means, please go ahead and do analysis.

A little is the last word I would use to describe the difficulty drop, unfortunately, it won't be May 19th but a bit later, here is how I see this playing out, the current epoch is ending tomorrow at just about flat 0%, so here is a break down for visualization for the next epoch


May 5 < from here
May 6
May 7
May 8
May 9
May 10
May 11 < to here, the average block time will be 10 mins
May 12 < party starts here, I suspect a drop in hashrate by at least 30% and this from here
May 13
May 14
May 15
May 16
May 17
May 18 < to here the average block time should be 10*130% 13 mins

so half blocks at 10 mins, the other half at 13 mins, the average timestamp will be 11.5 which will result in 15% drop, treat the dates as 144 blocks, which means the diff adjustment won't happen on 19th but 15% later which is 21st of May.

The above assumes no major changes in price, which I doubt, we are more likely to be at the 7k to low 8k region by then, which will make things even worse, so a 20% drop in difficulty is not too far a stretch, but let's wait and see.

اعتقد انه يجب ازالة كلمة يستحيل لان بامتلاك كل المعلومات المتعلقة بالحسابات سواء من المنصات او المواقع التي نشتري منها اشياء بالبتكوين, يوجد وبدون اذنى شك قاعدة بيانات تحمل كل تلك المعلومات وتمتلكها استخبارات الدول العظمى, مشكلة Coinjoin هي ان القيمة المحولة والمرسلة ممكن التعرف عليها في الكثير من الاحوال خصوصا لو كان هناك اختلاف في القيم المرسلة سيكون من السهل نوعا ما معرفة من ارسل لمن وماهي القيمة, ولكن بتساوي القيم سيكون من الصعب التتبع ولكن ليس مستحيل ابدا, يوجد ايضا مشكلة اخرى وهي ان الشركات والحكومات يمكن ان تكون جزء من التحويل, ونظرا لانها تعرف ال inputs والا outputs الخاصة بها تقوم باغاءها من المعادلة وسيتبين لها مصدر التحويلات الاخرى, تخيل ان الامر عبارة عن معادلة, بمعرفة الكثير من مجهولات المعادلة تصبح امكانية الوصول الى النتيجة اسهل جدا, الطريقة الافضل لاخفاء اثر التتبع هي استخدام Confidential transactions مع ال Coinjoin فهي تقوم بتشفير القيمة المحولة ولا يمكن لاحد معرفتها الا المرسل والمستقبل, وبذلك نكون اقفلنا ثغرة كبيرة, طبعا "التحويلات السرية" لم يتم تطبيقها بعض بحسب معلوماتي.

المشكلة الاخرى هي ان تحويلات Coinjoin معروفة, اي تحويل يحتوى على رقم كبير من Inputs يتم تصنيفه على انه Coinjoin وفي الماضي اشتكى بعض المستخدمين ان حساباتهم في بعض المنصات تم تجميدها عندما اسقتبلو اموال من تحويل Coinjoin.

بالمجمل فكرة Coinjoin جيدة جدا لاضافة نوع من الخصوصية وجعل موضوع التتبع مكلف ومتعب اكثر.

لا مانع اخي, يمكنك حتى ازالة كلمة المصدر ولك كامل الصلاحيات في نسخ الكلام, يوجد بضع النقاط الاخرى المتعلقة بموضوع توقيعات شنور الا انه ومن وجهة نظري الافضل ان يبقى الموضوع "خفيف" لان اضافة اشياء اخرى قد تقوم بتعقيده, بقرائتي للموضوع مرة اخرى اعتقد انه الان اصبح متكامل وكافي لاعطاء فكرة جيدة على شنور, لقد اكتشفت اني ارتكبت خطئين في الاملاء وقمت بتعديلهم في منشوري السابق, ارجو ان تقوم بنسخه مجددا.

If that's not too much to scape I would encourage you to do that, I am also interested in block-size analysis, kind of want to see if we are really fully utilizing the block-size we have now or we aren't and all these calls for block size increment are unlogical, further analysis like how often do we really get unusual block time such as 1 or 2 hours block is also interesting, different studies require different data, so scrapping everything especially from blockchair.com will be really useful, good luck and please keep me updated.




1TB is TOO MUCH, those files probably contain everything about the blocks and more, the current blockchain size less than 250gb, the data we need shouldn't be larger than 1mb in a text/excel format, I most certainly can't process a 1TB worth of data.



The generation is the same for every 210,000 blocks and they have nothing to do with a block being empty or full, the generations are not needed in this study and most likely not in any other analysis, I can simply populate them manually if I had to since we know the first block had 50 btc and then 210,000 later it was 25 btc and then 210,000 later it became 12.5 btc, I don't know how to explain it better, but really we don't need them.

for the reward, it's merely generation + fees, if you include the fee(btc) column you will see that, now similar fees for more than one block proves nothing, they are pretty normal.



That simply means we had less than 90k empty blocks since Satoshi mined the first block.



Phill, I will probably still do that analysis for you and the other person who requested it, but I can tell you beforehand that it will prove NOTHING, bitmain can find blocks in 30 seconds and fake the time in the block header to be 3 seconds unless you could hack into their database and assuming they do keep such records, the study will prove nothing, you are counting on their stupidity, integrity, and kindness, and we both know bitmain doesn't have any of those three aspects.

You can do that manually, it's pretty straight forward, take your hashrate for an instance, it's 112th, go to https://www.coinwarz.com/mining/bitcoin/hashrate-chart and get the current hashrate (it's just estimated by the way), it shows about 130EH for now.

Now change your hashrate from Terahash to Exahash by diving th/1,000,000 you get 0.000122EH

Your hashrate = 0.000122EH
Network hashrate = 130EH

Now if you want to know your chances of hitting the next block or any other block at any given time, simply divide the total hashrate / your hashrate

130/0.000122= 1065573.77 > This means how many blocks would need to be found before you can find yours, assuming luck is 100%, it also means for every block that is found your chance is 1 in 1065573.77 , so back to the crossbow example, there are 1,065,573 (over one million) people shooting at the same time as you are and there is only 1 mosquito to be shot.

maybe you want to know your odds of finding a block per hour, we know that on average we find 6 blocks, simply divide that number by 6 so you get 1065573.77/6 = 1 in 177595 chance every hour.

If you want your daily chances simply divide the hour number by 24 or the main number by 144 (number of blocks found per day) and you get 1 in 7399
If you want the weekly number? divide that by 7 and you get 1 in 1057 chance per week, and you can do all kind of estimates, do it for the sake of learning not for the sake of estimating your chances because you will be disappointed, you need a ton of luck to hit a block and it's not impossible, that's all you need to know.