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

Hi,

Yep i had the same problem few months ago when i tried, but i gave up (my knowledge are not as good to solve this sort of problem).

Hope you will do it !!

K.

Still here.
Was on the other side of the country (Australia); with my primary employer.

The NOMP/UNOMP pool is at the point where it is accepting and validating shares (meaning that independently the pool and miner agree on the blockheader); however once the pool sends the solved block to the daemon; the daemon segfaults, as even though the hash is technically correct (matches claimed PoW/nBits), the transaction data differs.

NOMP/UNOMP (or any opensource pool for that matter) have a fairly basic way of constructing a coinbase transaction which includes the pool's designated address. It does this by using fairly sparse details that it receives when polling the daemon for a block template. The pool then passes this information (coinb1 and coinb2 in stratum 'params') to the miner - the miner adds their extranonce value and hashes it for what is known as the transaction merkleroot.

The issue here is that Slimcoin (or any of the Peercoin family) has an odd transaction format that most pools have no idea about; using a set of zeroes for the sequence 'lock' rather than the bitcoin-standard 'ffffffff'; not to mention other oddities like giving the transaction itself its own timestamp, rather than just a timestamp on the input and output.

Have asked openly before on this topic (https://bitcointalksearch.org/topic/nonstandard-p2pkh-in-altcoins-1844717).

When the pool submits what it thinks is a valid block, the daemon gives the nod because preliminary checks pass - then has an Exception error; while giving a stack dump (while continuing to run).
Basically the same thing that was happening years ago - https://bitcointalk.org/index.php?topic=613213.3995;wap.

Anyway; i've started writing a pool from scratch that gets around this by using some getwork trickery; stay tuned.

james

barrysty1e's gone dark. I was in a convo with him, he shared some commercially-sensitive material with me. I was hoping to collaborate, he seemed up for it. Then he suddenly went dark. He's a Kiwi I think, apropos of nothing in particular. I just hope he's okay.

Cheers

Graham

What about the pool ?

Did barrysty1e replied at the end ?

K.

That's the intended destination, I'm just being idle and letting github do the rendering in temporary repos, I really can't be arsed to set up even a minimalist rendering environment. The next and most taxing step is to reduce the content to the bare essentials and simplify the writing. But anyway, now we know - the main idea behind Slimcoin was the ability to use cheap low-powered kit to contribute network-protecting hashpower instead of expensive ASICs. No ASICs for Slimcoin are in sight as yet, so P4Titan's hypothesis has not been disproven thus far.


minkiz might just need a force-refresh in the browser, letsencrypt refreshed the https certs. http://tessier.bel-epa.com:5064 is serving again.

Cheers

Graham

Edit: intemperate and ill-founded rant deleted

Very interesting, thanks. A "Slimcoin history" sub-page for slimco.in would be nice, maybe this can act as a source.

By the way, I can't access neither minkiz.co in my browser still (ping however works) nor the ACME instance at http://tessier.bel-epa.com:5064 (this one simply says "Unable to connect", but ping to tessier.bel-epa.com works).

I got this far: https://github.com/gjhiggins/throwaway

Cheers

Graham

Looks like the letsencrypt script has broken the Apache config, sigh. That's all I did, I ran letsencrypt - can't be anything else. (I used to run self-signed, because of the obvious garbage that was contaminating the official cert chain but over time my options have been gradually crowded out by an increasing number of nowhere-near-as-good-as-they-obviously-think-they-are, half-assed security “improvements” ... lemme restart the daemons ... okay I can see Minkiz now, I presume others can too. (Yes, I do have plans to upgrade the h/w, later this year).

Edit:
Qualsys results, if anyone cares: https://www.ssllabs.com/ssltest/analyze.html?d=minkiz.co

Cheers

Graham

Another reason I'm unimpressed with the degree of journalistic insight displayed by the WSJ is that Slimcoin users won't be able to read what, if anything, the WSJ writes about Slimcoin and PoB because the WSJ web site is behind a paywall.

I'm slightly puzzled why this WSJ journalist thinks an open source project would be a topic of interest for WSJ's nakedly acquisitive subscribers or why it's blithely assumed that volunteer technical contributors will be happy to devote time to personally answering elementary questions from the WSJ, the answers to which are already out there in front of them, in black and white, if they could be arsed to look. In this respect, Phred is no different to any other putative Slimcoin user - except that as a WSJ journo, she expects to be able to take directly with “the deveopment team”. The mismatch speaks very strongly of profound misconceptions.

Cheers

Graham

Hi all,

The ACME website seems to be off..

Is it normal ?

K.

What I found appealing about Slimcoin and Proof of Burn can be found in my articles on the website https://slimco.in, above all in the "Advantages" section. It's the long-term-involvement-awarding effect PoB provides - if you burn and want to see a profit, you'll have to wait, and so it's not adequate for short-term speculation while it encourages community participation.

Short-term speculation is what imho is causing most of cryptocurrencies' volatility and the constant risk for a small cypto to "die". In contrast, Proof of Burn ensures that there is a group interested in the well-being of the coin until more than a year after they've burnt coins.

I'm not very fluent in "spoken English", and I had never contacted the original developer (in fact, when I became involved, P4Titan was already about to leave the community). So I would prefer to direct journalists to what I wrote instead of an interview.

Ok, I'm up to it Graham, tell me what you want from me.

I may be wrong but I don't believe that any of the current subscribers to this thread are able to claim first-hand knowledge, the current understanding has all been constructed from publicly-available posts in the old OP bitcointalk thread and in the Slimcoin documentation.

Okay, so Phred hasn't read the thread - that means there's a high likelihood that her misperceptions will overwhelm both the context and the communication.

Point her at the documentation, it's in her native language and is the primary source she is seeking (and her article will probably be all the better for it).

Good instincts ... Teal model best practice is: any person can make any decision after seeking advice from: i) everyone who will be meaningfully affected, and ii) people with expertise in the matter.

