Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ
Ξ We've updated our CA certificate. All members need to be using the latest ones by Dec 22. See this page for more infoΞ

stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

This subforum is both a place to find & discuss independent cryptostorm token resellers, as well as to discuss cryptocoin related topics such as buying bitcoins, altcoins such as darkcoins and dogecoins, "tumbling" coins, theoretical/mathematical topics, etc.
User avatar

Topic Author
cryptostorm_admin
ForumHelper
Posts: 74
Joined: Tue Jan 01, 2013 5:43 pm
Contact:

stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby cryptostorm_admin » Thu Feb 05, 2015 7:55 pm

{direct link: cryptostorm.org/stormcoins}


As cryptostorm's membership base has grown, and the open-ended, decentralised components that together constitute cryptostorm have each seen smart and creative people begin thinking about and making use of them in new and often unexpected ways, novel circumstances have come up that have challenged us as a team to determine the "official" policy that best meets member and community needs.

We put official in "scare quotes" because it is the fundamental nature of the ecosystem we've sought to engender with cryptostorm that even the core project team really is not a unitary source of hegemony or operational authority over use-case questions. We generally illustrate that by using as example a question we're often asked: do we allow token resales.

To answer that question, one is best served by stepping to a meta-question: do we have any functional ability to exercise control over whether someone does or does not do whatever she wants with her token in the first place? As the answer to that question is obviously no, there's no point in asking whether we prefer to "allow" such events to occur or not; it's like asking whether we allow water to be wet, or the sky to be blue.

This is not an accident. We have sought intensively to shift functional agency over as much of the use-case elements of cryptostorm to the membership community as possible. This is done not out of some Randian besottedness we've developed after too many long debugging sessions, but rather fundamental opsec: get rid of the items that make no operational difference to crucial security matters, so that one can focus one's attention and resources on those items that truly do. We thus by far prefer to be out of the business of doing as many things as possible, so that we can be uniquely intent on those matters that require us to do our jobs well, do them reliably, and do them with clarity of purpose.

Here's some useful deductive outcomes that flow from these first principals:


token sales: cryptostorm as facilitator

A very small number of aleph 'lifetime' cryptostorm tokens have been minted and distributed over the years. Some are now being resold between private parties. To help solve the trust problem implicit in such transactions - there's incentive for infinite "double-spend" in a digitally-based asset, with the seller continuing to use the aleph even after the buyer has taken "control" of (a copy of) it - we've acted as a trusted facilitator for such transactions, and we're happy to do so with others upon request.

We take possession of the aleph from the seller, and then excise the hashed value of it from the production auth engine. Once done, we distribute a newly-minted aleph to the buyer. In this way, the buyer knows the seller doesn't have a copy of her new aleph, and the seller has confidence from the buyer that this will not be a problem - thereby enabling the market for aleph resales to enjoy a stable foundation. This, in turn ensure that alephs are not degraded by problems associated with double-spend, and keeps their value as long-term access keys to cryptostorm's full-bore network safe and in full effect.

We can do this facilitation for non-aleph token sales, as well. If you have such a request, let us know. If enough such sales request transaction facilitation, it would not be complex to automate the entire process and thus scale it arbitrarily to high volumes. We can also act as no-fee financial escrow agent for such transactions, if that's of use.

In sum, we're strongly supportive of the existence of a transparent, honest, low-friction, widely-accessible token resales market. Anything we can do to support that goal, we'll make our best efforts to do. If you've ideas in that regard, or a request, please don't hesitate to let us know - this is an area of evolving best-practice and many opportunities for the cryptostorm ecosystem overall.


token refreshes

From time to time, we are approached by token holders who have concerns that their token may have been copied or its security otherwise compromised, either because they have firsthand knowledge of such a circumstance or because they've tried to access cryptostorm and found that their hashed token is show by our authentication engine as already in-use. Additionally, we receive from time to time requests from token buyers to 'replace' tokens that have been verifiably lost to the seas of pure entropy: hard disk crashes, accidentally deleted emails, and so on.

Let us repeat a core element of our member security model, first, to remind of that foundational plank: CRYPTOSTORM DOES NOT RETAIN ANY COPIES OF TOKENS, AND ABSOLUTELY WOULD NEVER KEEP A 'TOKEN DATABASE' CONSISTING OF, PREVIOUSLY-DISTRIBUTED TOKENS. There is no such database, or list, or file. It is true (at this point) that we cannot offer independently verifiable proof of this assertion. That's frustrating to all involved, and if someone reading this has a clever idea to enable such a proof, we'd love to hear from you (our own in-house crypto theorist is convinced there's an elegant, mathematically provable way to do this... but we've yet to see him come up with pseudoocode demonstrating that functionality). And, in general, proofs-of-negation are deeply logically problematic: prove that you've never visited Antarctica, for example.

