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

I posted the original output from the dry run of the coinpunk patch:

https://gist.github.com/gjhiggins/4d97eeb24d0eca5de77a92d3996e91e3

for which the below is the corresponding commit:

https://github.com/slimcoin-project/Slimcoin/commit/a8a9e698a320a04cc5cf0e98ce61bc8e3a87d99d

Note the complete absence of any changes in the src/qt folder. This testifies that the GUI is oblivious to the changes made elsewhere and cannot distinguish between an address for which it has a pubkey but not a privkey (the definition of “watch address”) and a normal address for which it has both a pub and a priv key. Transactions for watch addresses seamlessly intermingle with the user's transactions and there's no visual distinction between them in the GUI.

The “watch address” patch code was intended for use with the JSON-RPC API and a headless daemon. This seems consonant with the main use case, AIUI. “Watch address” tx really should not appear in the GUI, or if they do, they should be differentiated and separately presented.

I'll have another go at watching something other than the burn address because it seemed to me that tx associated with the “watched” addresses were included in at least part of the stake calculations, at least judging by the report of a total of 5000-odd tx, 100% thread use and eventually thrashing so hard that the GUI stopped responding and the process had to be terminated from the command line. I know of only one circumstance in which this happens - stake calculations. I need to go through the code and instrument the staking process so that it reports the addresses of the tx for which it is calculating stake weight.

Some work required, still.

Cheers

Graham

Thanks, reading up now.

Ubuntu managed to effectively brick my new XPS by nuking the kbp/tpad driver so that the cursor produced an endless stream of clicks and declining thereafter to complete the boot sequence. I had to reformat the HD and install Mint, in the process losing some recent preparatory work (nothing significant), so your tip will be doubly useful. Thanks.

Cheers

Graham

Quote from: aIA on September 10, 2017, 02:02:49 PM
Hi guys, I think that the spirit of Slimcoin must be this, be slim...

I also agree with this statement.  

OK, no problem - although I am sure that my scripts are (much) less elegant than yours . I'll play around a bit myself (I have already saved the blockchain in the form of JSON files to understand its structure better, maybe it can be quickly converted into OWL/RDF with the CCY ontology) and otherwise I'll wait for your solution to be finished. I could even add "has_inscription_tx" for myself, as a workaround.


Go to "Help -> Debug window" and select "Console".
Type in
(the 9999999 is arbitrary, it can be any high number, it's the number of seconds to unlock. You later can lock it again restarting the client.)

See also: http://slimco.in/proof-of-stake-guide/ and http://slimco.in/proof-of-burn-guide/

How do I unlock the wallet for minting

May I recommend using screen or tmux for your ssh sessions to avoid ugly and often enough painful program/script terminations when your connection breaks (by whatever reasons).

HTH

I did reply but I must not have actually clicked on “submit”, this is from my drafts ...

---

Uh-huh, another spinning-on-a-stick plate of mine that's starting to wobble a bit and needs an energy boost.

A couple of weeks ago, I reorganised the application file structure on the server to pave the way for the next stage, that of creating an all-in deployment script. Unfortunately, I omitted to update the slimcoin config file with the new location of the blocknotify script and so the graph stopped being updated. Even more unfortunately, I didn't notice until just the other day that the graph is a couple of weeks behind. So far, I've tried to run the blocknotify-catchup script four times without success, I keep losing the ssh connection (/me waves at GCHQ) so I'll have to try a different tack. The catchup script is identical to blocknotify except that it's wrapped in an iterator that runs from last-sparql-reported blockheight to jsonrpc-api-reported latestblockheight, slowly, so as not to unduly stress either the node or fuseki.

This sort of hints that, as I suspected it might be, blocknotify is a little brittle for serious use. OTOH, it was working just fine before I screwed it up and it continues to work fine with datacoin (whose config I did manage to remember to update, apparently). But yes, I am now sufficiently resigned to the embarrassment of publishing the code - I've only spent a few scattered hours on it, with the basic objective of getting it to a working state in order to get a sense of whether the approach has any merit. So, elegant and well thought-out  it is not.

The same “suck it and see” approach is true of the CCY ontology, it seems to be doing the job. From a practical perspective, the usual space/time tradeoffs present themselves - inferences can be cached to save time, at the expense of space or re-inferred to save space, at the expense of time. It would be useful to denote which blocks contain inscription tx, it would narrow down the search/listing space. At the moment, the ontology does not include the boolean predicate has_inscription_tx but this does not preclude the appearance of such statements in the graph - or an associated graph if separation is deemed desirable. The ontology can be updated to suit.

The current namespace is merely custodial. It is mediated by purl.org, a popular solution for public service URL relocators - you publish a stable, unchanging purl.org address and 301 redirect to wherever the resource is actually located. Purl.org offers group ownership of the administration of the relocation destinations mapped to the public service URLs, so ownership can be brought into the community.

The ontology itself is an open source repos on github: https://github.com/DOACC/ccy and I don't think I have a clue what “stable” means - the term is inherited from the W3C approach and it possibly refers to some W3C process and is irrelevant in this context. 

I'll pull together the (happily, already-existing) components into a single script, in which the blocknotify script and its Python virtualenv context will all be painstakingly laid out in full detail (else it won't work).