I don't see any reason why we shouldn't collectively have a go at coming up with something, if not for Phred then for the next time someone asks or even for our own use in explaining to acquaintances. I've just d/led all the original Slimcoin bitcointalk posts and am in the process of filtering them for relevant content and then I'll re-work the P4Titan on Slimcoin section of the Slimcoin README into a more comprehensive document, confident in the knowledge that all the available relevant technical info has been harvested.

If you're up for it, I'd like to explore something ... create a description of the basic principles of the coin (which will cover the typical journo's needs) but take pains to ensure it is written in a very simple and straightforward style which, if my educated guess is correct, should result in broadly accurate machine translation. The acid test will be for subscribers to this thread to paste the english source text into something like google translate and check whether the machine translation into their native language preserves the broad sense of Slimcoin's features and principles according to their understanding of the way that Slimcoin works.

Once we have something reasonably robust, I'd like to add the text to the "About Slimcoin" tab in the wallet, localised with the (largely approved) mechanical translations. Of course, if anyone actually wants to work on a translation or improve it, the files are all here: https://github.com/slimcoin-project/Slimcoin/tree/slimcoin/src/qt/locale

I should be able to come up with something later this evening ...

Cheers

Graham

Everything ok with Barry.


On the bright side - WSJ Tokyo Journalist has sent to us, and our decentralized team a message:



Would any of you, would like to talk with Phred Dvorak from WSJ ? If not I'll arrange, and will do the talk myself, but I would be keen to give it to, someone with better background, and better understandment of code then me.

Would Graham @gjhiggins, or @d5000, or anyone else would like to participate in it?

Apart from it, I received a message from Blockbid about boarding coin on final stage of their exchange, which should later in 2018, as I assumed from the message

It's without any marketing. The project is defending itself, and when I will have more free time I want to contribute to it really, to make it great.
Proof of burn can be used in a Economics Universities to study, about economy of cryptocurrencies and their usability, and because it's the first use I will try to show it to some of my professors at my University.

Nice work.

Cheers

Graham

Inscriber tool for easy Slimweb inscriptions

I've tested the inscriber tool in mainnet and now after a few fixes it seems to work OK.

It can be downloaded here: https://github.com/d5000/acme-minitools (download the whole repository).

It uses the blocknotifybase script as a dependency; this is not ideal, but it was the easiest way to realize it In the future it should work as a standalone tool and use the standard configuration file (slimcoin.conf) for the needed parameters.

What does this tool do?

The inscriber tool provides an easy way to inscribe data on the blockchain via OP_RETURN transactions and gives you the ability to control the address from which the inscription is done.

This is important if you want to publish "Slimweb" websites and update them regularly, because in this case an address is the "identifier" of the website. As the current client doesn't allow coin control, currently you need to use workarounds.

NOTE: The Inscriber tool uses the Raw Transactions API. It is therefore a potentially dangerous tool. You should NEVER use it with your main wallet - in theory, a bug could "thrash" your coins. Try it out on testnet and then create a wallet with few coins to create inscriptions. As inscriptions cost only 0.02 SLM, with a few coins you'll be fine for a long time.

Basic Syntax


INSCRIPTION being the data you want to inscribe (e.g. a magnet link or torrent hash)
ADDRESS being the address (it must be one of your wallet addresses and contain more than 0.02 SLM) from which you want to send the data inscription.


If you don't provide an address, you can select one from the available addresses in your wallet with at least one unspent output of more than 0.02 SLM.

The inscriber tool will select an output from your address and then do the inscription. It can use the "smalldata" format which is recognized by the client as a "message" (default) or the raw OP_RETURN format which provides 4 bytes more. Maximum length is 80 bytes in raw format and 76 bytes in Smalldata format.

Each inscription costs two fees:
- 0.01 minimum standard transaction fee
- 0.01 additional fee because each output must have at least an amount of 0.01 SLM. This fee is burnt, too. (In theory, it could be transferred to another address you own, but you won't be able to use that output normally unless the 0.01 minimum fee is lowered.)

The default behaviour is that the change coins are returned to the original address. If you want to transfer the change to a new address use the "-n" option.

Example transaction created by the Inscriber tool

(More documentation - e.g. a simple howto to create and update a Slimweb site - to follow on the Wiki.)

Still waiting for nova to open the deposits  

Also, we're seeing an unprecedented market share spread, most probably in the next 2-3 years the majority of share will be held by a group of altcoins, spreaded between 15-20%, with Bitcoin on a lower position, but still in the top 10.

Actually i had the same problem using CPU mining.
I'm going to check which version of minerd i used..

K.

The problem that the pool is having is due to Slimcoin's custom transaction format (as mentioned by d5000).
The pool will correctly identify a blockheader with the correct amount of work, however when it sends this to the daemon using submitblock (along with the transaction data) the daemon then segfaults, as although the dcrypt hash matches - the block contents aren't correct.

The issue was encountered years ago with no proposed solution (https://bitcointalk.org/index.php?topic=613213.3995;wap).

I've worked with another currency 'Cryptonite' that an identical issue, where the solution was to only submit the blockheader (no tx data) using 'getwork'. The reason this works, is the daemon already knows about the transactions it has received via p2p (and its own coinbasetxn for the potential block) - the calculated merkleroot then matches the merkleroot provided in the blockheader.

It's not quite 'getwork over stratum', as its only used for the solution, not the work propagation.


I recently came across the GPU solo-mining code (not the stratum gpu miner @ https://github.com/JonnyLatte/slimminerGPU); this will not work against the pool due to differences in getwork/stratum work format and byteswapping of the nonces (and several other fields).

Even when the daemon had died, while the stratum was still up; it will still return valid hashes as it keeps the last blocktemplate in memory.
More than happy to do some testing if you like.

anyway

I'm writing a small patch to allow the block to be submitted using getwork; will post back on my results in an hour.

james