Another written-up digression ...

Where I am atm: working on nTotalBurnedCoins is slooooow, main.h is imported all over the place and so everything has to be recompiled, which seems to take forever and basically trashes the edit-compile-debug cycle. I've parked this effort on the back burner until I either get a new Linux box or get round to renting a fast machine in the cloud.

ACME-SLM is rolling along reasonably well. The blocknotify script which updates the Fuseki-hosted RDF graph has a bad habit of silently failing, leaving the RDF lagging until I notice it and run a catchup routine which so far has done the trick. So a little more work there, possibly refactoring to use a messaging system to trigger the graph update rather than calling the update script directly.

I'm currently extending ACME-SLM's features, my intention is to make it a desirable companion to the client that can be replicated as required. I picked up the OHLC history from Novaexchange and am retrofitting a marketcap line on top of the OHLC data.

In process:



This entails patching the RPC API to return the total minted coins and total burned coins for a given block, data that is saved in the database index but inaccessible via RPC.

From description of CBlock
/** Nodes collect new transactions into a block, hash them into a hash tree,
 * and scan through nonce values to make the block's hash satisfy proof-of-work
 * requirements.  When they solve the proof-of-work, they broadcast the block
 * to everyone and the block is added to the block chain.  The first transaction
 * in the block is a special one that creates a new coin owned by the creator
 * of the block.
 *
 * Blocks are appended to blk0001.dat files on disk.  Their location on disk
 * is indexed by CBlockIndex objects in memory.
 */

...

description of CBlockIndex and how to detect an orphaned block
/** The block chain is a tree shaped structure starting with the
 * genesis block at the root, with each block potentially having multiple
 * candidates to be the next block.  pprev and pnext link a path through the
 * main/longest chain.  A blockindex may have multiple pprev pointing back
 * to it, but pnext will only point forward to the longest branch, or will
 * be null if the block is not part of the longest chain.
 */

what actually gets written to the index:

    IMPLEMENT_SERIALIZE
    (
        if (!(nType & SER_GETHASH))
            READWRITE(nVersion);

        READWRITE(hashNext);
        READWRITE(nFile);
        READWRITE(nBlockPos);
        READWRITE(nHeight);
        READWRITE(nMint);
        READWRITE(nMoneySupply);
        READWRITE(nFlags);
        READWRITE(nStakeModifier);
        if (IsProofOfStake())
        {
            READWRITE(prevoutStake);
            READWRITE(nStakeTime);
            READWRITE(hashProofOfStake);
        }
        else if (fRead)
        {
            const_cast<CDiskBlockIndex*>(this)->prevoutStake.SetNull();
            const_cast<CDiskBlockIndex*>(this)->nStakeTime = 0;
            const_cast<CDiskBlockIndex*>(this)->hashProofOfStake = 0;
        }

        // block header
        READWRITE(this->nVersion);
        READWRITE(hashPrev);
        READWRITE(hashMerkleRoot);
        READWRITE(nTime);
        READWRITE(nBits);
        READWRITE(nNonce);

        // PoB
        READWRITE(fProofOfBurn);
        READWRITE(burnHash);
        READWRITE(burnBlkHeight);
        READWRITE(burnCTx);
        READWRITE(burnCTxOut);
        READWRITE(nEffectiveBurnCoins);
        READWRITE(nBurnBits);

        //cached hash of the block
        READWRITE(blockHash);
    )


