Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 90. (Read 137076 times)

Wallet miner is slow. Use JonyLatte miner, it is many times faster

Yes, I use the wallet miner. I have different CPUs, but I can check my hashrate with "gethashespersec" in the wallet.

That's why I'm asking for an estimate per 1000 H/sec, so I can calculate the rest myself

Do you use wallet miner? What CPU you have?

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

It is true that can be seen as a shortcoming but it is a deliberate design feature (mentioned the original ANN, see the link in the top-of-thread ANN).

Cheers

Graham

It is a straightforward consequence of my role as first-line partner support. Ngaio is my primary commitment, everything else is secondary.


That's the leverage I'm looking at.

Cheers

Graham

Ok, I now understand (maybe not everything, but I got a sense of what you mean). I didnt mean that dev, must be a centralized position, because there can be a lot of contributing developers as in Bitcoin was before Core team was defined (and thus it meant centralization of developing - I agree with you about that, it's not what we intend to). But I know what you meant.

With Datacoin parts of code, we could make better implementation of web2web, as I see.

@klmes - lead to lower inflation, and thus better value. It's a quite clever system, because it makes to take initiative, when it's low on hashrate and diff, and gradually makes it harder, this mechanism from Peercoin is ok, others (POS shortcomings, and high fees without miner reward, is something to be considered to change)

This coin has a shortcoming is more people to dig, dig will lead  to less，

As I mentioned earlier, I was investigating Datacoin because I was interested in finding out more about how the metadata was handled. With Datacoin, you could run apps straight out of the tx data. Could easily put a lightweight client in there, as binary. Iff you had metadata. You'd have to trust the address of the publisher and that could be conducted in a separate side channel and you could find out the metadata that way. But it's fragmentary, needs to be collated, so I adapted an ACME to check whether it worked in practice - and also get a sense of how much use was being made of that facility (elsewhere this is called “market research”).

As quid pro quo, I'm having a go at contributing an upgrade to a later codebase (aka “gaining experience”). It's what I do. I'm also contributing to Beecoin and Helium, have contributed to BelaCoin, Sprouts, PIVX, the list stretches right back to Feb 2014.

I have been quite specific, I'm a contributor and it would be a mistake to consider me as “the dev” for two reasons, the first is because it runs counter to Teal principles - to have “a dev” is a centralisation influence, the second is because this influence tends to create a central point of (all too human) failure, the very opposite of what was intended. This is a shared resource with shared responsibilities (if it's to sustain itself).

The Slimcoin network is recovering from its Nov 2016 all-time low, the engine's somewhat idiosyncratic-but-not-entirely-unpredictable behaviour is now more widely appreciated and some apparently reliable workarounds exist. By reference to the networks that cryptopia can apparently see, the Slimcoin network is positively glowing with health:



