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

Good find ... (I think)

The side-channel analysis is quite favourable. I'm comfortable with the non-nonsense stance - a Marshall Islands reg, no pretentiously misleading bogus T&C's. Reading between the lines, the most prolific blogger seems to be the manager. Maturity is evidenced in the writing style and approach. Capability is evidenced by the content, I find myself professionally interested in the (albeit under-powered) attempt to use textual analysis to beef up the p2p loan risk assessment.

I shall register, see how we get on.

Cheers

Graham

Can I suggest that strand of thought be scheduled for Phase II, after the migration? I can pretty much guarantee that it will also involve changes to the coin's monetary dynamics to make it “better suited to its new role”.

Also, I'd prefer not to have to allocate time to do re-re-branding at this stage.

And there is the not-insignificant issue that a globally-distributed peer-to-peer networked cryptocurrency has no legal standing in any national legal jurisdiction so is unable to defend any intellectual property rights such as a brand name.

The clot from jp who launched VCoin failed even to do local due diligence. There was already a VCoin fintech outfit in sg and their trademark application in the US for VCoin couldn't be challenged and that put an end to using the name VCoin commercially in the US. Any business in any legal jurisdiction can make an application for their exclusive use of a name and, in the absence of a challenge, the legal authorities will be obliged to grant it. Example: https://bitcointalk.org/index.php?topic=579973.msg16333557#msg16333557

I pondered on this for a while and noted a parallel with the Bene Gesserit - they have this place inside where they cannot see, as do all the geo-jurisdiction registration authorities. Hence VCoin became “V”. Let's see the buggers try and register that and it's a good name for a collective intelligence to be known by, I reckon.

Cheers

Graham

edit added example

It doesn't work like that. I've spent some time reading and thinking about it, came up with this articulation, still needs a lot of sharpening up ...

A different perspective on cryptocurrency

(a standalone not-yet-a-blog self-contained page of HTML+JS+CSS, pace a coupla std cdn js libs, which I'm using as test material for on-the-block publishing trials)

Cheers

Graham

Fortunately, sfultong has been making the running for me ...

treat snapshot balances as genesis block transactions

Cheers

Graham

Actually, it's already BEEgun and has reached stage 1, just yesterday evening I finished a rebranded clone of PIVX (as suggested by cryptohunter and whipped on by GREEDYJOHN):



It's not so much a hard fork as a complete change of vehicle, necessitating a snapshot of the extant BEE2 chain with UTXO balances programmatically transferred to the new chain. You'll get to keep the same addresses, same keys, same balance except that Beecoin is now running off've a Core 0.12 PoS + masternode coin.

Time to drop the "2"

Cheers

Graham

Seamless. From bootstrap.dat. Started at 11:42, just checked back at 14:36 to find it fully synced. Nice work dooglus.

Cheers

Graham

It is true that can be seen as a shortcoming but it is a deliberate design feature (mentioned the original ANN, see the link in the top-of-thread ANN).

Cheers

Graham

It is a straightforward consequence of my role as first-line partner support. Ngaio is my primary commitment, everything else is secondary.


That's the leverage I'm looking at.

Cheers

Graham

As I mentioned earlier, I was investigating Datacoin because I was interested in finding out more about how the metadata was handled. With Datacoin, you could run apps straight out of the tx data. Could easily put a lightweight client in there, as binary. Iff you had metadata. You'd have to trust the address of the publisher and that could be conducted in a separate side channel and you could find out the metadata that way. But it's fragmentary, needs to be collated, so I adapted an ACME to check whether it worked in practice - and also get a sense of how much use was being made of that facility (elsewhere this is called “market research”).

As quid pro quo, I'm having a go at contributing an upgrade to a later codebase (aka “gaining experience”). It's what I do. I'm also contributing to Beecoin and Helium, have contributed to BelaCoin, Sprouts, PIVX, the list stretches right back to Feb 2014.

I have been quite specific, I'm a contributor and it would be a mistake to consider me as “the dev” for two reasons, the first is because it runs counter to Teal principles - to have “a dev” is a centralisation influence, the second is because this influence tends to create a central point of (all too human) failure, the very opposite of what was intended. This is a shared resource with shared responsibilities (if it's to sustain itself).

The Slimcoin network is recovering from its Nov 2016 all-time low, the engine's somewhat idiosyncratic-but-not-entirely-unpredictable behaviour is now more widely appreciated and some apparently reliable workarounds exist. By reference to the networks that cryptopia can apparently see, the Slimcoin network is positively glowing with health:



