I started off by making this docker build box: https://hub.docker.com/r/sile16/graphene-build/

After that I thought, it can't be too hard to automate the build process so when a new commit hits github I'll run the build capture the output and print to html.  Took about 10 times longer than it probably should but here it is:

https://www.everydaycrypto.com/?page_id=107

Every 5 minutes my server checks for a new commit, will download build and update the webpage with the results.  It also builds docker images once a day for the witness node and cli, but those aren't quite ready for use as I still need to tweak the docker configs to allow the correct ports through etc.  But theoretically i'll be able to deploy witness nodes from the auto generated docker images:

https://hub.docker.com/r/sile16/graphene-cli/
and
https://hub.docker.com/r/sile16/graphene-witness/

Once we actually have a taged release on github for graphene those tags should propagate into the docker image as tags.   I'd like to do this for the testnet / devshares as well but not sure what github repo will be used for that whether bitshares/devshares will be used or cryptonomex/devshares   ... 

I'm new to all this docker stuff so if you have a good idea how to make it better let me know.

Oh,, and all the code i'm using the automate the build process is at: https://github.com/sile16/bts2

I'm sure someone is going to tell me you can do this with jenkins in like 2 lines of code or something.....  hahaha

On today's dev hangout Dan made the comparison between graphene and ethereum.  Ethereum is an interpreted language and anyone can submit and start running code.  Whereas, graphene is a pre-compiled chain with many smartcontracts as modules and adding features really isn't "that" much harder than in ethereum and anyone can submit a pull request to get their feature into the codebase.  The additional challenge is getting into the code base and then deployed out into the network, which is similar to getting approval in the Apple app store with the end result of a highly optimized compiled version of a specific smart contract.  I really like this comparison and it makes it easier for people to conceptualize the different approaches. 

I think it would be awesome to embrace this, one key challenge is when choosing a platform to develop to it's not just the code.  If we are really saying and encouraging people to contribute additional smart contracts to graphene, the whole toolchain and process needs to be documented and made as simple as possible:

1.  Document graphene internal api's , data flows, objects, etc.
2.  Make getting a development environment up and running very easy with step by step instructions. like what files are necessary, make files, etc.
3.  Provide examples of several simple smart contracts.
4.  Provide a policy to which pull requests are evaluated.  Need to have public guidelines that need to be met to be considered for acceptance.  Just like apple store policy, (but maybe try and be even more transparent.)

Until this is available I don't think it's really a legitimate comparison.

I'm curious if we could provide these two things:
1.  Allow a specific smart contract to pay 10% of fees to the creator of said smart contract.
  - This would incentivize a lot of developers to submit smart contracts and compete for inclusion into the blockchain.
2.  From a security point of view could these smart contracts be sandboxed in such a way so that a secuirty issue in a specific smartcontract doesn't put the whole chain at risk? 

If these two possible and we had all the documentation, toolchains, and processes in place it would be a very powerful story to attract new developers.

Forced cover doesn't happen until a short falls below 150% collateral.  I had an open short myself that was at 164% collateral.  60 USD short, with a BTS collateral of about 98.4 USD.  I believe the forced margin call would happen at 150% a.k.a. 66% of collateral, but I've not seen a forced cover on any of my personal transactions.

https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/market_engine_v7.cpp
      auto call_collateral = collateral;
      call_collateral.amount *= 2;
      call_collateral.amount /= 3;

So, call collateral is when 2/3 (66%) of total collateral.  Which is the same thing as saying 150% (3/2) collateral.

I'm not 100% sure this is the correct line but it would be nice to know exactly where this is controlled.  It looks like it maybe referenced in more than one place.


I think it's important to get this right as ByteMaster and others references the 200% number fairly often.  Here is one:
http://bytemaster.bitshares.org/article/2015/01/13/NuBits-is-a-Ponzi-Scheme/

I just published two new videos around bitAssets and how they work.  The first video is a whiteboard where I talk about shorting and the mechanics behind everything.  The second video I run through the process of shorting an asset using the bitshares client.

https://www.everydaycrypto.com/

enjoy!

I've seen a lot of stuff written and mentioned on Lets Talk Bitcoin, that bitAssets are 2x backed by BTS.  However, when walking through the process myself it appears to me to be 3x collateralized.

I put up 2x BTS for the initial 1x bitUSD.  That bitUSD is immediately sold and the proceeds give to me.  However, the original 2x collateral and the proceeds from the sale are marked as "add collateral" and neither hit my available balance.  It seems like the whole 3x balance is available for the system to use in a forced cover.  Seems like 3x to me.  Also, confusing is the language that says if I have to use 150% of my collateral to cover it will force me to cover.  But this value seems to be based on a 2x cover.  Example, if the short price was 50, you would be forced to cover at 75.

Also, from a practical point of view if you want to avoid a forced cover you actually need additional funds to manually buy the asset before you can actually cover.  So, if you plan to short and cover manually you need to have ~3x the funds yourself.  Maybe in the future you could put out a special buy order where it allows you to use your collateral to buy the asset and the asset is immediately used to cover that particular short so you would not need that additional capital to use shorts.

which actually brings up another question around short expiration.  I understand the forced cover, but if the short just expires how is that process handled?  Same as a forced cover I assume except maybe you don't have to pay the 5% penalty?

I put together this video to help explain why the certificate system is broken.  I thought it would be of interest to this community for explaining to others why bitshares DNS is important.

Here is the video:
https://www.youtube.com/watch?v=-LEru8wyGJw

I'm currently working on the follow up that talks about namecoin and bitshares.  Honestly I haven't looked into bitshares Namespaces, but what makes it different/better namecoin?  besides POW/DPOS.

I have two incoming transactions from bter.  For argument sake, lets say the first one is 20 and the second one is 10.  So my balance should be 30, however, it's only showing my balance as 10.  I've updated my client and deleted the DB but still the same behavior.

I'm using the mac client.  0.4.7

When I use the command:

"wallet_account_transaction_history everydaycrypto"
It shows all the transactions and the correct final balance in the balance column.

However, when I use "wallet_account_balance everydaycrypto"  again it shows the incorrect balance.