To any developers who are watching the current fiasco unfold, I have a suggestion for creating a DAC that I believe has a decent shot at beating the superDAC with minimal effort and expense. The Bitshares superDAC has the following weaknesses:

* The threshold for inflation is too low. By allowing inflation of up to 8% perpetually in the protocol, you end up with a situation where large stakeholders are able to "write their own paycheck" for lack of a better term. The biggest stakeholders in the superDAC will be I3, and for all intents and purposes they will be setting their own pay. It would take an almost impossible amount of stake (if you consider the avg participation rate) to "disagree" with their payrate and to vote them out. Any currency (even Bitcoin) allows for inflation. The difference is that inflation is not baked into the protocol, and would therefore require a far greater "stake" to implement (by modifying the protocol). Bitshares has ignored one of the main principles of crypto community: that scarcity should be (almost) inviolable.
* The second weakness of the superDAC is distribution. AGS distribution has already alienated a huge number of Bitcoin purists who are adamantly against "IPO coins". I don't necessarily agree with their philosophy, but there is a large segment of crypto users who will only invest in coins that have no IPO, no premine, and ONLY PoW distribution. The chaos that is unfolding with the superDAC has amplified the problem, possibly causing irreparable harm in PR and public distrust. I'm not speaking to intentions here. As they say, the road to hell is paved with good intentions...
* The last weakness of the superDAC is what I call "abuse of the DAC analogy". Let's face it, the killer app in the crypto-space has always been and will always be one thing: currency. And to be a good store of value, any coin that maintains the sanctity of scarce supply at the protocol layer, will be leaps and bounds ahead of the competition. What Bitshares gains in "marketing funds" they will lose in investor confidence (from the very investors they are "marketing" to). It is true that running a DAC like a business will result in a more agile and adaptive token. But I would argue that we should run our "business" with the aim of positioning ourselves as the best currency and store of value (the killer app). As I mentioned earlier, I believe the crypto-space is searching for a "unit of account" that will inevitably become something of a global reserve upon which everything else is built. The coin that wins this battle will NOT be Bitcoin (primarily due to the pitfalls of PoW) and it will not be the coin with the most advanced features (see Nxt). The coin that becomes the defacto world reserve must be appealing to governments and serious investors and must be perceived as (i) fairly distributed, (ii) scarce (non-inflationary), (iii) efficient (DPOS), and (iv) secure. Any feature built on top of this coin cannot be done at the expense of these 4 things. The superDAC has failed in distribution/allocation and scarcity.

Here is my proposal:

Someone should fork the Bitshares Toolkit and create a new Bitshares PTS that launches on November 5th (the date of snapshot). The new PTS should have nothing but the core Toolkit functionality (DPOS+TITAN). With DPOS technology, no inflation, and pure proof of work distribution, I argue that the new Bitshares PTS has a shot at dethroning the superDAC.

This is an experiment that can be conducted with minimal cost. The new PTS can always benefit from improvements made to the Toolkit, and if PTS wins I am sure Dan and the rest of the devs from I3 will jump on board (since they will have a large stake in PTS as well). If it loses then nothing much is lost.

****Edit: To my surprise, this has generated a lot of interest. Please DM me if you'd like to contribute to making it happen.
****Edit2: Organizing a mailing list for those who are interested: https://bitsharestalk.org/index.php?topic=10540.0

BM has repeatedly argued that current PTS is actually not very liquid and therefore PTS holders should be grateful to be "locked in" and "vested" in a more liquid BTS market. The crux of this argument is that, right now, you can't sell your PTS anyways since the market is too shallow to absorb any significant volume.

The fact of the matter is that the vast majority of PTS holders are small investors who could move in and out of their positions without significantly moving the market. This supposed "benefit" of liquidity in a deeper market is actually only a benefit for the handful of investors who (1) own extremely large amounts of PTS and (2) want the ability to rapidly invest/divest.

So it seems the entire structure of PTS allocation in the superDAC has been designed to benefit the wealthy at the expense of the average user.

Here's the trade-off for the vast majority of PTS users (95%):

* In the current PTS, average users do not face problems with liquidity.
* In the superDAC, average users will lose their liquidity by being "locked in" for 2 years.

Here's the trade-off for the extremely wealthy (top 5%):

* In the current PTS, wealthy users face problems with liquidity.
* In the superDAC, wealthy users are willing to "suffer" through the vesting period in exchange for something they don't currently have - liquidity.

Based on these arguments by BM, it appears that the proposed allocation for the superDAC was designed with the interests of the wealthy 5% superseding the interests of the majority of PTS users. Would love to hear a response other than "nothing is fair, we tried our best, deal with it", but I am not hopeful...

