Author Topic: Asserting the true value of BitUSD  (Read 2546 times)

0 Members and 1 Guest are viewing this topic.

Offline questionsquestions

  • Jr. Member
  • **
  • Posts: 39
    • View Profile
Cluttering of the directory is definitely an issue though, we already have hundreds if not thousands of scam accounts with nearly identical names, all seemingly designed to profit from accidental transfers. Some kind of pruning of account names over time would definitely be welcome.

Perhaps leveraging the existing voting technology? and/or proof of stake? Anything with less than X BTSX shares or a negative vote would be filtered by default. Infact, voting for accounts retaining a minimum BTSX balance would make the most sense since it would demand that for a vote to be cast and valid, a voter must hold a certain number of BTSX. This would hopefully limit spammers from down-voting accounts they don't like - since it would tie up BTSX (cost money) to do it.

Alternatively, could explore some kind of PKI certificate - so - for example - COMCAST or COINBASE could register themselves using their normal X59 certificates used for securing https traffic, and you'd filter the list based on those with valid certificates.

This and "REGEX validation for MEMO field" would be awesome ;)

Offline robrigo


Lastly, you cannot send directly to accounts unless the name is registered on the blockchain for a nominal fee of 0.1 BTSX. This can be done from that specific account's overview page.

I'd just like some clarity on this answer. Firstly; I've created three accounts, only one of which I registered. I was able to send BTSX from the REGISTERED account to the UNREGISTERED account without any problem and I have just sent funds from one of the UNREGISTERED accounts to another UNREGISTERED account. Is this therefore a bug? Also - registering requires a payment of 1 BTSX and therefore funds in the account, but accounts start with a zero balance. It does not make sense that you need to REGISTER just to use BitSharesX, surely?

Secondly; why would you want to register apart from being able to make yourself public for easy-lookup (E.g. I want to pay account COMCAST my telephone bill using MEMO {MySubscriberNumber}, therefore COMCAST would want to maintain a publicly indexed account) or to become a delegate?

If I were adopting BitSharesX as a privacy centric marketplace for example with per-customer accounts, I would not want those accounts to appear on a public directory or to be discoverable by any means (In the same way that Bitcoin Addresses cannot easily be tied to BitPay, Coinbase or any of the darknet market places). Mandatory appearance on some directory would mean I'd have to generate some extremely random names to prevent interested third parties from determining which accounts were owned by my marketplace and this would also serve to clutter the directory needlessly.

This leads to my third question; the Directory listing in the GUI. It provides options for discovering Registered and Unregistered (although this brings back no results - not sure if that's by design or just not working correctly yet). This seems like a significant oversight with regards to privacy? I can understand that certain accounts (like COMCAST mentioned above) may want to be publicly indexed, but a majority of users or market places creating accounts for customers to deposit into, will not want their accounts appearing or discoverable anywhere especially during the adoption phase where there is a lot less account entropy.

Thanks once again!

Oops sorry about the confusion, I should have said "you cannot send directly to account names..." in the quote above. svk cleared it up.  ;)

Offline svk

Accounts do not need to be registered to receive funds or make transfers, it's a constraint imposed by certain exchanges. Like you discovered you can transfer to any address you like, it just needs to have a local name set in your client (a contact name).

Only registered accounts are visible on the blockchain, so if you want to remain anonymous just name your accounts locally without registering them.

Cluttering of the directory is definitely an issue though, we already have hundreds if not thousands of scam accounts with nearly identical names, all seemingly designed to profit from accidental transfers. Some kind of pruning of account names over time would definitely be welcome.
Worker: dev.bitsharesblocks

Offline questionsquestions

  • Jr. Member
  • **
  • Posts: 39
    • View Profile

Lastly, you cannot send directly to accounts unless the name is registered on the blockchain for a nominal fee of 0.1 BTSX. This can be done from that specific account's overview page.

I'd just like some clarity on this answer. Firstly; I've created three accounts, only one of which I registered. I was able to send BTSX from the REGISTERED account to the UNREGISTERED account without any problem and I have just sent funds from one of the UNREGISTERED accounts to another UNREGISTERED account. Is this therefore a bug? Also - registering requires a payment of 1 BTSX and therefore funds in the account, but accounts start with a zero balance. It does not make sense that you need to REGISTER just to use BitSharesX, surely?

Secondly; why would you want to register apart from being able to make yourself public for easy-lookup (E.g. I want to pay account COMCAST my telephone bill using MEMO {MySubscriberNumber}, therefore COMCAST would want to maintain a publicly indexed account) or to become a delegate?

