Slimcoin | First Proof of Burn currency | Decentralized Web

[gjhiggins]

Early, publicly-accessible version of ACME block and tx explorer customised for Slimcoin:

http://tessier.bel-epa.com:6053/ <-now 6054

I have tried ACME now and it seems to work fine - only address queries seem not to work still, but that should be related to what you said about the still lacking SPARQL strategy for these queries. Thanks again for your work!

The address details are now rendering and all txin & txout (not quite sure how to enable results to be elided just yet). I haven't yet checked it but I noted that the balance of an address of mine seemed to be in the ball park. Just for passing convenience, I added the burn, donation and bounty addresses to the Transactions menu. The address layout remains as confusing as I am confused. I imagine the presentation will become more coherent as the user task information requirements become clearer.

The SPARQL works quite nicely, e.g. this for the txouts:

Code:

PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
SELECT DISTINCT(?txo AS ?transaction) ?datetime ?value ?stype
WHERE {
    ?txo ccy:address ccy:ShooqRfkshDajLTvYMEKRKxXW7ooZLBZsm .
    ?tx ccy:output ?txo .
    ?tx ccy:time ?datetime .
    ?txo ccy:value ?value .
    ?txo ccy:type ?stype
} ORDER BY DESC(?datetime)

Cheers

Graham

[ribdyne]

Guys,

There's any reason why the website and ANN on CoinMarketCap still outdated?
I can ask them to update this.

I'm at the same page with @dzarmush. This coin is been actively maintained, but for investors can seems risky to invest without a roadmap, plans for the future, an so on.

Until a better looking website can make some difference here. I can help with that.

[dzarmush]

Guys,

There's any reason why the website and ANN on CoinMarketCap still outdated?
I can ask them to update this.

I'm at the same page with @dzarmush. This coin is been actively maintained, but for investors can seems risky to invest without a roadmap, plans for the future, an so on.

Until a better looking website can make some difference here. I can help with that.

Since Slim is probably one of the most truly decentralized coins with no foundation and stuff like that I guess we need to self-organize somehow. I'd start with spreading some info about Slim thought different media. So what we need is a nice article about Slim and a list of most popular crypto news websites. Anybody have one? If not I'm gonna go and find out )
What I can't do is to write about Slim. We need someone to do that.

[muf18]

It's developed, but with only one dev, which is contributing we can't expect to have fast progress - but we have steady and good progress with experianced dev, who is Graham.
Coinmarketcap is outdated, because it doesnt have api to see the coin supply - ACME will resolve it.
It's the best thing it's so decentralized, I thought about starting foundation, but I don't think it's necessary.

[gjhiggins]

What I can't do is to write about Slim. We need someone to do that.

Unfortunately the OP doesn't seem interested in contributing but I am in the process of manually filtering the scraped posts of both bct Slimcoin threads for social and technical insights which I will (ultimately) summarise into a single posting to the group. I will also winnow the findings for useful passages to include in some in-wallet documentation which is so sorely needed.

On a slightly different matter, distributed exchanges are being discussed on HN today by some fairly well-grounded people https://news.ycombinator.com/item?id=14792071 (patio11 rounds off his observations with a delightfully wicked barb).

Some reflection might encourage the perception of an “exacting standards” programme as a defining feature of a centralised operation. Personally, I'd go further and tag it as a definitional element of corrupted centralisation. The fact that the more the hierarchy strives to exert control, the harder the attitude it takes towards enforcing exacting (what other type is there?) standards reveals it to be a typical component of command-and-control tactics and therefore not just irrelevant in a peer-to-peer context but potentially harmful because it works by falsely persuading peers that their understanding is faulty, i.e. it exploits a known vulnerability of peer-to-peer networks, that of pluralistic ignorance (aka “the bystander effect”). I believe I did mention that I'm a cognitive psychologist by training, so you may take it as read that I can supply peer-reviewed empirical support for my claims.

