Just wondering how long it will be before the focus of keeping new people coming into crypto sets in
The time for that has long since been and gone. The number of new altcoin launches per month has fallen back to near mid-2013 levels, before the $1000 BCT feeding frenzy kicked off.  If you can shift your thinking away from “investment” and towards “entertainment” then the situation gets a bit clearer. Much the same “oversupply” perception is applicable to a whole raft of entertainment products (films, computer games, songs, ebooks, lotteries, etc.) Cheers Graham |
|
|
|
Just wondering what your thoughts were on coins that appear to be dead, but might be ready for a rebound.
Can you point to any examples of once-popular altcoins that appeared dead at one time but which have, in your assessment, subsequently had a successful rebound? Cheers Graham |
|
|
|
Coin: Intellect
Dev status: abandoned
Hardly “abandoned”, the last commit was only three days ago: https://github.com/intellect-project/intellect/commits/masterAltcoins are being re-developed all the time but it's not proved to be a wildly successful exercise. In the case of PoS coins, if the wallet's stuck and a fix isn't readily apparent to the techs at the exchanges then I'm afraid that 5000 BROKEN isn't likely to get anyone very far. I checked recently and the going rate for commercial-grade contract C++ programming in the UK is around £50 per hour. The pay from a day's commercially-remunerated C++ work would command a dominant chunk of the marketcap of your typical BROKENCOIN, if not all of it. The biggest barrier to rescuing an abandoned altcoin is the intransigent expectations held by the existing community. Cheers Graham |
|
|
|
Here  I was wondering that too, didn't think to just enquire, lol. Nice work. Cheers Graham |
|
|
|
I advocate for tying the max amount of MNs to the coinsupply:
Max MN = (total coinsupply)/ 2880.
Well argued. I'm convinced. Cheers Graham |
|
|
|
I think the OP was referring to the web site code but anyway ... that's Mr Spread's abandoned repos. I created a github org https://github.com/spreadcoin, migrated all the code there and bestowed admin privs on the listed contributors, i.e. it's in common ownership atm. I've been wrapping up a few loose ends from before the phase 2 test, merging a few branches before conducting a comprehensive relabelling exercise. If you collectively wish to debate and decide upon different labels then so be it, the important point is that the labels have been changed: - Masternode -> Service node
- InstantTx -> ExpressTx
- DarkSend -> PrivSend
This activity is taking place in the sn-test branch which is being positioned as a candidate for the next round of testing. Cheers Graham |
|
|
|
I don't think its a deal breaker.
Me neither but I think the revenue stream may turn out to be much more modest than is currently fancied because the core service is basically a commodity and the main revenue will orient around the arbitration service. Props for finding that JPM doc, immensely valuable for the insights it brings: - 63% of buyers were private companies <- API needs to aim wider than just banks
- 13% of all transactions were cross-border <- does that represent an opportunity?
- 76% of escrow agreements specify a termination date, 18 months is the most prevalent <- service must be an emergent property
- 79% of escrow agreements have an explicit clause dedicated to the claims process <- Beware, here be monsters
- Over 70% of cash deposits were invested in Interest-Bearing Accounts <- PoS implementation required?
- 30% of all terminated deals had at least one claim, most commonly for purchase price / working capital adjustments <- so, might be do-able
My disciplinary interests start to kick in when I consider the representation of the semantics of an arbitrary "explicit clause dedicated to the claims process" because it's an unsolved problem. Where semantics are concerned, there's still a ways to go:  However, I'm hopeful that something can be done, albeit with a deeply impoverished service. fwiw, I have been able to make some progress in the domain of transparency data published by the UK Parliament and marked up with HTML. If that sparks an interest, there are a couple of related impress.js slide presentations in the list of owl-o-parl tours. The first is for general context of the effort. The second attempts an accessible description of how the site applies semantic web technology to turn a wall of text into separate facts (well, that's the intention, I'm still polishing the content). If a similar technique can successfully be applied to 80% of escrow agreements (and JPM's reference to template agreements suggests that there's some mileage there at least), then we're in with a fighting chance of making it computationally tractable, hands-off and trustless. Cheers Graham |
|
|
|
a start down the road might help to clarify and then define the end point.
Unfortunately, it's not going to be quite so easy as that: Persons or companies performing escrow services over the Internet in California, or performing escrow services for consumers in California, must comply with the licensing requirements of the California Escrow Law. The licensing and regulatory process ensures that companies' owners and key employees have been subject to background checks performed by the California Department of Business Oversight, that the company's financial condition and records are adequate, that the company is properly bonded, and that all customer funds are segregated in trust fund accounts until the terms of the escrow are met.
The service must be framed in a way that renders inapplicable the legal definition of escrow. Cheers Graham |
|
|
|
There should be no reason, that I can think of, why you can't introduce an API for banks to link to the SPR servicenode escrow service.
I tend to agree, there's no operational reason, per se. But that's just one element, there are other important aspects to be considered. To get an idea of what kind of escrow services are currently provided and who might be expected to use them, see: https://www.jpmorgan.com/pages/cib/escrow/overviewarms length multi-sig party
That's the fella, an API to cheap, commodity escrow. The concept is proven, the key issue now is whether to focus on the entire market spectrum or develop a tenable niche. Cheers Graham Edit: expanded slightly |
|
|
|
We want to share our shine with people around the world and we think is as a big opertunity to do so.
You're going to be disappointed. In Ireland, the brewing and sale of spirits requires a license. You can be forgiven for not knowing that fact, you not being Irish. Cheers Graham |
|
|
|
I really need someone with equal or better qualification to do a code review and correction just in case i made mistakes, working alone means there are times i can make mistakes and not pick up on them. There are bounties for this.
It might help if you were a bit more specific about what you're expecting to see for the money. Cheers Graham |
|
|
|
C'mon whats wrong with it this time?
Dunno yet, but please add it as an issue ticket to the spreadcoin github repos: https://github.com/spreadcoin/spreadcoin/issues so that any consequent technical discussion has a half-decent chance of remaining coherent. Cheers Graham |
|
|
|
@gjhiggins: Did you see any of the coding ?
I don't seem to have received an invitation, that's all I know. Cheers Graham |
|
|
|
Lets launch a crypto symbol standard, rather than having to work to the existing international currency standards (fuck'em).
Done. See the repos maintained by github org DOACC. To set the context: this is the core of the existing international currency standard 4217: ISO 4217ISO 4217:2008 specifies the structure for a three-letter alphabetic code and an equivalent three-digit numeric code for the representation of currencies and funds. For those currencies having minor units, it also shows the decimal relationship between such units and the currency itself.
fragment of XML rendering: <ISO_4217 Pblshd="2015-01-01">
<CcyTbl>
<CcyNtry>
<CtryNm>AFGHANISTAN</CtryNm>
<CcyNm>Afghani</CcyNm>
<Ccy>AFN</Ccy>
<CcyNbr>971</CcyNbr>
<CcyMnrUnts>2</CcyMnrUnts>
</CcyNtry>
<CcyNtry>
<CtryNm>ÅLAND ISLANDS</CtryNm>
<CcyNm>Euro</CcyNm>
<Ccy>EUR</Ccy>
<CcyNbr>978</CcyNbr>
<CcyMnrUnts>2</CcyMnrUnts>
</CcyNtry>
...
</CcyTbl>
</ISO_4217>
The cryptocurrency domain has DOACC (Description of a Cryptocurrency), an exhaustive collection of metadata about cryptocurrency (incl trading symbol) supported by a couple of accompanying ontologies ( DOACC and CCY) that precisely define the metadata terms (e.g. “symbol”) using a computationally-tractable representation (OWL). The project maintains an RDF graph representation of the metadata for over 2000 altcoins. The metadata description and the collection are under an open source licence and use a purl.org URL (group-owned eventually, if'n'when purl.org admins allow). Minkiz presents the DOACC graph as a Linked Open Data that is both browsable: https://minkiz.co/page/Repository/Da0770ce7-0c77-4295-b225-a54a277a7828and queryable as a SPARQL endpoint. Try pasting the query below into the text box on https://minkiz.co/sparql, it'll return the DOACC URI, name and symbol for the first 25 coins, ordered by symbol: PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX doacc: <http://purl.org/net/bel-epa/doacc#>
SELECT ?node ?label ?symbol WHERE
{ ?node skos:prefLabel ?label .
?node doacc:symbol ?symbol .
}
ORDER BY ?symbol
LIMIT 25
or use this canned query linkCheers Graham |
|
|
|
for a LOGO, i'd suggest this :  Even if it's a jocular suggestion, there are better choices than bilious green. Bitcoin uses an almost identical icon for testnet wallets:  Perhaps some inspiration could be found in thinking about which aspects of the brand identity could/should be communicated by the logo, assuming that is a consideration. Cheers Graham |
|
|
|
|
Show Posts
