Slimcoin | First Proof of Burn currency | Decentralized Web

[gjhiggins]

Hello  , srry for bothering all the time , but im very interested in mining this   coin , my problem is that when  i  put the chain block data into the  dir it saays the error : "blockchain download required".
It means that i need to download the chain block with the slimcoind program?... how ?

Sorry you're having trouble with the “snapshot” archive. It's not a “proper” linear bootstrap file, just a token “this might work for you” gesture.

The usual approach is to clear -datadir of everything other than wallet.dat, unzip the archive and try with that. If it doesn't work, then just delete the files extracted from the archive, start again with just wallet.dat and let the client synch from the network.

Cheers

Graham

[gjhiggins]

If anyone's interested in running their own instance of the Fuseki SPARQL server, I have published a github repository containing a vagrant+ansible deployment script that does the entire job:

https://github.com/gjhiggins/va-fuseki


Cheers

Graham

[cryptovore]

Thanks for that, appreciated!

BTW, the mac binary seems to get stuck at "Loading addresses...". May be because it's intended to use on a testnet and my wallet is on the mainnet?

Cheers!

[cryptovore]

Asking this in a separate thread:

If I have a wallet on a machine, I mined a bit, and I also burned a bit, but then I import the private key of that wallet in another wallet and shut down the machine, the PoB started on the first machine will still work?

I mean, the expected coins will come to the new wallet or never?

Is there a link between a specific wallet and the PoB algorithm or it's linked only to the address that burns coins? The wallet must be up all the time in order to receive the coins?

Thanks in advance.

[gjhiggins]

Thanks for that, appreciated!

BTW, the mac binary seems to get stuck at "Loading addresses...". May be because it's intended to use on a testnet and my wallet is on the mainnet?

Thanks for the problem report, I'll re-check the OS X client's functioning on my Sierra VM. The 0.5.0 client should sync up on either mainnet or testnet (depending on command-line option or config) defaulting to mainnet as per standard.

Begging testers to confine their experimentation to the testnet is only really a vague courtesy to the public ledger, a client shouldn't be able to “break” the blockchain, that would demonstrate a vulnerability in the protocol.

Technically speaking, the “release” process in this context is primarily a bit of software engineering theatre because it offers no surety of functionality. In fact, if I could successfully bring the blockchain to a halt with a specially-crafted client working outside the majority consensus, that would actually be a win from a white hat perspective.

The 0.5 binaries are actual release candidates and have full functionality.

ATM I'm in the process of finishing off the conversion from torrentpage to inscriptionpage so that users at least have a scrollable list of their previous inscriptions.

I have read up about Github releases, the process seems simple enough. I now just need to read through any FAIL reports to see what I'm missing

Cheers

Graham

[keliokan]

Hello,

I am using actually the last version (0.5 windows)
But it does crash all the time,
I would like to know if someone has the same problem or if it is just me.

Thanks

(edit : i was also trying to find the 0.4.1 but i just found the 0.4.0 if someone could post a link, thanks)

[aIA]

Hi!! I'm new here and triying seting up the wallet app for Windows with no luck.

I have tried all the list of nodes that i have found in all last 27 pages. Some times it connect but wasn't sync all the blockchain, only 10 or 15%.
I have downloaded a partial blockchain posted here, the wallet read it and it appear correct, but can't connect.
Could anybody post a list of live nodes?

Thankyou so much, and sorry my bad English, i'm Spanish.

[gjhiggins]

Could anybody post a list of live nodes?

Sure.

addnode=37.187.100.75:41682
addnode=212.243.7.37:57208
addnode=161.53.40.94:54692
addnode=217.175.119.125:35959
addnode=217.65.8.75:34987
addnode=217.65.8.75:27670
addnode=5.9.39.9:41682
addnode=212.74.203.97:21773
addnode=91.20.13.10:56064
addnode=92.193.110.121:48782
addnode=92.193.110.121:40066
addnode=92.193.110.121:51681
addnode=5.105.63.44:64536
addnode=94.25.179.179:53001
addnode=39.128.196.200:2410


You may wish to try a release binary: https://github.com/slimcoin-project/Slimcoin/releases