If I were adopting BitSharesX as a privacy centric marketplace for example with per-customer accounts, I would not want those accounts to appear on a public directory or to be discoverable by any means (In the same way that Bitcoin Addresses cannot easily be tied to BitPay, Coinbase or any of the darknet market places). Mandatory appearance on some directory would mean I'd have to generate some extremely random names to prevent interested third parties from determining which accounts were owned by my marketplace and this would also serve to clutter the directory needlessly.

This leads to my third question; the Directory listing in the GUI. It provides options for discovering Registered and Unregistered (although this brings back no results - not sure if that's by design or just not working correctly yet). This seems like a significant oversight with regards to privacy? I can understand that certain accounts (like COMCAST mentioned above) may want to be publicly indexed, but a majority of users or market places creating accounts for customers to deposit into, will not want their accounts appearing or discoverable anywhere especially during the adoption phase where there is a lot less account entropy.

Thanks once again!
 

« Last Edit: September 21, 2014, 08:53:29 pm by questionsquestions »

Offline erick

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
I know its a little pointless , but I have to thank you for asking these questions. This was a great all around thread, and I learned alot about the bitsharesx market. Thanks guys , eventually I will shed this newbish skin and be a full blown BitsharesX Master! :) but seriously thanks. :) these are the kind of posts that make a difference.
BTSX account: erick

Offline robrigo

Thank you very much for your detailed reply. This is exactly what I was looking for.

With regards to your answer in point 4:

BitShares X has Bitcoin-style addresses included in the wallet, and you can use them to transfer. Under the hood I think it works a lot like Bitcoin. The idea here is that for most purposes, account names are better as they are easier to type and remember. In any case, exchanges, developers etc. will have to experiment and customize solutions for given applications.

I've read some of the documentation and I can see that the account name and public key abstract the transaction layer, allowing for 'behind-the-scenes' generation of unique key-pairs for each transaction. I realize that this is to address the perceived flaw in address reuse that is prevalent in Bitcoin, but I'm still not clear as to whether generating a "per-account, per-customer" mechanism is an acceptable solution over the existing "single-account, memo-per-customer" method employed by bter.

For example; if I deposit Bitcoins to Bitstamp.net, I do so to a unique Bitcoin address that has been generated for me. This eliminates (almost) any chance of the Bitcoins that I send not being credited to my account.

In a comparable scenario with BitsharesX and bter.com - the reconciliation of funds to a customer account is done using the memo field. This means that if a customer mis-types the value, or forgets to enter it (and they will), the funds - while credited to bter.com - will not be credited to the customers account. This will generate significant support overhead as originating funds that do not contain the reference must then be manually reconciled.

So, firstly, is there a way to enforce a memo value - possibly allowing the provider to apply a regular expression pattern embedded into their public account (like website field now) that allows them to reject transactions that don't contain a recognized memo pattern. Or; would it be better for me - as a marketplace/exchange etc - to generate an account for each of my customers that register and give them the account name and public key to deposit their funds. This way, eliminating then need for any memo value?

If you have any use-cases for illustrating how BitsharesX would work in the context of a marketplace/exchange deposit and in the context of a BitPay/Coinbase merchant<->customer transaction - that'd be awesome.

