Quote from: muf18 on December 29, 2017, 12:38:49 PM

I will need to have detailed description of our project, what's aiming for, and what's our plans for future.
I know some of it, but we need all information we have. Can you help me?
Also interview with 'team' (as we can describe ourselves as team - cause we are developing it).

I must second gjhiggins here. In my opinion, the Slimcoin community has - on a much smaller scale - much in common with Bitcoin - it's decentralized, not company-owned. Would you speak, if talking about Bitcoin, about a "vision" or "goal"? Like Bitcoin, Slimcoin is also a general-purpose currency, not a project that concentrates on a specific task (like, for example, projects like Sia, Namecoin or even Ethereum). So it's goal must be to be used, as currency or as "valuable".

Slimcoin's "unique feature" is still Proof of Burn. The rest - e.g. the decentralized web - are projects that are possible with Slimcoin and are powered by some members of the community. These projects will make Slimcoin more useful, but I wouldn't describe it a "the one and only vision" for it.

@blockhash7: I mostly agree, also about the "slim" part. But I think we should not switch to the mini-blockchain scheme. The reason is that this scheme doesn't allow contracts with the Script language and "forgets" old blockchain entries - so it couldn't be used anymore for the "decentralized web". Cryptonite is awesome as a cash replacement, but for other purposes its scope is more limited.

Quote from: gjhiggins on December 29, 2017, 11:32:21 AM

The linkage is crude, needs to be refined to use an async messaging facility instead of just bash shell. (I'm even toying with the notion of running the three processes each on a separate machine, make each process resource-independent of t'other if the context turns out to require it.)
[...]
It sounds as if the blocknotify script isn't functioning properly. If you're running a standard Python dev setup (i.e. using a virtual environment), then you can run the shell and Python scripts in ${ACME}/scripts and the test scripts in ${ACME}/acme/tests (which have debug and test boolean flags for this purpose).

Oh, sorry, I should have clarified - I still haven't enabled real-time update because I need still to figure out the best configuration (when should "catchup" be triggered, and when the standard blocknotify is enough; having also reorgs in mind like we discussed on the previous page).

I have changed the blocknotify scripts a bit - like every n00b would do, I've taken away the unittest dependency so I could pass command line arguments and use one single script for multiple purposes Wink

But it's still a crude solution, maybe more crude than before because it's less error-resistant, but it basically does what I want. Basically, the catchup script I changed allows loops now, to be able to catchup faster if the RDF blockchain falls behind. (An idea: This changed script could be renamed to something like "blocknotify-cli" or "catchup-cli", so it's more clear that it's made to work with human interaction and not to be triggered "autonomously" like your original scripts.)

I'm very interested in the notion of signed graphs, but had still no time to study the concept in depth - but your post with the easy examples from a couple of days ago has not been ignored Wink

.

Thanks for your work, ACME is already awesome, and yes, there is no hurry, let it mature

(Edited the message to clarify some things.)