That said, we know we don't have such a database. We have an entire newly-minted token inventory management procedure designed to eliminate the risk of double-distribution (it's an issue, and surprisingly challenging to avoid), as well as the heavily complexity-pruned minting process itself (if anyone's interested, there's nothing secretive about it) which puts the probabilities of tokens generating hash clashes into the very low numbers. Basically we have single points of control over tokens at every step prior to distribution. Once it's distributed, it's coy out of the 'tokenstash,' pasted into the delivery vehicle, and that's that. This does a tremendous job of preventing double-distribution, and also means we never have to have concerns about "accidentally" retaining copies of tokens. (there are some corner state retentions that happen, which we've not been obsessive about closing out thus far: sent message archives in email systems, and the inevitable durability of sent bitmessages is immutable without a routine cycling of private keys - impractical currently - so there's some traces of token distributions here and there, full disclosure).

Thus to have such a database of tokens would both be terrible security procedure for our members, and open us up to targeting by anyone who wants to find out who owns a given token. We simply don't know - that's that. It's a nice congruence that eschewing any such system means our double-distribution concerns of newly-minted tokens are nearly totally eliminated. (there's still race-condition issues we have to deal with, and we have).

Which is to say that we can't replace lost tokens, because we don't have them. We may recognise someone as a token buyer - the fellow who sent from a given bitmessage address (though that doesn't prove identity), or the twitter member with the cool avatar, etc. We still don't have her token. What we often do, irrespective, is just issue a new token on the word of our members. We've done that for years, and really I don't think we'll stop doing it. The number of tokens we reissue is tiny, and if anyone is that desperate for a token that they can't afford one thus must try to trick us into giving them one, we ask they simply tell us and we'll donate a token (or they can use cryptofree, of course).

This procedure doesn't work for longer-duration tokens: people showing up to ask for aleph tokens to be reissued because 'lost' could get out of hand pretty quickly.

Fortunately, a cryptographically robust solution presents itself. While we don't keep copies of tokens, of course we do keep SHA512 hashed transforms of them, to be used in network auth. Our decision to do the one-way transform from tokens to hashes prior to production use was made based on numerous theoretical and functional considerations, and in this case it has proved useful again.

If someone comes to us with concerns that their hashed token has been compromised, we've an easy procedure to confirm they are the current holder of the token itself... even without having a copy of that token, ourselves, or any record of who bought it. As a trusted outside party, we ask that person to present for us both the token and the hash. If they have the token, of course they can generate the hash. But if they have only the hash - having grabbed it off a screenshot or some such - they cannot provide the token that generates the hash. We need not know that token value in advance, at cryptostorm, to confirm or deny they have the "right" token.

Thus when anyone who comes to us with a token ad requests it, we can 'refresh' the token - we will excise that hashed token from the auth engine across the network, and replace the token. The best we can do right now is a token of similar duration (or a bundle of tokens of smaller durations that add up to the correct amount) - it might not be synched to the day to the previous/excised one. However, if this becomes a popular thing (close readers will surely see why that might be the case; we leave that to others to enumerate more fully in print), it's another feature that would be easy to automate.


Since early in cryptostorm's development, smart folks have looked at our tokens and seen either echoes of bitcoins, or a form of alternative currency. Both are correct in some respects, and poor metaphors in others. We do expect to be writing tokens to the blockchain fairly soon, for a secure distribution method - and some on our team are insistent that alephs themselves should be written to the main BTC blockchain to solve elegantly the "double-spend" problem referenced above. That may happen; the only constraint is the low number of alephs in circulation, and likely to ever be in circulation.

In terms of currency, tokens have interesting and perhaps difficult attributes: they expire... but only once used to auth to the network. So pre-auth'd tokens could indeed be written to a sidechain and traded (perhaps they already are - we'd not know if so, unless told)... however when they drop off the shelf and begin to erode towards expiry, they're a... strange kind of currency. Then again, economic theorists might simply model that as a form of inflationary pressure - common in every financial system humans have devised thus far. Who's to say?

In the end, our tokens exist to enable robustly private authentication to cryptostorm's network, first and foremost. They may display emergent properties as quasi-currencies, alternative identity validators, or anything else. Unless those use-cases are directly and irreconcilably opposed to the goal of keeping cryptostorm members secure and connected, we'll not do anything to hinder them... and more likely than not actively encourage them.

Best regards,

~ cryptostorm admin
cryptostorm_admin - a mostly-shared, admin team forum account (sort of a person, but also shared)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

sample aleph transfer facilitation language

Postby cryptostorm_team » Thu Feb 05, 2015 8:07 pm

Here is the language used in the aleph transfer process:

Greetings -

We've been asked to act as transfer agent in the sale of a cryptostorm aleph token. The token being transferred to you has been marked as returned to minting pool, and your newly-issued aleph token is:

{newly-minted aleph}

Please do not lose it, as it cannot be replaced. We suggest you encrypt it with a good passphrase, and store its encrypted container in a couple of free "filesharing" sites such as mega.nz - then if you need to prove ownership of it in the future, you can pull a copy from cold storage and generate the SHA512 hash if requested.

