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

I mean Windows version.

Edit: after testing - 0.6 github version is working reliably as intended, "5.0" minikiz v0.6 client isn't sending transactions apart from some really small - dunno why, it can't calculate it? Also it sometimes miscalculates amount in the wallet. All on windows 10 x64.

Which OS?

Cheers

Graham
 

Ah, so 0.6 version is compiled with BDB 6.2?

Well that's good, just I didn't know it, we can put a respective description for it, to avoid confusion.

Yes, that can happen if the clients are compiled with a version of BerkeleyDB other than 4.8.

Scenario: User has client compiled with 4.8, creates wallet that is 4.8-format. User upgrades to a client compiled with (say) 6.2 which automatically updates the wallet (on loading it) to 6.2-format. User decides to return to previous client but that can only read a 4.8 wallet, not the upgraded 6.2 one saved by the new client. This is why users are urged to make regular and frequent backups of their wallet, especially when upgrading the client. A backed-up 4.8-format wallet can be read by any client and generally, any later version can read a previous-version wallet.

Decision: slow but compatible 4.8 or fast but incompatible 6.2?

Linux users can decide for themselves but users of proprietary OSes (Win/OSX) have to depend on whether I can be arsed to provide compiled binaries for both compatible and incompatible bdb versions.   

Cheers

Graham

Initially, the query came from Novaexchange during their pause in trading after they were bought out. Apparently the 0.5 wallet failed to create appropriate change addresses and listunspent was "wrong" and so the exchange's accounting didn't add up and under new strict accounting rules, that was a delisting issue. I tried to divine the precise nature of the problem from the informal description I was given but couldn't make any headway. I suggested they try the -avatar option but apparently that didn't work either.

At that time there was no difference between the PPCoin and Slimcoin transaction-handling code apart from P4Titan's additions for handling burn txs so I was unable to provide a fix. muf18 asked around various devs for help but no-one was interested. In a fit of desperation I copied over the coincontrol backport from PPCoin but I was informed by my exchange contact that they had been able to solve the problem by using a different approach.

All went quiet until mid-April when (unbeknownst to me) one of the Novaexchange staff DM'd me on Discord to report "problems with the wallet" and a fragment from the log that showed the exchange were using a checkout of the unstable "optimized-pos" master, followed a couple of weeks later by a "?". (I've learned to be really, really resistant to the development of casual assumptions of on-demand provision of technical support for exactly this reason. The exchanges are in permanent technical debt which they casually offload on to the same communities that they profit from. Nice trick if you can pull it off.)

When I picked up the laptop again in early May, I saw the DM and responded, advising the exchange to use a checkout of the updated master.

The next message was from the exchange staffer I'd worked with originally and who'd informed me that they'd solved the issue by a different means - apparently the accounting was incorrect due to an issue with change addresses but this time his description gave me a better understanding of the origin of the problem and I was able to commit a putative fix which my contact said he'd try out. That was over a week ago. I sent a follow-up "did it work?" a couple of days ago but haven't had a response yet.

Freiexchange don't experience the same accounting issues with their back end but I'm sure they'd be happy to pick up on a version where the change addresses actually work as intended.

Cheers

Graham

You seem not to understand the role of burnt coins in Slimcoin. I recommend that you read the ANN a bit more closely before making offensively rude postings.

Cheers

Graham

It is the first cryptocurrency, which has Proof of Burn consensus mechanism. Burning coins within normal cryptocurrencies isn't making any consensus mechanism at all, it's wastage of capital.
Here it makes sense, cause it's alligned into consensus and incentive mechanism.

And besides foul language isn't appreciated so you can go back to your tasks. It isn't an enterprise, nor it isn't "somebody" coin.

Dude stfu being a survivor does not magically add up merit or value to ur coin or enterprise. U got to work hard to put it back on track, and this is what most people tend to forget when assessing the chances of certain coins to take over. Needless to say this is not the first proof of burn crypto. History knows many such coins that were artificially made rare by reducing the supply. All dead.

Trading on Nova again blocked