One last slightly different question; I created two accounts within the client and when I tried to send funds from one account to the other, I was required to enter both the account name (E.g. "willabie") and the public key. The client refused to send the funds unless both values were present. I was under the possibly erroneous impression that the account name was a 'friendly' way of deriving the public key and as such, either that or the public key should be sufficient to send the funds onwards? (I'm also aware it might just be an eccentricity of the client and that the RPC commands do support this functionality - some clarity would be great)

On a side note; I firmly believe that BitsharesX is a contender for the future of crypto-currency, but how the user experience is presented will be key to gaining that adoption.

Welcome to the forum, these are good questions. I don't believe there is a way to make memo field match patterns yet, but that would be a good way to help prevent the scenario you described with BTER. I personally think it makes more sense for the exchange to take advantage of TITAN by registering accounts for each "deposit box". But there is also the argument that causes additional block-chain bloat I suppose.

As for the use cases, BitAssets such as bitUSD are fungible, allowing one to deposit them to exchanges just like other crypto tokens. Merchants using bitUSD could accept that directly to their registered account without the need for an intermediary like Coinbase.

Lastly, you cannot send directly to accounts unless the name is registered on the blockchain for a nominal fee of 0.1 BTSX. This can be done from that specific account's overview page.

Offline questionsquestions

  • Jr. Member
  • **
  • Posts: 39
    • View Profile
Thank you very much for your detailed reply. This is exactly what I was looking for.

With regards to your answer in point 4:

BitShares X has Bitcoin-style addresses included in the wallet, and you can use them to transfer. Under the hood I think it works a lot like Bitcoin. The idea here is that for most purposes, account names are better as they are easier to type and remember. In any case, exchanges, developers etc. will have to experiment and customize solutions for given applications.

I've read some of the documentation and I can see that the account name and public key abstract the transaction layer, allowing for 'behind-the-scenes' generation of unique key-pairs for each transaction. I realize that this is to address the perceived flaw in address reuse that is prevalent in Bitcoin, but I'm still not clear as to whether generating a "per-account, per-customer" mechanism is an acceptable solution over the existing "single-account, memo-per-customer" method employed by bter.

For example; if I deposit Bitcoins to Bitstamp.net, I do so to a unique Bitcoin address that has been generated for me. This eliminates (almost) any chance of the Bitcoins that I send not being credited to my account.

In a comparable scenario with BitsharesX and bter.com - the reconciliation of funds to a customer account is done using the memo field. This means that if a customer mis-types the value, or forgets to enter it (and they will), the funds - while credited to bter.com - will not be credited to the customers account. This will generate significant support overhead as originating funds that do not contain the reference must then be manually reconciled.

So, firstly, is there a way to enforce a memo value - possibly allowing the provider to apply a regular expression pattern embedded into their public account (like website field now) that allows them to reject transactions that don't contain a recognized memo pattern. Or; would it be better for me - as a marketplace/exchange etc - to generate an account for each of my customers that register and give them the account name and public key to deposit their funds. This way, eliminating then need for any memo value?

If you have any use-cases for illustrating how BitsharesX would work in the context of a marketplace/exchange deposit and in the context of a BitPay/Coinbase merchant<->customer transaction - that'd be awesome.

One last slightly different question; I created two accounts within the client and when I tried to send funds from one account to the other, I was required to enter both the account name (E.g. "willabie") and the public key. The client refused to send the funds unless both values were present. I was under the possibly erroneous impression that the account name was a 'friendly' way of deriving the public key and as such, either that or the public key should be sufficient to send the funds onwards? (I'm also aware it might just be an eccentricity of the client and that the RPC commands do support this functionality - some clarity would be great)

On a side note; I firmly believe that BitsharesX is a contender for the future of crypto-currency, but how the user experience is presented will be key to gaining that adoption.





« Last Edit: September 21, 2014, 01:36:51 pm by questionsquestions »

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
I've recently discovered BitsharesX and - on the face of it - it would seem to address many of the failings of the current incumbent; Bitcoin. But, I have a few questions;

Great! Welcome :)

1) BitUSD is likely to be the most useful asset for the majority *if* its value can truly be shown to be pegged to the USD. Now, I've acquired some BTSX and proceeded to try and convert it to BitUSD. First up; how do you obtain BitUSD at a more-or-less 1:1 value with USD? Looking in the BitUSD:BitX market in the client, and the liquidity is non-existent and the spreads are huge.

Yes it is somewhat volatile, and liquidity is lacking. Fixes are being honed and perfected to deal with volatility. From what I have seen it is usually much, much closer - within a 5% range. All things considered, that is pretty good. Only a few days after bitUSD was launched, BitShares X immediately went from 15 million market cap to 110 million and crashed to 40 million before it stabilized to where it is now - during that extreme volatility, bitUSD stayed very close to the dollar, which I think impressed a lot of people who were initially highly skeptical.

Unlike BTC or BTSX you know where bitUSD will stabilize: Very close to the value of the dollar. From what we have seen so far, all signs point to less volatility and more liquidity the more users adopt this system.

2) Hypothetically, if I were to operate a Coinbase-esque service that allowed people to convert USD->BitUSD - there would be an expectation that the values would be (almost) par (10 USD in, ~10 BITUSD out). How would this be made possible given the current pricing discrepancy and lack of apparent liquidity?

Liquidity will come if this is ever popular I think. Volatility is more tricky to perfect, but improvement are being made. However, even if we get within 1% of the dollar there will always be a small discrepancy. But there is a deeper problem that has nothing to do with bitUSD, and that is the fact that USD on different exchanges tend to be valued differently.

If we do the analysis from Bter correctly it will go like this: Bter has a BTC price of 415 atm. Coinbase has a BTC price of 396 atm. This means that the dollars on Bter are worth 5% less. Now let us look at bitUSD. I have to pay 1.0350 USD on Bter to get a bitUSD, and I get 0.9950 if I sell a bitUSD. That's a 5% difference as well. I think we can conclude that at this stage the spread will be significant, even if we hit it right on the nose.