(It is entirely possible that they under-report as much as novaexchange does for Slimcoin nodes https://novaexchange.com/addnodes/SLM/ but even if that is the case, ~40 nodes is still pretty healthy in context.)

There a number of GUI improvements in development, including an incomplete but functioning implementation of watch addresses. The torrenting aspects of web2web publishing proved tedious and torrent metadata is solely concerned with transport and reconstruction of resource fragments, it doesn't even record the mime type of the torrented resource, instead that task is devolved to torrent trackers.

The protocol doesn't really matter, if you're publishing content then if you're not hosting it yourself, someone else is on your behalf. ACME is aimed at allowing club members an alternative to torrenting / coughing up Bitcoin to have content hosted on IPFS. Run your own, share one with others, do as you see fit, there's no constraining cryptographic inheritance here, feel free to be as disorderly and rambunctious as you like.

I have an old blog in XML that I'm planning to render as HTML with base64-encoded resources, I just have to work out a metadata scheme (i.e. set of RDF statements) that I can store in the associated “metadata+content” graph, which I can then use to feed to javascript to get it to programmatically populate the other tabs of the standalone “A different perspective” post, turning it into a micro standalone blog app (with safely-embedded javascript libs + Semantic-UI css framework) with a list of past posts, titles, dates, abstracts, etc. which can be rendered in the wallet as a Qt-driven specialised in-wallet blogging app or the same thing as a component of an ACME instance, wherever hosted. Hey, twitter started out small.

Cheers

Graham

Thanks for creating this thread OP.



Is there a contact page if I have any questions or should I just ask them here?

Yes, it's also a reader. The retrieved content is base64-encoded text/html, ready to be base64-decoded and dumped into QtWebView (if you want it in the wallet) or into the html document if it's on an externally-hosted ACME.

The blog posts will go to whichever ACME you want. Maybe you run your own, locally or remotely, maybe you share one with some other people, maybe you took out a subscription to a commercial offering...

Riffing again, ACMEs could differentiate themselves by offering enhanced content presentation or specialising in themed or topic-related content. Or you can have one dedicated to your own content.

There'll probably need to be already-paved cowpaths so that people who opt to gain the advantage of signed graphs are assisted by automatically embedding non-text content as base64-encoded resources because otherwise, the common model of referencing external resources would defeat the purpose of a signed graph - to attest to the integrity of the RDF statements by validating the hash of the serialised graph. With external references, you're basically saying “It was over there, the last time I looked.” Which is a valid statement to make but rather a weak one with little purpose that I can discern. I'm fairly confident that Fuseki's back-end persistence takes advantage of compression and base64-encoded resources suitable for web presentation aren't all that luxurious, so it does seem do-able.

I'm not making any claims for the approach other than it's a means of publishing indexes to signed RDF graphs, with the overall expressive power that brings.


Cheers

Graham

Well, just hitting M1 isn't going to be that easy. As I noted, Datacoin had all the right elements in place but few people were interested, even with the comparative luxury of 128Kb per tx. My sense is that the UX was too fragmentary to offer much appeal and, in consequence, failed to present a coherent narrative. The crux of the issue is metadata. Metadata tells you what's stored and how to access it. Without that metadata, all you can do is serially guess. The adaptation of ACME for Datacoin can use the RDF graph to carry the metadata, the blockchain carries the content. The adaptation of ACME for Slimcoin uses the RDF graph to carry both the metadata and the content, the blockchain carries only an index into the graph.

ACME is just a web app that marshals and presents data obtained by talking to the coin's JSON-API and Fuseki's SPARQL endpoint. The web app component can be relatively trivially re-implemented in a Javascript framework such as Angular or Vue.js and the functionality (i.e. ACME as you see it right now) embedded in a wallet tab. ACME in the wallet, with a configurable whitelist of publishers' addresses plus whatever metadata is retrievable to convey information about the author, title, topic, tags, need, I, go, on. Publishing is ... let's riff on this ... in ACME via a javascript-implemented interface, could even offer in-wallet blogging, hitting “post” submits the content for javascript processing - the content and associated metadata are rendered as RDF, signed and pushed up to the configured ACME SPARQL UPDATE endpoint to be stored in the graph - and the ACME publication API updated. You don't even have to make the inscription, that's done automatically. All you need as a Slimcoin user is an ACME API key and off you go. At some stage archiving and migration functionality can be added but it amounts to little more than hooking up buttons to a few SPARQL queries.

I guess torrent serving could also be made (an optional) part of the package, torrenting does hook into a substantial propagation community, although RDF definitely carries the day when it comes to the extent of the metadata and so can be readily “discovered”.

Which is why ACME will be a self-deploying, as-hands-off-as-I-can-make-it package. I suppose, with a following wind, this might be reasonably mistaken for the raw material for a masternode system an overlay network administered by hoomans instead of an algorithm. It'll have it's pros and cons but it might see some use.

Cheers

Graham

I can see how Segwit and Lighting Network might be nice to have, but I view Slimcoin more as I view Bitcoin: an investment-oriented currency rather than a transaction-oriented currency.  

As such, above all, to me we need to make sure Slimcoin is solid and stable.  

Slimcoin has three pillars. If one of them could use shoring up, as @d5000 suggests, it would seem well worth doing.  

Great that most of my points are welcomed with enthusiasm.
I know that Segwit, and especially Lighting Network, will be hard to implement, and would require a hard-fork, but I think we can contact nova, and most miners are mining at v.0.5, from what I know (only some seeds, are on the old version v.0.3.2 and probably just because they don't have to change it).
If we have approval of nova (and mostly we will get it), rest will switch over, because they know, we can't have 2 networks (and second blockchain won't get to any exchange) - it's much easier, with our small, microscopic network, than with such big networks like ETH or BTC, and even then, they must hard fork chain or continue old chain, which was abducted.

About Android Wallet - can't we make it to listen tx's and view POB blocks as a POW blocks, outside of course on different server (because ? Is it completly different? I'm not a developer or even programmer, but I thought, about sth like that.
Also we could use something different than BitcoinJ implementation - I have stumbled across quite a few bitcoin wallets github android sources.

Great idea.

This is ... (sucks finger, holds it in the air) ... about 75% complete. I'm currently concluding my “is metadata really an answer?” investigation after gaining some rough understanding of what's been apparently holding Datacoin back because a few years ago, all the elements seemed to be in place ... https://bitcointalk.org/index.php?topic=405992.0;all (only 4pp in all but it does comprehensively cover the issues). What I'm currently pondering is: limit display of (potentially raw sewage) to IsMine() addys (no work entailed) or a configurable whitelist (GUI work entailed).

This is where my “different perspective on cryptocurrency” pays off by giving me more accurate projections. To achieve the proposed goal, the code implementing the tripartite minting will have to be rewritten in the new codebase and it would entail a hard fork, earlier clients will not be able to connect to the new blockchain. I predict that this will result in two networks, the original (dare I write “classic”?) and the new. (Go peer over the fence, In the case of both Ethereum and Bitcoin and a few other minor alts the new blockchain evolved as a separate entity co-existing with the original chain. So “evolutionary growth”, as expected from a Teal organisation and not “civil war” as expected from a hierarchy.) Note how many current Slimcoin users are quite comfortable with the old 0.3 version of the code and note that no-one can force them to upgrade, nor can sanctions be applied.

Another major rewrite, I'm afraid, in order to extend the client to handle PoB.

Sure, but again, not the (sadly, hopelessly wrong) direction in which everyone else appears to be headed. I already know that road leads to a sticky end.

(I find myself slightly shocked at some of the more egregious NIH failures exhibited by “the kids of today” - f'rinstance, all this business about ML algos picking up unwanted human biases was well-known in the mid-80s. ML-driven credit-scoring implementations in the US had already run afoul of what the USians call “red-lining”, a corporate optimisation and exploitation of the deleterious effects of social deprivation that was so pernicious that they had to pass laws to prohibit it. All the ML systems had “learned” was how to exploit vulnerable people, which they've done all over again because the current population of ML “hotshots” are, unfortunately, no such thing, as they have just demonstrated in spades that they themselves are too SQD* to be able to learn from others' previous mistakes and so they advertise openly that they are inherently incapable of designing ML systems, hence the general conclusion, “Oh, GIGO”). * I'm struggling to find a non value-laden term and “Systematising Quotient Dominant” is the best I can manage, although “Autistic-spectrum dominant” is more accurately descriptive.

I see similar inadequate shallow models at play in the domain that is over-broadly painted as “smart contracts” and I can see the same mistakes being made again - because SQD's have a weakness for focusing on the internal consistency of their models and failing to cross-reference the resulting simplified model with the complex models of inconsistent reality. The lawyer's slides in that slideset I posted a week or so ago contain a lot of cautionary material which did not pass me by.

I've already had a very encouraging chat with Steve (close friend and Labs oppo for pretty much the entire decade that we were both there) as to whether he agreed with my tentative assessment that Ginger would be an appropriate approach...
Basically, the Bitcoin scripting language (described by gmaxwell as “adequately expressive for ‘smart contracts’” and that's one dude whose technical assessment I'm happy to take at face value) is too low-level for general use and so I would use Ginger to create a set of higher-level abstractions that were more attuned to end-user needs and more tractable to work with. Steve agrees that a Turing-complete language is not what you'd want for this task and has basically “given the nod” to my idea of using Ginger and has even offered some assistance. It's down to me to identify, characterise and implement the higher-level abstractions. The approach would still reap the benefits of the computational predictability of the Bitcoin scripting language (just don’t ask Steve for his opinion of it, he's not as charitable as I am) but would be able offer more domain-focused and programmer-friendly abstractions with all the advantages that Ginger brings. (And yes, you did read that correctly, you can write in whatever syntax suits: Javascript, Lisp, Scheme, Pascal, Python, it all compiles down to an elegant back-end XML syntax.)

Where am I going for the higher-level abstractions? Well my first port of call is the 2004 W3C Choreography Description Language effort (sunk by MS pulling out I 'spect). If nothing else, it should give me a useful notational starting point, saves me having to start at Level 0.


Unexplored territory for me, can't really comment.


I'll limit this post to specific observations on the mooted “road map”.

Cheers

Graham

I think a merger of slimcoin.club and slimco.in is not needed. Slimcoin.club is a private site, and that's totally ok, while slimco.in is the "project web presence", directly connected with the Github project presence.

Regarding PoS, I agree basically with muf18 to lower the reward. That would require a hard fork, but if we plan it carefully (maybe for mid-2018) then perhaps we could optimize the whole PoS system to fix some of its flaws. 

In the last weeks, after the event when several PoS blocks were published in a row when a big staker connected his wallet, I thought about some aspects of PoS. A solution to avoid this kind of events could be to give PoS blocks less "chain trust", but maybe it's better to reduce chain trust more than now if more than e.g. 5 PoS blocks appear in a row. The reason for that proposal is that Peercoin's PoS is the weakest of Slimcoin's algorithms. I would also change to a simpler PoS mechanism like Blackcoin's (the one used by Particl).

Regarding the roadmap: I've looked into Navcoin again and perhaps it isn't the best option to port a 0.13+ Slimcoin version from because they've added some "privacy" features which require a second "layer" (from their whitepaper: "a secondary blockchain known as the Subchain"). This looks like a pretty non-standard and unproven solution Slim shouldn't copy.  Particl also seems to have a "privacy layer". It's perhaps possible to only port the Proof of Stake part and use standard Bitcoin code for the rest. I'm however still hoping for Peercoin to accelerate development - their Github is active but they will first switch to 0.8/0.9 code and then to 0.13+.

Sound good!!!

I propose loose roadmap for now, as a 'goals' we should go into, and make happen:

1/ Web2Web and ACME integration - M1
2/ Test network for segwit/porting from nav coin/particl - M2
3/ Android Wallet - M3
4/ Smart contracts integration - test network - M4
5/ LN test network - M5

And then integrate one-by-one. I don't know, about privacy for now, but I think SLM wasn't so meant for it to be, so for now we can pass on these (and integration zcash protocol or others mixing services will be much harder I guess).
If all these would be done till the end of 2018, it would be a huge step for us, and SLM.
Each of these can be thought as a milestone, which brings us closer to what we can call final shape of Slim (?)

Also I think we should change fee system, within Slim ecosystem - I talked about with @d5000 and we agree that it should be changed to bitcoin's "fee should be miners reward", because for now we have inherited Peercoin's "burning fee, as a hedge for inflation"
and I thought about changing minimal fee to 0.001 like in LTC (currently minimal is 0.01), and an easy setting for changing fee with client - because for now we can only set it with some commends I think.

POS consensus is something to think about also. At least % - 10% is a little too much inflationary imo. 2-3% is more suitable I think.
What do you think about such changes ? Would you approve it community?

BTW. - new market opened:
https://novaexchange.com/market/ETH_SLM/

Edit: I almost forgot - merging slimcoin.club and slimco.in into one site, with both domain redirecting to one server, should be also our next goal.
I wrote to @a123 if we can use website code, or how we could merge both websites, but he is semi-active on the forum, so I'm still waiting for response.