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 - monsterer

Pages: [1] 2 3 4 5 6 7 8 ... 125
1
Technical Support / Re: [api] bizarre get_block error
« on: April 09, 2016, 10:30:38 pm »
Many thanks guys - that was indeed the solution :)

2
Technical Support / [api] bizarre get_block error
« on: April 09, 2016, 08:31:35 pm »
This is occuring on the MUSE chain, for some reason, calling the get_block() api call on certain blocks has started failing with a strange error:

Code: [Select]
{"id":1,"method":"call","params":[0,"get_block",[4658091]]}

{code:1,message:7 bad_cast_exception: Bad Cast
Invalid cast from object_type to Array
    {"type":"object_type"}
    th_a  variant.cpp:530 get_array,data:{code:7,name:bad_cast_exception,message:Bad Cast,stack:[{context:{level:error,file:variant.cpp,line:53
0,method:get_array,hostname:,thread_name:th_a,timestamp:2016-04-09T20:28:59},format:Invalid cast from ${type} to Array,data:{type:object_type}}
]}}

If I call the function on the prior block it returns fine. Any ideas what could be causing this?

3
I assume you mean the mid-price of the last 24h candle? .. mid price as in high-low?

mid price = (bid+ask)/2

4
I can write a bot for this that sets the CER at last_trade +5% or so .. or use the 24h average instead of last_trade.
What do you think makes most sense?

Use the mid price, not the last trade

5
General Discussion / Re: New Release and Hard Fork for March 23, 2016
« on: March 20, 2016, 12:50:54 pm »
Build in 'Release' mode instead.
Anyway, this bug should be fixed

It's not fixed - the problem only occurs if you don't make in the bitshares-2 folder. For example:

Code: [Select]
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make

6
General Discussion / Re: New Release and Hard Fork for March 23, 2016
« on: March 18, 2016, 01:49:46 pm »
Code: [Select]
[ 55%] Building CXX object libraries/chain/CMakeFiles/graphene_chain.dir/database.cpp.o
In file included from /home/coinbox/bitshares-2/libraries/chain/database.cpp:30:0:
/home/coinbox/bitshares-2/libraries/chain/db_maint.cpp: In member function âvoid graphene::chain::database::update_worker_votes()â:
/home/coinbox/bitshares-2/libraries/chain/db_maint.cpp:105:53: error: âHARDFORK_607_TIMEâ was not declared in this scope
    bool allow_negative_votes = (head_block_time() < HARDFORK_607_TIME);

Building in Release.

7
OP-er. Wrong!

@tonyk is correct, but with one huge caveat - there absolutely must be an IOU backed by real off chain crypto in order for BTS price to have any meaning at all in a system where BTS only trades internally.

9
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 08, 2016, 09:45:58 am »
Most of the committee seems to be fine with reducing issuer/burn fees out of schedule to support our existing business partners. We are evaluating out options

Take your future business partner's needs into account as well; any cross blockchain IOU issuing will struggle on bitshares with perception and trust issues with this new fee schedule.

10
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 07, 2016, 06:49:03 pm »
Anyway, we are already discussing about it, and I personally hope we would be able to push this change asap.

I personally like more the on-demand issue/burn scheme than the pre-issue one.

I'm glad you are considering revising these fees; it will be much better for bitshares as a platform to have issue/burn fees the same as transfer, so that exchanges/bridges can move onto bitshares without friction.

11
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 07, 2016, 11:21:45 am »
The Committee will take your valuable input into considerations. I've added a remark to our current fee schedule:
https://github.com/BitShares-Committee/Instructions/commit/dd23653e17b24ee5a1e6c8a25378022b9f9c2eba

@monsterer .. In the meantime, what would be the argument of having a next-to-burn account that collects some of those assets and burns them after a couple of weeks to spare fees?
In the end, if they are held by the issue, your customers can have the same kind of trust that put into you not just issuing new shares. All they need to do is take another balance into consideration to verify that the supply matches the debt, not?

It works in principle but I means I have to completely change the way our back-end works for issuing IOUs; it just makes the whole process a PITA. Bare this in mind if you are trying to attract exchange partners to build on top of bitshares, because they will have the same issue as I do with this work around.

12
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 07, 2016, 10:48:47 am »
Good point.
Afaik OpenLedger is operating in a pre-issue schema, BlockTrades operates TRADE.BTC in a pre-issue schema as well but on-demand-issue schema for DOGE/DASH.

Not unless they were only expecting to issue 25 BTC worth!

https://bitshares.openledger.info/#/asset/TRADE.BTC

Or 230 worth:

https://bitshares.openledger.info/#/asset/OPEN.BTC

13
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 07, 2016, 10:21:40 am »
Somebody had better inform open ledger / blocktrades about this otherwise any unscrupulous individual could rack up some serious fees for them by sending tiny amounts repeatedly to their bridge

@dannotestein @ccedk

14
General Discussion / Re: 234 BTS for issue/burn asset?!?!
« on: March 07, 2016, 09:05:40 am »
These are horrible ideas. It means the available supply is no longer representative of  currency in use.

This change won't just affect metaexchange, but any business issuing IOU bitshares tokens for crypto/fiat.

15
General Discussion / 234 BTS for issue/burn asset?!?!
« on: March 06, 2016, 10:33:26 pm »
Who increased the issue/burn asset fee to 234 BTS?! That fairly badly affects metaexchange's business model, since we swallow all transfer/issue/burn fees.

I've had to temporarily disable metaexchange's IOU markets.

Pages: [1] 2 3 4 5 6 7 8 ... 125