In there is the nMoneySupply value needed (as the dividend to the corresponding OHLC record's price divisor) and I wrote earlier about adding an accumulating total READWRITE(nTotalBurnedCoins) to the above - and happily, hacking the index to do just that is fairly straightforward and seems to work.

Not *just* to retrofit a market cap but also to expose additional essential information via the API and get a better handle on adapting 3rd-party apps that need to read the Slimcoin blockchain.

I can, and shall, configure ACME to use a back-end store, make a daily call on Novaexchange's API and record the OHLC data for that day as a db entry along with nMoneySupply and nTotalBurnedCoins. 24 hours seems adequate granularity for such a broad-brush presentation.

And after that, it would be quite straightforward to extend the data recording to use coinmarketcap.com's API to pick up marcap data for, say a dozen other coins whose market characteristics are perceived as sufficiently similar to Slimcoin's in some aspect or other to act as an index backdrop, setting Slimcoin market data in a more readily comparable context.

The last task is to embellish the publications listing with the metadata that accompanies the signed graph (that will be) stored in the adjacent Fuseki dataspace:



Cheers

Graham

Attending to correspondence often produces digressions, occasionally some are just about worth a separate post:

Hacking around in ABE and ACME and importaddress has given me an insight that I thought I'd share ...

So, you take a zeroed HD, a freshly-installed OS, d/l Slimcoin, fire up the app, run importprivkey and, hey presto, there are your SLIM. What you don't get is those little notes you made for each previous tx but you do see the tx.

It's not a “wallet” at all, it's a transaction browser, scoped to a set of addresses and using a bit of temporary local storage.

Thinking of it as a tx browser relieves you of the misconception that your coins are safe in your wallet, the wallet merely *reads* the blockchain and holds some pubkey/privkey pairs in woefully transient local store. Give someone your privkeys and next time you open your “wallet” it could be empty.

'snot a wallet - thinking of it as one can lead you badly astray.

Cheers

Graham

Good guess but Slimcoin's documentation is a bit erratic here'n'there and this one's an undocumented command-line option:

https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L5451


so -genproclimit=4 and -gen=1 it is. Could try setting it in the config file, see if that works.

Cheers

Graham

I'm with d5000:

The codebase has been persistently problematic in the past, even after extended periods of stability.

I did learn a lesson looking over Mr Spread's shoulder during the period he was running tests with Spreadcoin. The first time through seemed a bit muddled and sort of petered out disappointingly. The second time through, he first published a set of objectives for the testing effort and that did the trick. So that's what I'm working on, a set of safety-first exercises and key callisthenics. With a bit of thought it might be distilled into a basic certificate of competence - the tx on the blockchain to stand as testament.


I'm just another contributor to a communal effort aimed at curating the codebase. True, I have spent a lot of time working on the codebase but that's i) because I've been doing it on my tod so the effort was disproportionate but ii) it was sorely needed. Slimcoin seems to have maintained a reasonably stable network thus far but it is mostly comprised of 0.6.3 clients atm, so I can't really afford to be too pretentious about my perceptions of the impact of my contribution, not if I want them based on reality.

I'm with the crypto on this and I view exchanges as pseudonymous nodes in a peer-to-peer network. As commercial enterprises interacting with the blockchain, they may have interestingly different requirements to non-commercial users. Unfortunately, the goatfuck that is altcoin daytrading rather obscures everything. With a very broad brush, you could paint Novaexchange in reasonably favourable colours for i) knowing how to run a Slimcoin node without it crashing all the time and ii) not delisting the coin, despite the miniscule volume of trade.

I've lost track of the original post but someone produced a rather useful characterisation of altcoins, there were three but I can only recall two i) a store of value and ii) a token exchange, e.g. Dash and Dogecoin respectively. The difference is that the users of token exchange coins get their jollies from using the tokens to gain pro-social benefits, the users of store of value get their jollies from using the token to gain fiscal benefits. The result is that the fiat exchange aspects are given much less significance in the token exchange model.

Where does Slimcoin appear to fit in this characterisation?

Cheers

Graham

It uses an extensively modified version  of Abe, for which the trail starts here.

Slimcoin's extended block structure (as described in “Anatomy of the Genesis block”, a new addition to the website-hosted docs, edits, corrections, etc. welcome) impacts Abe profoundly because Abe reads the block data out've the chain, recreates the individual block metadata and tx structures, then stashes the data in a DB.

It is quite nitty-gritty stuff, even had Peter Bushnell hunting for implementation detail.

It's not clear to me yet whether ABE's db structure would need to be changed for this specific usage (but it obviously would have to be changed for Abe to be usable as a block explorer for Slimcoin).

Cheers

Graham

That bct commentards *still* haven't managed to grok that Dogecoin is a “phenomenon sociologique”, to take a phrase from Close Encounters. But that's hardly surprising, given how many bct posters struggle to exhibit any social intelligence at all.

Prove me wrong.

Cheers

Graham

https://github.com/MatthewLM/peercoin-android-wallet

Needs/Uses a modified Peercoin Abe explorer as a central server to validate hashes.

Cheers

Graham

FB continue to make ill-conceived patent applications that testify to the corporation's innate culture of hostility towards users....

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=20150242679&OS=20150242679&RS=20150242679

---

United States Patent   9,681,166
Naveh   June 13, 2017
Techniques for emotion detection and content delivery

Abstract
Techniques for emotion detection and content delivery are described. In one embodiment, for example, an emotion detection component may identify at least one type of emotion associated with at least one detected emotion characteristic. A storage component may store the identified emotion type. An application programming interface (API) component may receive a request from one or more applications for emotion type and, in response to the request, return the identified emotion type. The one or more applications may identify content for display based upon the identified emotion type. The identification of content for display by the one or more applications based upon the identified emotion type may include searching among a plurality of content items, each content item being associated with one or more emotion type. Other embodiments are described and claimed.

Inventors:   Naveh; Barak Reuven (Palo Alto, CA)
Applicant:   
Name   City   State   Country   Type

