<blockquote>
  <p>I want to know who gives a block to the miners?</p>
</blockquote>

<p>Nodes typically give the block (or block template) to the miners. To be even more accurate, typically mining pool software will get the block data from a node, and distribute that to the miners.</p>

<p><code>getblocktemplate</code> is an RPC call in Bitcoin Core intended to provide the miner with something to mine. It should contain valid transactions assembled as a valid block that just needs the proof of work. See <a href="https://bitcoincore.org/en/doc/0.16.2/rpc/mining/getblocktemplate/" rel="nofollow noreferrer">https://bitcoincore.org/en/doc/0.16.2/rpc/mining/getblocktemplate/</a></p>

<pre><code>getblocktemplate ( TemplateRequest )

If the request parameters include a 'mode' key, that is used to explicitly select between the default 'template' request or a 'proposal'.
It returns data needed to construct a block to work on.
For full specification, see BIPs 22, 23, 9, and 145:
    https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes
    https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

Arguments:
1. template_request         (json object, optional) A json object in the following spec
     {
       "mode":"template"    (string, optional) This must be set to "template", "proposal" (see BIP 23), or omitted
       "capabilities":[     (array, optional) A list of strings
           "support"          (string) client side supported feature, 'longpoll', 'coinbasetxn', 'coinbasevalue', 'proposal', 'serverlist', 'workid'
           ,...
       ],
       "rules":[            (array, optional) A list of strings
           "support"          (string) client side supported softfork deployment
           ,...
       ]
     }


