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

@d5000 - you have torrent network that's viable and sustainable most of the time? And will it be using IPFS or standard Bittorrent protocol?

My pessimism of usage is regarding to all smaller alts - they are used mainly for speculation against BTC (especially now!), not for actual use of any kind, even if they have good ideas.
PPC has marketcap of about 45m $, and have only 400-700 transactions per day. And it's our forked coin, which should be having much more usage, and much bigger audience, and much more transaction (in theory at least, seldom forks are more successful than main branch).

OP_RETURN to 500-512KB sounds good for me. NXT 40KB wasn't used much imo, because it wasn't marketed at all, and 40KB is too low to store anything (even text files can have bigger size).
500-512KB could make store even some compressed heavily pictures eg. art or ancient works as I mentioned.

I will perform some study about it - can it be with some surveys around altcoin groups, and here on bitcointalk, because it's the only way we could see, if it would get attention or not.

@cryptovore: That's awesome! I fully support that. I unfortunately can't help developing (I had even to google what a VM does in the cryptocurrency space), but if you need someone to test it later, I'm in.

@gjhiggins: A little question ... I have installed a Fuseki instance to provide the Slimcoin RDF block chain, mainly for my own web2web tests, for now, but also as an block explorer API. A couple of weeks ago you mentioned a Python blocknotify script you have written that "translates" the block JSON structure from the Slimcoin client into the RDF structure used in your CCY ontology. Can this script be downloaded or could you upload it publicly so I can use it? (I could write a similar script but why invent the wheel two times ...) Is your CCY ontology "stable" or are you still working on it?

@muf18: Regarding your pessimism on usage: I think that only can grow in a gradual way. We're just starting a bit of marketing, have now a pretty stable client and a website, but that wasn't so half a year ago. My hopes for web2web and similar technologies lie in bringing uncensorable web sites. I see a high potential for authoritarian countries, because w2w is so simple to use and doesn't require an installation (like ZeroNet, Maidsafe, IPFS etc. does), and we could get a first mover advantage if we're the first cryptocurrency that is using that technology on a larger scale and promoting it.

For a very simple example, we could hash regularly an updated Wikipedia snapshot into the Slimcoin chain and distribute the snapshot via torrent for our Chinese and Turkish friends where Wikipedia is blocked or restricted. Accessing that snapshot via a Slimcoin address would be much easier than having to search an updated snapshot via Google every couple of weeks.