It was stated on this forum that each dollar of AGS donated prior to Feb 28th was equal to $6.6 of PTS. I think we can all agree that this difference was SOLELY due to the fact that PTS is liquid and AGS is illiquid.

It stands to reason that any plan for converting AGS to a liquid asset should provide exactly 6.6X greater equity for each converted pre-snapshot PTS. In other words, pre-snapshot PTS should receive 6.6X greater equity in the new DAC to offset the "gift" of liquidity granted to AGS holders. 6.6X is in fact the quantifiable "value" of liquidity, as proven by the market price.

Let's ignore post-snapshot PTS for the time being and talk about why this does or does not make sense.

Some criteria I use for selecting delegates (in order of importance):

1) Has the delegate revealed their realworld identity?

Exposing your identity is the single biggest deterrent to doing anything malicious.

2) What is their history/reputation in the community and forums?

Important, ideally in conjunction with #1.

3) Are they technically competent?

The client is not yet resilient enough to be managed by non-technical delegates. Delegates should be scripting their price feed updates and missed block notification, and should be able to react swiftly to attacks on the network.

4) Are they running more than 1 delegate?

I refuse to vote more than 1 delegate per person. Furthermore, if a person has more than a couple of delegates in the top 101 I will do my best to vote them ALL out. It is harmful and should be discouraged.

5) What is their payrate and usage of funds?

Obvious, but not terribly important.

Based on these criteria I think the quality of delegates needs to improve.

Right after displaying "calculating the last 3 digits of pi" the client crashes. Output:

Process:         BitSharesX [781]
Path:            /Applications/BitSharesX.app/Contents/MacOS/BitSharesX
Identifier:      org.bitshares.btsx
Version:         .. (..)
Code Type:       X86-64 (Native)
Parent Process:  launchd [157]
Responsible:     BitSharesX [781]
User ID:         502

