Is the network working at all? how many nodes are available? Was not there a dangerous blockchain fork?
We've been tracking 20 or better nodes for the last several months.
The
coinbase maturity is 3000 and I haven't witnessed any wipeouts due to reorganization.
I say we need to drastically reduce the number of confirmations needed. All the coins are trying to increase transaction capacity and Datacoin is chugging along at 3000 confirmations. I understand that it was probably to stop censorship via 51% attacks, but that is not our immediate concern. We need adoption, and that means network speed.
So I am seriously proposing that we drop the number of confirmations needed to 6.
We all think that the disappearance of the developer killed the coin. But if there had been wider adoption other developers would have stepped forward sooner.
Hi Extro,
The two types of transactions to be concerned with here do not affect transaction capacity or network speed by any large measure.
We're basically speaking to the properties of transaction inputs.
One case is where the input to the transaction was an unspent output from a mining reward and the other case is an input which happens to be an unspent output from a user signing over some datacoins to another address.
The first type of transaction is just like what you find in the Genesis block.
These are emissions from the blockchain in the form of miner rewards and are referred to as coinbase transactions.
Coinbase outputs are created out of thin air due to consensus protocol and proof-of-work; as an incentive to miners for securing the network.
These outputs must be 3,000 blocks deep and considered "matured", before they may be used as an input in another transaction.
The second most common type of transaction is the ordinary transaction where an unspent output held by one address happens to be signed over to another address as an input within a transaction.
The owner of the matured datacoins may spend them and use them as inputs in a new transaction.
The new owner will have unspent outputs which can be used in a subsequent transaction.
The new owner will not need to wait 3,000 blocks.
These types of transactions are the common transactions you are referring to which typically have 6 confirmations before they may be used as an input in another transaction.
In other words, if you buy some datacoins on an exchange you do not have to wait 3,000 confirmations before the coins are yours or to be free to spend them.
COINBASE_MATURITY has nothing to do with transaction capacity whatsoever. It is a consensus rule which helps people from losing coins.
If you want to decrease it substantially, first we must grow the network such that the proof-of-work hashrate is orders of magnitude greater and sustain it for a very long time and only then *maybe* consider reducing COINBASE_MATURITY.
Here's how it works. Let's suppose there is a fork.
Now, let's suppose the fork isn't reconciled for 500 blocks.
Now let's suppose merchants are concerned they will lose datacoin as a result of the 500 block deep reorganization.
Since the transactions are going to be reconciled on both sides of the fork, none of those merchants will lose any datacoin.
The above statement precludes any malicious intent or attempts to double-spend.
... also, since the COINBASE_MATURITY is 3,000 there will be no chance for "new" coins from the losing fork to have ever been spent because the fork was small ( 500 < 3000 ).
Therefore, only valid coins would ever be spent on a 500 block re-organization and the transactions will reconcile on both sides of the fork.
The only loser in a 500 block re-organization when there is a 3,000 confirmations deep network confirmation protocol would be the pool or miner who happens to have been on the losing fork.
Hopefully this helps to clarify how COINBASE_MATURITY is a relatively insignificant feature of the protocol when it comes to evaluating network speed.
Network speed is governed by target spacing, hash rate and peer connectivity.
The target spacing determines how many seconds / minutes there are supposed to be between each block.
The hash rate being regular and sustained keeps the network hitting its target (difficulty) at the prescribed time repeatedly.
The peer connectivity helps to relay new blocks and transactions in a timely manner.
These properties are within our control by influencing an outcome where we achieve an ever increasing hash rate and continue to add new well-connected nodes to the peer swarm.
Best Regards,
-Chicago