Bitcoin Forum
October 19, 2017, 04:05:36 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 »
  Print  
Author Topic: Slimcoin | First Proof of Burn currency | Test v0.5  (Read 74649 times)
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 07, 2017, 10:56:13 AM
 #1181

Thank you for your detailed and articulate response to what was frankly an offhand and ill thought-out comment from me.

Ave, adventor.

It's worth acknowledging that at the moment, the Slimcoin “onramp” is more like a near-vertical flight of steps. Assorted folks are picking away at the problem, in their own time (and quite rightly so), we'll get there eventually. Until then, ISTM that recognising the likelihood of a degree of frustration is incumbent on those of us that have managed to find some solid Slimcoin ground on which to pitch our tent.

Quote
I haven't the technical skills to contribute to the project, or else I would. But I do think I have a nose for value, and the concept is quite interesting. That and, the community-while it certainly doesn't fit the traditional mold for an alt-coin, I've been impressed and intimidated by many in this thread. I've got a decent-sized position and am going to see what the future brings.

I can't speak to value, not even potential value, it's too much of a chimera and there is a long roll-call of altcoin failures. I think it is significant that Slimcoin has thus far escaped this fate, perhaps only by virtue of its unique triple minting approach but hey, we'll take whatever's going. There seems to be a bit of a “thing” developing for the re-visiting of some of the altcoin offerings-in-principle, such as the wave of interest that swept through masternode coins a few weeks ago. It may be that the drift towards ICOs has now resulted in sufficient reduction in the number of “traditional” ad hoc altcoin launches that people looking for non-ICO opportunities to engage are now taking a slightly longer look at those that have survived a few years because, if the blockchain is still active then someone must see some value in keeping it going and just maybe there's something more substantial underpinning it.

The concept is still being developed but the Slimcoin blockchain has been mapped to an RDF graph with a supporting SPARQL query service that I'm using to animate ACME, A Cryptocurrency Metadata Explorer, the mention of which has disappeared under the waves: https://bitcointalk.org/index.php?topic=1141676.msg20407730#msg20407730 while I get on with it.

The state-of-play demonstrator is on http:// tessier.bel-epa.com : 6054/ I have some local updates which I will flush up to the server later today and make a (brief, phew) post pointing to the changes.

ATM, the “Publications” listing is a brute-force “list all tx with OP_RETURN”, just a starting position, obviously no a viable approach with the block height now over 1m but ....

I'm currently developing the POST section, using the W3C's Activity Streams vocab for interoperability:


{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Person",
  "id": "http://purl.org/net/bel-epa/ccy#Sj9oBMXyJgxM7GZ5CpUtf3mixFEhk4ern9",
  "name": "Graham Higgins"
  "url": "https://bel-epa.com/users/gjh/foaf.rdf#me",
}


Where I'm using one of my Slimcoin addresses (generated from BIP32 using an '/m/9/0' path to bodge up an informal semantic designation) as a unique identifier (by the time its embedded the URI), enabling others to whitelist the corresponding OP_RETURN inscriptions from that address, should they be rash enough.