It is strange that Freiexchange doesnt have any issues since the beginning

It's strange, but I thought it's not a major bug.

I'll try to see what is causing it.

Edit: even more strange - after restart of the client it sent without problems...
Don't know why. Can it be caused by mining?

Btw. is it normal that wallets from 0.6 are incompatible with 0.5 client?

And as I see nobody is minting now?

Ah, well. I guess we should just not bother with 0.6 then. At least I tried.

Cheers

Graham

I have often an error message, when I want to send SLMs around that the balance is insufficient, although I have more than required...
Or error that transaction couldn't be created
With newest client v0.6 with UPnP.

The older v0.6 client without UPnP from github works well.

Although even in older 0.6 client small amounts that are still on the wallet (like 1-2 SLM) can't be sent, cause it says "insufficent balance" .

We are now displayed on the main page of chainz explorer.

I also asked, if they can have differation of PoB blocks, and that's the question to people more knowledgeable than I am, from people running chainz.


@gjhiggins - do you see now more nodes listing?

UPNP re-enabled client binaries compiled from current master:

 - Win 32bit
https:minkiz.co/noodlings/slm/slimcoinqt-5.0-win32.zip

 - OS X High Sierra
https:minkiz.co/noodlings/slm/SLIMCoin-Qt.dmg

Cheers

Graham

It's a community rather than a project so it's more useful to talk about strategy rather than specific marketing plans. d5000 has done a good job of keeping the ANN up to date.

The original basic raison d'être of a tripartite PoW-PoS-PoB minting system seems to have some practical merit as Slimcoin has turned out to be a survivor coin, having just passed its 5th anniversary. d5000 and I are separately exploring not-entirely-unrelated avenues of inquiry aimed at leveraging the Slimcoin blockchain to support content publishing.

Cheers

Graham

ok
nothing prevents me from adding listen=1, especially that my wallet online since november 2016
slimcoin's thread is very different from others
does this project have any marketing plans or it's just for leveling coding skills of a group of enthusiasts ?

Thanks for responding positively but I must confess that you have me at a slight disadvantage.

You shouldn't need to. Under the standard modus operandi, Slimcoin is assumed to be running in a local network and uses UPNP in the background to negotiate port mappings with your router. At least that's how it works on the bog-standard consumer router supplied by our ISP.

Well, at least that's how it works now that I've re-enabled UPNP in the Slimcoin code. However, that's still in master and I haven't yet updated the Win/OSX binaries mostly because I'm waiting for a response from Novaexchange as to whether the last update to the code fixed their change address problem. If I have correctly understood their description of the problem, I'm reasonably confident that it was successful.

Given this positive response to making the network more robust, I will get straight onto compiling up fresh binaries for Win/OSX and will post their availability here (in about an hour or so, I expect). Until then, you may care to experiment with making an explicit port mapping.

Cheers

Graham

More than enough (see below). Just add listen=1 to your slimcoin.conf file.

Strictly speaking, a static IP address isn't required, it's just more effective ...

When you run the client as a listening node and open the debug window, you'll see that "Number of connections" is more than 3. I just restarted my local node here (88.98.87.243) and it's reporting 13 connections - 3 are "inbound: false", that means they are listening nodes and my node connected to them so the connection is not inbound to me and so it reads "false" and the rest are (atm) "inbound: true" which means they are not listening to incoming connections but instead they are making incoming connections to my node to pick up tx/block broadcasts, hence "inbound" reads "true".

Slimcoin has a 90-sec block generation time and the chain is running a little fast atm (according to the chainz explorer "overview" tab) so in the initial stages at least, check your outgoing bandwidth from time to time in case the traffic starts approaching your upload limits - which it shouldn't be but YMMV.

Apologies for the slight delay in responding, I had to check my facts first.

Cheers

Graham

I have listen=1, and it seems that my node isn't broadcasting transactions?
Should I open specific ports too?

Useful pointers, thank you. It's a pity that the articles are such a mixed bag but that's typical of altcoinland.

Cheers

Graham