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 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22
211
General Discussion / Re: When will the full wallet work better?
« on: January 05, 2015, 04:16:41 pm »
I'm using it to test bitshares-js which is more of the web wallet.  As I see things I will try to fix them and let everyone use it on devshares.  It will take a while, I have to craft up all these transactions in JavaScript first (as the priority) then I get to use them in the web_wallet as part of the testing.  At that time I have a chance to make it better and ultimately put that back into the desktop.  This is just me, others may have there own plan too.

212
General Discussion / Re: Am I being selfish?
« on: January 05, 2015, 02:19:44 pm »
So when next bull is here you will bask in the glory exagerating the claim that you called it/caused it? :)

I agree and to sum up think positive and the outcome will be positive.

Yes (in a very humble way), It goes both ways though... Actually I hope for tame bulls and even predictable markets!

213
General Discussion / Am I being selfish?
« on: January 05, 2015, 01:48:08 pm »
this post deleted... I can do better..

214
General Discussion / Re: The worth of Stan's contribution to BitShares
« on: January 05, 2015, 01:54:49 am »
 

**Full disclosure, BM does not own a dog.  I'm using another metaphor.  :D

I recommend the all loving Poodle...

It was an easy decision to vote for Stan and Dan. 

215
DevShares / Re: Wow, is Devshares ready?
« on: December 27, 2014, 01:59:39 pm »
I have a node running but no connections, I assume the network is not live yet.  Anyone know when we will be live?

216
General Discussion / Re: Introducing BitShares Object Graph
« on: December 25, 2014, 03:39:11 am »


C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
CoffeeScript is even easier.  It is basically 1 for 1 with JavaScript and gets rid of most of the unnecessary work. 


217
General Discussion / Re: Introducing BitShares Object Graph
« on: December 25, 2014, 03:23:04 am »
It is a start: http://neo4j.com/blog/prototyping-a-graph-database-rvb-2014/   I would like to see more examples..

218
It is all true.  I would add your very flexible, easy going, and open to a variety of ideas... + eats healthy .. I have voted for you!

219
Code: [Select]
wallet_account_transaction_history
  account_name (string, optional, defaults to "")
  asset_symbol (string, optional, defaults to "")
  limit (int32_t, optional, defaults to 0)
  start_block_num (uint32_t, optional, defaults to 0)
  end_block_num (uint32_t, optional, defaults to -1)

This call returns a list of transactions for a given account or multiple accounts in the wallet.  Included in each transaction entry is an array of running_balances.  The running_balances array is just how it sounds, a running total of the accounts balance just like what you would see on your bank statement:

Code: [Select]
TRANSACTION AMOUNT BALANCE
alice to bob +5 5
bob to alice -5 0

When I'm viewing just bob or alice, this list makes perfect since and this is just what the API does.

The confusion comes in when one starts with a higher block number (after alice transfers money to bob).  Currently the API will return this:

Code: [Select]
TRANSACTION AMOUNT BALANCE
bob to alice -5 -5

I would say, that is not correct, it should instead return this:

Code: [Select]
TRANSACTION AMOUNT BALANCE
bob to alice -5 0

Finally, there is one more consideration and this one is probably optional.  I do however see that with security like multi-sig is will be safer to have have larger wallets with more accounts.  So, when querying in a large wallet for say 100 accounts (or leaving the account_name empty), currently each transaction return will have a `running_balances` return for all accounts in the wallet.  Think about your bank statement, running balances only make since when your looking at a single account at a time.  I'm not aware of any case where you want to see all of these running balances together unless your intent is to cache them and report them as single accounts at a time.  If your going to cache them and group into single accounts then it should be trivial to collect up all the smaller balance records from separate transactions and total them.  In other works, each `running_blanaces` array should only contain balances for the accounts involved in that transaction.

This is one test ledger entry from "GENESIS" to "delegate44" as returned by `wallet_account_transaction_history`:

Code: [Select]
{
    "is_virtual": true,
    "is_confirmed": true,
    "is_market": false,
    "is_market_cancel": false,
    "trx_id": "f85054558d6c2ad7fb1021455109817ad3dfc7a1",
    "block_num": 0,
    "ledger_entries": [{
        "from_account": "GENESIS",
        "to_account": "delegate44",
        "amount": {
          "amount": 1980198019801,
          "asset_id": 0
        },
        "memo": "claim PjETkso5HWNvUp5PusP8nufyv192aMe2Ph",
        "running_balances": [[
            "alice",[[
                0,{
                  "amount": 0,
                  "asset_id": 0
                }
              ]
            ]
          ],[
            "bob",[[
                0,{
                  "amount": 0,
                  "asset_id": 0
                }
              ]
            ]
          ],[

220
Stakeholder Proposals / Re: Delegate Proposal: elmato
« on: December 21, 2014, 01:43:02 pm »
 +5% voted .. Remember me after you get to the top!  O yea, also remember those price feeds too.  Let me know if there is anything I can do in bitshares-js to make it more mobile friendly.

221




Hey guys,

I have reworked everything and made a bitshares payment gateway (called it Bitshares Checkout)... I implemented the ecwid cart implementation but the checkout system will be standalone so anyone can integrate with it.. they just have to follow the "API" and implement the 4 or 5 php files I put in the integration folder. I will reuse it to do the rest of the carts, so look and feel will be the same on all implementations.

here is the source again for the ecwid: https://github.com/sidhujag/bitshares-ecwid

here is the demo: http://bitshares.ecwid.com

Go ahead and create a fake order then it will take you to the checkout for bitshares... you can pay via BTS and will be credited for BitUSD orders for testing. I will send all coins back anyways.

Eventually, it would be nice to have a seed list of public bitshares api clients the same way the native clients do it.  I planning to implement this in JavaScript.  We will need everyone to consider a new bitshares_client configuration parameter to enable CORS.  I think this will greatly simplify your plugins.
Ive expressed this to bm about cors already on the http port.  CORS would allow us to load the wallet via the web... can we do everything safely in jslib? You have other usecases in mind?
The plugin must run on the client computer because it will access their wallet to poll for transactions.. did you try the demo?

Maybe by the new year we can take your URL on a hosted web wallet, let them pay then come back to the commerce site.   

Is the fruit organic?  I would like to buy some with DevShares.
Heh its a demo shopping cart.

So a hosted web wallet would be backed by rpc node? Or fully emulated?

I was thinking to host it and make a call thru jslib to get the url of the account which I assume isthe merchant website url.. this way merchant would setup their account thru their wallet and then use a hosted gateway.. And loading the gateway I only meed to pass in orderid/hash and accountname to lookup url via rpc (jslib) since we prob wont support php

Yes...  Public calls like blockchain_get_account can go directly to a full node.  Jslib does not manage node lists right now.  I am implementing some calls that start with wallet_....

222
Thinking about this more... We can do the following:

Merchant would copy bitshares php lib and php integration files in cart folder

The gateway can be hosted anywhere and doesnt depend on rpc.. it will call the php integration callbacks.

The url of the merchant must be specified when accessing thr gateway.

Eliminating the rpc requirement would be a big win, but I suspect it's not eliminated but rather is used within the php lib.
Maybe using js lib... not sure if its a full node port or it needs rpc itself
The plan is that jslib will need only public RPC calls.   And as you have probably guessed it has to manage private keys so having a source code audit trail it's very important.

After I get all the pieces put together I have more time to research our options.

223


Hey guys,

I have reworked everything and made a bitshares payment gateway (called it Bitshares Checkout)... I implemented the ecwid cart implementation but the checkout system will be standalone so anyone can integrate with it.. they just have to follow the "API" and implement the 4 or 5 php files I put in the integration folder. I will reuse it to do the rest of the carts, so look and feel will be the same on all implementations.

here is the source again for the ecwid: https://github.com/sidhujag/bitshares-ecwid

here is the demo: http://bitshares.ecwid.com

Go ahead and create a fake order then it will take you to the checkout for bitshares... you can pay via BTS and will be credited for BitUSD orders for testing. I will send all coins back anyways.

Eventually, it would be nice to have a seed list of public bitshares api clients the same way the native clients do it.  I planning to implement this in JavaScript.  We will need everyone to consider a new bitshares_client configuration parameter to enable CORS.  I think this will greatly simplify your plugins.
Ive expressed this to bm about cors already on the http port.  CORS would allow us to load the wallet via the web... can we do everything safely in jslib? You have other usecases in mind?
The plugin must run on the client computer because it will access their wallet to poll for transactions.. did you try the demo?

Maybe by the new year we can take your URL on a hosted web wallet, let them pay then come back to the commerce site.   

Is the fruit organic?  I would like to buy some with DevShares.


224
Hey guys,

I have reworked everything and made a bitshares payment gateway (called it Bitshares Checkout)... I implemented the ecwid cart implementation but the checkout system will be standalone so anyone can integrate with it.. they just have to follow the "API" and implement the 4 or 5 php files I put in the integration folder. I will reuse it to do the rest of the carts, so look and feel will be the same on all implementations.

here is the source again for the ecwid: https://github.com/sidhujag/bitshares-ecwid

here is the demo: http://bitshares.ecwid.com

Go ahead and create a fake order then it will take you to the checkout for bitshares... you can pay via BTS and will be credited for BitUSD orders for testing. I will send all coins back anyways.

Eventually, it would be nice to have a seed list of public bitshares api clients the same way the native clients do it.  I planning to implement this in JavaScript.  We will need everyone to consider a new bitshares_client configuration parameter to enable CORS.  I think this will greatly simplify your plugins.

225
DevShares / Re: Wow, is Devshares ready?
« on: December 20, 2014, 12:12:11 am »
I love it: "theft is legitimate" given our goal is to produce trust less systems.  This is the way to go.

Since we claim the shares with real private keys, we should mention that theft of any private key is not allowed.

Or a design so we don't use a real private key....

Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22