I'm intending to gather up all my blog posts and re-publish them, using the W3C's ActivityStream vocab (https://www.w3.org/TR/activitystreams-vocabulary/):


{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Article",
  "name": "A different perspective on crpytpcurrency",
  "mediaType": "text/html",
  "content": "<div></div>",
  "icon": [
    {
      "type": "Image",
      "summary": "Header (1100x303)",
      "url": "https://acme-slm-164936252.io/Sj9oBMXyJgxM7GZ5CpUtf3mixFEhk4ern9/note1.png",
      "width": 1100,
      "height": 303
    },
    {
      "type": "Image",
      "summary": "Note (32x32)",
      "url": "https://acme-slm-164936252.io/Sj9oBMXyJgxM7GZ5CpUtf3mixFEhk4ern9/note2.png",
      "width": 32,
      "height": 32
    }
  ]
  "image": [
    {
      "type": "Image",
      "name": "Rabbit 1",
      "url": "https://acme-slm-164936252.io/Sj9oBMXyJgxM7GZ5CpUtf3mixFEhk4ern9/rabbit1.png"
    }
  ],
  "attributedTo": http://purl.org/net/bel-epa/ccy#Sj9oBMXyJgxM7GZ5CpUtf3mixFEhk4ern9"
}


relevant but unedited, just to give a flavour of the work. For example, I have a standalone page of HTML (do a “View source”) as a blog post which I can just insert into “content” and store the lot in the RDF graph, calculating a hash signature of the added statements that than be inscribed on the block chain.

Other stuff in the vocab which is going to come in handy in terms of implementing the polling functionality in Javascript and populating the contents of the “About” and “Index” tabs in the standalone HTML example ...


{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "GJ's blog posts",
  "type": "Collection",
  "totalItems": 3,
  "current": {
    "type": "Link",
    "summary": "Most Recent Items",
    "href": "https://acme-slm-164936252.io/collection"
  },
  "items": [
    "https://acme-slm-164936252.io/posts/1",
    "https://acme-slm-164936252.io/posts/2",
    "https://acme-slm-164936252.io/posts/3"
  ]
}


{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Page 1 of GJ's blog posts",
  "type": "CollectionPage",
  "prev": {
    "type": "Link",
    "name": "Previous Page",
    "href": "https://acme-slm-164936252.io/collection?page=1"
  },
  "items": [
    "https://acme-slm-164936252.io/posts/1",
    "https://acme-slm-164936252.io/posts/2",
    "https://acme-slm-164936252.io/posts/3"
  ]
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Page 2 of GJ's blog posts",
  "type": "CollectionPage",
  "next": {
    "type": "Link",
    "name": "Next Page",
    "href": "https://acme-slm-164936252.io/collection?page=2"
  },
  "items": [
    "https://acme-slm-164936252.io/posts/1",
    "https://acme-slm-164936252.io/posts/2",
    "https://acme-slm-164936252.io/posts/3"
  ]
}


I hope to have more of it working as described above by the end of the week. (I need to crack on, I have a fair few posts to collate)


Cheers

Graham

[edit: apologies for the scrambled text, in a bit of a rush today]
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508385936
Hero Member
*
Offline Offline

Posts: 1508385936

View Profile Personal Message (Offline)

Ignore
1508385936
Reply with quote  #2

1508385936
Report to moderator
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 07, 2017, 11:07:06 AM
 #1182

pish, I forgot to post what I came for:

Here's a PDF report of the banking industry's 2016 “Smart Contract Templates Summit

Useful overview of takes on smart contracts. 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
cryptovore
Member
**
Offline Offline

Activity: 97


View Profile
August 07, 2017, 11:20:33 AM
 #1183


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:
Code:
>,<,+,-,[,],comma.point
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...
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 07, 2017, 11:56:28 PM
 #1184

Ricardian contracts (or any smart contracts) can be parseable in RDF, but they must be enforced first at the blockchain level.

You're probably right, I was basing my understanding of a quick skim of:

Ian Griggs' Introduction to Ricardian Contracts, retrospective (begins at p45 of the Smart Contract Templates PDF). Note: “Smart Contract Templates

Quote
Lightbulb - The Contract IS the Issue
Flip the logic upside down
• keep prose document as is
• let the program extract its parts from document
• place the users -issuer+holder- first
• and the developer second

As developer, I don’t need to convert the bond
1. capture into signed digital document
2. read out 10 or so values
3. identify the document for accounting

...

The Hash as identifier
PGP again provided the clue
cryptographic message digest or Hash
Turns any ‘document’ into number:
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3
(Hal Finney’s Bitcoin account)
Hashes are:
• Secure, unique, global, free
• 1:1 with your document
...

The Ricardian Contract
• Captures any legal prose contract
• any financial deal
• no harder to read or write than any other contract
• (too) brutally honest
• not good for hiding intent
• Signed and Hashed
• self-identifying, self-verifying
• hash makes participation in any digital agreement trivial
• add keys & server locs for self-assertion, self-routing
• Easy to implement – 1000 lines of code


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.

From my reading of the runes, it's not that the whole process is automated, only the (mutually-agreed) blockchain part of it is. It's that the accompanying formal annotation is usefully more precise than NL for certain common tasks and so can be abstracted to the design level, devolving the tedious implementation details to semantic and syntactic engines.

That's the theory anyway. Success will depend on whether the DSL (Domain-Specific Language) and the TSL (Transaction Scripting Language) were  designed with enough sensitivity to the inevitable power / expressibility / comprehensibility tradeoffs. Somewhere in the annals of bct, gmaxwell avers that the Bitcoin scripting engine is quite capable of expressing smart contracts and hints that we might want to reflect on whether the power of a Turing-complete language is actually desirable in this instance (it isn't, imo). Having blundered around these byways for some time, I know where Griggs' efforts are going to get bogged down. I can see two pain points in Griggs' slides. The first is the formalisation of the domain of contracts - aka “knowledge acquisition and representation”. This is still very much an ill-understood, specialist subject and without recognising that, they are not likely to be able to make much actual progress. The second pain point is going to be the characteristics of the TSL in computational linguistic terms.

