Oh thanks a lot, now i understand.
So the "reward" itself is included in the new Block, so for example:
So the "reward" itself is included in the new Block, so for example:
In bitcoin? Yes, that is how it works.
I launch a new coin, and miners start mining, but no pending transaction are available for a loong time.
So everytime a miner start mining, new blocks are created with only miners reward, in this case how I could handle supply?
So everytime a miner start mining, new blocks are created with only miners reward, in this case how I could handle supply?
That's up to you. You are designing the coin, you need to decide how you want it to work.
with difficulty?
With Bitcoin, difficulty is used to control what the average time is between solved blocks. If you want your coin to work the same way, then you need to find a way for all nodes to agree about how fast blocks are being solved, and then to all adjust the difficulty in the same way to speed up or slow down the blocks as needed.
If you don't want your coin to work the same way as Bitcoin, then you get to decide how you want to use difficulty (if any).
In my coin difficulty is measured in this way:
difficulty 2:
Means finding a proof when hashing it with last proof finds a hash with 2 0's at the end of the hash,
difficulty 2:
Means finding a proof when hashing it with last proof finds a hash with 2 0's at the end of the hash,
Are you talking about the hash as represented in binary? If so, that's not going to give you much control over difficulty. For example, if you use SHA256, then you'll only be able to make a MAXIMUM of 256 adjustements, and then you'll run out of zeros. Also, adding a zero is a DOUBLING of the difficulty. You won't be able to adjust difficulty by 10% or 5% or anything like that. You'll only be able to make it DOUBLE as difficult!
At the start it would be very easy to mine blocks, but every 10 Block's I increment difficulty (which means more time). Would this be correct?
So, assuming you are using SHA256 and binary representation, after 2560 blocks you will have used up all your zeros, and have the maximum possible difficulty. Blocks will be solved once every few trillion years. After just 720 blocks you will already have higher difficulty than Bitcoin, and after 760 blocks your coin will be more then 10 times more difficult to mine than Bitcoin.
You really might want to think about the mathematics and incentive structures behind your coin if you want it to work, otherwise it will be completely unusable.
And another question:
When new transactions arrives to my node, I check the transaction signature with the public key (to know if the sender of the tx is the owner of the address), then I add this transaction to a "pending transaction pool" this is a pool of valid transactions that have to be mined, would the node forward this valid pending transactions to other nodes too?
When new transactions arrives to my node, I check the transaction signature with the public key (to know if the sender of the tx is the owner of the address), then I add this transaction to a "pending transaction pool" this is a pool of valid transactions that have to be mined, would the node forward this valid pending transactions to other nodes too?
This is your coin. You can make it work however you want. If that's what you want it to do, then that is what it should do.
If you are asking about how bitcoin handles transactions:
Each node maintains a list of unspent outputs. When it receives a transaction, it verifies that all of the transaction inputs are in its list of unspent outputs. If there are any inputs that are NOT in that list, then the transaction is invalid. The node then executes the script formed by concatenating the Txout-script (also called the scriptPubKey) with the Txin-script (also called the scriptSig). If that script does not execute without error, or does not have a valid result, then the transaction is invalid.
As long as the transaction is valid, then the Bitcoin node adds it to its own mempool (list of unconfirmed transactions) and shares that transaction with all the peers it is connected to which have not yet received it.
Because it can be possible that a miner is not connected to all nodes, and if the miner mine's the block the node would forward the valid block to all nodes.
This is your coin, you can design it to work however you want. If you want ALL nodes to have the blocks, then you need to find a way to share that block with everyone. One possible method (the method that Bitcoin uses) is to forward the blocks (relay them to all connected peers that haven't received it yet)
And another question:
What is the storage system? Just hold it in memory or MySQL for example? or mongodb?
What is the storage system? Just hold it in memory or MySQL for example? or mongodb?
This is your coin. You can use whatever database you want. Bitcoin holds some data in memory structures, and other data it stores in levelDB.
And another question:
Everytime someone does a transaction I have to iterate over all blocks and transactions to check if the public address has enough funds?
Everytime someone does a transaction I have to iterate over all blocks and transactions to check if the public address has enough funds?
This is your coin. You can make it work however you want
If you are asking how Bitcoin does it...
Bitcoin nodes do not keep track of balances at all. Transactions consists of two lists. The first list is called "inputs". The "inputs list" provides value to the transaction. It is a list of some of the outputs that are not currently seen as inputs in any other valid transactions. The second list is called "outputs". Each output in the "outputs list" is assigned value from the transaction. If the sum of the value of the outputs exceeds the sum of the value of the inputs, then the transaction is invalid. When an output is not yet used as an input it is called an "unspent" output. When it is used as an input, it is called a "spent" output. The node only needs to keep track of the unspent outputs. When it adds a transaction to its memory pool, it removes all the transaction's inputs from its list of unspent outputs (since they would then be considered "Spent". It also adds all the new outputs to it's list of unspent outputs.
