Imagine where Bitcoin would be now if it had an ever growing assured minimum price? Imagine the price of each BTC now if all the money used in the very expensive arms race that has been raging for years had simply been poured into the market instead of fattening power company and Asic producers' pockets? I bet there would be a minimum supported price of ~ 5000.
Sounds about right. Bitcoin would have attracted far more confident investment and would now be a useful tool of commerce, not still languishing as an irrelevant toy for small time gamblers to play with.
Beginning to optimize what i can of the bidding process, have already reduced from >1000 lines to ~ 850. Hopefully i can keep make it faster and more efficient until the "poll and parse" wait is negligible.
If anyone can help, i want to try multi-threading using either the standard pthread or else boost.
If there's eg. one daily superblock of fresh BCR mintage and asset addition, could the asset data (or some of it) be built into that block so that other clients could share it, and not have to recalc all of it themselves, just calc the additional daily running totals of bids? Of course, the client should be able to independently verify the superblock data if wanted, but it could default to the block record.
This assumes that any asset expenditure also comes out of / is accounted for in the daily superblock.
Ah, thanks, i guess i never really laid out the system , let me do it now.
Basically, in order to maintain consensus i have decided to use block count rather than time, by using the networks' average blocktime we have an easily verifiable point. A few blocks before (maybe 5 ) the daily payout block, the mining enabled clients poll api's for the balance, bids and amount, sort through the data and create a file with the relevant details ready for adding to a block. When the payout block is due, clients build the block based on the data supplied. In order to keep things stable, miners will only poll the api's once a day all at the same time, this will result in uniform results across the board (as far as i have tested).
Eventually, (once i figure a safe way of excluding blocks not produced by a BN) only BNs will be mining enabled, or if you wish to proxy mine, you will need a active Bank nodes' key. However to avoid a few Bns totally dominating the scene (much like any serious miner can do now) I will place extra restrictions on blocks, ie blocks signed consecutively by the same key will be rejected. This means each key can only sign a single block every 20 or so blocks (this is enforced by default simply because even if you have a script making new addresses to mine with, it will still take you 20 Blocks to get the confirms necessary for a BN to become active) pretty nifty eh?
I think relaying the data from a few points creates possible room for manipulation and exploits. While it would be less resource hungry, a client can get fed false data , thereby encouraging forks in the network. The way things are, each node should be able to independently verify a block's accuracy. While we maybe be adding elements of distributed networks to the decentralized model i think we should keep clients able to function autonomously and able to verify everything for themselves.
As part of the test, i will release a dumb rc that will have the mining stuff enabled but ineffectual, then we can all compare results, that way we can compare what happens across operating systems and pcs' with different "endianess".
As for assets , the way it works is that there are two different addresses for each asset, the first is a normal address that receives the daily bids, after a payout block, a script will send all those funds into a multi-sig address whose keys are provided by the community. Target address type is a 3/5 multi-sig, meaning that we need 3 people to agree on any action related to those funds before anything can be done.
We already have 4 sets of keys, i am waiting for the fifth to provide keys then we can start testing it out.