Regarding increasing the OP_RETURN field to 1 MB, I have thought a little bit about it. My preliminary stance is:
- one single OP_RETURN transaction should not be able to fill a whole block, so the maximum I would allow are about 500 kB per transaction. That would be more than enough for long, compressed text files, such as descriptions of inventions, property records, etc. I would be more happy with 100 kB maximum that also should be enough for most use cases.
- and even then, I would only support such a high limit if you can prove (with at least a "rudimentary" market study) that there is demand for it. I was a long time active in the NXT community where they can load up to 40 kB (see here) of arbitrary data into a transaction. But this feature is barely used. And you said Datacoin also has only a 2 GB blockchain (simliar to Slimcoin's), so demand to store data seems not very high. So I remain skeptic, and cryptovore seems to have the same opinion.
- As I said, I have no problem of allowing OP_RETURN data transactions up to 1 kB, as long as the 1 MB block size limit is not touched.

I would have thought that by now most Slimcoin users would find the words “Loading Block Index...” rather tediously familiar. As advertised on the splash screen, it is loading the index. Which, as is observed in the commented source code, can take several minutes.

Or maybe it just hung. If so, then your interlocutor is correct, the debug log should contain a clue.

Cheers

Graham

That's interesting turn of events, very interesting project.
I can then, back down, from my proposition, but OP_RETURN making bigger is necessary to make some improvements, at least I think so.

As a Slimcoin community email account on behalf of it I emailed to novaexchange with kind proposal to upgrade client to v.0.5.
That's what they mailed me back:


@gjhiggins - any thoughts, about it?

Edit: some serious issues with security of IOTA, which makes whole design and it's technology questionable if it's secure enough.

https://medium.com/@neha/cryptographic-vulnerabilities-in-iota-9a6a9ddc4367

Interesting piece of work you have there. I might have an appropriate hook-up ... from an adjacent tab open on a discord session:


I think I mentioned previously, I'm looking into the “nature of the language” in terms of characterising the domain tasks performed by users and analysing the information requirements of the tasks. Starting with the abandoned W3C Choreography effort, just because it's there.

There's some pertinent work in AI done back in the 80s, some potentially useful abstract models of identity-to-identity exchange of items. May not be useful other than to indicate “don't go here” but you never know. Remember all the attention given to “An AI-powered chatbot has overturned 160,000 parking tickets” in the middle of last year?  Know what the “AI” is? A buncha production rules, aka what used to known as an “expert system”, all the rage at one point.

And, of course, Bitcoin itself was based on 80's and 90s comp sci and crypto as detailed in this piece for the ACM Bitcoin's Academic Pedigree. The concept of cryptocurrencies is built from forgotten ideas in research literature. The HN discussion is illuminating in places: https://news.ycombinator.com/item?id=15134670 “After 12 years as an academic computer scientist, Bitcoin was the most impressive computer science research I saw. And it came from outside the academy.”


Not 'arf!


Sounds about the right timescale for something that needs to unfold in the right way.

Cheers

Graham

Ok. IPFS - isn't so reliable, and isn't so decentralized as nodes on blockchain.
Other are commercial used. We won't be use it for commercial, but for humanity and research.
I think that 1MB blocks could be preserved and thus 1MB max file size, or placed in parts.
We could use to upload some thing like Datacoin browser?
They used it to upload files to the blockchain, and as I say - only small files with meaningful uses, I think I can create such a list of files, pack of files and would use some of my SLM to upload it and effictavely make them unspendable.
Of course it's a idea, but I think make bigger header for OP_RETURN, is one of the way to expand our platform for various things, and small files won't bloat blockchain, which is going to rise anyway. Of course before even introducing we should, and must do exstensive testing of such feautures, and have some fees that could make them balanced not to overbloat blockchain.
About updates - great, it's a great news.
But IOTA or micro computer like rspi can have microsd cards, which in the end will be needed, because it's not like our blockchain will be always empty. It's now empty, but with some use it rose by 1-2gb per year no problem, with more transactions even more. So 32-64GB or even 128gb cards would be needed to sustain blockchain for long time as a node.


BTW. - help to maintain Ethereum/Slimcoin market at nova

https://novaexchange.com/market/ETH_SLM/
They closed our LTC/SLM market, because there wasn't any vol - help to maintain at least Ethereum market, because they opened it for us, and they didn't have to.
If you can - make a few bid/ask offers, to tighten spreads and make trading real

Sorry for popping out of nowhere, but I see the current topic is about potential changes (hardforks?) of Slimcoin. I want to give you a few updates and voice my opinion on the "files on blockchain" proposal.

1) "files on blockchain" - I do not support storing files on blockchain, because: a) the "blockchain" is a consensus engine, not a storing engine, and b) there are already solutions for this problem (IPFS, Storj, Sia, Burst, BigchainDB, to name just a few).

2) Updates: for the last weeks I've been playing with a very small VM, trying to integrate it with the Slimcoin blockchain. So far the VM, which I call it slimvm (because it's very... slim, obviously) compiles correctly and gets integrated, but it doesn't do anything else other than that, there is no integration (mainly because of some architectural challenges I'm having, I still don't know which route to take).