I share Griggs' enthusiasm for re-purposing cryptographic hashes as identifiers --- by prefixing a few characters to a blockhash I have an RDF identifier with increased confidence in its uniqueness. It's a direct mapping, works for tx hashes too, and addresses. We should specialise the ccy vocab to Slimcoin and use a dedicated namespace:

PREFIX slm: <https://raw.github.com/slimcoin-project/slimcoin/vocab/slimcoin#>

slm:C00000d7e8a80fec4057cb6d560822705596040bf41f0ebb2465dcdf46e4c517e

I believe RDF gives us some slight operational edge in that what is notarised is a fully formal description of the object that is capable of carrying a significant information payload, including arbitrary  serialisations of the object, (video, audio, image, text) etc. and the metadata allows indexing and cataloguing.


OP_RETURN capacity is configurable - https://github.com/slimcoin-project/Slimcoin/blob/master/src/script.h#L27

static const unsigned int MAX_OP_RETURN_RELAY = 80;      // bytes

ViaCoin has a generous 128 bytes, IIRC. I've configured Slimcoin's a little more economically. 100 seemed a bit lavish, after putting a few URLs into it. But the value could be bumped up a bit or even a lot (what other plans for the coin are there?). Slimcoin's 90s rapid-fire block emission rate offers a relatively low impedance to inscription txs. They get quickly cleared away rather than piling up.

Keybase.io is another outfit writing its stuff to the bitcoin blockchain, it uses the popular merkle tree approach of “locking” hash references using OP_RETURN.

Oh, Project Provenance is also interesting.

Cheers

Graham
ojeck
Member
**
Online Online

Activity: 64


View Profile
August 08, 2017, 06:07:19 AM
 #1185

Is this normal ?

Quote
2017-08-08 06:06:16 UTC hashmeter   4 CPUs   3397 hash/s
   PoW Target: 0000000a8e7a0000000000000000000000000000000000000000000000000000
trying connection 1.23.43.88:41682 lastseen=-19879.6hrs
connection timeout
trying connection 217.65.8.75:46733 lastseen=-389492.3hrs
connection timeout
trying connection 86.130.245.53:41682 lastseen=-27702.6hrs
connection timeout
trying connection 217.65.8.75:37262 lastseen=-389492.3hrs
connection timeout
trying connection 175.143.17.109:41682 lastseen=-23578.5hrs
connection timeout
trying connection 146.185.168.142:60082 lastseen=-389492.3hrs
connection timeout
trying connection 196.28.245.222:41682 lastseen=-22861.7hrs

