Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jamesc

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 22
How about a random sharedrop date based on 1 minute of text captured during a public mumble session?  This could be independently verified by a few of us.  I included some directions below.

Code: [Select]
/* <- ignore, this is a JavaScript comment
 * Paste the text including "cat" to "done" into a Unix shell.  You should get the same hash below.
cat <<-done | sha1sum
<replace with 1 minute of mumble comments from a public session>

d062f0e592f0f8286dc2da3eeba2dff2ee1d604d  -
 * You can copy paste this entire script (comments are optional) into `node` to
 * get a share drop date..  You can do the same thing live using any JavaScript
 * runner.  I created a very fast quick and dirty runner here:

var begin_date = new Date("Wed Aug 19 2015 13:00:08 GMT-0500 (CDT)")
var end_date   = new Date("Wed Dec 19 2015 13:00:08 GMT-0500 (CDT)")
var hash = "d062f0e592f0f8286dc2da3eeba2dff2ee1d604d"

var random_seed = parseInt(hash.substring(0,4), 16)
var random_max = Math.pow(2, 16)

// random_multiplier is a decimal number between 0 and 1 (or very close)
// For example:  0xFFFF / Math.pow(2, 16) == 0.9999847412109375
var random_multiplier = random_seed / random_max

var offset = end_date.getTime() - begin_date.getTime()

offset *= random_multiplier

var share_drop_date = new Date(begin_date.getTime() + offset)

var output = {
//random_max: random_max,random_seed: random_seed,random_multiplier,
share_drop_date: share_drop_date


//  Given a begin date: "Wed Aug 19 2015 13:00:08 GMT-0500 (CDT)"
//  An end date:        "Wed Dec 19 2015 13:00:08 GMT-0500 (CDT)"
//  And a chat log hash of d062f0e592f0f8286dc2da3eeba2dff2ee1d604d
//  You should get   {"share_drop_date":"2015-11-27T01:22:50.304Z"}

Next issues are front running (you pay more for feeds that are closer to real time). 

Also pricing errors (even happens to MSN), transactions are not reversible.


Can you ask @bytemaster if he is implementing @starspirit no. 2 of bitAsset valuing in the hangout tomorrow.  And if we are still 3 months away from 2.0 if we are three months away I will start a bounty.

Thank you each individual for your contribution to this thread and for kind words.

It's up to the feed producer and has can be enabled immediately out the gate with bit shares 2.0 presuming it delivers on what it promises
You could publish the value price in the feed with all adjustments baked in.   It doesn't have to match the real price it just has to be correct and verifiable.

There is the stock split too.   It is actually a real challenge/expense to get the detailed dividend and split data required without having rounding errors (which compound over time) or violating someone's terms of service.   It is as if we have the new technology and that it is better if we support companies that upgrade.

Dividend feed?

Did you children sell your bitcoins a few years ago when they went down from $30 to less than $2?

I didn't.

I bought more.

And I sold them later at $800 each (to buy BTS)

And I am buying more BTS now.
I call this value investing. Well done!

General Discussion / Re: Announcing Brownie Points (BROWNIE.PTS)
« on: July 03, 2015, 12:59:43 am »
This is Fun....  I program BitShares web wallets.   : slim180

General Discussion / Re: Trust Me With Your Private Keys Please
« on: June 16, 2015, 02:04:00 am »

But we should always keep the ability to have and control our own.

2 of 4 active...  You can still have the owner or owners which typically are cold wallet keys..

I'm not disagreeing, just saying people should also have the option to be the sole controller of their accoun.

I see...  You can do this.   This is in the transaction format.  The wallet is going to allow any valid transaction.

I would use some frozen code like a plugin or a cold wallet to sign transactions as the sole owner but make 3 private key owners.   Before I put any money there I'd have backups off site, next of kin.   I would probably use 2 of 3 three there so someone lost my wallet I wouldn't lose my funds.

General Discussion / Re: Trust Me With Your Private Keys Please
« on: June 16, 2015, 01:47:23 am »

But we should always keep the ability to have and control our own.

2 of 4 active...  You can still have the owner or owners which typically are cold wallet keys..

I would like to see the transfer transaction have an optional account name "to" field.  Because the transfer transaction can also have an account id, it should also be provided and validated when ever possible.

Bytemaster (in github) noticed a few other operations where this might be useful.  I looked into and, well, lets say it started expanding into a lot of other what-ifs...  So, that is getting complicated.  Lets remember we can do things off-chain...   

One case jumps out at me, btercom vrs bter.  This is a real loss.  The BTER exchange registered "btercom" but some other entity registered the shorter name bter.  Sure enough, a user sent money to the wrong address.  It was not good, this user was just getting into BitShares and this was there initial investment. 

So, here is the new hypothetical story... creates there new account "examplecom".  When they do, their wallet hashes that name adding 3 base58 encoded characters to the end.  Now, there safe name would look like this:


Also, assuming this is not a cold-wallet, the wallet will also grab examplecom's account id which is say 37,521 (current registered accounts on BitShares).  Finally, 3 more chars are added which is a check for both examplecom and the encoded account id.  Note, this is the actual length with fake checksums:


This becomes useful in anyplace where we use an account ID (for example: active and owner signature authorities).  If the ID is not known a shorter version may be used (just examplecom_8d8).  It should still be possible in every case to simply use examplecom.

The identicon should remain unchanged on the account name, this gives the cold wallet the ability to show a matching identicon even though it can't lookup the account number.

I used an _ because that most often lets one double-click and select the entire name.  An underscore is not allowed in a BTS account name.

btw: did you notice, I really typed two 'l's in the example .. complete accident I promise...  If only exampllecom_8d8 was provided, the computer would catch the mistake in all but 1 case in every 190K cases).

General Discussion / Re: The BitShares Hosted Web Wallet is ready...
« on: June 10, 2015, 01:14:13 am »
Same output  :-[
Have you used a number > 10 .. maybe 100 or so?
Do you use the exact same "wallet" as you used when you created your account?
maybe also try a second optional parameter like 2000

The hosted wallet does not recover numbered account in the same way as the desktop wallet.  Even though the hosted wallet uses a sequence it is not the same hash.  This is really only because the c++ code is amazingly complex in the way that was done (well easy to do in c++ but not so easy to re-create or debug).  I got close but never got it right.  We finally just moved on based on good advice and the idea that this was all gonig to be re-written (graphene, yea!!).  So, I just used some more of Nathan's great ideas and added a simple hash and the counter.  The hosted wallet differs a bit, there is no large number involved your really not scanning much.  It just counts and checks every step of the way.  You really can't skip numbers.  It is straight forward so there is no number exposed in the API, it is done behind the scenes.

There is a Wallet Advance feature where you can try to recover an account by its name.  This is a light-wallet account or, for a 'very' short period of time, the hosted wallet used the account name in that hash I mentioned above.  In any case, you may gain insight by using it.  If you try to recover an account by name that was not created with your recover key you will see something like this 'can't recover, this account is not owned by this wallet'...  So, this would confirm you need to check the recover key.

General Discussion / Re: The BitShares Hosted Web Wallet is ready...
« on: June 10, 2015, 01:05:12 am »

Question: is there a way to select my own Recovery Key rather than the random one thats automatically generated?

I'm sure there is, i just dont see it.

it's only possible with the console version of the client:
wallet_create <wallet_name> <new_passphrase> [brain_key] [new_passphrase_verify]                     

but I would not recommend using a brain_key unless you REALLY REALLY REALLY know what you are doing!!

Just use "Recover Wallet" and type anything you want.. yes, you really should limit funds if you start doing that or better yet run some numbers and share.  I use simple keys for my test accounts which will be transferable to a stronger key later in Graphene.   At least the wallet gives us a hint what the a proper strength should be (we did some math and compared it to the industry standard)...  Of course, keep in mind, this is a server hosting js files that creates the key.  We really have to do better than this; we just need that key created in a format where the source code can be frozen or ran in cold storage.  So, you can at least see what a retirement strength key should look like..


2. the internal webwallet should give some hints in regards to naming. just tried it and the faucet gave me a "only cheap names can be registered please choose another one" - BUT the webwallet wouldn't let me add another one until the first is registered.

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 22