Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tomasz Kajetan Stańczak
    @tkstanczak
    test
    Tomasz Kajetan Stańczak
    @tkstanczak
    For reference - the set of questions that I sent to the experts today that will allow me to understand better practicalities of industrial mining on Ethereum:

    Hi! Thanks once again for help - here are the questions that I have prepared.
    Please advise also if some of these questions seem wrongly formulated / miss some important concepts.

    1) When mining on Ethereum how do you establish the communication between the block producer (node) and the mining rigs (GPU / CPU)? (custom protocol / Stratum based custom protocol / other)

    2) How do you define strategies for transactions selection for a block? Do you just accept the standard settings or use custom / advanced solutions?

    3) Do you have any custom build or publicly available solutions for the best expected value among the available blocks to mine on top of? Similarly how do you make a decision between mining an empty block or waiting for transctions? (This question is all about trade-offs in choosing various branches and delaying block production for better tx fees)

    4) Do you constantly update your mining rigs with the best possible block mix hash and nonce? (i.e. you start mining a block 'N' and in the meantime a better block at height 'N' can be constructed with better tx fee rewards (but the same parent) - do your block producers send an updated mix hash + nonce immediately or do you commit to a previously produced block.

    5) What types of nodes are you running? (Parity / Geth / other; fast sync, full sync) Are there any important configurations that you adjust?

    6) What is causing the most trouble with the current client implementations from a miner perspective?

    7) How do you control your nodes? Through JSON RPC over HTTP / over WebSockets / different?)

    8) Do you run only one node and many mining rigs or many nodes?

    9) How do you deploy your nodes (Docker style containers / manual installation)

    10) How do you upgrade and monitor client versions.

    11) What signalling methods do you use / would like to use.

    12) How do you ensure that your mempool is populated - do you keep a big list of static nodes?

    13) Do you have geographically distributed light nodes or custom solutions to broadcast blocks quickly around the world?

    14) What mining libraries do you install. What APIs do they expose.

    tvanepps
    @tvanepps
    love this initiative. I'm sure Hudson would be able to connect you with some miners.
    Peter Pratscher from Bitfly is pretty active in the Core Dev gitter, maybe ping him
    Tomasz Kajetan Stańczak
    @tkstanczak
    yes, he already said he will be glad to answer the questions - sent him a DM
    I think some people are already on holiday and it is fine to continue this converstion in January
    Andrea Lanfranchi
    @AndreaLanfranchi
    About question 4
    Block producer (better defined as work-provider while CPU-GPU miners should be work-consumers) does not send any nonce nor a mix-hash.
    Informations sent are : header hash, seed and target.
    It's up to work consumer to pick the nonce range it prefers.
    Only notable pseudo exception is stratum in nicehash mode where extra nonce is sent to assign work-consumer a very wide nonce range to stick into. (to reduce work overlap among miners)
    Tomasz Kajetan Stańczak
    @tkstanczak
    Interesting - but I guess with many work consumers it would be desired to avoid overlaps (or do they have such a small probability of overlapping that it does not matter?)
    Andrea Lanfranchi
    @AndreaLanfranchi
    Technically impossible unless all work consumers for a given PoW do all attach to a single work provider thus node. Only in that case you might deliver non overlapping nonce ranges but they would be smaller and smaller as higher is the number of consumers: in such case you'd be setting a winner at work provider level.
    When instead different work-consumers are connected to different work-providers (nodes) they may well work on same nonce ranges even if they do overlap. In such case there is no duplicate work being carried out as different nodes deliver different header hashes (header hash in fact includes coinbase transaction which is different among nodes)
    Tomasz Kajetan Stańczak
    @tkstanczak
    My feeling was that it would never make sense to have more than one work provider since you just care about the best possible block at any given time? Interesting that you say that there are many work providers.
    By splitting the range you are not licking the winner since you do not knie which winner is the best? Do you mean something else by that?
    Andrea Lanfranchi
    @AndreaLanfranchi
    Define what you mean by :
    • "best" possible block at any given time
    • "best" winner
    I do think those concepts may confuse you
    In mining ethereum there is no "best" block which wins ... there's only the block candidate which gets sealed first which "wins" (gets appended to the chain)
    Andrea Lanfranchi
    @AndreaLanfranchi
    With regard to question 8 : it may surprise you that in many cases of "industrial mining" there are no self ran nodes involved. The use of "public pools" is still present in large mining operations
    Andrea Lanfranchi
    @AndreaLanfranchi
    On question 5 : at the moment of mining there is no difference among fast sync and/or full sync. As long as a node is not fully sync'ed it can't provide any work.
    Tomasz Kajetan Stańczak
    @tkstanczak
    by the 'best' block I mean the block that at the given time is the most profitable block constructed from the tx pool transactions and a set of potenial parent blocks - most profitable by means of total expected value of rewards + uncle rewards + fees
    so a block A that has 1 uncle which is a block mined by you earlier is better than a block A' without uncles
    a block B mined on top of a big pool parent block is better than a block B' mined on top of a small pool parent block (less chances of staying canonical, hence less expected value)
    block C with tx fees of 0.1 ETH is better than a block C' with fees of 0.08 ETH
    block D that contains front running txs valuable for the mining pool is better than block D' that does not contain such transactions
    and so on
    Tomasz Kajetan Stańczak
    @tkstanczak
    for any work consumer there exists a work provider which delivers work with the highest total expected value for that consumer
    Andrea Lanfranchi
    @AndreaLanfranchi

    a block B mined on top of a big pool parent block is better than a block B' mined on top of a small pool parent block (less chances of staying canonical, hence less expected value)

    I think you misunderstood all of this

    Tomasz Kajetan Stańczak
    @tkstanczak
    I think I see that you consider work consumers as oblivious of the type of work they receive
    I am to learn here so I will keep listening more than talking from now on :)
    Andrea Lanfranchi
    @AndreaLanfranchi

    I think I see that you consider work consumers as oblivious of the type of work they receive

    It's not a consideration ... it's a fact.
    Hashing workers (miners of any kind CPU, GPU FPGA ASICs etc) do not have any knowledge about the meaning/composition of the job they've been provided.
    Their task is simple : given the input (header hash) do a linear search on nonces (choose any range you prefer in 0~2**64) which, applied to the algorithm provides a result below target. Seed hash is provided to determine the epoch which has an impact on DAG size and is part of the algorithm.
    Nothing else. Miners do not have any knowledge of how the header hash is obtained (one TX ? multiple TXs ? gas limits ? whatever ...) ... they simply INPUT -> HASH ALGO -> OUTPUT.
    Prove is you can provide them with any kind of randomized header hash (which might have no corresponding data in any block or candidate block) and they will carry out the task.

    Any decision about what to include/exclude from candidate block is performed at node level.
    Tomasz Kajetan Stańczak
    @tkstanczak
    I need to clarify then that as a node developer I am particulary interested at the way the block is constructed / selected / dispatched from the node.
    For the work consumer part - we will only need to implement proper APIs - sending job, receiving results, sending job updates.
    (from the perspective of work provider)
    Andrea Lanfranchi
    @AndreaLanfranchi
    Stratum is the most common way to communicate with work consumer's. For all the rest you need to dig into p2p consensus protocol which has (almost) nothing to do with mining
    Gaurav
    @buddies2705
    Hey guys
    Tomasz Kajetan Stańczak
    @tkstanczak
    hi
    Gaurav
    @buddies2705
    Hey Guys Can you add Netherming on CoinCodeCap.. we are building a place where people can discover and review crypto products and open source tools
    Tomasz Kajetan Stańczak
    @tkstanczak
    haven't looked at it much before but does it often happen that one miner will produce competing blocks:
    image.png