Date/Time:       2014-08-20 10:57:04.019 -0700
OS Version:      Mac OS X 10.9.4 (13E28)
Report Version:  11
Anonymous UUID: 


Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called
*** error for object 0x7fff7d001330: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib           0x00007fff94f1e866 __pthread_kill + 10
1   libsystem_pthread.dylib          0x00007fff8fc7035c pthread_kill + 92
2   libsystem_c.dylib                0x00007fff8bbadb1a abort + 125
3   libsystem_malloc.dylib           0x00007fff954b107f free + 411
4   libstdc++.6.dylib                0x0000000113473bce std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow(int) + 302
5   libstdc++.6.dylib                0x00000001134778ce std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) + 62
6   libstdc++.6.dylib                0x00007fff95d63b44 std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) + 430
7   com.AdobeAAMDetectLib.AdobeAAMDetect   0x000000012d084239 NP_Initialize + 409
8   QtWebKit                         0x000000010f9986b5 WebCore::PluginPackage::load() + 245
9   QtWebKit                         0x000000010f99771a WebCore::PluginPackage::fetchInfo() + 42
10  QtWebKit                         0x000000010f8e8157 WebCore::PluginPackage::createPackage(WTF::String const&, long const&) + 55
11  QtWebKit                         0x000000010f8e4915 WebCore::PluginDatabase::refresh() + 677
12  QtWebKit                         0x000000010f8e440c WebCore::PluginDatabase::installedPlugins(bool) + 236
13  QtWebKit                         0x000000010f529e04 PlatformStrategiesQt::getPluginInfo(WebCore::Page const*, WTF::Vector<WebCore::PluginInfo, 0ul, WTF::CrashOnOverflow>&) + 1348
14  QtWebKit                         0x000000010f84b976 WebCore::PluginData::PluginData(WebCore::Page const*) + 134
15  QtWebKit                         0x000000010f831c4e WebCore::Page::pluginData() const + 46
16  QtWebKit                         0x00000001103324a1 WebCore::DOMImplementation::createDocument(WTF::String const&, WebCore::Frame*, WebCore::KURL const&, bool) + 305
17  QtWebKit                         0x000000010f796503 WebCore::DocumentWriter::createDocument(WebCore::KURL const&) + 147
18  QtWebKit                         0x000000010f795faa WebCore::DocumentWriter::begin(WebCore::KURL const&, bool, WebCore::Document*) + 106
19  QtWebKit                         0x000000010fa422cd WebCore::SVGImage::dataChanged(bool) + 669
20  QtWebKit                         0x000000010f87bc08 WebCore::Image::setData(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) + 104
21  QtWebKit                         0x000000010f77dd5e WebCore::CachedImage::finishLoading(WebCore::ResourceBuffer*) + 158
22  QtWebKit                         0x000000010f7c0935 WebCore::SubresourceLoader::didFinishLoading(double) + 133
23  QtWebKit                         0x000000010f96c331 WebCore::QNetworkReplyHandler::finish() + 257
24  QtWebKit                         0x000000010f96ac4b WebCore::QNetworkReplyHandlerCallQueue::flush() + 203
25  QtWebKit                         0x000000010f96df1a WebCore::QNetworkReplyWrapper::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 58
26  QtCore                           0x0000000112de7c6f QMetaObject::activate(QObject*, int, int, void**) + 1871
27  QtNetwork                        0x00000001123cbf41 QNetworkReplyHttpImplPrivate::finished() + 1153
28  QtNetwork                        0x000000011244cb2d QNetworkReplyHttpImpl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 1901
29  QtCore                           0x0000000112de0d7b QObject::event(QEvent*) + 747
30  QtWidgets                        0x000000010eec92dc QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300
31  QtWidgets                        0x000000010eecbd9b QApplication::notify(QObject*, QEvent*) + 6187
32  org.bitshares.btsx               0x000000010d64756e BitSharesApp::notify(QObject*, QEvent*) + 14
33  QtCore                           0x0000000112db45d7 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 631
34  libqcocoa.dylib                  0x0000000114e3aad6 QCocoaEventDispatcherPrivate::processPostedEvents() + 278
35  libqcocoa.dylib                  0x0000000114e3b478 QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) + 40
36  com.apple.CoreFoundation         0x00007fff913705b1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
37  com.apple.CoreFoundation         0x00007fff91361c62 __CFRunLoopDoSources0 + 242
38  com.apple.CoreFoundation         0x00007fff913613ef __CFRunLoopRun + 831
39  com.apple.CoreFoundation         0x00007fff91360e75 CFRunLoopRunSpecific + 309
40  com.apple.HIToolbox              0x00007fff8d9b1a0d RunCurrentEventLoopInMode + 226
41  com.apple.HIToolbox              0x00007fff8d9b17b7 ReceiveNextEventCommon + 479
42  com.apple.HIToolbox              0x00007fff8d9b15bc _BlockUntilNextEventMatchingListInModeWithFilter + 65
43  com.apple.AppKit                 0x00007fff9252624e _DPSNextEvent + 1434
44  com.apple.AppKit                 0x00007fff9252589b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
45  com.apple.AppKit                 0x00007fff9251999c -[NSApplication run] + 553
46  libqcocoa.dylib                  0x0000000114e3a1d4 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2420
47  QtCore                           0x0000000112db0acd QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 381
48  QtCore                           0x0000000112db4007 QCoreApplication::exec() + 359
49  org.bitshares.btsx               0x000000010d645ce0 BitSharesApp::run() + 2608
50  org.bitshares.btsx               0x000000010d6451b5 BitSharesApp::run(int&, char**) + 469
51  org.bitshares.btsx               0x000000010d626dc4 main + 20
52  libdyld.dylib                    0x00007fff993f35fd start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib           0x00007fff94f1f662 kevent64 + 10
1   libdispatch.dylib                0x00007fff8ec15421 _dispatch_mgr_invoke + 239
2   libdispatch.dylib                0x00007fff8ec15136 _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib           0x00007fff94f1ee6a __workq_kernreturn + 10
1   libsystem_pthread.dylib          0x00007fff8fc70f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib          0x00007fff8fc73fb9 start_wqthread + 13

Thread 3:
0   libsystem_kernel.dylib           0x00007fff94f1ee6a __workq_kernreturn + 10
1   libsystem_pthread.dylib          0x00007fff8fc70f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib          0x00007fff8fc73fb9 start_wqthread + 13

Thread 4:
0   libsystem_kernel.dylib           0x00007fff94f1ee6a __workq_kernreturn + 10
1   libsystem_pthread.dylib          0x00007fff8fc70f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib          0x00007fff8fc73fb9 start_wqthread + 13

Thread 5:
0   libsystem_kernel.dylib           0x00007fff94f1ee6a __workq_kernreturn + 10
1   libsystem_pthread.dylib          0x00007fff8fc70f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib          0x00007fff8fc73fb9 start_wqthread + 13

Thread 6:: com.apple.CFSocket.private
0   libsystem_kernel.dylib           0x00007fff94f1e9aa __select + 10
1   com.apple.CoreFoundation         0x00007fff913ada03 __CFSocketManager + 867
2   libsystem_pthread.dylib          0x00007fff8fc6f899 _pthread_body + 138
3   libsystem_pthread.dylib          0x00007fff8fc6f72a _pthread_start + 137
4   libsystem_pthread.dylib          0x00007fff8fc73fc9 thread_start + 13

