 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
Glad to see the ANN live here. I'm one of the earliest adopters of this (user number 90, if I'm not wrong) and recently I took quite a lot of heat on Steemit for this (thanks for stepping in and explaining, btw, that was very good PR).
Supporting this coin 100%.
Good luck!
|
|
|
|
|
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.
|
|
|
|
|
The Slimcoin version 0.5.0 is not working properly on any of my ARM boards (Raspberry Pi & Odroid XU4) even if I manage to compile it properly. It crashes randomly and my debugging skills got me as far as dumping a core and investigating the stack frames, but no useful thing came out of this.
My hunch is that it may have something to do with the boost libraries. But I may be wrong.
|
|
|
|
|
I think I'm pretty much on the same side with Graham on this one.
I've been following this thread for a meager 9 months, during which I did a bit of promotion, testing, provided feedback and tinkering privately with the code. I had at all times at least 2 Slimcoin nodes up and running, thus helping the network.
Am I entitled to some reward, proportionally equal to the effort? I think so.
Would it be even comparable with the effort (or "luck") of someone who was keeping a node active since the day one, or who mined with the wallet from they day one? Absolutely not.
So, what we are witnessing right now, is in fact a principle of "justice written immutably in the code". There is no bug. These guys have the right to get back their rewards.
We should have seen this coming (and I confess that when I saw Slimcoin listed again on CMC I even made a mental wager with myself that it wouldn't take longer than 3 months for the initial players to come back, at least for a quick cashout). Getting involved in this community under the assumption that the initial coins (a few millions) are "lost", or "dead' is just plain wrong. Early adopters have all the rights to get back their investment.
For me this is not discouraging. On the contrary. It shows that with enough patience and contribution, value will always increase.
|
|
|
|
|
Glad you realized the difference and appreciate your honesty. I am actually the developer behind hubcoin.cash and I intend to launch the product really soon. My proposed ticker would be HCN (I saw yours is HUB).
What can we do to continue both our missions but avoid confusion? I respect your ideas and your development, but HCN was there before, even if it wasn't listed on CMC. There is even an asset issued on top of the NXT blockchain with that name, specifically to avoid collision (once the actual HCN blockchain will be live, that user issued asset will be converted to the new blockchain).
Maybe we can find together a new name or approach for your project in such a way that it wouldn't collide with Hubcoin.cash? Maybe Coinhub? It seems more appropriate for what you do.
Let me know your thoughts.
Best of luck, Dragos.
|
|
|
|
Just checked coinmaketcap and it seems they updated the meta data for Slimcoin (market cap and circulating supply). - market cap: 110 BTC ($371.871) - circulating supply: 14,830,042 SLM Thanks to all who made this possible  One more thing: 1 SLM = 740 Satoshis (approx two and a half cents). But don't hold your breath, volume is still insignificant, this price is after a whopping $80 trade Anyways, nice times ahead. |
|
|
|
In my book, that's a match. It may not match anyone else's notion of a Ricardian contract but I've got all that I need from it. For his kind of Ricardian contract to be considered complete by the parties prepared to commit to abiding by it, you need i) a formal description of the domain ii) a script to execute the described instructions and iii) a metadata representation scheme capable of making statements in the domain about outcomes of the script.
Cheers
Graham
Thanks for taking the the time to respond, always appreciating your posts. I see a subtle, yet, in my opinion, very important issue when the storage of the contract is referenced in another realm which is not enforceable by the same rules, or by the same source as the proof of the contract (the hash of the transaction). For instance, I can create a contract and store it on IPFS, on a torrent hash or even on an URL. But, apart from IPFS, the latter two are not enforceable, the content at the location can be changed. In my understanding, only a blockchain based storage solution can enforce the immutability of the data. For publishing content, which is a one to many broadcasting operation, the immutability of the data is not that important (sometimes it's a burden, because you would like to amend some content you wrote, hence a bit of versioning). But for a contract, I think the immutability of the storage is fundamental and, if it's broken, the contract may be broken too. I'm very keen to use OP_RETURN too, and by looking extensively at the source code of Slimcoin (and a few other colored coin derived from the intial Bitcoin code base) I see it can be tweaked, at least in size. I even did my attempt at creating an identity proof, by inscribing my own name using it, and it kinda worked. The transaction id is 7a343510f4c1b1d42c9ed585b03a35e488194658642e8502f825b611e91ed408 and the OP_RETURN block has been correctly filled. It also shows in ACME, by the way, it's the second inscription after your article. I also briefly looked into go-ethereum, which is the ethereum evm implementation in GO, just to have a gist of what it does. It seems way too complex (which also means quite a big attack surface) but it has interesting features. I can see a similar machine, with a much lower set of operations, implemented as a plugin on Slimcoin. A very simple use case would be a basic e-commerce functionality: adding/removing/editing products and selling them. This type of behavior can be modeled with a much simpler vm than the one in ETH. In this case, OP_RETURN will serve a signaling switch, informing the reader about the type of the operation, and the hash of the contract owning that operation. Increasing the size of OP_RETURN would be obviously necessary, but not more than 160 bytes. Another interesting approach observed in evm is the requirement for payment to use the vm (it's in Slimcoin inscription too, as I saw). Other implementations (like the Steem blockchain) are using a "bandwidth" metaphor, but the idea is the same: limit usage to prevent abuse. |
|
|
|
The reason for posting is that Slimcoin's RDF backing positions it very well as a host for for Ricardian contracts, assuming that i) they work in practice and ii) there's any interest in using them.)
Cheers
Graham
As far as I understand (probably wrong) the RDF backend is derived from blockchain data. Ricardian contracts (or any smart contracts) can be parseable in RDF, but they must be enforced first at the blockchain level. OP_RETURN is not suitable for that, IMHO, or it may be only if we follow the same design pattern: store the URL of a certain document, and the document itself in another storage (an RDF instance, in our case) but a smart contract also has parameters. OP_RETURN seems to be too small for this type of project. I've been diving into various small Turing complete machines (even gotten into one called BrainFuck, which only uses 8 symbols to describe a full Turing complete machine: but couldn't find one shorter than 80 bytes (which is the OP_RETURN size (usually it's 40 bytes, if I'm not wrong). I'd be interested to know more of your thoughts about this... |
|
|
|
|
It's probably somebody who, encouraged by the development and status of the project, set up a bot and tries to make some liquidity. It's a good thing.
|
|
|
|
Thanks for reminding me of the crow story, I remember reading about it a while ago. It's a fascinating story about how arbitrary "value" is. On a less cheery note, the same beans have been exchanged by colonists with amerindians and that didn't bode well for the latter. And that gives at least a partial conclusion: the coherence of the context is fundamental for the weight of the "value". The crow context is way less coherent with a human context than is, obviously, the context of a human... So we first must agree on the main rules, to be able to derive value. I used to think - and I still do - that money is the most common - and powerful - form of agreement. At least between humans. Not a lot of thought has been given to online groups, even less to the likely impact of introducing technology-based support for managing social relationships. We are very definitely in new (social) territory.
Cheers
Graham
It fascinates me as well. Hence, my intention to formalize this with a token called hubcoin.cash. I've been playing with Tendermint as a blockchain backend and I'm putting together the application logic. Tendermint is written in Go, and Go is similar with Chinese to me, which basically means 1) I don't understand a thing and 2) I'm compelled to learn it. So it may take a while until the MVP is live (the roadmap on the site is already a bit overdue). But hey, at least I have a white paper |
|
|
|
I'm mining from one machine and pointed the miner to the other: ./minerd -o http://192.168.1.6:41683 -O slim:slimpass -t 6
In the debug log of the .6 machine I see this: ThreadRPCServer incorrect password attempt from 192.168.1.3
.3 is the machine from where I mine. slimcoin.conf on the .6 machine: listen=1
server=1
daemon=1
rpcallowip=192.168.1.*
rpcport=41683
port=41682
rpcuser=slim
rpcpassword=slimpass
reservebalance=0
Any thoughts? |
|
|
|
WTS:
30m PNut
17m Fuguecoin
20m Roulettecoin
21k Chaincoin
Nice hodlings
(Hence my recent interest in a Raspberry Pi)
Cheers
Graham
I'm a huge fan of Raspis too and, lately, of Odroid. In a rather serendipitous flow of events, I managed to install and run a slim miner on my Odroid XU4 (mind you, the Slimcoin wallet still crashes) and started to mine on the Raspi Slimcoin wallet which I configured as a server. It's nice when you look at those tiny boxes under my TV, each talking to each other, sending hashes, crunching numbers, supporting an invisible web of constant interactions. As per understanding the concept of "value" (or any other concept, for what matters) I once again resort to Buddhism, which postulates that for each event to be considered existent, you need 3 factors: the observer, the object being observed and the process formed between the observer and the object. Which basically means everything is value, given enough observers are engaging in similar cognitive processes towards the same type of objects. Try to explain to an 17th century banker how we are all rich because we "have" numbers in machines powered by electricity (Good God!) talking to each other (a blatant case of witchcraft, by the way). |
|
|
|
There need be no overall deleterious effect on the parent group, the post-evolution state better suits the members of the parent group because the “troublemakers” now have their own coin, which (some will maintain) is a shitcoin, bound to fail, can't possibly succeed, is already failing, etc.
Slimcoin is one of those Bitcoin's "sihtcoins" IMHO. And in its own group it does pretty well. I do see a conundrum, though. The group health is inversely proportional with its size: in Slimcoin, for instance, at this very moment we can safely negotiate whatever we need to do, 'cause we're just a handful of people. Subsequently, the value of the coin is dimes. The only way for the value to grow is for the group itself to grow. At some point, the group health will start to suffer, precisely because of its size... Like Bitcoin "crushed" itself with BCC. I wonder where the "goldilocks" area for such a group is - or if there is such a "goldilocks" area at all. How many people in the group: 100? 1,000,000? 10,000,000? |
|
|
|
There is no straightforward, absolute, canonical, or true description of a behavioral system; all behavioral descriptions are relative to a particular set of questions they are intended to answer.
Cheers
Graham
Everything is subjective. Or, as Buddhism postulates, everything is dependent arising. It is based on something else, which is derived from something else, which is derived from something else and so on... In this context, the "hodl" phenomenon is based on previous experiences with similar contexts. People won't sell their coins because, previously, there has been consistent reporting of economical appreciation of similar tokens, given you "hodl" to them enough time. There's no intrinsic value of Bitcoin or Slimcoin, it's all arising within our own context. |
|
|
|
so -genproclimit=4 and -gen=1 it is. Could try setting it in the config file, see if that works.
Cheers
Graham
Thanks |
|
|
|
|
Is there a way to specify in the slimcoin.conf file the number of cores, so mining will be enabled immediately? I tried generate=4 but it doesn't seem to work.
|
|
|
|
The plot thickens... After I successfully compiled and started the 0.5.0 version mentioned, it still continued to crash randomly, while downloading the blockchain, without any info. I feared a hardware problem, and a look at the Armbian logs showed that the SD card, via the eMMC driver, was doing way too many writing/reading cycles and choked. The solution was to move the blockchain files to an USB drive and start the Slimcoind daemon with a different datadir option /usr/local/bin/slimcoind --datadir=/media/usb/.slimcoin
But even now I was experiencing random crashes, due probably to a certain limitation in the file descriptors on Armbian / Odroid XU4. So I ended up creating a watchdog for the Slimcoin process, called monitorSlimcoin, which is in turn started by a different file, called startSlimcoin. startSlimcoin file, saved in /usr/local/bin/startSlimcoin /usr/local/bin/slimcoind --datadir=/media/usb/.slimcoin
monitorSlimcoin file, saved in /usr/local/bin/monitorSlimcoin (and caressed with a gentle chmod a+x before launching it) #!/bin/sh
until slimcoindDaemon; do
echo "Slimcoin daemon crashed with exit code $?. Respawning.." >&2
sleep 10
done
to be sure it will survive reboots, I added this line on crontab, by firing up crontab -e @reboot /usr/local/bin/monitorSlimcoin
The natural progression would be to add the mining option directly to the slimcoin.conf file, but atm I don't know if it's generate=4 (the number of cores) or setgenerate=4, and I'm a bit tired. Will do more trials (and, obviously, errors) tomorrow, and report back. I know this setup is almost unbearably ugly, but it does the job. And the job is to assess how reliable such a device would be for a general purpose Slimcoin node. For those of you not aware, Odroid XU4 has an octa-core ARM at 1.6Ghz, and 2GB RAM, almost like an entry-level laptop, but it only draws 5-10W of power. |
|
|
|
for whatever reason, this version "version" : "SLMv0.5.0-15-g3092f1e-dirty-alpha"
works, now downloading the blockchain. Will report later if it crashes, but so far so good. I think it's the feature.bip65 branch. |
|
|
|
still no luck with version 0.5.0 on odroid. I isolated the problem: at exactly block 500 it segfaults without too much info, here are the last lines in debug.log SetBestChain: new best=000000166b368bf21d0b height=497 trust=498 moneysupply=0.009912 nEffectiveBurnCoins=0.00
ProcessBlock: ACCEPTED
received block 0000000ab07647579dcf
CBlock(hash=0000000ab07647579dcf, ver=1, hashPrevBlock=000000166b368bf21d0b, hashMerkleRoot=fb2e104ec5, nTime=1401355108, nBits=1d42237b, nNonce=3128, vtx=1, vchBlockSig=30440220208c74e644f0217740daa08e020861f90c1834f9642abdfdf5a28cb0b6bf044d02204fbff0ba44a82659a6fecb1b4e8ae0e24b9e85b9addcae98074900b703e93b9a)
CBlock General PoB(nBurnBits=00000000 nEffectiveBurnCoins=0 (formatted (null)))
Coinbase(hash=fb2e104ec5, nTime=1401355100, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, -1), coinbase 045cfb8653011a062f503253482f)
CTxOut(nValue=0.000017, scriptPubKey=03737b6885f2db3ed5861da8dfd51a42fdc1de251344ece29db0d68feeffa8affc OP_CHECKSIG)
vMerkleTree:
SetBestChain: new best=0000000ab07647579dcf height=498 trust=499 moneysupply=0.00993 nEffectiveBurnCoins=0.00
ProcessBlock: ACCEPTED
received block 0000000d27ddc7a84896
CBlock(hash=0000000d27ddc7a84896, ver=1, hashPrevBlock=0000000ab07647579dcf, hashMerkleRoot=2520cf02ee, nTime=1401355356, nBits=1d3c8a20, nNonce=268435667, vtx=1, vchBlockSig=304502205f7f05a1bc13e40ba87122800219b1dc1e5a89dbbaf2fb3c05c06c3613a48d25022100e87ec2342df15e2aea9c06aaddd4f8c38484fd602c96b20d1e594f20f0839e90)
CBlock General PoB(nBurnBits=00000000 nEffectiveBurnCoins=0 (formatted (null)))
Coinbase(hash=2520cf02ee, nTime=1401355110, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, -1), coinbase 045cfc865303d4ef03062f503253482f)
CTxOut(nValue=0.000017, scriptPubKey=03fbfa443d3891689d7a58e2fb99a8ec142f1d228eac42f520bb17719bc63c4b11 OP_CHECKSIG)
vMerkleTree:
SetBestChain: new best=0000000d27ddc7a84896 height=499 trust=500 moneysupply=0.009947 nEffectiveBurnCoins=0.00
ProcessBlock: ACCEPTED
received block 0000002a085c6068b74c
CBlock(hash=0000002a085c6068b74c, ver=1, hashPrevBlock=0000000d27ddc7a84896, hashMerkleRoot=9365804ede, nTime=1401355686, nBits=1d46a958, nNonce=144937, vtx=1, vchBlockSig=3046022100811306d04799cbd78c95f52803dafbe016a8d2207ca1ce7bfed7712f18522f17022100c0bbd375c4454cc6d6c67f3deb033df7aaebe4e892b50234a4539fa634712c3d)
CBlock General PoB(nBurnBits=00000000 nEffectiveBurnCoins=0 (formatted (null)))
Coinbase(hash=9365804ede, nTime=1401355360, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, -1), coinbase 0460fc86530114062f503253482f)
CTxOut(nValue=0.000018, scriptPubKey=02cbf61f45f268feed4594bdfd0d527d9c52e907280f70675b3e5b5eab941eff8f OP_CHECKSIG)
vMerkleTree:
SetBestChain: new best=0000002a085c6068b74c height=500 trust=501 moneysupply=0.009965 nEffectiveBurnCoins=0.00
ProcessBlock: ACCEPTED
askfor block 0000000318a2596e9395 0
Added 999 addresses from 144.76.64.49: 1 tried, 1016 new
Added 814 addresses from 144.76.64.49: 1 tried, 1676 new
sending getdata: block 0000000318a2596e9395
askfor block 0000000eb7131996f9b7 0
sending getdata: block 0000000eb7131996f9b7
received block 0000000318a2596e9395
CBlock(hash=0000000318a2596e9395, ver=1, hashPrevBlock=00000002c2322842c6bf, hashMerkleRoot=403dfb38c0, nTime=1501002977, nBits=1d0f4c1c, nNonce=1688356384, vtx=1, vchBlockSig=3045022023ba7d6d0e83ca3bc976f3b650a36929f692915479d9af3eba787f517eab225f022100e105ec2e99a81721dc052c9f1cfc0c963af945c4dc348dd19bdd4656a1201d79)
db.log is empty. Here's what slimcoind getinfo gives in the few seconds before crashing: "version" : "SLMv0.5.0-dirty-alpha",
"protocolversion" : 60003,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 500,
"moneysupply" : 9965.80000000,
"connections" : 0,
"proxy" : "",
"ip" : "0.0.0.0",
"difficulty" : 0.01415176,
"testnet" : false,
"keypoololdest" : 1501002984,
"keypoolsize" : 101,
"paytxfee" : 0.01000000,
"errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
Compiled fresh on Armbian (which uses ubuntu 16.04 packages) with Berkeley db 4.8. Thoughts? Suggestions? |
|
|
|
|