Not that such a meta-analysis is needed though; the programme is patently bogus from an engineering perspective because it's severely sub-optimal. The optimal approach for public-facing APIs is one that focuses on function, taken from the profoundly mature understanding of impedance-matching in the hardware domain: “be forgiving in what you accept as input and strict in what you emit as output”. (I may not have mentioned that I also know my way around a circuit board.)

Cheers

Graham

[gjhiggins]

Coinmarketcap is outdated, because it doesnt have api to see the coin supply - ACME will resolve it.

ACME is overkill for such a basic software engineering problem. The appropriate action would be to add the necessary command to the JSON-RPC set. I shall investigate what's involved and report back to the group.

It's the best thing it's so decentralized, I thought about starting foundation, but I don't think it's necessary.

May I suggest “the best thing is its insistent focus on decentralisation” and fwiw, I agree with you about a foundation not being necessary but it might not actually be undesirable if it were able to preserve and promote the insistent focus. Asimov has already given us a model (Foundation, Second Foundation) which we can adopt should we wish, being fully aware of the irony and using it to our advantage.

TBH, we're collectively treading fresh ground here. There's no map, just vague indications and hints along the lines of “heere be tygers” or “maybe some rockes”, gleaned from hard-to-replicate empirical studies in the social sciences.

Cheers

Graham

[d5000]

Until a better looking website can make some difference here. I can help with that.

The website is maintained at Github: https://github.com/slimcoin-project/slimcoin-project.github.io

You can fork the repo and make pull requests for (S)CSS style improvements and so on. However, I would strongly advise against a typical "shitcoin" website style (those that look like a standard Wordpress theme). The general idea behind the website is to provide a clean experience like http://bitcoin.org and to be multi-lingual, but obviously the Bitcoin site is much better still. Also, a better start page image idea  - but with similar associations of "community" and "decentralization" - would be a good idea ...

A good idea, I think, would be to integrate the design @dzarmush elaborated in some way, maybe with a "smaller" version of the header, with the title and subtitle right of the logo, so it fits in the website header.

@gjhiggins: Thanks again, also for the BIP65 feature! I'll look into it later today.

[drbarber]

Hi again, newb OSX Miner here. Previous problems resolved, thanks for those who helped.

I started mining through the OSX QT, everything seems to be running smoothly.

How do I know my mining attempts will get rewarded?
I see blocks get mined (i.e. it was on 1047677 and now 1047678) but I don't receive anything.
Do I receive the coins randomly or do I have to have the best hashrate or something else?

Below is my current console:

Code:

11:59:24
getmininginfo
11:59:24
{
"blocks" : 1047680,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.04372810,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 1058,
"networkghps" : 0.00118868,
"pooledtx" : 0,
"testnet" : false
}

[psycodad]

How do I know my mining attempts will get rewarded?
I see blocks get mined (i.e. it was on 1047677 and now 1047678) but I don't receive anything.

You never know, while your hashrate suggests you should be finding a block something like every 1000 POW blocks, it can happen in the next minute or never. Over the longer run, the percentage of found block solutions should get close to network hashrate / your hashrate.

Do I receive the coins randomly or do I have to have the best hashrate or something else?

Your miner has to find a block solution, then you will get the coinbase transaction to your wallet (new coins). Simply put, you are rolling 1058 dice a second with a chance to get the right magic number that makes it a block solution, while the rest of the network rolls 1188680 dice a second.
People call what you do solo mining, in contrast to pool mining (which is not possible yet for SLM) where many small miners group together and share their block rewards according to the hashing power they contributed. You probably had pool mining on your mind with your question.

I'd recommend you to buy a few SLM on an exchange to further explore the fun of staking and burning SLM which seems currently  more rewarding in terms of coins earned.

HTH

[drbarber]

Ahhh thanks I understand.