Libre Bazaar - A Decentralized Anonymous MarketplacePre-ICOAnnouncement Thread
Blockchain and Data Storage Network Coupled With P2P Anonymous Networking
User Friendly ▲▼ Anonymous ▲▼ Community Driven
cryptovore
Member
**
Offline Offline

Activity: 97


View Profile
August 08, 2017, 08:49:52 AM
 #1186


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.
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 08, 2017, 11:18:07 AM
 #1187

Is this normal ?

Quote
2017-08-08 06:06:16 UTC hashmeter   4 CPUs   3397 hash/s
   PoW Target: 0000000a8e7a0000000000000000000000000000000000000000000000000000
trying connection 1.23.43.88:41682 lastseen=-19879.6hrs
connection timeout
trying connection 217.65.8.75:46733 lastseen=-389492.3hrs
connection timeout
trying connection 86.130.245.53:41682 lastseen=-27702.6hrs
connection timeout
trying connection 217.65.8.75:37262 lastseen=-389492.3hrs
connection timeout
trying connection 175.143.17.109:41682 lastseen=-23578.5hrs
connection timeout
trying connection 146.185.168.142:60082 lastseen=-389492.3hrs
connection timeout
trying connection 196.28.245.222:41682 lastseen=-22861.7hrs

What seems to be the problem?

Cheers

Graham

edit: re-phrased response
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 08, 2017, 02:15:53 PM
 #1188

Thanks for taking the the time to respond, always appreciating your posts.

Generous of you to say so. I'll grab any excuse for an opportunity to pontificate paint some more pictures.

Quote
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).

I disagree that the difference is subtle. I see it as complete, unbridgeable and profound. As isolated cognitive entities, we are also ungrounded. I like Marmite, let's say, for the purposes of discussion, you don't. What does it mean to you when you say “Graham likes Marmite”. Where's the semantic grounding located? How do you “prove” that statement in a way that is both sound in an epistemological sense and would also satisfy your local LISP programmer as a specification that could be coded to work reliably and accurately? We can't. But it doesn't slow us down.

As autonomous cognitive entities, we are functionally adequate. If we make a fatal mistake, someone else will arrive at another solution - rinse and repeat, general progress of the many continues at the occasional cost of a venturesome individual. Too bad about the fallen poppy but hey, we got fields of 'em. Next volunteer, please.

We (not me, I hasten to add) dreadfully abuse our artificially-created non-autonomous cognitive entities by wanting them to be formally adequate, provably “correct”, no product must ever be allowed to make a single mistake. That would be a huge failure and undermine people's faith that the technology always produces unbiased, correct answers - such as “Graham likes Marmite”. Unfortunately, the formalism is inadequate for its purpose and probably always will be (c.f. Joseph Becker). For a kick-off, it ignores the possibility that Graham might just be lying about his uninspectable mental state, gambling on the near-certainty that no-one can prove otherwise.

Quote
But, apart from IPFS, the latter two are not enforceable

Someone on HN posted a summary, I clipped it for my NOTES3.md file (in which I keep a copy of stuff that's informing my thinking, Ngaio's working her way through NOTES1.md):

