Quote from: Gentso1 on September 23, 2014, 09:55:39 PM

Quote from: trader on September 23, 2014, 09:07:21 PM

Quote from: Gentso1 on September 23, 2014, 08:00:30 PM

Quote from: bytemaster on September 22, 2014, 11:03:01 PM
Voters elect delegates that upgrade as they wish.

How consolidated are btsx shares at this point?

I remember the idea of a btsx rich list was tossed around but with TITIAN I would imagine it might be difficult. I would be curious to see how much everyone's votes really matter in comparison with the large holders.

Why dont you start a poll asking how many BTSX people have.

I could but I doubt the big holders will participate, which would make it useless.....

You can try to analyze genesis block: https://raw.githubusercontent.com/dacsunlimited/bitsharesx/master/libraries/blockchain/genesis.json

Probably you understand what even in Bitcoin you can't make exact rich list, you only can see the top of unspend outputs and can't know if few of them belong to same owner.

Quote from: clout on September 22, 2014, 11:37:26 PM
I provided the answers to your question in my original post in bold.

I see - I missed them since they were embedded inside the quoted text. Thanks alot!

In response to to this question:

Quote from: clout on September 22, 2014, 11:37:26 PM
    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?


A market order is just buying at lowest ask or selling at the highest bid. You can obviously do that now...

A market order isn't a straightforward BUY or SELL at the lowest ASK or BID price though. A market order steps up the price paid, or drops down the price offered until either the requested number of assets has been obtained or expended. E.g. Sell 1000 BTSX for BITUSD - at whatever price you can get, and keep selling until all the BTSX have been sold.

Buying at either the lowest ask, or selling to the highest bid would be a limit order. E.g. Sell whatever I can into this BID or ASK, and then just leave the rest on the order book if the full amount was not sold or purchased.

So, the question still stands; does the ability to liqudate or fill a position at any price automatically exist, or does the system only support limit orders?

Quote from: trader on September 23, 2014, 09:07:21 PM

Quote from: Gentso1 on September 23, 2014, 08:00:30 PM

Quote from: bytemaster on September 22, 2014, 11:03:01 PM
Voters elect delegates that upgrade as they wish.

How consolidated are btsx shares at this point?

I remember the idea of a btsx rich list was tossed around but with TITIAN I would imagine it might be difficult. I would be curious to see how much everyone's votes really matter in comparison with the large holders.

Why dont you start a poll asking how many BTSX people have.

I could but I doubt the big holders will participate, which would make it useless.....

Quote from: Gentso1 on September 23, 2014, 08:00:30 PM

Quote from: bytemaster on September 22, 2014, 11:03:01 PM
Voters elect delegates that upgrade as they wish.

How consolidated are btsx shares at this point?

I remember the idea of a btsx rich list was tossed around but with TITIAN I would imagine it might be difficult. I would be curious to see how much everyone's votes really matter in comparison with the large holders.

Why dont you start a poll asking how many BTSX people have.

Quote from: bytemaster on September 22, 2014, 11:03:01 PM
Voters elect delegates that upgrade as they wish.

How consolidated are btsx shares at this point?

I remember the idea of a btsx rich list was tossed around but with TITIAN I would imagine it might be difficult. I would be curious to see how much everyone's votes really matter in comparison with the large holders.

Quote from: Thom on September 23, 2014, 03:52:56 PM

Quote from: trader on September 22, 2014, 11:04:34 PM
Upgrading the protocol is easy if the community understands why it is being done and agrees with it, and/or trusts the lead developers. The lead developers simply update the software and users upgrade. Its no big deal.

Also, updates include checkpoint ids which deal with forks.

No offense, but that sounds dismissive. An earlier post indicted the problems that occurred with Bitcoin in 2013 when some of the clients didn't upgrade, thus making it difficult to integrate the pre / post fork chains to ensure a trustworthy bitcoin network. It became a big deal for Bitcoin when everyone didn't upgrade. Is that scenario also possible with BitShares and if not why not? How is it different?

In bitshares client upgrade is irrelevant. As long as some delegates upgrade the network will continue to function normally.

Quote from: trader on September 22, 2014, 11:04:34 PM
Upgrading the protocol is easy if the community understands why it is being done and agrees with it, and/or trusts the lead developers. The lead developers simply update the software and users upgrade. Its no big deal.

Also, updates include checkpoint ids which deal with forks.

No offense, but that sounds dismissive. An earlier post indicted the problems that occurred with Bitcoin in 2013 when some of the clients didn't upgrade, thus making it difficult to integrate the pre / post fork chains to ensure a trustworthy bitcoin network. It became a big deal for Bitcoin when everyone didn't upgrade. Is that scenario also possible with BitShares and if not why not? How is it different?

Quote from: questionsquestions on September 22, 2014, 05:58:31 PM