There are 10 opcodes so far in the VM and I do not intend to have more than 20 opcodes in it (Ethereum VM has about 114 opcodes, if I'm not mistaken, and 4 pre-compiled contracts). The "human" language built on top of these could probably be way less complex than Solidity.

The reason I'm doing this is that I see a gap (opportunity?) in the market, where a very slim vm can be used for very small ricardian contracts (small in size). Also, the smaller the VM, the smaller the attack surface, so this implementation would be - allegedly - more secure. One of the use cases would be in the IoT area, where nodes with very small requirements in terms of power could execute various tasks: opening / closing doors, operating street lights, etc. All these IoT operations could then be mapped to SLM, as a token, increasing the demand.

I'm also doing this as an exercise in learning. If anyone is interested, let me know.

Please be aware that at this moment it's less than an MVP, just some scattered code and, at the current speed of work (slow, as I have a day job and a few other blockchain projects which are more demanding) I expect to have some decent code in a couple of months.

"Potentially death trap". If it was a way to storage large data, with low cost - yeah it would kill network in a few months or years.
If it's optimally choosed, with economically not viable approach after putting more than we want size of files into chain - it can boost network usage (in healthy way), and boost demand.
What's the usage of slim (in sense of small) blockchain, because and if it's not used at all?



You mean 90 seconds right? About table - yeah, but max capacity now would also mean 937.5MB (960 x 1000KB full blocks) added transactions to blocks per day, so nodes need a high-end hardware today (but it's not gonna happen - altcoins like our have no use, unfortunately, as I presented, at least for now), but to calcs: 937.5MB (~~0.9155GB) x 365 ~~334GB per year - not bloated blockchain ?

Ok, with 1MB, we could get somewhere.




Because one is tested and quite stable for now - Proof of burn, and we could add new features? Web2Web is coming, which a good idea, but making something like this is I think as much
important if not more important. And because altcoins are for new features - every alt, which is bitcoin clone is usually mocked (apart from LTC, but yeah, at least it had new scrypt algo).
Datacoin isn't in good shape, has less nodes, than we (like 18-20, as I have seen), and their development was stalled, before Graham started to contribute too. They haven't got any support from almost anyone (one website I have seen, which built tool for it, but it could also be used in BTC/LTC and it's not using special features of Datacoin, so it's useless for now). No exchanges, for now it has only blockchain working with network, I think they are miles behind us (they have one website, but with dead links, and second also with dead links)




I see a difference, because it's a forked code, not like "our" invention. Like it wasn't changed at all, only want to point a difference, it was used in Slimcoin, only because of Peercoin forked code.
It's a nice touch actually, and make some sense to a "Proof-of-burn" crypto, but not intentionally I guess(?) or maybe I'm wrong?



But you didn't include in your calculations, that no one could do eg. 500GB of data stored in the blockchain, because no one would have enough SLM to do it (apart that it won't be redistrubed to miners again just burned), in one year. Even in 10 years. Maybe in 30 years, than maybe, but it's a long time to come up, with sidechains solution also, and maybe blockchains will be different then and we could upgrade, maybe HDD/SSD will be so huge, that it would take only 1% of 50TB or 0.1% of 500TB HDD/SSD.
Making economically viable only for small and important files to be stored, are the main concept, I'm trying to say here. Not a torrent-warez like network.
And with bubbles I can only say - if someone wants to pump a coin, he/she will do it, regardless of anything. So we can't be shielded from it, maybe if we has mechanism like Bancor, but it's completly different story, here we have simple - demand/supply model with open order books, and like a whole crypto world, we are vulnerable for manipulation from both sides.
Bloatcoin - again, you would have also bloatcoin if you put to use whole space on blocks with slimcoin. Not spamming network are only shielded, because of so high fees, here we can be shielded the same way - with high fees for storing files and burning coins after spending on storing it.


I agree with it, but how you will make it happen (even with plugin?). Why would someone choose this coin, over 100s other with bigger exchanges and so much better liqudity.
I'm realistic, and I know that for now it's impossible.
Web2Web will maybe make some buzz, but it's like niche - and so would be my idea - a niche, that nobody, or almost nobody is now using, but could have some demand.
If you want to fight with mainstream crypto - it's a lost fight.

(Just for users that have not seen our PM discussion:

My main point why I oppose a (significantly) larger "data field" (>1 kB) for blocks transactions, like muf18 proposes, is that I consider blockchain bloat a potentially deadly trap. Data that is once saved on the blockchain could never be deleted, and so a huge bloated blockchain will be huge and bloated forever.)

That would be a bit high for me. If Slimcoin had 10 minute block time, OK. But it has 90 minutes. So 2 MB Slimcoin blocks would be equivalent to 16 MB Bitcoin blocks. Look at this study (table 2 on page 4) and you'll see that if there is usage of this "feature", then full nodes will already need high end hardware.

I would even maybe support an increase to 1MB for the OP_RETURN transaction field (must think about it) if the block size stays the same and fees also, but no increase.


Why two experiments in the same coin? As I already wrote, there are already some other coins that provide the same service. (Datacoin!)



It's a minor issue and does not ad much to the discussion, but just out of curiousity: where do you see the difference?



That was not my point, although I think I got what you wanted to say - you think SLM value will increase gradually with that feature and cryptocurrencies getting more popular. But I was referring to the scenario I sent you per PM. I cite it so other users see it, too:


In short: I'm afraid that any instability/crash/correction could dramatically let decrease the number of nodes and put Slimcoin (or "Bloatcoin", because it's no longer "slim"), every time that occurs, on the verge of collapse and death.