Facebook, Inc.    Menlo Park    CA    US

...

TABLE-US-00001 TABLE 1 Emotion Characteristics Emotion Type A, B Happy D Bored C, D Sad E Looking away F Looking at device

---

Unfortunately for USians, the functioning of the econo-political system in the US has degraded to the extent where this ^^^^ nonsense is more likely to be approved than not. Happily we can let FB continue pursuing its own corporate death spiral by poisoning its own watering hole and then having to introduce increasingly preposterous remediation strategies to (unsuccessfully) neutralise the poison that it introduced in the first place.

I call this sort of thing, AI. Yes, that's basically the same “AI” as you're seeing plastered all over the media and prompting discussions of the ethics of classification algorithms applied to machine-logged “records” of human behaviour, etc. the sort of AI where the semantics of the abbreviation more properly refer to “Autistic Intelligence”.

I will readily concede that in significantly-reduced bandwidth channels, it is now effectively impossible to distinguish machine-hosted autistic intelligence from human-hosted autistic intelligence.

I've yet to get a sense of whether that's going to be a Good Thing(tm) or not.

Cheers

Graham

There doesn't seem to have been much progress on peercoinj: https://github.com/kac-/peercoinj


Not unless your mobile device both supports and provides BerkeleyDB libs in the same version as the version used by the client that created the wallet in the first instance No, it has to be an importprivkey if that's allowed, other than that, the SPV client creates a wallet that is suitably compatible to the host OS and that becomes your wallet.

'snot about the wallet, 'sabout the privkeys.

Cheers

Graham

Unfortunately, a lot. As roughly sketched out in the Peercoin forum:

https://talk.peercoin.net/t/goals-18-android-wallet/1242/19

Cheers

Graham

You'll find pretty much all of that is covered in the ANN. If there's anything in there that you feel needs further or clearer explanation, the group would benefit from a brief report of your experience.


It takes a few days. The slimcoin.conf file should be edited to read reservebalance=0.

Cheers

Graham