Quote from: bytemaster on September 22, 2014, 05:30:47 PM
In BTSX exchange you always "get what you ask for" in the exchange... ie: if you are willing to pay X per Y then you will pay X for all Y even if some Y are available for less than X.   This prevents front running and encourages traders to trade on value rather than technicals.   If you want a "market order" that will have to be done slowly via multi-step process.

Ok, that makes sense. What about the other questions? I find it slightly hard to believe:

Quote from: clout on September 22, 2014, 05:25:14 PM
Basically BitShares has no limits lol

however well thought-out and implemented Bitshares may be.

It generally makes it easier to convince people of the merits of a system if you can also indicate its short-comings. Bitcoin has plenty of shortcomings, but it does have the benefit of the network effect.

I'd appreciate if anyone can provide any more detailed answers to the questions I've asked.

Thanks once again.

I provided the answers to your question in my original post in bold.

Upgrading the protocol is easy if the community understands why it is being done and agrees with it, and/or trusts the lead developers. The lead developers simply update the software and users upgrade. Its no big deal.

Also, updates include checkpoint ids which deal with forks.

Voters elect delegates that upgrade as they wish. 

Quote from: questionsquestions on September 22, 2014, 10:51:25 PM
Thanks for the answers. This response:

Quote from: bytemaster on September 22, 2014, 06:14:27 PM
The question is perhaps poorly phrased:  Bitcoin could easily be hard-forked to support 1000 transactions per second, but then it would become fully centralized and everyone would have to use light weight clients.

begs one question; does Bitshares have a mechanism for enforcing protocol upgrades? As you mentioned, Bitcoin can be hard-forked - but the inherent risks are significant if a majority of the network does not follow suit. Where the majority does not upgrade, there is a high likelihood of two chains occurring as happened back in 2013 in Bitcoin when an upgrade of the database storage introduced blocks incompatible with legacy clients.

If two or more chains exist for any period of time, there is likely to be a cascade loss of confidence in the system. This, as I understand it, is one of the primary reasons that upgrading Bitcoin is so difficult. So, does Bitshares have some way of managing this?

This question is very important and must be addressed.

Thanks for the answers. This response:

Quote from: bytemaster on September 22, 2014, 06:14:27 PM
The question is perhaps poorly phrased:  Bitcoin could easily be hard-forked to support 1000 transactions per second, but then it would become fully centralized and everyone would have to use light weight clients.

begs one question; does Bitshares have a mechanism for enforcing protocol upgrades? As you mentioned, Bitcoin can be hard-forked - but the inherent risks are significant if a majority of the network does not follow suit. Where the majority does not upgrade, there is a high likelihood of two chains occurring as happened back in 2013 in Bitcoin when an upgrade of the database storage introduced blocks incompatible with legacy clients.

If two or more chains exist for any period of time, there is likely to be a cascade loss of confidence in the system. This, as I understand it, is one of the primary reasons that upgrading Bitcoin is so difficult. So, does Bitshares have some way of managing this?

Quote from: bytemaster on September 22, 2014, 07:33:34 PM
Light weight means there is trust.   That trust can be placed in anyone running a full node and can be redundant (checking with more than one source).   

I really don't like the sound of that. Can't we argue that lightweight clients trust that the delegates have little incentive to falsify blockchains since they will eventually be caught and fired? I see no reason why the lightweight client can't keep proof of transaction existence (Merkle branches and block headers) signed by delegates for all received funds so that if they later find out it was invalidated by a double-spend they can broadcast the proof to the network for all the full clients to vote out the evil delegates (actually the lightweight clients could check the proof and vote out the evil delegates too).

Quote from: drltc on September 22, 2014, 07:16:00 PM

How would a lightweight client keep track of which delegate signatures are legitimate?

Wait, they could just check if a majority of known-legitimate delegates accept a block produced by a new delegate.

But if the delegate turnover rate ever exceeds fifty percent in one round, then the lightweight clients would be unable to pass that point, and in-fact the kicked-out delegates would be able to form their own fork.

But wait a minute, a fifty-one delegate bloc could make a fork that even heavyweight clients would accept.  I guess this objection is irrelevant because you always trust fifty-one delegates, heh.

Light weight means there is trust.   That trust can be placed in anyone running a full node and can be redundant (checking with more than one source).   

BTSX by its nature cannot support light weight client validation (no Proof of Stake coin can).   Light weight clients simply trust those with full clients. 

If you need "heavy trust" then you can ask the heavy weight client to post a bond and sign under risk of forfeiture of their bond.   This will allow you to trust them for amounts up to their bond + value of all future revenue and trust they may have in the industry.

How would a lightweight client keep track of which delegate signatures are legitimate?

Wait, they could just check if a majority of known-legitimate delegates accept a block produced by a new delegate.

But if the delegate turnover rate ever exceeds fifty percent in one round, then the lightweight clients would be unable to pass that point, and in-fact the kicked-out delegates would be able to form their own fork.

But wait a minute, a fifty-one delegate bloc could make a fork that even heavyweight clients would accept.  I guess this objection is irrelevant because you always trust fifty-one delegates, heh.