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.


Topics - questionsquestions

Pages: [1]
1
Technical Support / Stealth Transactions - Any ETA?
« on: July 05, 2016, 03:17:00 pm »
Is there any ETA on some form of workable stealth transactions for Bitshares to obscure either the amounts and/or the transaction participants? Being able to enter poloniexwallet (the Bitshares wallet of the exchange Poloniex) and see their entire balance and transaction history is just such a huge barrier when selling or developing for the Bitshares platform, which otherwise is pretty great. 

2
Technical Support / Bitshares Account Setup for centralised website
« on: March 02, 2016, 11:08:16 pm »
I'm building a simple website to explore how I would store Bitshares asset balances for user accounts. Taking typical Bitcoin websites as examples; as a user, you are issued a Bitcoin Address and can send Bitcoins to that address. The website 'owns' the private key to that Bitcoin Address within it's wallet, and can therefore spend the balance of any Bitcoins sent to that address. It's analogous to an account number and pretty simple from a user's perspective (ignoring the amalgam of characters that constitute a Bitcoin address).

However, I'm not clear how to replicate similarly simple behaviour in Bitshares. It seems there are two possible approaches;

1) Create a single 'company' account on the Bitshares blockchain and issue the customer with the name of the account along with a custom 'memo' identifier that allows routing of their funds within the context of the website. This approach was used on Bter and is thwart with the possibility of user-error because the memo field is ostensibly free-text without validation. If the user inputs a wrong character (which they will definitely do) when they are trying to deposit funds, the whole automated process breaks down (and someone supporting the website would need to manually identify and route the funds).

or;

2) Create a unique account on the Bitshares blockchain for each user registering on the website and issue the customer with the name of the account. The account's private keys are held locally by the website and the user uses the name as a unique identifier to route their funds. This seems like an approach that is more user friendly, but raises the possibility of
  • A) cluttering the bitshares blockchain
  • B) users attempting to register the same account name outside of the website (E.g. through the bitshares client) and being denied because the name is taken by the website
  • C) identification of accounts tied to the website by third parties; for example - if new accounts were prefixed 'MYWEBSITE-' (nasty privacy violation)

In the case of B and C, is there a way to stealth-ify accounts? Perhaps through the issuance of an Address (in the same vain as Bitcoin) rather than a friendly account name; and is there a way to prevent or hide account names to avoid identification and relation of accounts back to the website?

I'd really appreciate some input on the available options to solving this problem.
 

3
General Discussion / Truthcoin - Bitshares(X) perceived limitations
« on: November 07, 2014, 05:34:30 pm »
Someone is hawking a new coin called Truthcoin (http://www.truthcoin.info/) that has been proposed as a sidechain to Bitcoin. One of the benefits that Truthcoin has over BitsharesX is apparently:

Quote

...the BitAssets of BitsharesX, but done right (no soviet-style price fixing, or fiat 'name only' assets, and no swapping out the tried-and-true security model with what someone had for breakfast today)...


I am not entirely clear on what this statement means, so perhaps someone can clarify? I am aware that no crypto-currency is perfect, so the points leveled by the Truthcoin author may well be valid and I would be interested to know - if they are - are there any proposals in the works to address them?

As an aside; I also though DPos as one of the potentially best consensus algorithms that currently exist today. Far less wasteful than Proof of Work and with built in determinism to ensure fast and  consistent block creation times.


4
Is there a concrete timeframe for the merger of AGS/PTS/BTSX and all the competing DAC's under the "Bitshares" and BTS brand? I am very keen to promote BTS(X) - specifically BitUSD, but I can't find any concrete timeframes only proposals and vague (albeit exciting) roadmaps.

Is there a date when everything is going to be brought back into the Bitshares fold, so that we can start building services around a single brand and technology stack (Bitshares) without the risk of causing confusion and ambiguity to new potential adopters?

5
Technical Support / Wallet intermittently stops synchonizing
« on: September 24, 2014, 07:39:07 pm »
There appears to be a bug in the client that stops it synchronizing. As of version 0.4.16, a restart of the application fixes the issue.

The software literally just stops synchronizing on a block and won't get passed it. In 0.4.16 which I was running this afternoon, it suddenly because stuck on block 571072. There doesn't seem to be any specific steps in the UI to replicate the behavior reliably, it just seems that software receives a block it doesn't like and then stops processing future blocks. I've provided a screenshot here: http://imgur.com/EVHf2ID

Platform: Windows
Version: BitSharesX-0.4.16-x64.exe

6
General Discussion / The limitations of BitsharesX vs Bitcoin
« on: September 22, 2014, 02:51:19 pm »
I've been doing more digging around the wiki and I've come up with some questions I cannot find satisfactory answers to. Could someone outline and honest and realistic appraisal of the limitations of Bitshares vs Bitcoin? Specifically;

  • Scalability: Bitcoin suffers from a maximum theoretical limit of 7.2 transactions-per-second (without a hard fork). While the current traffic hasn't reached anywhere near this number, if Bitshares were to take off it is entirely possible that the number of transactions would grow rapidly. So;

    • What's the maximum number of transactions Bitshares can accommodate in a block?
    • Does Bitshares have the ability to scale the size of blocks to accommodate growth
    • How large is the blockchain in Bitshares likely to be vs Bitcoin? Bear in mind that Bitcoins full blockchain is running at ~30 GB currently
    • How will a large blockchain affect new clients entering the eco-system? Bitcoin offers work-arounds such as SPV and server based offering such as Electrum - how does Bitshares accomodate this?
-
  • Fees: The fee structure appears to be a mandatory minimum 0.5 BTSX / operation. Fees do not appear to be refunded in the event of a cancellation

    • Can fees be varied if the value of BTSX grows? Bitcoin suffers from its own success in this regard. Transactions fees are generally 0.0001 BTC, which when Bitcoin was circa 1000 USD was the equivilent 10 cents just to send any value through the system. This made micro-payment scenarios uneconomical vs incumbent solutions like credit cards. NB: Floating fees aimed to address this, but Gavin Andressen indicated that in some cases the transaction fees would actually go up rather than down.
    • Through the distributed exchange mechanism - is it possible to receive a rebate for a cancelled trade? For example; a limit order isn't filled
-
  • Distributed Exchange:
    • Do the market orders pay the exact price offered by a BUYer, or do they cross over the order-book ala Bitstamp? For example; I want to buy 10 BITUSD, there are 5 on offer at 1 BTSX each and 5 on offer at 2 BTSX each. If I make a limit order and offer 15 BTSX, do I end up with 10 BITUSD (5 BITUSD @1 BTSX each and 5 BITUSD @2 BTSX each) or 7.5 BITUSD - meaning I pay 2 BTSX each for each BITUSD, until all 15 of my BTSX are consumed?
    • Is it possible to create a market order to buy or sell assets? For your average consumer who just wants to move wealth in and out (akin to normal forex transfers), a limit order would mean waiting around for it to fill or paying above market price?

Anything else that paint a true picture of the limitations of Bitshares.

Thanks for all the responses.

7
General Discussion / Asserting the true value of BitUSD
« on: September 20, 2014, 02:44:30 pm »
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. 

Pages: [1]