(It is entirely possible that they under-report as much as novaexchange does for Slimcoin nodes https://novaexchange.com/addnodes/SLM/ but even if that is the case, ~40 nodes is still pretty healthy in context.)

There a number of GUI improvements in development, including an incomplete but functioning implementation of watch addresses. The torrenting aspects of web2web publishing proved tedious and torrent metadata is solely concerned with transport and reconstruction of resource fragments, it doesn't even record the mime type of the torrented resource, instead that task is devolved to torrent trackers.

The protocol doesn't really matter, if you're publishing content then if you're not hosting it yourself, someone else is on your behalf. ACME is aimed at allowing club members an alternative to torrenting / coughing up Bitcoin to have content hosted on IPFS. Run your own, share one with others, do as you see fit, there's no constraining cryptographic inheritance here, feel free to be as disorderly and rambunctious as you like.

I have an old blog in XML that I'm planning to render as HTML with base64-encoded resources, I just have to work out a metadata scheme (i.e. set of RDF statements) that I can store in the associated “metadata+content” graph, which I can then use to feed to javascript to get it to programmatically populate the other tabs of the standalone “A different perspective” post, turning it into a micro standalone blog app (with safely-embedded javascript libs + Semantic-UI css framework) with a list of past posts, titles, dates, abstracts, etc. which can be rendered in the wallet as a Qt-driven specialised in-wallet blogging app or the same thing as a component of an ACME instance, wherever hosted. Hey, twitter started out small.

Cheers

Graham

Yes, it's also a reader. The retrieved content is base64-encoded text/html, ready to be base64-decoded and dumped into QtWebView (if you want it in the wallet) or into the html document if it's on an externally-hosted ACME.

The blog posts will go to whichever ACME you want. Maybe you run your own, locally or remotely, maybe you share one with some other people, maybe you took out a subscription to a commercial offering...

Riffing again, ACMEs could differentiate themselves by offering enhanced content presentation or specialising in themed or topic-related content. Or you can have one dedicated to your own content.

There'll probably need to be already-paved cowpaths so that people who opt to gain the advantage of signed graphs are assisted by automatically embedding non-text content as base64-encoded resources because otherwise, the common model of referencing external resources would defeat the purpose of a signed graph - to attest to the integrity of the RDF statements by validating the hash of the serialised graph. With external references, you're basically saying “It was over there, the last time I looked.” Which is a valid statement to make but rather a weak one with little purpose that I can discern. I'm fairly confident that Fuseki's back-end persistence takes advantage of compression and base64-encoded resources suitable for web presentation aren't all that luxurious, so it does seem do-able.

I'm not making any claims for the approach other than it's a means of publishing indexes to signed RDF graphs, with the overall expressive power that brings.


Cheers

Graham

Well, just hitting M1 isn't going to be that easy. As I noted, Datacoin had all the right elements in place but few people were interested, even with the comparative luxury of 128Kb per tx. My sense is that the UX was too fragmentary to offer much appeal and, in consequence, failed to present a coherent narrative. The crux of the issue is metadata. Metadata tells you what's stored and how to access it. Without that metadata, all you can do is serially guess. The adaptation of ACME for Datacoin can use the RDF graph to carry the metadata, the blockchain carries the content. The adaptation of ACME for Slimcoin uses the RDF graph to carry both the metadata and the content, the blockchain carries only an index into the graph.

ACME is just a web app that marshals and presents data obtained by talking to the coin's JSON-API and Fuseki's SPARQL endpoint. The web app component can be relatively trivially re-implemented in a Javascript framework such as Angular or Vue.js and the functionality (i.e. ACME as you see it right now) embedded in a wallet tab. ACME in the wallet, with a configurable whitelist of publishers' addresses plus whatever metadata is retrievable to convey information about the author, title, topic, tags, need, I, go, on. Publishing is ... let's riff on this ... in ACME via a javascript-implemented interface, could even offer in-wallet blogging, hitting “post” submits the content for javascript processing - the content and associated metadata are rendered as RDF, signed and pushed up to the configured ACME SPARQL UPDATE endpoint to be stored in the graph - and the ACME publication API updated. You don't even have to make the inscription, that's done automatically. All you need as a Slimcoin user is an ACME API key and off you go. At some stage archiving and migration functionality can be added but it amounts to little more than hooking up buttons to a few SPARQL queries.

I guess torrent serving could also be made (an optional) part of the package, torrenting does hook into a substantial propagation community, although RDF definitely carries the day when it comes to the extent of the metadata and so can be readily “discovered”.

Which is why ACME will be a self-deploying, as-hands-off-as-I-can-make-it package. I suppose, with a following wind, this might be reasonably mistaken for the raw material for a masternode system an overlay network administered by hoomans instead of an algorithm. It'll have it's pros and cons but it might see some use.

Cheers

Graham

And also full of bullsh*t, I've spent most of my life trying to figure out which is which. Let's see if I can actually deliver this.

Cheers

Graham

Great idea.

This is ... (sucks finger, holds it in the air) ... about 75% complete. I'm currently concluding my “is metadata really an answer?” investigation after gaining some rough understanding of what's been apparently holding Datacoin back because a few years ago, all the elements seemed to be in place ... https://bitcointalk.org/index.php?topic=405992.0;all (only 4pp in all but it does comprehensively cover the issues). What I'm currently pondering is: limit display of (potentially raw sewage) to IsMine() addys (no work entailed) or a configurable whitelist (GUI work entailed).

This is where my “different perspective on cryptocurrency” pays off by giving me more accurate projections. To achieve the proposed goal, the code implementing the tripartite minting will have to be rewritten in the new codebase and it would entail a hard fork, earlier clients will not be able to connect to the new blockchain. I predict that this will result in two networks, the original (dare I write “classic”?) and the new. (Go peer over the fence, In the case of both Ethereum and Bitcoin and a few other minor alts the new blockchain evolved as a separate entity co-existing with the original chain. So “evolutionary growth”, as expected from a Teal organisation and not “civil war” as expected from a hierarchy.) Note how many current Slimcoin users are quite comfortable with the old 0.3 version of the code and note that no-one can force them to upgrade, nor can sanctions be applied.

Another major rewrite, I'm afraid, in order to extend the client to handle PoB.

Sure, but again, not the (sadly, hopelessly wrong) direction in which everyone else appears to be headed. I already know that road leads to a sticky end.

(I find myself slightly shocked at some of the more egregious NIH failures exhibited by “the kids of today” - f'rinstance, all this business about ML algos picking up unwanted human biases was well-known in the mid-80s. ML-driven credit-scoring implementations in the US had already run afoul of what the USians call “red-lining”, a corporate optimisation and exploitation of the deleterious effects of social deprivation that was so pernicious that they had to pass laws to prohibit it. All the ML systems had “learned” was how to exploit vulnerable people, which they've done all over again because the current population of ML “hotshots” are, unfortunately, no such thing, as they have just demonstrated in spades that they themselves are too SQD* to be able to learn from others' previous mistakes and so they advertise openly that they are inherently incapable of designing ML systems, hence the general conclusion, “Oh, GIGO”). * I'm struggling to find a non value-laden term and “Systematising Quotient Dominant” is the best I can manage, although “Autistic-spectrum dominant” is more accurately descriptive.

I see similar inadequate shallow models at play in the domain that is over-broadly painted as “smart contracts” and I can see the same mistakes being made again - because SQD's have a weakness for focusing on the internal consistency of their models and failing to cross-reference the resulting simplified model with the complex models of inconsistent reality. The lawyer's slides in that slideset I posted a week or so ago contain a lot of cautionary material which did not pass me by.

I've already had a very encouraging chat with Steve (close friend and Labs oppo for pretty much the entire decade that we were both there) as to whether he agreed with my tentative assessment that Ginger would be an appropriate approach...
Basically, the Bitcoin scripting language (described by gmaxwell as “adequately expressive for ‘smart contracts’” and that's one dude whose technical assessment I'm happy to take at face value) is too low-level for general use and so I would use Ginger to create a set of higher-level abstractions that were more attuned to end-user needs and more tractable to work with. Steve agrees that a Turing-complete language is not what you'd want for this task and has basically “given the nod” to my idea of using Ginger and has even offered some assistance. It's down to me to identify, characterise and implement the higher-level abstractions. The approach would still reap the benefits of the computational predictability of the Bitcoin scripting language (just don’t ask Steve for his opinion of it, he's not as charitable as I am) but would be able offer more domain-focused and programmer-friendly abstractions with all the advantages that Ginger brings. (And yes, you did read that correctly, you can write in whatever syntax suits: Javascript, Lisp, Scheme, Pascal, Python, it all compiles down to an elegant back-end XML syntax.)

Where am I going for the higher-level abstractions? Well my first port of call is the 2004 W3C Choreography Description Language effort (sunk by MS pulling out I 'spect). If nothing else, it should give me a useful notational starting point, saves me having to start at Level 0.


Unexplored territory for me, can't really comment.


I'll limit this post to specific observations on the mooted “road map”.

Cheers

Graham

I searched and failed to find this. Would appreciate a pointer if you have one.

Cheers

Graham

FYI:

https://doc.qt.io/qt-5/qtnetwork-torrent-example.html

'snot obviously monetized, so no-one's interested, apparently.

Cheers

Graham

Quite a wide spectrum, new and old, different issues.

Scroll to “Build on OS X”: https://github.com/slimcoin-project/Slimcoin/blob/master/README.md, gives you some idea of the process (i.e. using brew to provide the required libraries and utilities.)

Cheers

Graham

Here you go Kyle ...

https://steemit.com/video/@heimindanger/introducing-dtube-a-decentralized-video-platform-using-steem-and-ipfs

Note the “Browserify” option for https://github.com/ipfs/js-ipfs-api which means that the V client can offer a publish-by-ipfs facility.

Note also that the user is, albeit after ~57 months, obliged to pay for continued storage, as well as the assumed contribution from profits (aka “fuck all”). However, V could serve files from datadir, it has read/write access. The “hard client” he's talking about is libtorrent, which can be linked. There's even a Qt tutorial example of a full-bore torrent client running in a Qt window. Not too difficult to integrate. But I doubt members will want sole ownership of the responsibility for curating their content, I think some people will be sufficiently engaged to self-organise a group solution to share the burden and thus lighten it but I can tilt the odds in favour by providing an easy-to-deploy package.

I take his point about “witnesses” (which I assume form some sort of STEEM overlay network) and wonder if that's a strong enough argument to add an overlay network to V. OTOH, SOLID probably has a putative solution.

This is part of why I'm mucking about with ACME, it's a package: node&blockchain+webapp+fuseki. I'm already intending to use Fuseki to store additional metadata & content (thumbnails, etc) and I've been staunchly resisting the urge to add the SQLAlchemy ORM to the web app and bring in the code I already have for quizzing coinmarketcap for the data to offer an up-to-date index, either using a selection tailored to the alt or a standard selection of 20 top coinmarketcap alts.This functionality doesn't need to be prematurely shoehorned into the confines of a masternode client. As the author observes, application provisioning and deployment tech is getting a lot more accessible to the ordinary V club member. I'd be happy to contribute to the cost of hosting a half-a-dozen instances of ACME for a year, viewing it as a kind of annual subscription. That would enable publishing by torrent and/or IPFS, or even off've the web app. I guess the instances would be SOLID servers, too.

Cheers

Graham

While your SPR are on Bittrex, as far as the blockchain is concerned, they belong to Bittrex. “Depositing” coins on Bittrex === sending them to a Bittrex-controlled address.

It's one of the basics: no ticket, no ride, i.e. no privkey, no coins.

Bittrex have the privkey of your Bittrex address, so they will get the amount of Helium issued against that privkey and its UTXO balance and they will pass them on to you. That's the general idea - so that people who have significant amounts of SPR parked on Bittrex won't miss out on the Helium distro. But it doesn't change the fact that while your coins are on Bittrex, they are owned^Wcontrolled by Bittrex and if Bittrex ultimately decline to be involved in the distro, they have no obligation to do anything with the privkeys they hold to SPR addresses.

If you want the Helium to arrive under your control, withdraw your SPR from Bittrex to your own wallet and when the tx is adequately confirmed for your peace of mind, simply shut down your SPR wallet. Y'see it's not so much that transactions are recorded on the blockchain, they are implemented on the blockchain. As long as you have your privkey safely written down somewhere, you don't even need a computer to store your coins. They'll be waiting for you on the blockchain, whenever you're ready.

It's worth doing, as a safety drill. I'm not sure if there's a Spreadcoin testnet or not but if there is, use that for preference. Or run the drill on the testnet of another altcoin, it's a standard safety drill.

1. Start your client and use the console to dumpprivkey <address> for each of your addresses with a non-zero balance (or consolidate them into one address, according to your infosec preferences). Copy the privkeys somewhere safe, (actually, while you're at it, write down each privkey).
2. Shut down the client.
3. Navigate to wherever you have configured the datadir data directory to be --- or to the platform-specific default, e.g. as detailed in GetDefaultDataDir: https://github.com/spreadcoin/spreadcoin/blob/master/src/util.cpp#L1031
4. MOVE wallet.dat file somewhere else on your computer, just for convenience. (If you're feeling super-confident, you could just delete it but why not try that next time through?).
4a. See other OPTIONS (below) at this point, assuming that you have written down your privkey(s)
5. Start the client.
6. Note the 0 balance. Don't despair.
7. Using the console, enter importprivkey <privkey>, feeding it your privkeys as you go.
8. Check the overview tab, as you import each privkey, the address appears in the wallet and all the tx show up in the tx history.
9. Shut down the client, navigate to datadir and DELETE wallet.dat. MOVE the original wallet.dat file back into datadir. (This step is basically theatre, if you've successfully imported all your privkeys, you could just use the new wallet and discard the old one)
10. Start the client, check the tx history and balance, all should be exactly as before.

OPTIONS: Book a hermit's holiday - 6 months on top of a convenient mountain-top. Before you depart, put your computer in a blender, client, wallet and all (but NOT the paper on which you have written the privkeys), switch it on. Dispose of the trash responsibly. Enjoy your holiday. On your return, buy a replacement computer, d/l a copy of the client, start it up, import your privkeys and you should be back where you started, looking at your original balance and tx history.

(Next in this series, how to do the Jason Bourne thing and have a privkey laser projector embedded in your flesh.)

CLAMs were distributed by snapshot (of three blockchains, BTC, LTC and DOGE). If you had an address or addresses with non-dust amounts on any of the three chains, you got 4-and-a-bit CLAMs for each addy. I had a couple of DOGE addresses and Ngaio had one, so we got 12-and-a-bit CLAMs in total. Collecting them was interesting. You moved your DOGE wallet aside, started the client to create a new empty DOGE wallet, made a note of the new address, shut down the client, move the new wallet to one side, bringing back the old wallet. Start the client again, send all your DOGE to the new address, wait for confirmation. After confirmation, move the old wallet (with old addrs now with 0 balance) somewhere handy and move the new wallet back into place as the DOGE wallet (one new addy, with all yr DOGE). You were now done with that stage.

Next stage, start CLAMs client, click Import->Wallet, select old (empty) DOGE wallet and as if by magic (but actually by privkey), there's a 4-and-a-bit CLAMs balance for every (qualifying, i.e. non-dust) was-DOGE-now-CLAMs address. Delete old empty DOGE wallet.

CLAMs is doing okay at just short of $8 a pop. It's a PoS coin and the 12-and-a-bit CLAMs we started with has grown to 100+. All because I knew: no ticket, no ride.

HTH

Cheers

Graham

I wasn't planning to take that route. The Datacoin approach is reasonably straightforward, uses an extra field in the CTransaction object, no impact on the opcode/scripting at all (afaict). Or have I missed something critical?


Even better, gatra's Riecoin is a primes-as-proof-of-work clone of straight Bitcoin 0.8.3, not a hint of “ppcoin” anywhere in the sources and a very useful set of version branches.


  remotes/origin/0.10.2
  remotes/origin/0.6.2
  remotes/origin/0.6.3
  remotes/origin/0.7.2
  remotes/origin/0.8.1
  remotes/origin/0.8.3
  remotes/origin/0.8.4
  remotes/origin/0.8.5
  remotes/origin/0.8.6
  remotes/origin/0.8.6-ric
  remotes/origin/0.9.1
  remotes/origin/0.9.2
  remotes/origin/HEAD -> origin/0.10.2
  remotes/origin/blockheaders
  remotes/origin/freenode-verf
  remotes/origin/master
  remotes/origin/master-ric


So, I was able to upgrade foo1inge (via Primecoin) to 0.8.4 and 0.8.5 and then pull up to 0.8.6, at which point I was able to shimmy over to 0.8.6-ric, pick up the (albeit Riecoin-specific) primes-as-PoW architecture, then take a long running jump and grab to Datacoin 0.9.1. Which is where I am atm, cross-referencing against a Minkiz Foundry 0.9 Bitcoin Core template (to identify common change points). At this point, the refactoring of foo1inge Datacoin-specific code is still significantly incoherent with respect to the 0.9.1 base, so the next step is a cross-comparison of Datacoin vs its original cloneparent at the point of cloning - to more precisely delineate the original footprint of the Datacoin-specific changes and use that as reference for the final refactoring of the Datacoin code so that it is coherent w.r.t to an 0.9.1 codebase. It should only be a standing jump to 0.10 from there, iirc. And the only remaining Prime/PPcoin code will be limited to that which is required by the Datacoin-specific PoW routines, i.e. not a lot.

Cheers

Graham