3) I've read in some topics that holding BITUSD implies you receive a share of the profits from short positions as interest? Could someone clarify if this is the case and - as such - if this incentivizes the risk averse to actually hold wealth in the asset as opposed to trying to dump it out to the real world at the nearest FIAT<->CRYPTO exchange (E.g. Coinbase, Bitstamp etc) as soon as possible?

Yes. BitUSD gives you what we like to call yield, which is almost like an interest on your bitUSD holdings. The money comes from fees associated with the bitUSD markets inside BitShares X, and is deposited directly into your account. We hope of course that this will get people to deposit bitUSD in our "vault" as opposed to banks or whatever other crypto they enjoy holding. As each bitUSD is backed by BTSX, the demand for bitUSD will grow the market cap of BitShares X. Demand for bitUSD will also make the market peg less volatile, and of course increase liquidity.

4) Bitcoin (somewhat) evolved this (and I'm thinking in particular in the context of the darknet markets here) by allocating each customer their own unique deposit address, thus removing the need for customers to provide a routing reference (MEMO) and the inherit risk and increased support overhead this introduces. 

BitShares X has Bitcoin-style addresses included in the wallet, and you can use them to transfer. Under the hood I think it works a lot like Bitcoin. The idea here is that for most purposes, account names are better as they are easier to type and remember. In any case, exchanges, developers etc. will have to experiment and customize solutions for given applications.

If you have anything specific in mind or want more detail on any of these questions don't hesitate to ask. I only answer as I am amble, and there are many people here who can help you go in depth on all of these issues.

Also see http://wiki.bitshares.org/ for a broad overview.
« Last Edit: September 21, 2014, 08:45:29 am by CLains »

Offline questionsquestions

  • Jr. Member
  • **
  • Posts: 39
    • View Profile
I've recently discovered BitsharesX and - on the face of it - it would seem to address many of the failings of the current incumbent; Bitcoin. But, I have a few questions;

1) BitUSD is likely to be the most useful asset for the majority *if* its value can truly be shown to be pegged to the USD. Now, I've acquired some BTSX and proceeded to try and convert it to BitUSD. First up; how do you obtain BitUSD at a more-or-less 1:1 value with USD? Looking in the BitUSD:BitX market in the client, and the liquidity is non-existent and the spreads are huge.

At the time of writing; 27 BTSX/BITUSD equates to 0.00007610 BTC / BTSX* which equates to 0.0315815 USD / BTC. So basically, 3 cents per BTSX, which means 1 BITUSD is  trading at about 85 cents or 85% of it's real world USD value.

How do we stop the same issues affecting BITUSD as have affected Bitcoin? namely the crippling volatility that prevents anyone (aside from speculators and idealists) from holding it.

* BITX/BTC prices from BTER.COM


2) Hypothetically, if I were to operate a Coinbase-esque service that allowed people to convert USD->BitUSD - there would be an expectation that the values would be (almost) par (10 USD in, ~10 BITUSD out). How would this be made possible given the current pricing discrepancy and lack of apparent liquidity?

3) I've read in some topics that holding BITUSD implies you receive a share of the profits from short positions as interest? Could someone clarify if this is the case and - as such - if this incentivizes the risk averse to actually hold wealth in the asset as opposed to trying to dump it out to the real world at the nearest FIAT<->CRYPTO exchange (E.g. Coinbase, Bitstamp etc) as soon as possible?   

4) When transferring assets between accounts, I've noticed some providers (namely BTER.COM) use the memo field as an account identification mechanism. This comes with the age old warning; "If you forget to add this memo, contact us so we can find and credit your deposit". This implies that BTER only hold a single account and reconcile the account to credit inbound transactions to using the value in the MEMO field (exactly the same as todays bank transfers).

Bitcoin (somewhat) evolved this (and I'm thinking in particular in the context of the darknet markets here) by allocating each customer their own unique deposit address, thus removing the need for customers to provide a routing reference (MEMO) and the inherit risk and increased support overhead this introduces.

The equivalent mechanism in BitsharesX would be to generate new account for each customer that signs up and propagate the public key and account name to them. Is there any reason that this would be a negative, for example; spamming the BitsharesX blockchain since I assume the account name has to be stored somewhere, unless account name is used to derive the public key in the same way as Bitcoin does it and therefore the account name can be implicitly derived from the account public key?

Thanks for the responses.