Bitcoin Forum
October 15, 2018, 04:21:27 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: How devil competes with its own mined blocks.  (Read 355 times)
spuky
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
September 20, 2018, 03:39:32 PM
 #21

How did you come up with your 90s in the initial post if i compare the timestamps of the screenshot the difference is 42s
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1539620487
Hero Member
*
Offline Offline

Posts: 1539620487

View Profile Personal Message (Offline)

Ignore
1539620487
Reply with quote  #2

1539620487
Report to moderator
1539620487
Hero Member
*
Offline Offline

Posts: 1539620487

View Profile Personal Message (Offline)

Ignore
1539620487
Reply with quote  #2

1539620487
Report to moderator
1539620487
Hero Member
*
Offline Offline

Posts: 1539620487

View Profile Personal Message (Offline)

Ignore
1539620487
Reply with quote  #2

1539620487
Report to moderator
DarkStar_
Legendary
*
Offline Offline

Activity: 1120
Merit: 1421

*dabs*


View Profile WWW
September 20, 2018, 10:05:04 PM
 #22

Claiming to be big and attracting miners because of it comes with responsibilities. For a pool operator it is no excuse to say: "hay, we are in china, and we don't trust in our Europe mirror and we have to validate their blocks and it takes so much time so we compete with each other"!

This isn't about trust. The scenario could have played out like this, if one branch didn't broadcast their block:

AntPool finds block outside of China. The block propagates fine for the rest of the world, but has issues getting through the GFW. While it's trying to get to China, ViaBTC in China finds a block. Since they have not gotten the AntPool block yet, they propagate their block. ViaBTC manages to propagate throughout all of China, while AntPool propagates everywhere else. If the next block is found by a Chinese miner who built on ViaBTC's block, AntPool's block would have been orphaned, even if it was technically mined earlier.

I believe this happened in the past with KanoPool & BTC.com. KanoPool found a block a few seconds before BTC.com, but BTC.com (located in China) also broadcasted their block. The next block was found by BTC.com, so Kano's block was orphaned.

aliashraf
Sr. Member
****
Offline Offline

Activity: 602
Merit: 368


View Profile
September 21, 2018, 08:50:30 AM
 #23

How did you come up with your 90s in the initial post if i compare the timestamps of the screenshot the difference is 42s
Timestamps does not help when it is about seconds. Bitcoin uses a rather sophisticated timing mechanism (network adjusted time) that allows timestamps to diverse from UTC a bit. Plus, miners are free to play with timestamp field. Pools specially can, use this field to distribute work among several workers to prevent them from repeating each other's (failed) attempts, ...
aliashraf
Sr. Member
****
Offline Offline

Activity: 602
Merit: 368


View Profile
September 21, 2018, 09:23:02 AM
 #24

Claiming to be big and attracting miners because of it comes with responsibilities. For a pool operator it is no excuse to say: "hay, we are in china, and we don't trust in our Europe mirror and we have to validate their blocks and it takes so much time so we compete with each other"!

This isn't about trust. The scenario could have played out like this, if one branch didn't broadcast their block:

AntPool finds block outside of China. The block propagates fine for the rest of the world, but has issues getting through the GFW. While it's trying to get to China, ViaBTC in China finds a block. Since they have not gotten the AntPool block yet, they propagate their block. ViaBTC manages to propagate throughout all of China, while AntPool propagates everywhere else. If the next block is found by a Chinese miner who built on ViaBTC's block, AntPool's block would have been orphaned, even if it was technically mined earlier.

I believe this happened in the past with KanoPool & BTC.com. KanoPool found a block a few seconds before BTC.com, but BTC.com (located in China) also broadcasted their block. The next block was found by BTC.com, so Kano's block was orphaned.
Speaking of block propagation, it is useful to dive a bit more in details:

Once a miner finds a block it starts relaying it to its peers, for each peer to be convinced about the authenticity of the block, both the lucky miner and the peer should go through a rather lengthy protocol in which the bottleneck is not the communication channel but the ability of the peer to validate it mainly by comparing each of the transactions included in the block against the UTXO (blockchain state) besides a lot of other measures, like running the input scripts, checking consensus rules, ...
Unless the peer finds everything consistent, it doesn't care about the block under consideration and specifically it won't  interrupt its own mining operations (if any) and it won't start relaying the block (at least before passing some specific steps).

But when it is about the branches of a same pool, the situation is radically different:
They can switch to new job start relaying it almost immediately, simply because they are not peers!
They are multiple instances of a single entity and trust each other.

If Antpool is so naive that runs each of  its branches just like an independent pool, it doesn't deserve its reputation for being big and attractive and if it has adjusted its intra-p2p protocol to avoid such a meaningless and time consuming "re-validation", how is it possible for it to relay two blocks simultaneously and competitively, without a bad intention?

As of Kano/btc.com case it is obviously a competition between two blocks of two different miners and normally happens with orphan blocks as its result.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!