Quote
[HM: libertymcateer](https://news.ycombinator.com/item?id=14945061)

I have been saying this for quite sometime on this forum - contracts have to deal with ambiguous circumstances and expressly contemplate being resolved in courts. Ambiguity of contracts is a *feature*, not a bug, as it is in the interest of both parties to be able to argue about certain unanticipated events when they occur.

Quoting my own comments from a while back:

> The vast majority of contracts do not have syntactically testable conditions. They just don't. Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about. Unless you can create a condition that is testable by code, you cannot have a contract that self-enforces with the block chain. The conditions set forth in contracts are extremely complex and reasonable people can differ. I cannot imagine how you would have a contract be triggered on the insolvency of a privately held corporation - good luck defining insolvency and good luck getting access to the underlying books. Copyright infringement is also a preposterous idea - the amount of semantic judgment that must be made to determine if a work is infringing is enormous. Only the very simplest of conditions - comparing numbers, checking the time, can be reliably automated, and if you are getting a lawyer to write your contracts, odds are there is substantially more complexity in the agreements than this, which is why you hired the lawyer in the first place. In addition, a fair portion of contracts that can actually be set up to work this already are - and the blockchain is not necessary. They are things like credit cards and they work pretty good without the blockchain.

---

Oh good, someone's on the ball, saves me having to write it ...

An important non-SQ truth for engineers: “Ambiguity of contracts is a *feature*, not a bug.”

Closely-focused autonomous cognitive entities (let's not start the Butlerian jihad just yet) that are engaged in detailed modelling of domain properties are at risk from complete irrelevancy if they ill-advisedly ignore influential elements from a broader context, e.g. many people fail to heed the bald, unambiguous, tell-it-like-it-is of:
Code:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Quote
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.

Well done, you managed to get that tx through quite a narrow window. I managed it once, when the network was quiet and my server was influential but I did most of scribbling on the testnet (also browse-able, just click on the slimcoin icon in the ACME nav bar to toggle).

Quote
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.

The attack surface is further enlarged, unfortunately, by the Ethereum team's apparent complete unawareness of the existence of extensive research on the psychology of programming. The fundamental problems are obvious but Buterin seems insensible to them (boy, have I seen that before) and I've learned not to waste my time. Either people will adapt their way of working to conform to its simplistic assumptions or it will permanently occupy a niche market.

(Apologies for being tediously predictable) As you might predict, I'm a lurker on PPIG. Programming and cognition are also longstanding R&D interests of mine (art is a lifelong thing, I've found). In fact, I just came across some of the old tech papers I published inside HP from the early days when Steve and I were researching the application of cognitive science to software engineering. My ex-oppo-from-HP Steve is still interested in pursuing the topic generally in the form of “Ginger”, a syntax-neutral programming language - it's a long-term best effort (i.e. when he can find the time) project that he is leading, in conjunction with some other grizzled vets/code gurus. They hang out on a slackalike but the codebase is on github: http://github.com/Spicery/ginger:

Quote
Ginger is our attempt to build an elegant but friendly and practical programming system. It includes a programming language, virtual machine and supporting tools.

The programming language itself is syntax-neutral. By this we mean that you can choose any of several 'pluggable' front-end syntaxes - there's one rather like Algol/Pascal, another like Javascript, another like Lisp. They all get turned into an elegant back-end XML syntax.

Ginger is a modern programming language supporting automatic memory management, object oriented programming, pervasive multiple values and a simple but powerful data loading mechanism that includes data-format conversion.
I'm the project's tame cognitive scientist. <anticipating/> I think it (looking at Ginger with an eye to using it as a TSL) is an avenue that could be explored. I recently received a notification that the Ginger effort is aiming to pick up a bit more speed so I can check whether such an effort might pique Steve's interest.

Quote
Increasing the size of OP_RETURN would be obviously necessary, but not more than 160 bytes.
Worth doing then. For clarity, this is the MAX_OP_RETURN_CHARACTERS, a limit.

Quote
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 blockchain is the ultimate and only authority, anything else can be altered. Basically, no matter what it is, if it's not got its fingers permanently trapped in the blockchain, it's free to run off with your money.

IMO, Griggs has found the only practicable path through the symbol grounding maze, on a “render unto Caesar” basis  - use the machine context to resolve issues of formal internally-consistent grounding and use the embracing human-mediated social and business context to resolve issues of informal externally-inconsistent grounding.

Cheers

Graham


muf18
Full Member
***
Offline Offline

Activity: 182


View Profile
August 08, 2017, 09:58:53 PM
 #1189

Sorry to inform, but I can't deliver Chinese and Korean, translation for now, because people didnt respond me or don't want to do it(?) have holidays. So yeah... Sorry really.
Still I'm on holidays now, but I really tried to make it with some contacts made. I will try maybe with Japanese, but I don't know. I can't promise anything. I thought I can rely on some people - and it seems I can't. Sorry for deliver this news, which isn't best.
Still I'll try to work out somethin else.

cryptovore
Member
**
Offline Offline

Activity: 97


View Profile
August 09, 2017, 06:38:02 AM
 #1190

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 Smiley

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 Smiley

Anyways, nice times ahead.
muf18
Full Member
***
Offline Offline

Activity: 182


View Profile
August 09, 2017, 09:24:52 AM
 #1191

At last...
They made! Great job, even they updated social media, I wrote them with new twitter account. Didnt update website to slimco.in, still I'm impressed (I think my first submit about twitter was almost 2 months ago).
81BTC market cap - I even do screenshot for this. It's laughable, but we are still in early days of development (even tho community take over was excatly 2 years ago)...
But hope to see greater numbers in 2018 Cheesy

Sorai
Member
**
Offline Offline

Activity: 90


View Profile
August 09, 2017, 07:01:12 PM
 #1192

Saw this article today and thought of Slimcoin.  

Eco-crypto: 8 coins focused primarily on the environment
https://cryptoinsider.com/eco-crypto-list-coins-focused-environment/

Seems to me Slimcoin should be on such a list.  What do you guys think?  Looking at the big picture, do you suppose a Slimcoin-based economy would be better for the environment than one based on a staking-only coin?  
hannusolo
Sr. Member
****
Offline Offline

Activity: 280



View Profile
August 09, 2017, 08:12:31 PM
 #1193

In the slimcoin wallet can I somehow see the Proof of stake statistics like in other wallets? I mean "my weight in the netrork" and the "total network weight". Can I access these data thorigh some console commands maybe?

        ETHEAL           ETHEAL
      ETHEALETHE       ETHEALETHE
    ETHEALETHEALET   ETHEALETHEALET
  ETHEALETHEALETHEA ETHEALETHEALETHEA
 ETHEALETHEALETHEALETHEALETHEALETHEALE
ETHEALETHEALETHEALETHEALETHEALETHEALETH
ETHEALETHEALETHEALETHEALETHEALETHEALETH
ETHEALETHEALETHEALETHEALETHEALETHEALETH
 ETHEALETHEALETHEALETHEALETHEALETHEALE
  ETHEALETHEALETHEALETHEALETHEALETHEA
   ETHEALETHEALETHEALETHEALETHEALETH
    ETHEALETHEALETHEALETHEALETHEALE
      ETHEALETHEALETHEALETHEALETH
        ETHEALETHEALETHEALETHEA
          ETHEALETHEALETHEALE
            ETHEALETHEALETH
              ETHEALETHEA
                ETHEALE
                  ETH
                   E


🅽🅴🆆 Operating System of $7600B+ 🏥 Healthcare industry
🕸 Website  📝 Whitepaper  Video  📢 ANN  💰 Bounty  💬 Telegram
Improving the lives of 1 billion people by making Healthcare transparent.


d5000
Legendary
*
Offline Offline

Activity: 1526


Enjin Coin - Smart Cryptocurrency for Gaming.


View Profile
August 09, 2017, 09:02:36 PM
 #1194

The russian translation of the website is now online. Thanks @dzarmush! (It seems you have translated directly the HTML files, that would not have been necessary - translating the .md files you probably had much less work ...).

So CMC finally are tracking us the right way. I will supervise them a bit, to see if they are tracking slimcoin.club's statistics correctly. Once ACME is finished, I plan to run a node and would provide it to them as an alternative source, to have more redundancy. The current market cap for me is much more realistic than the one we had with the 1999 satoshi spike Wink

A little comment on the testing of 0.5:

As far as I read the last pages, there are not really important bugs left (please correct me!). So I think we could already point to 0.5 as the "stable" release, as we had already a generous testing time for it. @gjhiggins, would you be OK if your newest additions (BIP65 and watch addresses, if I remember right) are included in the "next release" (perhaps v0.5.1)?

The goal is to get more servers to use 0.5 so we can move forward with the OP_RETURN feature. I was still not able to do an inscription on the mainnet, only on testnet. In my case, using the GUI, the client rejects any OP_RETURN transaction as "non-standard". Does someone know if that is determined by the network state (= how many 0.5 clients are connected)? On testnet, inscriptions do work.

PS: Just observed, CMC is lagging a bit behind slimcoin.club counting the circulating supply (CMC: 14,830,042, Slimcoin.club: 14838606). I'll observe that - for now, the estimation is OK, but if the difference is bigger I'll return to my idea to provide them the number as a better readable web service).