Ironically, there's an extremely opportunistic “off-the-wall” alternative solution that *would* work in its own offbeat fashion. Upthread, I reported an abortive attempt to add an “watching address” facility which added an importaddress command the to API and would present a pubkey-only address and transactions in the wallet - it’s for when you might not trust the integrity of the system/client, you can keep an eye on your stash without exposing the privkey. It seemed to work but without considering the full implications, I thought “although it's supposed to be for watching your own addresses, technically it should work with any address” and I tested it with the Slimcoin burn address - and the client promptly went into overdrive calculating the stake weight for all the burned coins ('cos all the wallet can see is *incoming tx*).

However, if you set reservebalance on a fresh empty wallet to a comfortably large number, import the burnaddress and thereafter, the RPC command getbalance will return the balance of coins sent to that address --- which is the current total number of burned coins, the magic number required for a marketcap calculation.

Would need a dedicated node on its own port but hey, it'd work.

Cheers

Graham

Iff it floats your boat My sense is that the community is relaxed about such things and I was content with contemplating that at least it'll be nice to be able confer occasionally on the odd engineering nuance.

Cheers

Graham

D'yknow, I was so focused on the syntax that  I paid only scant attention to the semantics. The soft fork is to enable the situation described the comment:

 

It would be a soft fork in that future blocks will be a subset of all blocks, including those that were minted before the fork and which could contain scripts whose meaning would change and whose outcome would be different under the new script rules.

In this instance (caution! “weasel words” - DYOR) it doesn't appear to be the case (caution! “weasel words” - DYOR) that the introduction of CHECKLOCKTIMEVERIFY would cause previously-successful Slimcoin scripts to fail or vice versa.

I'm always cautious about assuming that the existing blockchain doesn't contain any retrospective “gotchas” which could be triggered by the subsequent introduction of a script feature.

An example - and a snap test for those following along at home ... have there been any multisig transactions recorded on the Slimcoin blockchain?

Cheers

Graham

Fortunately, neither. The presence or absence of the total doesn't affect the coin's operations at all. The calculated total is stored in blkindex.dat - which the client constructs for itself either by reading an existing blkindex.dat or by reading the data from the blockchain, laying down a new blkindex.dat in the process. The tx data from which the total is calculated are in the blockchain. All very properly self-contained.

Cheers

Graham

Oh no, not by any means and I'm horrified that I inadvertently gave you cause to think so. By OP I meant slimcoin@anche.no - that's the canonical source.

Cheers

Graham

edit:

I'll bear that requirement in mind when filleting the posts, if I can get it right, you should just be able to paste and edit to your satisfaction.

Understood, np. With that future possibility in mind, I'll devote some time to tidying up the workplace, making it more sharable, that sort of thing. I've learned to appreciate a well-designed on-ramp, let's see if I can manage to create one myself.

Reporting back - still “close but no cigar”. The adjacent latest peercoin code includes a -reindex facility. However, it uses routines added to PPCoin but not yet to Slimcoin, so there's a degree of subsidiary support required.

I suspect the solution will necessarily include a fix for getting the client to actually read the blk0001.dat file - a resolution of that issue is somewhat overdue; distributing a datadir snapshot is a convenience but has a social bug in that it inappropriately requires users to trust the originator.

Cheers

Graham

Noted in the Spreadcoin thread, someone lost 10K SPR by sending them to an uncompressed address instead of the compressed one.

https://bitcointalk.org/index.php?topic=1045373.msg20223325#msg20223325

In hindsight, the decision to save a few bytes by defaulting to the use of compressed addresses was perhaps more costly than anticipated.

Slimcoin addresses also use a networkbyte (address prefix) of 63 but Slimcoin uses the more usual uncompressed address format, so the default is “safe”. But if an uneducated user selects “compressed” and sends SLM to that address, those coins will be lost and gone forever.

It's worth being aware of the difference.

Cheers

Graham

That's exactly the route I was planning to take. Of course, with the blockchain being a representation of a state machine in successive states, there's nowhere other than that representation of state to store, well, state. YIL that metadata is stored in blkindex.dat:


    CBlockIndex()
    {
        phashBlock = NULL;
        pprev = NULL;
        pnext = NULL;
        nFile = 0;
        nBlockPos = 0;
        nHeight = 0;
        bnChainTrust = 0;
        nMint = 0;
        nMoneySupply = 0;
        nFlags = 0;
        nStakeModifier = 0;
        nStakeModifierChecksum = 0;
        hashProofOfStake = 0;
        prevoutStake.SetNull();
        nStakeTime = 0;

        nVersion       = 0;
        hashMerkleRoot = 0;
        nTime          = 0;
        nBits          = 0;
        nNonce         = 0;

        //PoB
        fProofOfBurn   = false;
        burnHash       = 0;
        burnBlkHeight  = -1;
        burnCTx        = -1;
        burnCTxOut     = -1;
        nEffectiveBurnCoins = 0;
        nBurnBits      = 0;
        burnt = 0;
    }


and that's where moneysupply is stored, explicitly in each block's database index entry. (So I need to legislate for a blank datadir where blkindex.dat has yet to be created.)

The tail-end burnt (above) is the addition I made that preserves the net burned coins accumulated total up to the block forming the current state. (It still needs to act sanely when rendering an arbitrary block, so from a contemporary perspective the index entries have to be “backfilled” - however, because it's a state machine, the translation boils down to “redo from start, as required”.)

I added a burnt field to CBlockIndex and adjusted AcceptBlock to keep score of the accumulating total of burnt, scribbling it into the new CBlockIndex structure. It compiles and runs but testnet is limping atm and whilst it does record and tally new burns, I don't think there were any burn txs in the testnet blockchain that I was using, so it's unclear (without close, time-consuming detailed inspection) whether something as usefully straightforward as -rescan will, as one might hope, recreate the index from scratch, recording the accumulating “burnt” as it goes. atm, mainnet is allegedly “Loading block index ...”, I'll report back later.

update - it does partly work - on mainnet, the client was behind by a few thousand blocks. It recorded the accumulating burn tx nValues for all the new blocks accepted during syncing (several thousand SLM), so that strongly suggests that if all else fails, a sync from 0 will create a fully-populated blkindex.dat including a block-by-block tally of the number of SLM made unspendable.

In the meantime, I'm trying other tactics to persuade the client to reindex from start (maybe I just need to copy across the -reindex code from a nearby codebase and make sure that it starts from 0).

Laters.


Cheers

Graham

P.S. If your successful second-guessing gets any more detailed, it'll risk being mistaken for a PR

Just for starters, I have hacked the calculation directly into the getinfo call:

{
"version" : "SLMv0.5.0-3-g43621ddb-dirty-alpha",
"protocolversion" : 60003,
"walletversion" : 60000,
"balance" : 0000.0000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 1047752,
"moneysupply" : 16588427.50562300,
"burnt" : "1949861.259862",
"connections" : 6,
"proxy" : "",
"ip" : "88.98.87.243",
"difficulty" : 0.03901757,
"testnet" : false,
"keypoololdest" : 1495960540,
"keypoolsize" : 104,
"paytxfee" : 0.01000000,
"errors" : ""
}

It's not a solution because it counts afresh from 0 each time it's called and that seriously slows down the response time - to a few minutes, lol. But it does work.

Cheers,

Graham