I'd recommend you to buy a few SLM on an exchange to further explore the fun of staking and burning SLM which seems currently  more rewarding in terms of coins earned.

What does staking and burning do exactly that could earn more coins?

[psycodad]

I'd recommend you to buy a few SLM on an exchange to further explore the fun of staking and burning SLM which seems currently  more rewarding in terms of coins earned.

What does staking and burning do exactly that could earn more coins?

Please note that I said "seems", that statement of mine is purely based on anecdotal evidence from my own experience and what others posted here in the thread.
I just meant that if you're impatiently waiting to see a block minted by and to your wallet, you'd have probably a faster success by investing $5-10 in SLM, burn 10-20% and let the rest stake in your wallet. But for sure you can also keep your computer running and mining and with some luck you'll get a block within the next 24 hours.

[drbarber]

Please note that I said "seems", that statement of mine is purely based on anecdotal evidence from my own experience and what others posted here in the thread.
I just meant that if you're impatiently waiting to see a block minted by and to your wallet, you'd have probably a faster success by investing $5-10 in SLM, burn 10-20% and let the rest stake in your wallet. But for sure you can also keep your computer running and mining and with some luck you'll get a block within the next 24 hours.

Ah, I just mean I don't fully understand what burning or staking do, can you explain? The 1st page is a bit technical, I liked your explanation for mining.

[gjhiggins]

Coinmarketcap is outdated, because it doesnt have api to see the coin supply - ACME will resolve it.

ACME is overkill for such a basic software engineering problem. The appropriate action would be to add the necessary command to the JSON-RPC set. I shall investigate what's involved and report back to the group.

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

[Sorai]

As I reported earlier, I immediately received two mints by staking.  These have now been confirmed.  My wallet balance includes these now.

However, the address field for the new mints says "(n/a)" in place of an address or address label.  (On other coins I have staked, newly minted coins are deposited into one of the pre-existing addresses containing the staked coins).  For this account, under "receive addresses" there is only one address. Why didn't this address receive the minted coins?   Why doesn't the wallet display the address into which the newly minted coins were placed?  

Update:  I checked the only address associated with my wallet in the block explorer.  The balance on the address does include the amount I received from minting.  

In terms of how staking deposits were made, block explorer shows the original deposits to the address being split in half, with half of each of the two staking returns added to each of the half of the original deposits.  Here's what it shows (numbers are just illustrative):

address X (1000 SLM) -->
address X (550 SLM)
address X (550 SLM)

(550+550)-1000 SLM=100 SLM
1000 SLM was one of deposits I previously made to address X.  100 SLM is the staking amount received from staking that deposit (according to my wallet). 
  




 

[akamy789]

I didn't smile when I bought this coin, because I was always high

[cryptovore]

{
"moneysupply" : 16588427.50562300,
"burnt" : "1949861.259862",
}

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

How does the moneysupply var gets calculated? It is stored somewhere in a separate field? Given the specifics of Slimcoin, I think the burnt var should be a citizen with the same rights as moneysupply, thus a stronger approach to store and display it should be acceptable. I.e. "caching" it into a separate field on the data structure.

[gjhiggins]

{
"moneysupply" : 16588427.50562300,
"burnt" : "1949861.259862",
}

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.

How does the moneysupply var gets calculated? It is stored somewhere in a separate field? Given the specifics of Slimcoin, I think the burnt var should be a citizen with the same rights as moneysupply, thus a stronger approach to store and display it should be acceptable. I.e. "caching" it into a separate field on the data structure.

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

[gjhiggins]

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

[cryptovore]

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

If by PR you mean Pull Request, I'd be happy to contribute at that level, but ATM the daily job requirements are swamping me. It will be a good opportunity to brush up on my C skills (which are lame, to be optimistic). BTW: your RDF suggestions are top of the list, for whenever I may find some decent chunk of time (weekends are good candidates for that).

[gjhiggins]

ATM the daily job requirements are swamping me

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