muf18
Full Member
***
Offline Offline

Activity: 182


View Profile
August 09, 2017, 09:45:27 PM
 #1195

They arent updating their numbers at all - from today it wasn't updated any time - and because of this it will lag more and more.
We must provide direct number to them

d5000
Legendary
*
Offline Offline

Activity: 1526


Enjin Coin - Smart Cryptocurrency for Gaming.


View Profile
August 09, 2017, 09:53:45 PM
 #1196

They arent updating their numbers at all - from today it wasn't updated any time - and because of this it will lag more and more.
We must provide direct number to them

You are probably right.

I've provided them this link to the "getinfo" function on Slimcoin.club, so they could update their stats in real-time. The link is providing (at 21:52 UTC) the following numbers (in the source code, every number has a separated line, so it's very easy to grab):
Code:
v0.3.2.0-13-gd9fad6e-dirty-alpha
14838852.6304
1068848
38
0.08328525
3005940.0
357712883.255
1135448973843

being the second number the correct, and constantly updated, "circulating coin supply". Maybe I must resend the information to explain them in more detail how slimcoin.club works.

drbarber
Member
**
Offline Offline

Activity: 71


View Profile
August 09, 2017, 10:35:43 PM
 #1197

So I've had my coins in my wallet for a week, how do I get them to move from balance to stake? My reserve balance is set to 0. setgenerate true doesn't make them move and I'm not sure what command does D::::
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 10, 2017, 02:47:22 AM
 #1198