Thread 7:
0   libsystem_kernel.dylib           0x00007fff94f1e716 __psynch_cvwait + 10
1   libsystem_pthread.dylib          0x00007fff8fc71c3b _pthread_cond_wait + 727
2   org.bitshares.btsx               0x000000010db1915c boost::condition_variable::do_wait_until(boost::unique_lock<boost::mutex>&, timespec const&) + 76
3   org.bitshares.btsx               0x000000010db16172 fc::thread_d::process_tasks() + 562
4   org.bitshares.btsx               0x000000010db1a7ca fc::thread_d::start_process_tasks(long) + 26

Thread 8:
0   libsystem_kernel.dylib           0x00007fff94f1aa1a mach_msg_trap + 10
1   libsystem_kernel.dylib           0x00007fff94f19d18 mach_msg + 64
2   com.apple.CoreFoundation         0x00007fff91361f15 __CFRunLoopServiceMachPort + 181
3   com.apple.CoreFoundation         0x00007fff91361539 __CFRunLoopRun + 1161
4   com.apple.CoreFoundation         0x00007fff91360e75 CFRunLoopRunSpecific + 309
5   com.apple.AppKit                 0x00007fff926c605e _NSEventThread + 144
6   libsystem_pthread.dylib          0x00007fff8fc6f899 _pthread_body + 138
7   libsystem_pthread.dylib          0x00007fff8fc6f72a _pthread_start + 137
8   libsystem_pthread.dylib          0x00007fff8fc73fc9 thread_start + 13

Friends, the PTS price has been dropping rapidly for the last few weeks. Dan has indicated that the maintenance and decisions related to PTS are no longer the responsibility of Invictus. The user "testz" has been tasked with maintaining PTS in accordance with the community's consensus. I created this poll with 3 options, but as we all know there are really only two paths forward. The current PTS chain is insecure and inefficient due to a low hashrate, high inflation, and other problems (difficulty adjustment, etc).

We need to decide how and when to proceed with an upgrade. Please vote and comment to indicate your preference as well as your preferred timing of the upgrade. I personally believe that PTS should be upgraded IMMEDIATELY as a standalone DPOS chain and should NOT be a user-issued asset in BTSX and here is why:

BTSX is essentially the first DAC. There are very ambitious features of the BTSX DAC that could fail spectacularly, independent of DPOS (pegged assets, for example). PTS should not be subject to the volatility and risk introduced by these features or future features that may be implemented by BTSX. PTS should be independent, both in price, volatility, and features from the DACs that are born from it. It should be the Switzerland of DACs, agnostic and separate from even the market perceptions of a DAC and its features. This way it ends up representing a more distributed and non-biased segment of investors who are not for or against any particular feature of any particular DAC, but who believe in the underlying protocol as a foundation (DPOS).

With respect to the timing of the upgrade, I believe it should be done urgently and immediately to prevent a further decline in the price and investor confidence in PTS. The upgrade should be seamless and relatively frictionless now that the large exchanges have implemented BTSX (implementation of any DPOS wallet is essentially the same). An advanced announcement of the exact block of the snapshot for the upgrade should be sufficient. If it is agreed, we will need people to reach out to cryptsy, bter and other exchanges to coordinate the timing.

With Invictus shifting their focus away from PTS, it is up to the community to make this happen and to stop the bleeding in PTS. Whatever your opinion, please make it known or nothing will change.

I heard of Invictus a while back and thought they were trying to do too much to be successful at any one thing. Recently I watched some discussions with Daniel Larimer about BitShares and I am becoming more and more convinced that he is on the right track.
The problem I see is that there is a serious branding and messaging problem with Invictus products. For example:

* protoShares (AKA bitShares PTS)
* bitShares AGS
* bitShares and bitShares X (one is an exchange/bank, the other stores equities for all Invictus DACs? Still confused about this)
* Keyhotee

Please do not take this the wrong way, but what the hell? Even worse than being non-descriptive and difficult, these names are way too similar for the separate and distinct functions they are supposed to convey. At the very least, IMO, the names need to be changed immediately if this project is expected to gain any mainstream traction. I would go even further and say that I don't think most of the early adopters understand what these products actually are. Here is just one list of suggested names, off the top of my head, though I am sure the community can do much better if we tried:

* ProtoShares -> BitFund (funds the whole operation)
* BitShares -> BitCorps (stores equity in multiple corporations/DACs)
* BitShares AGS -> BitCorps Angel Investor Fund (why call this a "share" if it is not tradable/liquid? For consistency I would just call this a fund).
* BitShares X -> BitBank or BitExchange
* Keyhotee -> BitIdentity or BitID

I'd love to hear your thoughts, as well as clarification on the issues I am not understanding correctly. Thanks.