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

Pages: 1 ... 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43
541
Openledger / Re: The URL bitshares.openledger.info just sucks.
« on: October 26, 2015, 10:50:19 pm »
I don't understand how exchanges can brand under openledger? If I wanted to use openledger name I would want pheonike.openledger.info, but howvwould I control that domain name?
I guess it's the different Graphene-based blockchains (not exchanges) that will be branded under OL.
OL is a name for an order book shared with all decentralized exchanges, not a name for a federation of decentralized exchanges.
At least that's how I understand it

correctly put jakub

Hi @Ronny:

I'm a little confused about the overlap between markets on CCEDK and OpenLedger.  Do you expect in the near future to have some integration between CCEDK and OL (for the markets where there is overlap e.g. BTS:BTC)?  If not, then the liquidity remains fragmented and the purpose of OL (i.e. pooled liquidity through shared order books) seems somewhat defeated, no?   

On a slightly different note, are you aware that we still don't have market history on the OL exchange?  As you know, market history (aka "the tape" aka "time & sales") is one of the three most fundamental components of a trading interface (order book, time and sales, chart) when it comes to gaining visibility into the price action of a market.  Without it, a trader is seriously handicapped.  So we really can't attract traders at this point.  And without traders, how can we build liquidity?  And if we're not serious about liquidity, why are we even bothering with any of this?  I know the market history on OL is out of your hands.  But surely you have some influence to help make it happen sooner rather than later.

-tbone

542
General Discussion / Re: CMC Exchange API
« on: October 26, 2015, 07:58:08 pm »
@bytemaster, funny you mentioned the different versions if BTC on the dex.  I've been thinking about these different versions and how, as you know, currently they form their own pairs and therefore their own order books.  I think it would be very beneficial for liquidity if they could be combined into one order book.  What would it take to accomplish this?  And perhaps solving this problem would also help solve your CMC problem?

It could be combined in the wallet, but it wouldn't actually be combined when you place an order.   The assets for OPEN.BTC and TRADE.BTC are fundamentally different because of the different issuers.

I don't know the exact ramifications of that.  All I know at this point is that one of the great features of the Bitshares exchange network is pooled liquidity.  But if every exchange that joins the network has their own versions of currencies that each form a new set of trading pairs entirely separate from the trading pairs formed by the versions of the same currencies issued by other participating exchanges, it would seem to negate the pooled liquidity aspect of the exchange network.  Am I wrong about this?

543
General Discussion / Re: CMC Exchange API
« on: October 26, 2015, 07:14:26 pm »
@bytemaster, funny you mentioned the different versions if BTC on the dex.  I've been thinking about these different versions and how, as you know, currently they form their own pairs and therefore their own order books.  I think it would be very beneficial for liquidity if they could be combined into one order book.  What would it take to accomplish this?  And perhaps solving this problem would also help solve your CMC problem?