That is related to what I said here:


Now to your last point:


We share this poor level of activity with most altcoins. Even in the top 10 there are some coins that are barely used (NEM, principally). But "Featuritis" won't save us, only adoption will.

ACME/web2web should give us more adoption already. But everybody that wants it can add Slimcoin as a payment method for a shop - there is no technical restriction. In my opinion, a much more necessary addition to achieve adoption than a "large data field" would be actually a Magento/Shopify/Woocommerce plugin for Slimcoin.

Ok, so increase block size to 2MB, and make max file of 2MB.


Monetary incentive, but apart of and it would be experiment - like bitcoin is also an experiment, slimcoin with proof of burn also is experimental.


Fee problem could be discussed, I didn't have specific value, in mind, only to provide it economically not viable to spam network.
0.03SLM/KB would be good if price of SLM would be like 20000 satoshi or more

No it's basically like Peercoin code fee system is working in Slimcoin now, because it's peercoin model of burning fees. Apart from it - how much it's buring - a few SLM for a week? It's completly different scale, comparing to thousands of SLM required for storing.


How can you be shielded from speculative bubbles in crypto world? Now whole crypto world is in bubble (maybe apart from Slim), and do you see it stoping? It was growing day by day - and one day it will plumet for sure - but then in next years it will raise again. There are more users adoption after each bitcoin bubble, and now after altcoin bubble will be the same.
Cost of the running node of bitcoin or litecoin or any bigger coin is also growing day by day, and they dont say, that they now will stop hosting blockchain.


But tell me what currency usage? Nova exchanging a few satoshis for a few thousands SLM, 3-4 times in the week? Is this our " currency" usage? Because I don't see any other, usage is almost none, so as our blockchain, and you say that one data is more "precious" than other data, quite interesting, but I can't agree with this. Important files of culture and history are more far more improtant than, bitcoin blockchain usage GBs on ledger with only transactions, and petahashes or exahashes of network strenghthen.

As muf18 already said I oppose an increase of the OP_RETURN data space over 1 kB, because I fear blockchain bloat. Some points:


This would not be possible. One file could only reliably be stored in one transaction, and one transaction cannot be split across blocks. Otherwise you would have to use a second "layer" which splits the files into various small parts and stores them in transactions. That would be basically the same what we have now (80 Bytes per OP_RETURN output).


The "huge value to whole humanity" would only be achieved if it's really stored for a long, long time (100 years, for example). How to ensure the blockchain would work for such a long time, if it's expensive to run a node?

OK, that would be expensive - so expensive that it would never be used, because the current fee is 0.01 SLM/kB, only that you cannot use the whole "transaction space" for data, only about 35% (max.) of it (80 bytes of ~190), but that would mean 0.03 SLM/kB. To differentiate the OP_RETURN fee from the regular fee would add complexity.

That's basically like SLM fees work now.


As already written per PM, we already have Datacoin, Byteball, Nxt, Steem and Qora as competitors.

With the "monetary incentive" part we have part of the problem:
- cost for nodes to store the blockchain would grow every day
- but their "profit" would be the same (speculative bubbles aside).
So again, how to ensure long term sustainability?