---

I'm still wrestling with the script ... progress not helped by the fact I managed to brick the XPS last night. Took all day to get it booted again

Cheers

Graham

Thanks for that feature! But in theory you could use the "totalburnt" client for everything and discard the "standard" client, or not?

I'm asking that because it would be a good idea, I think, to create a release candidate for "version 0.5.1" with the newer features you ported to Slim in the last weeks/months (BIP 65, "totalburnt" and - if I remember right - watch addresses). Maybe there's still testing needed, but this way we could pass a new "mini-milestone" and compile binaries etc.

(BTW: Have you seen this post? I was asking if you could provide me your blocknotify script to translate the blockchain to RDF as I have begun to set up a Fuseki node that is planned to hold the Slimcoin blockchain as an alternative to your installation. If it's still not "shareable", no problem ...)


Fully agree ...


Yep, a (pegged?) sidechain for data would be totally OK. I like the "Drivechain" mechanism a lot, it was proposed for Bitcoin about two years ago. However, it would need a new opcode, and also it would probably need more mining power than we have now.

Another idea would be to use Datacoin as a "not-pegged" data sidechain for Slimcoin and use a BIP-65 enabled atomic cross chain protocol to communicate between both blockchains and trade "datacoin tokens" to Slimcoins. I mean to remember, however, that this would need also a malleability fix (like Segwit of Flextrans).

Please, could you point me message number? I have been locking for without luck.

@aIA - I think it was done (Rasperry Pi version of Slimcoin client), by @cryptovore - some posts ago.
I thought about also, making a full node version of Slimcoin, cause it's mainly written in C++ and python, with the usage of QT libs, which are compatible with Android.

I'm still a noob, when it comes to coding, but I'll try to improve my skills (from 0 to some coding isn't so hard, then it goes uphill)...
Tho I think full node version for Android, shouldn't be so complicated, apart from rewritting interface, which can be a little trouble.

Hi guys, I think that the spirit of Slimcoin must be this, be slim...

As proposed muf18, adding a feature to preseved very important files could be an attractive feature for some people and may grow our community. May be if it could be achieved in a parallel block chain and that were optional to support and there were rewards to user for use their nodes (as storj style). Don't know sure how to incorporate that. But more important part is do that in the way that don't change Slimcoin spirit.

I have been attracted to Slim thinking that I could mining with low power device. But not really... For the moment.
I think that differential feature of Slimcoin is PoB and if we're possible that works perfectly on low power hardware like Raspberry Pi and other ARM device this could attract lot of people that haven't high power pc or greats mining rigs as me. And achieve it in a low power consumption device it could be economically viable to motivate lots of users to get running full nodes (ok, is not useable for PoW and PoS, but at least for PoB)

As you can read some pages back I have been trying to do Slimcoin daemon compiling and working in Raspberry pi... I only achieved to run 0.5 (compiled with BerkleyDB 4.8 in order to pass blockchain files from windows wallet because daemon doesn't sync from scratch, always stuck) with encrypted wallet because it crash always when try to do PoB. At least work as a full node because syncing new blocks does work.

I would like offer a bounty of 10.000 SLM for a full functionally ARM updated version of daemon. If any one can support this bounty it could be interesting for a dev.

Please, excuse my poor English grammar.

Cheers.

@d5000 won't join slack, and @gjhiggins, I think will talk only on basis for integration development on slack (we can't have such things, through forum, it's too hard to communicate this way - it's the purpose of developemnt channel, strictly for development things), and I think he will be even more active here, than there.

We have Greg now on board too, I hope they (@gjhiggins, @cryptovore, and @gkucmierz) will cooperate for the future development of Slimcoin.
It's better than having 2-3 seperate people working on something, they don't know each other progress, and don't know if it's compatible etc.

And of course anyone can be added if want to slack - and can be also added as a contributor-dev, programmer, like any open-source project.

you will, but what about others? devs don't usually have a lot of time to chat, if gjhiggins and d5000 leave BCT it won't be good

As I said, we should maintain discussion here, and I'll regulary post here, but slack is for faster communication between people interested more in the project, and also, for developing (it's faster and on-time, so you can communicate easier). We don't leave BCT - I'll just write on both.

I see huge lack of PR in Particl because of dead Bitcointalk thread. Everybody moved to Slack and most BTT users have no idea what PART is.

Thanks for it. Graham would you consider being added to slack, to have faster communication, and with development channel also? We could talk here, and there, because it would make it faster I guess, @cryptovore is added, and we have now one more contributor-dev, co-founder of https://www.experty.io/en - Greg Kućmierz.
He said that he will help us, if he can.
I think that's positive news.

Another good news.
Nova updated wallet.
Proof:



Mining performance on Windows 7 is about 7-10% faster than on Windows 10 (both X64), tested with FX-8320 4Ghz and 4.4Ghz (both has almost the same speed).

Whilst fumbling around in another atcoin's innards, I found myself looking at the solution to adding an accumulating total of burned coins to the results of a getinfo call, a copynpasta adaptation of the existing code that implements the associated “moneysupply” value:

https://github.com/slimcoin-project/Slimcoin/commit/ad8077c040d5dd0483efd21e11e92ea4a3e99168

It is a soft fork because blkindex.dat must be rebuilt from scratch and so users are obliged to sync-from-genesis via the network.

My preferred solution is to have a synced-up node (compiled from master) running off've standard port 41682 and when I run the node compiled from the “totalburnt”, I call it thusly:

$ ./slimcoind -datadir=/home/gjh/.slimcoin/reindex -conf=/home/gjh/.slimcoin/reindex/slimcoin.conf -connect=127.0.0.1:41682

i.e. I've told it to use /home/gjh/.slimcoin/reindex as its datadir and similarly with -conf.

(I actually have the connect declaration in the conf file, its use in the command-line example is strictly speaking superfluous, albeit illustrative.)

$ ./slimcoind -datadir=/home/gjh/.slimcoin/reindex -conf=/home/gjh/.slimcoin/reindex/slimcoin.conf getinfo
{
    "version" : "SLMv0.5.0-24-gad8077c0-alpha",
    "protocolversion" : 60003,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 804,
    "moneysupply" : 18331.01000000,
    "totalburnt" : 2977.49000000,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : 0.02217633,
    "testnet" : false,
    "keypoololdest" : 1504919979,
    "keypoolsize" : 101,
    "paytxfee" : 0.01000000,
    "errors" : ""
}



$ ./slimcoind -datadir=/home/gjh/.slimcoin/reindex -conf=/home/gjh/.slimcoin/reindex/slimcoin.conf getinfo
{
    "version" : "SLMv0.5.0-24-gad8077c0-alpha",
    "protocolversion" : 60003,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 157787,
    "moneysupply" : 1702548.61565800,
    "totalburnt" : 587129.62050900,
    "connections" : 1,
    "proxy" : "",
    "ip" : "0.0.0.0",
    "difficulty" : 0.12167454,
    "testnet" : false,
    "keypoololdest" : 1504919979,
    "keypoolsize" : 101,
    "paytxfee" : 0.01000000,
    "errors" : ""
}

I think that's a fix.

Syncing continues. When the process has completed, I'll repeat the exercise on the server and add a separate “totalburnt” datadir snapshot to (optionally) alleviate the necessity of syncing from genesis via the network.

Summarising: standard datadir will NOT work with totalburnt client and totalburnt datadir will NOT work with standard client. In both cases, resyncing from 0 is required. But that's all that is required and it is a “regulation dance move” (c.f.my GTA VC analogy).

(BTW, the load-from-bootstrap functionality never worked, it always fails when it can't find an index. A functioning feature was added sometime in the procession of 0.8.X versions but has, thus far, staunchly resisted all of my attempts to backport it.)

I'll report back later on progress.

Cheers

Graham

Slack for Slimcoin - yeah, it gives more options than telegram, so I thought it would be better.

https://join.slack.com/t/slimcoinproject/shared_invite/MjM3ODU5MjU4Mzg0LTE1MDQ5MDczMDgtNGFlZjc0ZDRjNg

Ok, in my header you have poll on bct, and here I provide my own google docs:

https://docs.google.com/forms/d/1uez9e0yfGFfBwY2UXgHn4ebg1mu4swL6Both4paOsNY/

You can fill both, we will see dispropotion if there will be (I only posted this question on altcoin/cryptocurrencies and blockchain groups on fb).

It uses WebTorrent, a variant of BitTorrent that allows users to read files without having to download a software. The redundancy obviously is less high than with a blockchain, but the files cannot be manipulated (only, in the case there is no one interested in publishing it, it can be "lost").



True, but that does not mean that will be this way forever. One of the reasons SLM is not used is for example that it's complicated to use for a merchant because there are no light clients and no e-Commerce plugins. There are many points to improve.

I don't think 40 kB like in NXT is so few, because with compression you can fit a pretty big text document into it (obviously not a PDF with infographics etc., even Word documents have pretty much overhead and would not be ideal). A text file has about 2500 to 3000 characters/page (~3 kB), and as far as I know LZMA compression achieves about 15% compression ratio for plain text, so it would be about 0,45 kB/page - the 40 kB would be enough for a document of 80-90 pages. Not bad for a single transaction and enough for most white papers.

Yep, that's what I thought. But even if you get some interest, then take into account that even if I should change my mind and approve it, there are other community members that also should approve it. I am not particularly interested in the "data storage" thing, but if the majority of the community wants 500 kB space for OP_RETURN tx, then OK. But I wouldn't accept more than that, and also no block size increase.