544
Muse/SoundDAC / Re: cob, are you ready for tomorrow's go live?????:'( :'(
« on: October 26, 2015, 02:49:42 pm »
I'm seeing 2 hours and change remaining.  So I'm not sure what some of you are talking about. 

545
I think its a great idea! Its similar to non-fungible CFDs that I talked about a while back.

Under this system going long on a BitAsset would not give you a fungible / exchange tradeable asset - its just a CFD. I think thats GOOD. If 90% of BitAsset holders just want to get exposure to dollars/gold, and dont want to use that BitAsset as a currency, then they dont need fungibility.

The drawbacks of fungible BitAssets is that the shorts are always at a disadvantage, resulting in less liquidity. This is what BitAsset traders care about the most, and lack of liquidity is our biggest problem.

@Bytemaster: how about having 2 types of markets: the existing type with fungible BitAssets and a new type where both long and short trades are totally symmetrical? (Assuming the 2 types could not co-exist in the same market).

Could someone please explain the mechanics a little more?  Specifically, I'm curious to know exactly what about fungible BitAssets puts shorts at a disadvantage that wouldn't be the case with non-fungible BitAssets.  Thanks.


546
People are discussing this polo and I agree with the traders (who by the way, are one of our main target markets):

* The fee to place a trade needs to be extremely low.  Just enough to prevent spam.
* The fee to cancel an order should be 0.
* The fee upon the EXECUTION of an order should be "high" (aka, current levels).

I agree with Ander's premise that the cost for placing a trade should be low, the cost to cancel should be zero, and the cost of successful trade execution should be high.  bytemaster's proposal is intended to accomplish these goals while providing incentive to NOT leave orders open on the dex.  I think it's an elegant solution, although I'm not sure there's much of a problem with people keeping unnecessary orders open because when your order is open it ties up your funds.  So that already provides far more incentive to close any orders that don't need to be open. 

With that in mind, I think it would be much easier for people to understand the fee structure if we simply charged a spam fee to place an order, then either zero to cancel OR a full fee upon successful trade execution ($.05, $.125, or $.25 - after cash back - depending on membership level). 

By the way, it should be clear to everyone that one of the things bytemaster built into his proposed solution is an order placement fee that varies depending on membership level.  So in his example, the cost to place an order (that later gets cancelled) is $.002 for lifetime members, $.0755 for annual members, and $.201 for basic members.  Personally, I think the order placement fee in this scheme is WAY too high for basic and annual members.  Ander's idea was to avoid spam (not to profit massively from orders that end up getting cancelled) and I agree with him 100%.  So I think everyone should get charged the same order placement fee.  Perhaps UNLESS people with lower membership levels pose more of a spam risk.  In which case I would support a sliding scale, but a much more gradual one.  Perhaps $.002, $.004, and $.005.  Remember, most people are not spamming, and I think charging them much more than spam deterrent fees just to place an order would be very counterproductive.

@Ander: you're the OP on this thread and it seems there is a lot of support for your original premise.  What do you think about this?

547
Technical Support / Re: losing 2FA access / lost phone on poloniex
« on: October 24, 2015, 12:05:44 am »
still waiting... how long does it take for them to get to a support ticket? can someone ask in poloniex trollbox for me please? i can't bc i can't login in :( thanks

You don't need someone to ask in the trollbox for you.  You can just create another account to log in and ask for yourself.

548
Stakeholder Proposals / Re: Witness pay in BitShares 2.0
« on: October 23, 2015, 01:44:24 pm »
Why would any witnesses be overly concerned with their level of profitability at this early juncture when we're trying to get the system up and running?  Wouldn't they be more concerned with establishing themselves as good, reliable witnesses so they will be in a position to profit handsomely in the not-too-distant future? 

As for the specific issue of the feed publishing fees, ultimately these are going to be a very small cost relative to witness income, no?

549
With all due respect, I do not want to diss your project or anything, I'm just voicing my opinion.

As fav says, workers are not meant to fund external projects.

Examples for workers:
Add blinded transactions to frontend and post results on github for everyone to see
Add vested balances to frontend
Add proposed transactions to frontend
Improve market trading api calls since they're not too good at the moment
Create mobile wallet

All of these items are not a project that is trying to make money on its own, and I think that is the big difference.

@mindphlux: Obviously the community is divided as to whether it's appropriate to use a worker proposal to fund development of an external exchange.  I tend to agree with those that would be against it.  But what do you think about using a worker proposal to develop integrated, decentralized storage of other coins, which could then be traded on the Bitshares dex in the form of corresponding smartcoins?  I think that would be a massive winner for us.  Imagine if people could deposit and then trade BTC on the Bitshares dex just like they do at a centralized exchange, but free of counterparty risk.  And imagine further that once coins are trading on the Bitshares dex in this manner, that would provide a nice, easy migration path for these coins (perhaps not Bitcoin, but others) to move from their own blockchain onto ours. 

https://bitsharestalk.org/index.php/topic,19276.msg248887.html#msg248887

@seraphim: is this a project you would be interested in if the community got behind it?

An interesting idea for sure. I'd prefer the external solution, because everyone who wants to can become a signer without having to run a (later on potentially resource hungry) witness node besides the coin nodes.  A great part of the BTS universe isn't interested in other cryptos, just like other coin devs (potential signers) probably won't care about the mass of transactions on the bts chain.
For me, the dx gateway would have been a part of bts anyway. Creating another client instead of adding everything to the core just allows everyone to only run the software they need.

For users, I see no reason for the interface to be outside the Bitshares wallet.  In fact, that would create a disjointed and confusing user experience.  We're talking about deposit/withdrawal functionality here.  How does it make sense to require an additional client for that?  As for the signer interface, that could potentially be a different matter.  For example, if the only option is for the signer UI to be in the full node as opposed to the light wallet, then creating a standalone client for the signers could be a sensible alternative vs. forcing some signers to install the full node when they might otherwise have no reason to do so.

By the way, you've described the role of the signers as signing off on every deposit or withdrawal, correct?  But would that really be necessary?  Why couldn't that be automated?  So in the UI, a user can generates a bitcoin deposit address, for example.  Once the address receives a deposit, the blockchain issues a corresponding number of e.g. MY.BTC to that user's account, which can then be traded on the dex for, say, BTS or bitUSD.  Why would humans need to get involved, except when it comes to adding support for additional coins to the decentralized storage? 


550
With all due respect, I do not want to diss your project or anything, I'm just voicing my opinion.

As fav says, workers are not meant to fund external projects.

Examples for workers:
Add blinded transactions to frontend and post results on github for everyone to see
Add vested balances to frontend
Add proposed transactions to frontend
Improve market trading api calls since they're not too good at the moment
Create mobile wallet

All of these items are not a project that is trying to make money on its own, and I think that is the big difference.

@mindphlux: Obviously the community is divided as to whether it's appropriate to use a worker proposal to fund development of an external exchange.  I tend to agree with those that would be against it.  But what do you think about using a worker proposal to develop integrated, decentralized storage of other coins, which could then be traded on the Bitshares dex in the form of corresponding smartcoins?  I think that would be a massive winner for us.  Imagine if people could deposit and then trade BTC on the Bitshares dex just like they do at a centralized exchange, but free of counterparty risk.  And imagine further that once coins are trading on the Bitshares dex in this manner, that would provide a nice, easy migration path for these coins (perhaps not Bitcoin, but others) to move from their own blockchain onto ours. 

https://bitsharestalk.org/index.php/topic,19276.msg248887.html#msg248887

@seraphim: is this a project you would be interested in if the community got behind it?

551
General Discussion / Re: Reducing Bitshares Supply : A different approach
« on: October 22, 2015, 03:12:00 pm »
I don't think seraphim is blowing anything out of proportion.  Not to mention, he is correct about the centralized exchange.  What do we need another centralized exchange for?  The solution needs to be decentralized.  Actually, I would point out that a worker proposal is not appropriate for ANY exchange (that's what the referral program is for).  Plus we already have an exchange UI built into the wallet (albeit not a very usable one at the moment).  But adding decentralized storage seems completely appropriate for a worker proposal.  And that's the killer app for us.  Imagine people can send their BTC, for example, to OpenLedger and trade it on shared order books without any worry about the safety of their funds?  What are we waiting for?

552
Technical Support / Re: Why there is no Market History in new wallets?
« on: October 22, 2015, 02:43:43 pm »
What do we need to do to get this moving ASAP?  You can't have a trading platform without market history.  And there are several other usability issues with the trading platform including charts, order books, etc.  A few of us spent considerable time putting together detailed feedback on these items.  I believe svk is currently working on this stuff but there is no indication that the market history API issue he is facing has been resolved.  These items are required for minimum level of usability. 

@svk: has there been any movement on the market history API calls?  What about the other items discussed in the thread linked below?  By any chance do you have an ETA at least for the items not relying on the missing API call?  Thanks in advance.

https://bitsharestalk.org/index.php/topic,19194.msg247239.html#msg247239

BUMP
I don't have anything new to report other than the changes that I've already implemented. I'll keep working on the frontend stuff but can't do anything aboutnthe backend.

In order to help get the market history I guess you need to pm  bytemaster or theoretical and ask them to finally get it done. It shouldn't take them very long but for some reason it seems to be low priority..

You sound frustrated.  And I can see why.  It is baffling that the market history would be considered low priority for a TRADING PLATFORM.  In any event, obviously there's nothing you can do about that.  And I certainly appreciate your efforts.  Having said that, there are still some other things that are not helping make the trading interface usable. 

The most basic need is for a way to view all available trading pairs, and to manage which ones are favorite.  Then give the user a way to switch between them without leaving the trading dashboard.  This feature is one of the best things about the Poloniex GUI.  All you need to do is list the user's favorite markets somewhere on the trading dashboard (upper right hand column makes sense to me).  Even if you don't yet have the API you need to display some basic market data along with each pair, at least listing the favorite pairs themselves on the trading dashboard will be a BIG improvement. 

Also, there are some issues with the chart.  The price bars are not displaying proper width (although volume bars are fine).  The crosshair isn't working properly - it needs to move more freely in the vertical direction (horizontal movement is fine) and the horizontal line itself is not visible in TRADE.BTC:BTS for some reason (although it is visible in BTS:TRADE.BTC).  And finally, the zoom slider at the bottom of the chart doesn't work at all.   

I sincerely hope we can get some of these issues ironed out ASAP so that there's a sense we're making progress, and so that once the market history API is finally available, this will quickly shape into a very usable trading interface.  Thanks again for your efforts.

553
General Discussion / Re: Lowering Transfer Fees
« on: October 22, 2015, 12:57:46 pm »
I think I've discovered a reasonable explanation why the current transaction fees are perceived by some of us here as too high.
We are generally BTS holders and the reason we hold our BTS is because we feel they are actually worth much more than their current market value.

So we perceive spending 20 BTS (and now even 40 BTS) as a significant expense because we take into account the expected future value of BTS.
In other words, in the not-so-far future 40 BTS might be worth much more in terms of fiat than it is now so it feels very expensive. It feels like the we are forced to sacrifice part of our core investment just to make a transaction.
But a non BTS-holder won't necessarily feel this way.

Does it make sense?

EDIT: So my point is that we need to differentiate between the point of view of BTS holders and BTS users.
We, as BTS holders, are likely to be biased because we value our BTS much higher than the outside world.
For an outsider $0.20 might be no big deal but for an insider 40 BTS is a big deal (especially if you are not a whale and every 40 BTS spent now is perceived by you as having e.g. 0.1% of your investment gone).
So let's make this pricing decision rationally, i.e. by doing a market research among people who have never heard of BTS. Because this is the actual pool of our future users.

I think the fear of rising fees due to rising BTS value over time is just part of the problem.  It seems the bigger issue is the reality that some demographics are simply going to have lower average transaction sizes.  With a flat fee that means they will be charged higher rates to move funds.  That's too arbitrary, and it means we'll lose some users that would have been profitable for the network, even if they may not have been as profitable as others.  And we'll lose some businesses whose model depends on a lower than average transaction amount.  Do we really want to lose some users, let alone businesses that would otherwise build on top of Bitshares?  Aren't we're trying to achieve network effect?

So what's the answer?  We just need to use a percentage-based fee.  This way the fee is automatically dynamic and we don't have to keep changing it.   I think we should seriously consider that.  Of course, we'd have to set a minimum fee to discourage spam.  And we should probably have a maximum fee too. I think these parameters can be set at levels that would be sensitive to the different demographics, but without substantially changing the overall income to the network or the referrer/registrar.  Personally I don't see any reason why we shouldn't set the minimum as low as possible, just low enough to ensure the network doesn't get spammed and doesn't lose money on the lower end transfers. 

As for stealth transfers, we should definitely charge more (these may have to be a flat fee?).  And we should charge more for trades.  Although fees for setting and canceling orders should be set just low enough to prevent spam.  And to encourage liquidity providers, a maker/taker pricing model would be sensible.

554
Technical Support / Re: Why there is no Market History in new wallets?
« on: October 21, 2015, 04:18:57 pm »
What do we need to do to get this moving ASAP?  You can't have a trading platform without market history.  And there are several other usability issues with the trading platform including charts, order books, etc.  A few of us spent considerable time putting together detailed feedback on these items.  I believe svk is currently working on this stuff but there is no indication that the market history API issue he is facing has been resolved.  These items are required for minimum level of usability. 

@svk: has there been any movement on the market history API calls?  What about the other items discussed in the thread linked below?  By any chance do you have an ETA at least for the items not relying on the missing API call?  Thanks in advance.

https://bitsharestalk.org/index.php/topic,19194.msg247239.html#msg247239

BUMP

555
General Discussion / Re: Fee Adjustments
« on: October 20, 2015, 03:54:52 pm »
We have put through a proposal that will adjust the fees to keep them in line with our stated targets of $0.20 per transfer and will continue to adjust the fees to maintain this target as the price of BTS changes.

All fees will scale equally so the relative costs will be the same. 


This is welcomed news.  I think the "fees are too high" crowd was somewhat driven by fear of the fact that fees would get out of control as the price goes up. 

By the way, can you please address the market history issue in the thread linked below?  Thanks.

https://bitsharestalk.org/index.php/topic,19038.msg247717.html#msg247717

Pages: 1 ... 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43