Or, if you can use (install) Vagrant and Ansible, you can use the vagrant+ansible deployment script on an Ubuntu 16.04 VM to cross-compile your own “untouched by human hands” Windows binary:

https://github.com/slimcoin-project/ansible-slimcoin-qt-win

Cheers

Graham

[gjhiggins]

I am using actually the last version (0.5 windows)
But it does crash all the time,

Details? I've noticed that the Windows 0.5 binary also crashes on the wine emulator in my Ubuntu 17.04-pre distro but that might be unrelated. I'm definitely not in a position to comment w.r.t. different Windows versions.

I would like to know if someone has the same problem or if it is just me.

Impossible to assess, atm: absence of evidence is not evidence of absence.

Cheers

Graham

[aIA]

Could anybody post a list of live nodes?

Sure.

addnode=37.187.100.75:41682
addnode=212.243.7.37:57208
addnode=161.53.40.94:54692
addnode=217.175.119.125:35959
addnode=217.65.8.75:34987
...

Thanx a lot!!!!

Now its syncing with 0.4.0...

I have tried 0.5.0 but crashes two times... one at launch and another waiting for connection...

How can I get info from the crahs and send you? I'm on windows10.

[PeterTheGrape]

...

Is the original dev still involved?

From the Ann

Slimcoin is a P2P project - we have no "official dev", nor it is managed by any centralized entity or organization. There was no premine at the start. You can contribute with coding, testing, providing goods & services or simply using it. Be welcome!

[keliokan]

I am using actually the last version (0.5 windows)
But it does crash all the time,

Details? I've noticed that the Windows 0.5 binary also crashes on the wine emulator in my Ubuntu 17.04-pre distro but that might be unrelated. I'm definitely not in a position to comment w.r.t. different Windows versions.

I would like to know if someone has the same problem or if it is just me.

Impossible to assess, atm: absence of evidence is not evidence of absence.

Cheers

Graham

Hello,

Sorry fo the lack of details,
I am using windows 10
The crash happens basically 90% of the time.
When the logo disappears and the wallet must appear.
Sometime if lucky the wallet appears and windows says that the programme crashed.

