BTW Graham did you get my PM regarding setting up a foundation BTC address to accumulate BTC for exchange listings and other things where they only accept BTC or fiat like a server and such?
Yes I did, sorry for the lack of response. In order to construct a coherent and accessible non-technical description of the problem, one first has to understand the nature and detail of the problem. Usually, laying bare the nature and detail of the problem is a direct precursor for a solution, as it proved to be in this instance so I chose to implement the solution first and write about it later.
I've got this far;
getinfo
{
"version": 13000000,
"protocolversion": 70016,
"walletversion": 130000,
"balance": 0.00000000,
"newmint": 0.00000000,
"stake": 0.00000000,
"blocks": 5,
"timeoffset": 0,
"connections": 2,
"proxy": "",
"testnet": false,
"keypoololdest": 1513046497,
"keypoolsize": 100,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
}
I'll restrict my comments to addresses, preferring to leave the emissions control system until I've constructed a more detailed mental model of its structure and functioning. I'm not completely out of the woods yet ...
2018-01-25 01:40:28 ERROR: ContextualCheckBlock() : incorrect proof-of-work at height 5, 1e0fffff / 1e0f095b
2018-01-25 01:40:28 InvalidChainFound: invalid block=000008324[...]6906668 height=6 log2_work=22.807356 date=2018-01-25 01:40:28
2018-01-25 01:40:28 InvalidChainFound: current best=00000c054[...]4ce9a80 height=5 log2_work=22.584964 date=2018-01-24 23:16:40
The UTXO set/public ledger transfer is eye-wateringly detailed here:
https://github.com/gjhiggins/been/blob/bee/src/chainparams.cpp#L46 and initial results are
very promising.
Previously, I just used an arbitrary address and a 1234567890 balance conjured out of thin air, worked okay a coupla months ago:
This time out, I created three additional pub/prv address pairs, funded from the community chest and I parked them at the front of the queue so I could check whether the advertised “do it in the genesis block” solution actually worked:
This is all from the current code as committed to the repos. If you can compile up a Linux binary of Bee Core (I haven't got round to working out how to adjust the gitian build system to generate Windows/OSX binaries) then you can import your privkey(s) into it and check whether your UTXO balance i) shows up at all and ii) is accurate. I hope this works as described, it is the most
transparent solution. But if not, there are other ways of skinning this particular cat such as a hacking the reward calculation to yield a humungous premine (the unspent total UTXO set) in block 1, credited to a distro address and use the rest of the blocks mined during the stabilisation period to turn the premine back into the UTXO set simply by sending the corresponding calculated balance to each address until the premine's all spent.
For those who like to work things through for themselves ...
It's the PoS thing, see. AFAIK there are only two PoS alts cloned from Bitcoin Core > 0.10, PIVX and Navcoin.
The technical cost of ownership of PIVX’ complex architecture and functioning puts it currently out of reach of the Bee community (that's my informed assessment). And anyway, PIVX is a clone of Dash and is basically Core 0.11 with Dash additions - I'm unsure whether it includes CLTV (enables decentralised exchange ops).
OTOH, NavCoin is a clone of Bitcoin Core 0.13 (mostly 0.13.1, with a few elements from 0.13.2) adapted for PoS and augmented with some centralised anon servers. CLTV is a feature of 0.13 so decentralised exchange ops are available from the get-go.
Bitcoin Core 0.10 changed the protocol, optimising and reducing the amount of data being sent over the wire, effectively throwing a terminally large spanner into the stake calculator engine (Bitcoin devs couldn't care less). And this is why the vast majority of PoS alts are still running on clones of 0.8.X (attested to by the presence of a qmake .pro file) - a few may have have upgraded to Bitcoin Core. ... okay, I
had to check my model against reality and it holds true for all the Bitcoin clone PoS alts in the top 86 alts on coinmarketcap ... Bitcoin Mechanic
claimed to have a solution, albeit not quite complete but it didn't get far. I
think the 0.10 optimisations stopped carrying the date of each of the txs, deemed necessary to calculate coin age. At least that what I'm inferring from
Hans Robeer's solution for PeerCoin - AIUI, his insight is:
for the limited purposes of coin age calculation, using the block time as a proxy will suffice. I suspect this is how Navcoin also solves the problem, given that they're adding
nTime back into the CTransaction class definition:
Bitcoin Core 0.13.1:
https://github.com/bitcoin/bitcoin/blob/03422e564b552c1d3c16ae854f8471f7cb39e25d/src/primitives/transaction.h#L371Navcoin:
https://github.com/NAVCoin/navcoin-core/blob/master/src/primitives/transaction.h#L408Aaanyway, the overall plan was/is to do some basic re-branding, strip out the anon stuff to leave a vanilla Core 0.13 PoS coin, switch in the key Bee parameters and insert the Bee UTXO/public ledger.
What I'm stuck on atm is the PoW instamine that kick-starts the blockchain. Because Bee is basically just Navcoin-rebranded code and Navcoin kicked off with a PoW period before changing over to 100% PoS (as hashrate from staking took over from hashrate from mining), Bee needs to follow the same pattern (except that as we don't need incentivising to mine a few BEE blocks, any generated during the PoW will accrue 0 BEE reward). The coins in the transferred ledger should be ready for staking as soon as the
importprivkey returns, so it seems reasonable to expect stakehash will pick up reasonably promptly.
Part of the problem is that Navcoin's own PoW and emissions control code has been untouched since they switched to 100% PoS aaaages ago and the rest of the codebase has since moved on and there may yet be unresolved issues in that department but on the face of it, those tests that are expected to pass (i.e. they do with Navcoin) do pass, looks like the engine is assembled okay, it turns over, starts and even runs, briefly and now it becomes a matter of adjusting the carburettor/timing settings, so to speak. I just have to study the code a bit more and make intelligent use of the QtCreator debugger (a very acceptable IDE, IMO).
The trouble is, I don't often get blocks of uninterrupted time so progress tends to be in fits and starts.
Cheers
Graham