Result:
{
  "version" : n,                    (numeric) The preferred block version
  "rules" : [ "rulename", ... ],    (array of strings) specific block rules that are to be enforced
  "vbavailable" : {                 (json object) set of pending, supported versionbit (BIP 9) softfork deployments
      "rulename" : bitnumber          (numeric) identifies the bit number as indicating acceptance and readiness for the named softfork rule
      ,...
  },
  "vbrequired" : n,                 (numeric) bit mask of versionbits the server requires set in submissions
  "previousblockhash" : "xxxx",     (string) The hash of current highest block
  "transactions" : [                (array) contents of non-coinbase transactions that should be included in the next block
      {
         "data" : "xxxx",             (string) transaction data encoded in hexadecimal (byte-for-byte)
         "txid" : "xxxx",             (string) transaction id encoded in little-endian hexadecimal
         "hash" : "xxxx",             (string) hash encoded in little-endian hexadecimal (including witness data)
         "depends" : [                (array) array of numbers 
             n                          (numeric) transactions before this one (by 1-based index in 'transactions' list) that must be present in the final block if this one is
             ,...
         ],
         "fee": n,                    (numeric) difference in value between transaction inputs and outputs (in satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one
         "sigops" : n,                (numeric) total SigOps cost, as counted for purposes of block limits; if key is not present, sigop cost is unknown and clients MUST NOT assume it is zero
         "weight" : n,                (numeric) total transaction weight, as counted for purposes of block limits
         "required" : true|false      (boolean) if provided and true, this transaction must be in the final block
      }
      ,...
  ],
  "coinbaseaux" : {                 (json object) data that should be included in the coinbase's scriptSig content
      "flags" : "xx"                  (string) key name is to be ignored, and value included in scriptSig
  },
  "coinbasevalue" : n,              (numeric) maximum allowable input to coinbase transaction, including the generation award and transaction fees (in satoshis)
  "coinbasetxn" : { ... },          (json object) information for coinbase transaction
  "target" : "xxxx",                (string) The hash target
  "mintime" : xxx,                  (numeric) The minimum timestamp appropriate for next block time in seconds since epoch (Jan 1 1970 GMT)
  "mutable" : [                     (array of string) list of ways the block template may be changed 
     "value"                          (string) A way the block template may be changed, e.g. 'time', 'transactions', 'prevblock'
     ,...
  ],
  "noncerange" : "00000000ffffffff",(string) A range of valid nonces
  "sigoplimit" : n,                 (numeric) limit of sigops in blocks
  "sizelimit" : n,                  (numeric) limit of block size
  "weightlimit" : n,                (numeric) limit of block weight
  "curtime" : ttt,                  (numeric) current timestamp in seconds since epoch (Jan 1 1970 GMT)
  "bits" : "xxxxxxxx",              (string) compressed target of next block
  "height" : n                      (numeric) The height of the next block
}

Examples:
&gt; bitcoin-cli getblocktemplate 
&gt; curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblocktemplate", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
</code></pre>

CC BY-SA 4.0
2018-09-07T14:52:41.060Z
2018-09-07T14:52:41.060Z
JBaczuk
<p>Nobody gives the block, the miner comes up with it. Think of it as designing a mansion. The possibilities are endless: it can even be an empty block without transactions (there is no mansion, just a garden shed). It only needs to be valid in two ways: no conflicting transactions (the design is physically possible to build) and it has to be cryptographically secured (you have to go through the legal bureaucracy before the construction may begin). In bitcoin world, only the last part takes any significant time, and it doesn't depend on your design at all, it's pure luck.</p>

<p>Only certain blocks are valid, so miners have to spend time manipulating the contents of the block until it satisfies the target hash. The transactions however are merely suggestions, the miner has the complete authority and can "build" whatever they want. When they work on the block to make it meet the difficulty standard, they only "manipulate" the parts that don't matter.</p>

CC BY-SA 4.0
2018-09-05T09:24:25.490Z
THis answer would be better if it also answered the part of the question where Fahd asked *"[how] does the transaction come to the pool of miners?"* and explained what incentive there is for miners to include transactions in blocks rather than mining empty blocks.
RedGrittyBrick
CC BY-SA 4.0
2018-09-05T07:26:37.840Z
2018-09-05T07:26:37.840Z
FrownyFrog
<p>Im still making my way into the block-chain world. I have been reading a lot. </p>

<p>I want to know who gives a block to the miners?, then they compete to get the challenge right, whoever gets the challenge right has the privilege to add the block. My confusion is how is a block created in the first place? where does the transaction come to the pool of miners? </p>

<blockchain>
Who gives the block to the miner
Fahd
# Who gives the block to the miner

(Asked by: username_0 on 2018-09-05)

Im still making my way into the block-chain world. I have been reading a lot.

I want to know who gives a block to the miners?, then they compete to get the challenge right, whoever gets the challenge right has the privilege to add the block. My confusion is how is a block created in the first place? where does the transaction come to the pool of miners?

**Tags:** blockchain


---

## 2 answers

### Answer by username_1 on 2018-09-07. Score: 0

> I want to know who gives a block to the miners?

Nodes typically give the block (or block template) to the miners. To be even more accurate, typically mining pool software will get the block data from a node, and distribute that to the miners.

`getblocktemplate` is an RPC call in Bitcoin Core intended to provide the miner with something to mine. It should contain valid transactions assembled as a valid block that just needs the proof of work. See <https://bitcoincore.org/en/doc/0.16.2/rpc/mining/getblocktemplate/>

```
getblocktemplate ( TemplateRequest )

If the request parameters include a 'mode' key, that is used to explicitly select between the default 'template' request or a 'proposal'.
It returns data needed to construct a block to work on.
For full specification, see BIPs 22, 23, 9, and 145:
    https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes
    https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

Arguments:
1. template_request         (json object, optional) A json object in the following spec
     {
       "mode":"template"    (string, optional) This must be set to "template", "proposal" (see BIP 23), or omitted
       "capabilities":[     (array, optional) A list of strings
           "support"          (string) client side supported feature, 'longpoll', 'coinbasetxn', 'coinbasevalue', 'proposal', 'serverlist', 'workid'
           ,...
       ],
       "rules":[            (array, optional) A list of strings
           "support"          (string) client side supported softfork deployment
           ,...
       ]
     }

Result:
{
  "version" : n,                    (numeric) The preferred block version
  "rules" : [ "rulename", ... ],    (array of strings) specific block rules that are to be enforced
  "vbavailable" : {                 (json object) set of pending, supported versionbit (BIP 9) softfork deployments
      "rulename" : bitnumber          (numeric) identifies the bit number as indicating acceptance and readiness for the named softfork rule
      ,...
  },
  "vbrequired" : n,                 (numeric) bit mask of versionbits the server requires set in submissions
  "previousblockhash" : "xxxx",     (string) The hash of current highest block
  "transactions" : [                (array) contents of non-coinbase transactions that should be included in the next block
      {
         "data" : "xxxx",             (string) transaction data encoded in hexadecimal (byte-for-byte)
         "txid" : "xxxx",             (string) transaction id encoded in little-endian hexadecimal
         "hash" : "xxxx",             (string) hash encoded in little-endian hexadecimal (including witness data)
         "depends" : [                (array) array of numbers 
             n                          (numeric) transactions before this one (by 1-based index in 'transactions' list) that must be present in the final block if this one is
             ,...
         ],
         "fee": n,                    (numeric) difference in value between transaction inputs and outputs (in satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one
         "sigops" : n,                (numeric) total SigOps cost, as counted for purposes of block limits; if key is not present, sigop cost is unknown and clients MUST NOT assume it is zero
         "weight" : n,                (numeric) total transaction weight, as counted for purposes of block limits
         "required" : true|false      (boolean) if provided and true, this transaction must be in the final block
      }
      ,...
  ],
  "coinbaseaux" : {                 (json object) data that should be included in the coinbase's scriptSig content
      "flags" : "xx"                  (string) key name is to be ignored, and value included in scriptSig
  },
  "coinbasevalue" : n,              (numeric) maximum allowable input to coinbase transaction, including the generation award and transaction fees (in satoshis)
  "coinbasetxn" : { ... },          (json object) information for coinbase transaction
  "target" : "xxxx",                (string) The hash target
  "mintime" : xxx,                  (numeric) The minimum timestamp appropriate for next block time in seconds since epoch (Jan 1 1970 GMT)
  "mutable" : [                     (array of string) list of ways the block template may be changed 
     "value"                          (string) A way the block template may be changed, e.g. 'time', 'transactions', 'prevblock'
     ,...
  ],
  "noncerange" : "00000000ffffffff",(string) A range of valid nonces
  "sigoplimit" : n,                 (numeric) limit of sigops in blocks
  "sizelimit" : n,                  (numeric) limit of block size
  "weightlimit" : n,                (numeric) limit of block weight
  "curtime" : ttt,                  (numeric) current timestamp in seconds since epoch (Jan 1 1970 GMT)
  "bits" : "xxxxxxxx",              (string) compressed target of next block
  "height" : n                      (numeric) The height of the next block
}

Examples:
> bitcoin-cli getblocktemplate 
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblocktemplate", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

```


---

### Answer by username_2 on 2018-09-05. Score: 0

Nobody gives the block, the miner comes up with it. Think of it as designing a mansion. The possibilities are endless: it can even be an empty block without transactions (there is no mansion, just a garden shed). It only needs to be valid in two ways: no conflicting transactions (the design is physically possible to build) and it has to be cryptographically secured (you have to go through the legal bureaucracy before the construction may begin). In bitcoin world, only the last part takes any significant time, and it doesn't depend on your design at all, it's pure luck.

Only certain blocks are valid, so miners have to spend time manipulating the contents of the block until it satisfies the target hash. The transactions however are merely suggestions, the miner has the complete authority and can "build" whatever they want. When they work on the block to make it meet the difficulty standard, they only "manipulate" the parts that don't matter.

> **Comments:**
> **username_3**: THis answer would be better if it also answered the part of the question where username_0 asked *"[how] does the transaction come to the pool of miners?"* and explained what incentive there is for miners to include transactions in blocks rather than mining empty blocks.  

---