Yes, but currency usage (as a currency, not as a data storage!) increases its value (according to the Quantity Theory of Money). So a currency that is much used as a currency, automatically justifies its "blockchain bloat".

Ok.
So me and @d5000 have serious conversation, about one of the upgrades I purpose (and which I wanted to execute, because probably, we could have some more people on board,
which are programmers/developers, and could help us, with my friend's help to make it happen)

Upgrade Slimcoin code to use some code of Datacoin to store small files in the blockchain (I purposed max 5mb for files, but it could be even max 2mb), blocks would still be 1MB.
What is my points to do it:
1/ Making a database, which is immutable, which can store files, and is never down is a huge value to whole humanity (of course with proper number of nodes)
2/ Making it quite expensive (I thought about 0.5SLM/1KB), making it economically not viable to post some "shit" files, and only upload really important documents or pictures
3/ After storing files in the blockchain, coins which was used for storing, won't be spendable again (would be burned), and thus reducing inflation, or even providing deflation
4/ Make greater demand for a Slim - as I have said, storing files in blockchain, could really prop up our image and make us visible to the world of crypto, to prove, what I'm talking about take this
Google trends table as a hint: https://trends.google.pl/trends/explore?date=2013-07-08%202017-09-07&q=slimcoin,datacoin
5/ It could contain of all necessary for humanity files, which could be destroyed in next years (manuscripts, ancient works, importan scientific research etc.)
6/ Make it possible to store it in blockchain, makes it possible to never disappear (instead of others method, hostings, or even IPFS, which could fail), of course IPFS is the strongest one here and least likely to fail, but I think only storing it in a main chain (or if it's possible in side chains), make possible to restore files in even most harsh conditions (only monetary incentive can keep system running continually and undisturbed)
7/ I acknowledge of "some" blockchain bloat - in this way I want to make max files requirement, and make cost quite expensive in relative monetary terms, besides - our blockchain doesn't have any use as of now, and we are mining empty blocks, and that's why it's so small, otherwise it would balloon up quite fast with 1.5min blocks.
8/ For my data I used that 100-200MB would be uploaded to Slim network (it's more than, it would be economically viable, with the cost more than 50000-100000SLM, which price also would be higher due to demand for storage). So in my basic and rough calculation, it would be around 10 years to make blockchain bloat up to ~~700-720GB, with 200mb capacity per day used all the time (and we know, that if coins were burnt, it wouldn't be like that, it most likely be 1/10 of that amount or even less, because amount of coins produced would be to small, and it would balloon up price on exchanges, if someone would like to use it so much), and in 10 years we could develop idea of sidechains quite well I think.

Now there is about 8000-10000SLM produced per day, so even if miners would sell all those coins - it would be economically viable and possible to store only about 20000KB of files everyday, so about 20mb of data, which is not much for our blockchain - in 10 years max capacity would be about ~~72GB.

So ultimately no I don't think it would kill Slim, I think it would strenghthen capabilities and make a great purpose for humanity to use Slim blockchain for such purpose, also could prop up price on exchange/s, make demand, and we could be closer to the mainstream of crypto.

I will write shortly @d5000 points, but maybe it will be better to correct it, by @d5000 himself:
1/ It would bloat blockchain
2/ It won't have big demand
3/ It will kill Slimcoin in long run - blockchain "bloat"

For instance I think that I proved valid points, and @d5000 also made some vaild points, to which I answer in my statement above.
It's up to you to decide, who is correct, and make viable approach to this topic.
I stand by my point, but it's a community driven project, so community members should say, what they think, and choose.

Of course you can.

Thank you. Could I import private key elsewhere so I can run wallet in two places? One 24x7?

Datacoin have now some service (3rd party) as I have seen which makes it possible to even run some basic jscript apps in it, I think.
But I don't know, how excatly it works, and it's still in beta or alpha, and also is used with other coins.

There was an idea of side-chain/personal, but wasn't developed, with nodes choosing, which chains they support, and contain blockchain of it.

Apart from that I make some basic research of disproportion of Slimcoins across owners, and it seems that almost 5 milion coins are probably lost (at least wasn't spent for more than 200 days), unspent there are probably more, but I added some coins to active because some addresses can't be seen, or can be waken up in future. But about 5 milion coins I think can be said that are lost.
Active coins (spent within 200 days period), made up for "Total balance of All active addresses with more than 10000 SLM: 6945932 SLM".
Which probably means, that more than half supply is frozen for now, can be considered inactive, so, that's also why exchanges are so dried up, most of big holders are sitting tight, and only smaller are trading, but I think it's quite normal situation - also quite good, because big holders are enthusiastic - they don't sell, because they see future in these, otherwise they would dump on first ocassion, because there are several offers now on nova, and were even more offers, and biggest trading vol was about 2BTC, with 350K SLM in one trade, and it wasn't from the biggest holders

BTW. - and maybe give some support on https://twitter.com/Slimcoin_club

I didn't follow Datacoin that extensively, but it may be caused because of Datacoin's big blockchain (because they started "storing everything on the blockchain", the same error Steem does/did), which didn't exactly incentive full nodes. I never heard that they managed to get done the task to combine their blockchain-based storage with torrent technology (or another non-blockchian alternative) in a user-friendly manner (the thread you pointed also seems to indicate that).

Yep, that's something to consider. Peercoin - Slimcoin's "mother coin" - is planning a hard fork to update the code to a more modern Bitcoin version, even if they only update it now to 0.8 or 0.9, but they had always a strong leadership by "Sunny King" and now they have an "official development team", so it's maybe easier for them.

I see two alternatives besides a hard fork, if we want to update Slimcoin to enable new features like the Lightning Network (and my personal favorite, Atomic Cross Chain trading) that depend on a malleability fix:
- continue with an older codebase and backport a fix for transaction malleability. It may not be Segwit, but there are other, a bit simpler ideas around like Flexible Transactions, although they unfortunately are much less well tested than Segwit.
- try to achieve the update to a modern Bitcoin version via soft forks, like Bitcoin did it. That would be perhaps the best idea, but also the one with most work involved ...

However, if we find a way to port PoS and PoB in Slimcoin's incarnation to Bitcoin 0.13+, and the development work can be achieved, a hard fork planned well in advance would very likely succeed. As Slimcoin is not Bitcoin and would have to convince much less service providers to update (non-institutional users should not be the problem), maybe 6 months is enough between the release of the updated code and the hard fork date.

I am observing the current hard fork debate in Bitcoin, above all with the eyes on the planned hard fork in November by a "cartel" of miners and service providers (the "Bitcoin Cash" hard fork was more similar to "just another altcoin with an airdrop to Bitcoin users" than to a real hard fork that sought to really "update" the code). Perhaps Slimcoin can learn from it, because Bitcoin is also a pretty decentralized community (without an "official dev" or another strong hierarchic component).

this like monero or vrm ? and where block explore, pos or just pow ?

I was trying on an AMD FX-6350. And I think I would appreciate the tutorial, rough calculation gives me 0.3 blocks per day with my CPU. So even if I run it a few weeks, I could get nothing because I am unlucky, or because something is configured wrong...

What CPU do you have?
Just do simple math calculation - your hashrate / network hashrate, I think there are about 520 blocks PoW per day (I don't know if number of blocks to approve block is number creating POW blocks per day, even if not it's close number to it like 540-570 I think). And you will know how much you should get.
You should be using DCrypt, because SLM is using Dcrypt as a algo, but if it's running probably with proper libraries, but not optimized. I'll put some guide to mining on yt and now DTube at end of this month I think, because I have a few other things to do, but I'll note it, to make it, with Windows and Linux miners, it will on Slimcoin Community channel.

Okay, thanks for the suggestion. I downloaded slimminer and am running that now. It says it is using the Scrypt algorithm, is that correct?

I do get about 10x the hashrate now, assuming everything is working correctly, but my original question still stands, how can I estimate the time to find a block with a given hashrate?