sending getdata: block 0000000f16945426ea1f
sending getdata: block 0000002c386e6500a390
received block 0000007e03c1344b3ea8
CBlock(hash=0000007e03c1344b3ea8, ver=1, hashPrevBlock=358609ef751ba08c352c, hashMerkleRoot=297295c8ad, nTime=1493492463, nBits=1e00b2f4, nNonce=38231873, vtx=1, vchBlockSig=3045022100b6aa6de4ba8ae1c103bf67fb77c209b2af68c47e7aeeb7204eca972299b54018022039f66eaf8e9f63c3f03a90e54e2fb2dd2743c7d2ad2c855ef2f0c676cd4d799a)
CBlock General PoB(nBurnBits=1c68e258 nEffectiveBurnCoins=2084638376 (formatted


this is the debug last lines,

hope it,s enough

thanks

[gjhiggins]

this is the debug last lines,

hope it,s enough

Thanks ... me too

I have a trial Windows VM and a 4 year-old step-by-step guide. I'll let y'all know how I get on.

Cheers

Graham

[keliokan]

this is the debug last lines,

hope it,s enough

Thanks ... me too

I have a trial Windows VM and a 4 year-old step-by-step guide. I'll let y'all know how I get on.

Cheers

Graham

If it can help,
When launched from fresh (nothing in the Slimcoin directory)
It does crash at block 500 (during the sync)


SetBestChain: new best=0000002a085c6068b74c  height=500  trust=501  moneysupply=9965.00 nEffectiveBurnCoins=0.00
ProcessBlock: ACCEPTED
askfor block 000001e1d2134a607c66   0
sending getdata: block 000001e1d2134a607c66
Refreshing inscription tableaskfor block 000000212357de32d88d   0
sending getdata: block 000000212357de32d88d
received block 000001e1d2134a607c66
CBlock(hash=000001e1d2134a607c66, ver=1, hashPrevBlock=37de29ee1fda38e5cbfe, hashMerkleRoot=6a391aaa5e, nTime=1493751184, nBits=1e01f64d, nNonce=12119510, vtx=1, vchBlockSig=3046022100b089adc8acf6307904fba78c50dd4bdf49e8bed03391d589e8807293f33a4b2f0221009dd59279407c3f3f76bdaea6e030ac35371ca581d738188c01395a1dd5353762)
CBlock General PoB(nBurnBits=1d008af0 nEffectiveBurnCoins=2756378618 (formatted

[gjhiggins]

I have a trial Windows VM and a 4 year-old step-by-step guide.

Yuck, that's a very tangled mess. I'll have to leave that approach for another time.

Instead, I tracked through the commit history (tedious but effective) until I found the offending commit. I had omitted to follow-up on a crucial detail on removing the C99 “PRI64*” macros.

Issue has been resolved with the latest commit: https://github.com/slimcoin-project/Slimcoin/commit/43621ddb701b01e2df36e87113e034a10accaafc

and I have updated the Windows binary slimcoin-qt-v0.5.0-win32.zip listed on the 0.5 release download page

After I've posted this, I'll fire up the Sierra VM, update the OS X app, similarly update the release binary and advertise it here.

I've also discovered the issue with the snapshot - haven't checked the bootstrap yet - it needs be of a datadir for a client that was compiled to use BDB 4.8 - I'll configure my headless client on the server to use BDB 4.8, create a fresh snapshot on the server and also advertise it here.

Cheers

Graham

[gjhiggins]

After I've posted this, I'll fire up the Sierra VM, update the OS X app, similarly update the release binary and advertise it here.

The OS X GUI client in the 0.5 release section has now been updated.

Cheers

Graham

[Slimcoin Community]

I have updated the OP page and linked the 0.5 release page.

I have a slight doubt: Is 0.5 now enabled for mainnet or still testnet-only?

Next week I plan to begin with a "non-development" roadmap for Slimcoin. So when Slimcoin 0.5 gets ready for the masses we can attract more users. I plan to write a little github.io page with Jekyll, some more wiki pages, and announcement threads in German and Spanish, for now - in a timeframe of 1-2 months from now.

I'm open to other suggestions

[gjhiggins]

I have a slight doubt: Is 0.5 now enabled for mainnet or still testnet-only?

It has returned to normal behaviour, i.e. defaulting to main but configurable (via both command-line option and config file) to use test.

I mused on it for a bit, trying to get a better understanding of the purpose of testnet.

Bitcoin Core now has three networks, main, test and regtest.

The way testnet coins are now generated points to a difference - for Bitcoin Core, testnet coins are generated via RPC console command generate <n> <N> where <n> is the number of blocks and <N> is the number of guesses (too few = no blocks). Regtest network behaves the same as  main. I infer that test is for testing changes to the basic protocol and regtest is for running protocol usage experiments. Or vice versa.

In principle, the public ledger must be safe from J. Random User's dedicated-but-individual attempts hack their copy of the client to suborn the network to their personal advantage. I am no different from J. Random User except that my intentions are allegedly beneficial (says me) so by the same token, the network should be safe from any of my individual efforts whether deliberately or inadvertently mounted. Of course, if I can persuade > 50% of users to join my camp, then whatever I've done to the protocol/functioning will become the new norm. Testnet gives me some protection from any inadvertent ganging up on the currently-accepted consensus but then again, I hadn't introduced any significant changes to the functioning of the engine, merely adjusted the timing belt, to use a motoring analogy.

But I'm always acutely aware that the numbers represent far more than just public ledger accounting - humans are involved.

Cheers

Graham

[Slimcoin Community]

Thanks gjhiggins!

I was a bit confused because you one page ago recommended to use the testnet to test the 0.5 code. But I assume with your latest changes you consider it ready for mainnet. The only real consensus change with respect to 0.4 should be the addition of the OP_RETURN opcode, am I right?

I am actually trying to compile the SLM-0.5.0 branch - I think this code should be similar to that used by the Windows/Mac binaries. But I get an error here (using the qmake/make method):

Code:

In file included from src/qt/inscriptiondialog.cpp:2:0:
build/ui_inscriptiondialog.h: En la función miembro ‘void Ui_InscriptionDialog::setupUi(QDialog*)’:
build/ui_inscriptiondialog.h:78:22: error: ‘class QLineEdit’ no tiene un miembro llamado ‘setClearButtonEnabled’
         lineEditMsg->setClearButtonEnabled(false);
                      ^
Makefile:1917: recipe for target 'build/inscriptiondialog.o' failed
make: *** [build/inscriptiondialog.o] Error 1

(Sorry for the "Spanglish", but it should be understandable - "función miembro" should be "member function" and "no tiene un miembro llamado XX" is "hasn't a member called XX")

Edit: Compiling the daemon (slimcoind) with the 0.5 branch works and it connects to the testnet without problems.

I cannot for now offer a stable testnet node but will connect occasionally and do tests. I'm open to suggestions what can be tested - my long-term idea is to port PeerAssets (when it's ready) to Slimcoin, so we could have a crowdfunding platform It uses OP_RETURN and would need almost no porting effort.

My testnet address is myCzqTssZ2MorXi8g3iheNeQhYabg1vhSt (I actually generated some testnet coins, so for the moment I don't need any).


(PS: Using the Slimcoin Community account because I would like to get out of the "newbie" category to improve the OP a bit with images, colours etc - I think you know my identity.)

[gjhiggins]

I was a bit confused because you one page ago recommended to use the testnet to test the 0.5 code. But I assume with your latest changes you consider it ready for mainnet.

The code compiles, the tests pass, the app syncs and handles the protocol. Those are the only verifiable criteria in this specification-by-implementation context.

The only real consensus change with respect to 0.4 should be the addition of the OP_RETURN opcode, am I right?

Mostly. I have been reporting informally as I made progress. I will create a Changelist file, (based on the commit record).

I get an error here (using the qmake/make method):

Code:

In file included from src/qt/inscriptiondialog.cpp:2:0:
build/ui_inscriptiondialog.h: En la función miembro ‘void Ui_InscriptionDialog::setupUi(QDialog*)’:
build/ui_inscriptiondialog.h:78:22: error: ‘class QLineEdit’ no tiene un miembro llamado ‘setClearButtonEnabled’
         lineEditMsg->setClearButtonEnabled(false);
                      ^
Makefile:1917: recipe for target 'build/inscriptiondialog.o' failed
make: *** [build/inscriptiondialog.o] Error 1

The error indicates that you are using a version of Qt earlier than Qt 5.2 (http://qt.apidoc.info/5.2.0/qtwidgets/qlineedit.html#clearButtonEnabled-prop).

I doubt that C++ #ifs will work in XML so you cannot use #if QT_VERSION >= 0x050200 to isolate the code, so you need to delete lines 130-132 of src/qt/forms/inscriptiondialog.ui.

(Sorry for the "Spanglish", but it should be understandable - "función miembro" should be "member function" and "no tiene un miembro llamado XX" is "hasn't a member called XX")

No hay problema, yo hablo poquito castellano.

my long-term idea is to port PeerAssets (when it's ready) to Slimcoin, so we could have a crowdfunding platform It uses OP_RETURN and would need almost no porting effort.

That's one approach, I have to say I'm underwhelmed by the chosen analogy.

I'm intending to pick up on a nice little paper written by fellow Labbie, Jeremy Carroll (yeah, go on, accuse me of cronyism):

Assuming P<GI<NP, the creation and verification of a digital signature of an arbitrary RDF graph cannot be done in polynomial time. However, it is possible to define a large class of canonicalizable RDF graphs, such that digital signatures for graphs in this class can be created and verified in O (n log (n)). Without changing its meaning, an arbitrary RDF graph can be nondeterministically pre-canonicalized into a graph of this class, before signing. The techniques in this paper are key enablers for the use of digital signature technology in the Semantic Web.

This technique should work comfortably with RDF graphs which formally describe the state change and whose canonical digital signature can be inscribed in an OP_RETURN and for which existing inference engines such as FAST++ can do the heavy lifting.

- I think you know my identity.)

Sorry, I don't.

Cheers

Graham