Cryptostorm does not keep a list of aleph tokens sold - or any tokens sold. Production nodes each contain an independent copy of the hashed tokens minted thus far; without the token itself, reversing these hashes is very, very difficult. Someone getting ahold of your hashed token can use cryptostorm for free, but if you want to contact us (as an impartial intermediary) and prove ownership of the token itself - not just the hash - you can show us the token securely, and we can verify that the token generates the hash. With that, we could expunge the compromised hash from the production systems (a manual process, and one we'll only do after token-ownership validation as per above), issue you a newly-minted aleph, and you're back to unique control over the hash.

However, if you lose control of the token itself and someone else can meet this forward-hash challenge, they will be able to expunge the production hash... and the first one to do that has sole control of the replacement token.

Here are the details regarding your aleph email account:

email user: {identifier}@CRYPTOSTORM.IS
email pass: {password}
IMAP IN: mail.cryptostorm.is - port 993 (SSL/TLS)
IMAP OUT: mail.cryptostorm.is - port 465 (SSL/TLS)
WEB ACCESS: https://cryptostorm.is/m

If you've any troubles with it, let us know. They run on the same production mail systems as our in-house team, so we're pretty familiar with its inner workings. Note that, via webmail interface, you can cycle your own password without our involvement. For obvious reasons, we suggest you do so once you have control of the account.

Congratulations on becoming an aleph holder.

Best regards,

~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

vpnDarknet
Posts: 128
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby vpnDarknet » Fri Feb 06, 2015 3:44 pm

Hi guys, apologies I've been non active on the forums & twitter feeds since before the New Year, but I'd just like to acknowldege that this statement stands for me too:

CRYPTOSTORM DOES NOT RETAIN ANY COPIES OF TOKENS, AND ABSOLUTELY WOULD NEVER KEEP A 'TOKEN DATABASE' CONSISTING OF, PREVIOUSLY-DISTRIBUTED TOKENS.

I do not keep track of which token has been sent to which buyer, all records of tokens, including emails & BitMessages are deleted.

I, and certainly Cryptostorm, do not know, or care, who is using what token when
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby parityboy » Fri Feb 06, 2015 5:45 pm

@OP

In terms of currency, tokens have interesting and perhaps difficult attributes: they expire... but only once used to auth to the network. So pre-auth'd tokens could indeed be written to a sidechain and traded (perhaps they already are - we'd not know if so, unless told)... however when they drop off the shelf and begin to erode towards expiry, they're a... strange kind of currency. Then again, economic theorists might simply model that as a form of inflationary pressure - common in every financial system humans have devised thus far. Who's to say?


This is very interesting (at least to me). How much value could a (for example) a full speed, 1-day token have? Probably zero...unless...the Cryptostorm network offered some kind of "token freezing" service. On an anonymously-accessed secure network, a 24- or 48-hour full-speed token might actually have some value over and above that of the Cryptofree service.

Would this be doable technically? Absolutely - in MongoDB just add another column - FROZEN true|false - and adjust your query accordingly. Allow such a service to be accessed via a Web API (with a valid (and possibly paid-for) API authentication token of course), and this would allow resellers to "freeze" a token (maximum 7 days left) and sell it on. The token could then be unfrozen simply by trying to authenticate with it - this would be the simplest method. Or, it could be unfrozen simply by using the freezing service without a valid API key.

These are just ideas, and there are still security implications. For example, I've not addressed the "double spend" problem. However, it would be interesting to see if out of the ideas on this page there evolves a trading platform where 24-hour and 48-hour tokens are considered to be "hot" items (for whatever reason).


mart-e
Posts: 18
Joined: Thu Jul 02, 2015 5:07 pm

Re: stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby mart-e » Sat Sep 12, 2015 6:30 pm

Sorry for the digging of old post but you claim not keeping a list of distributed token. Ok I can believe you but then the question is : what do you keep?

I mean, how do you know that the hash I give you comes from a valid token and not an outdated token or something made up ?
To do so the only solution I can find is that you keep a list of hash with the validity. If that's true, how is it different than keeping a list of token? You could still make things like revoke access.
I guess I've missed some part of the crypto-process of the tokens authentication. Can anybody enlighten me here ?
Thanks

User avatar

parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby parityboy » Tue Sep 15, 2015 9:20 pm

@mart-e

When tokens are minted by the CS team, the hashes of those tokens are injected into the database sitting on each node; the hash is what you authenticate against.

As far as the tokens themselves, obviously the token (in its original form) has to be kept somewhere until it is sold, either to a customer or to a token reseller. I can only assume that once this process is complete, the token (in its original form) is deleted by the CS team.


mart-e
Posts: 18
Joined: Thu Jul 02, 2015 5:07 pm

Re: stormcoins: cstorm facilitation of token resales, token hash excisions, & token refreshes

Postby mart-e » Fri Sep 18, 2015 3:43 am

@parityboy

Ok, I read @cryptostorm_admin's message again and I now understand it says they don't keep a list of tokens but they do keep a list of hashes.
So of course they can do things like revoke hash (then the linked token) or regenerate a new one if you can show you own the initial one. Just not keeping the list of tokens reduce the link between the payment and the connections.


Return to “independent cryptostorm token resellers, & tokens 101”

Who is online

Users browsing this forum: No registered users and 6 guests

cron

Login