what you want to introduce seems to be a master chain that logs hashes of multiple chains
one chain that deals with large value transactions.. EG an IMF institutional wealth swap network.
and another chain that deals with consumer value transactions
thus the IMF institutional wealth swap blockchain has exceedingly long hash solving time and the consumer blockchain having short hash solving time
There seems to be a wrong assumption. Chains should not be two. Rather, should be well thought out how to distribute transactions among the various chains, of which number appears uncertain so far in the thought process. It would be, as per intuition, impractical to assign a chain for each transaction size, for example, 0.80 BTC, 5 BTC, or 1.000053 BTC, as it would be an astronomically large number.
here are the problems
its not just difficulty at play. its the hash COST
a institutional chain could have just 100 asics(real cheap) but a high enough difficulty to make blocks be solved roughly once per hour but costs pennies to solve
where as a consumer blockchain can have 6000 asics.. the same difficulty of the institutional value chain. but due to the mass asics solves blocks in 1 minute but costs 60x more in mining cost
I'm not sure I've got your affirmations. I think they are based on the imposed assumption upon which you're developing your reasoning. Please note that for non-genesis chains, mining difficulty would adjust to transaction size and base itself on a computational power of reference, that is given by the genesis chain, the central chain of reference. The computational power (Pn) to confirm transactions of a
n quantity of bitcoin, would be: P
n= P
0 * log
10n, where P
0 is the reference power for 10 mins.
More powerful miners would have no interest in verifying smaller transactions, as fees could depend on transaction size. The protocol could be assigning miners to their respective chains based on mining power, but it is uncertain if this could open the system to attacks as people could exploit the assignment phase. A secure solution would be to make sure that the point of best profitability for a miner is exactly where he is supposed to be based on his mining power.
Furthermore, there is no direct mention of the number of chains to be two. With the phrase "then increasing mining difficulty for transaction size > 1 BTC, and decreasing it for transaction size < 1 BTC, in a correct mathematical manner (common logarithm)", I describe a situation in which a given transaction size would be associated to its environment of difficulty. "In a correct mathematical manner" is a way to regard the relationship between transaction size and time;
for example,
1 BTC = 10 m (reference, genesis); 0.1 BTC = 1 m; 0.01 BTC = 0.1 m; and so on.
Inversely,
10 BTC = 100 m ; 100 BTC = 1,000 m; and so on.
I apologize for being ambiguous.
the issues are that some dont like waiting an hour for 1 confirm
they want it locked fast but then for security of establishing immutably then decide to wait X confirms
Transactions could still be quickened by paying higher fees, as it is now. For those big transactions that pay bigger fees to make it quicker, mining difficulty would be reduced accordingly to the entity of the fee, thus on how much the user is willing to pay. For example, 10 times quicker, 10 times more costly. These transactions would be assigned to the quicker chain thereafter. For this purpose, it seems important that the transaction size would not coincide with the data size.
which is why bitcoin solves this problem without your idea. becasue those wanting to be confident of no block reversals wait 6 confirms for large amounts before they class it as immutable where as small spenders are happy with 1 confirm.. thus doesnt need multiple chains, multiple mining groups of differing hashing parameters of difficulty
its just simply. wait a few more confirms if your receiving mansion level value or accept 1 confirm if grocery level
Please note that this idea refers to solving the scalability problems of Bitcoin. It gives a possibility to Bitcoin to process small transactions at a faster pace, at the cost, or truly, at the proper implication of transacting bigger quantities in more time. This dynamic seems in harmony with how different quantities of mass influence the perception of time, and movement, in the universe; that is, with more mass comes more time dilation (time runs slower), and with less mass comes less time dilation (time runs faster). So, in parallel: the 10 BTC mass would see the 0.1 BTC mass transacting/moving in faster manners, i.e. at a faster pulse, while the 0.1 BTC mass would see the 10 BTC mass transacting/moving in slower manners, i.e. at a slower pulse. The pulse is the "refresh rate" of the temporal/movement perception, or in Bitcoin's context, the rate of block creation.
,,
the problem is that with different levels of difficulty/timing/costing for mining then makes the value of bitcoin more varied. for instance the institutional level network may be centralised thus cheap mining becasue its closed network amungst the elite using protocols to reject intrusions. thus thety can mine cheap so their rewards/fees can be sold off cheap thus bringing the price of btc down. where as the consumer network open to any participant to mine will cause hash competition and price rises of costs thus want to sell coins/rewards higher to break even thus cause more economic instability..
Such a problem is solved by having a reference computational power, which is the one related to the genesis chain. Non-genesis chains have computational power requirements that are based on the reference requirements, and according to their position, which is in turn according to the transaction size. In this way, the chains wouldn't be independent, but actually all dependent on the genesis chain, which is the one setting the reference. The reference power seems to be supposed by the total hash rate, so a change in that would signify a change in every computational power requirement across the multichain.
I agree that such a system could create problems of centralization for unpopulated chains and be more prone to attacks and for these reasons needs careful consideration. The truly difficult task would be to know how to determine this reference for computational power and how to distribute the transaction sizes among the multi-layer blockchain while preserving the strengths of Bitcoin, most importantly, the all-is-one property. In other words, while having multiple chains, or better saying, different ramifications or versions of the same chain, this remains one single entity, verifiable by everyone not by means of others’ copy but one’s copy. This would be the one task requiring great feats of mind and creativity.
again bitcoin avoids all that by just saying if your moving large yield wealth wait a few confirms
its actually more secure to have 6 hashes of 10 minutes desired solve time each.. rather than 1 hash of 60 minute desired solve time... for multiple reasons
This would be all a matter of the relativity of each chain. Temporal perception would be proportionate to their transaction size and computational power requirements. For example, by following previous reasonings: 1 hash of 60 minutes desired solve time would be related to transactions of 6 BTC; such chain would have its own computational power requirements, which would be 6 times the reference power. A user could still wait a few confirms, and for an attacker to attack the chain would need to adjust his computational power to the chain itself. The perception would be the same for every chain: the only things changing would be the spatial and temporal conditions.