Code:
v0.3.2.0-13-gd9fad6e-dirty-alpha
14838852.6304
1068848
38
0.08328525
3005940.0
357712883.255
1135448973843

Would probably be better to emit JSON. I don't think they want much ...
Code:
{
    "blocks" : 1069037,
    "moneysupply" : 16861433.31502200,
    "burnedcoins" : 2010861,
    "timestamp" : 1502274320,
}

Cheers

Graham
gjhiggins
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
August 10, 2017, 03:02:51 AM
 #1199

So I've had my coins in my wallet for a week, how do I get them to move from balance to stake? My reserve balance is set to 0. setgenerate true doesn't make them move and I'm not sure what command does D::::

The command

setgenerate true n will create one or more separate threaded processes devoted to mining Slimcoin. n is the number of threads to be started.

Coins are alleged to start staking after around 8 days (the precise value is in the source code).

A non-zero value assigned to reservebalance will disable staking of coins to that amount.

balance - reservebalance = staking amount

Cheers

Graham
gavrilo77
Hero Member
*****
Online Online

Activity: 651



View Profile
August 10, 2017, 03:38:41 AM
 #1200

So I've had my coins in my wallet for a week, how do I get them to move from balance to stake? My reserve balance is set to 0. setgenerate true doesn't make them move and I'm not sure what command does D::::

My wallet started to stake after 9 days, so just wait a few days more

BitSend ◢◤Clients | Source
www.bitsend.info
| Your Digital Network | 10MB Blocks
| Algo: XEVAN | DK3 | Masternodes
| BSD - Tether USDT Pair ✔
| Bittrex | C.Gather | S.Exchange
| Cryptopia | LOCALCRYPTO | Livecoin
| CoinPayments | Faucet | Bitsend Airdrop

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!