Also the websocketpp deflate code is very new, so it might be a novel bug in websocketpp.  A quick run-through of the websocketpp issue tracker shows some known race condition crash bugs in websocketpp [1] [2] [3] and it is not out of the realm of possibility that one of these leads to a use-after-free.  Some of these bugs are TLS only, so it is possible that disabling TLS fixes the issue.

[1] https://github.com/zaphoyd/websocketpp/issues/459
[2] https://github.com/zaphoyd/websocketpp/issues/451
[3] https://github.com/zaphoyd/websocketpp/issues/336

Possible memory corruption?

If you're running head instead of the last release, there are three changes in FC which might be the cause of the problem:

• websockets now compress data
• websocketpp dependency has been updated
• Use-after-free bug was fixed in future.cpp

If you could run this command:


(cd libraries/fc/vendor/websocketpp && git log -1)


it would be useful.  I'm thinking it sounds like you upgraded an existing source checkout, so it might be possible you updated submodules non-recursively, meaning you'd get the new FC code but older websocketpp code, and maybe the new FC code requires more recent websocketpp (I'm just guessing here).

Quote from: mint chocolate chip on March 10, 2016, 02:36:02 PM
Unless you actually referred annual members...those referrers get screwed.

Most of the 31 annual members were either registered by OpenLedger or existed at genesis.  There are exactly four actual referrals of annual memberships, by three people.  If the community thinks reimbursing them is important, it would be possible to set up a worker to pay them manually (or make arrangements with an existing worker to do this).  One of those four annual memberships upgraded to LTM on its own, so their referrer has already been paid.  The remaining two referrers (two of the three accounts were referred by the same referrer) are:

1.2.97634 (referred annual member in block #3028579)
1.2.32176 (referred annual members 1.2.97382, 1.2.101152 who upgraded in blocks #1391978, #3255854)

This is my personal opinion, not an official Cryptonomex statement on the matter.

Annual memberships are broken [1].  Annual memberships are unpopular [2].  They have been disabled in the GUI for approximately one month [3], and were never implemented in the CLI wallet in the first place.

The developers have already sunk more time into the annual membership feature -- indeed have sunk more time into discussing the potential ramifications of deprecating AM's -- than the feature has ever generated in value for the system.  The code is broken, doesn't do what it's supposed to do, and isn't economically worth fixing (it's actually less complicated to disable the old version of the feature and re-write a new version of it from scratch).

Maybe the idea of pricing tiers and lesser memberships is sound.  Maybe it can be made to work.  That's a larger business / marketing concern, which is not really my area.  My area is code.  And from the standpoint of code, if this is an idea that will ever be made to work, then it will be made to work with different code than what we have.  The existing design and code of this feature is simply too broken [4].

The medium-to-long-term decision about whether we'll retire or re-implement annual memberships is still unsettled.  (Although my personal point of view is that, while marketing theory unequivocally says offering AM's should be beneficial, the data [2] equally unequivocally directly contradicts the theory, and experiment is the ultimate arbiter of truth for any real-world project.  Which is why BitShares, and for that matter the whole blockchain industry, is a grand experiment -- although there are a lot of economic theories out there, you simply can't know for sure how real people will act with real money in real economic systems until they're built and deployed.)  Anyway, whichever way the decision of whether to retire or re-implement annual memberships goes [5], the short-term first steps are the same on either route:

The existing annual membership code must be retired [6].  The existing annual members should be given some non-broken replacement for the broken functionality they received.  By far the simplest, least expensive thing to do is simply give them a lifetime membership -- which is a non-broken thing we already have that is similar to (and actually strictly better than) what they were supposed to get.  So we're planning to upgrade every existing annual member to a lifetime member shortly after the next release.

We've maintained radio silence on this, except for advising the committee that annual memberships should be disabled (by increasing the fee to 1 billion BTS).  For the good and simple reason that we didn't want to encourage buying an AM upgrade as a backdoor route to a cheap LTM upgrade (which it would be, if it had been publicly known that AM's will receive a free LTM upgrade in the near future).  Now that AM's are disabled, we're free to discuss what their future should be.

[1] https://github.com/cryptonomex/graphene/issues/539
[2] As of this writing, 31 annual membership upgrade operations and 5744 lifetime membership upgrade operations have taken place on the chain.
[3] https://github.com/cryptonomex/graphene-ui/issues/730
[4] Why this is much more broken than any other part of Graphene involves a bit of Graphene history, but basically what happened is that the requirements of the referral system gained a lot of complexity over time and co-evolved with the code during Graphene's mid-to-late development, leading to an implementation with a sub-optimal design.  Annual memberships were added last, which meant they both had the most existing constraints/complexity to work with, and the most time pressure (the release date was already starting to loom large at the time they were added.)  If there's a second time around for the annual membership feature, hopefully we'll have a much better idea of exactly what we want to build before we start writing code, not be developing an entire new blockchain implementation alongside it, and not be under the same kind of time pressure, which should lead to much better code.
[5] Because of how broken they are, leaving them unchanged is simply not a viable approach from a technical standpoint -- they don't get what they're supposed to get, and in some cases get nothing!
[6] It can't be totally removed because future releases still have to understand the way past releases handled annual memberships in order to sync from genesis to the current state of the chain.

Approved by init's.  FYI, we don't have to do this with the committee account, anyone can create a burn / refund worker.  The owner doesn't really matter for the burn/refund worker policies, since a worker's owner cannot change its policy (there is no worker_update_operation).

I've spent a lot of time investigating this and going over every line of code in the clear_expired_orders().  I can't find the problem from inspecting the code, and I do not have any way to reproduce it reliably.  If someone can provide specific steps or a specific datadir to reproduce it, I might be able to make progress in the investigation.

This should now be fixed on the BitShares branch.  I'm replaying in Debug mode now, I'll tag a release as soon as I make sure it finishes.

Quote from: bytemaster
We have a new release out that addresses some late breaking security concerns issues.  Most exchanges have already been notified.  There have been a series of releases over the past two days.  The most recent release fixes a operation numbering bug and is only necessary for those using operation ids.  Otherwise, the unannounced release made last night is identical to the release made today.   

We apologize for the rapid release (3 updates in 3 days), but would like to thank the community members (you know who you are) who helped us identify and fix a significant security vulnerability before any money was lost.

Today's new release 2.0.151216 is basically the same as yesterday's release 2.0.151215, but 2.0.151216 maintains the numbering used by 2.0.151209 and earlier for 1.11.x objects.

The renumbering in 2.0.151215 was an unintended, accidental side effect of fixing a critical security vulnerability.  Our first awareness of this vulnerability was when technical details of it were publicly posted.

The good news:

• The exchanges have been informed of the problem and the availability of a fix for about 20 hours now.
• If an exploit was attempted, it would leave evidence on the blockchain.
• We looked, and did not find any such evidence; no one has actually attempted to exploit this vulnerability.
• There has been no loss of funds (that we are aware of).
• Anyone who didn't get the word and is still running 2.0.151209 or earlier will realize they need to upgrade when they desync due to tomorrow's hardfork.

Some more details about the situation:

• In a private conversation, I found the longstanding community member who discovered the problem was already aware that security-critical vulnerabilities should not be publicly disclosed until a fix is available.  He simply had not realized the security implications of the problem he'd found -- a totally understandable human mistake, he did nothing wrong.  To his credit, after being apprised, he took it upon himself to delete technical details from his postings.
• As you can imagine, we felt under great time pressure to produce a fix as quickly as possible.  In addition a key developer had to leave suddenly in the middle of the day.  So we weren't able to test and review the patch as much as we would have liked.
• The nature of the vulnerability made it much more dangerous to exchanges than normal users.  We wanted to give the exchanges some lead time to upgrade their internal systems, as obviously exchanges are key partners in our community.  So we delayed posting about the release on this forum until we were sure the exchanges had their situation under control.

We're aware of the operation history renumbering issue and a patch which will restore the old numbering should be available soon.

OpenLedger's faucet script had a private workaround for one of the referral system glitches fixed by this release.  This private fix doesn't play nicely with the "proper" fix which was included in the new cli_wallet.

The correct people have been notified of the problem and how it should be solved; the faucet should be fixed soon.

Quote from: bytemaster on December 10, 2015, 03:03:03 PM
The final destination for all mail would be the blockchain

You need to read the paper more carefully -- you're no longer talking about Vuvuzela, but some hypothetical blockchain-based system that does things differently than Vuvuzela.  Vuvuzela's critical contribution is that it's scalable because it doesn't broadcast messages.  If you put messages on the blockchain, you're not only broadcasting them (which is more expensive than the way Vuvuzela does it) but requiring the broadcast nodes to archive them (broadcasting and archiving is even more expensive than broadcasting).

OP idea doesn't really specify how Vuvuzela protocol would interact with the blockchain or what would give the asset any value.

If you create an asset A and set the price feed of A to be a function F(x) of the price x of some other asset like


F(x) = x^n


then how many percent does F(x) move for a given percent movement of x?


log(F) = n*log(x)


So a d% gain in x will increase log(x) by log(d%) which will increase log(F) by n*log(d%), which is nearly log(n*d%) for small d, i.e. a 1% gain in X will lead to an approximately n% gain in F(x) -- and likewise a 1% loss will lead to an approximately n% fall in F(x):


log(F) = log(x) + log(1%)


Effectively A has the same gain/loss profile as borrowing money to invest in the underlying, then borrowing / repaying on the loan as needed to maintain the same leverage continuously as the price of underlying moves, without actually requiring any actual loan to take place.

There are a couple problems:

• A black swan is easier to happen in A than in an asset that tracks the underlying directly
• You have to find a counterparty who wants to invest in the opposite market at the same leverage ratio you do, which may be a very thin market for some pairs
• The new asset may need its own marketing independent of the underlying asset (especially if they have different feed providers)

Having a way for the system to automatically compute these derived feeds was on my wishlist for Graphene, but nobody seemed to care much about implementing leverage this way.

Quote from: BunkerChain Labs on December 10, 2015, 02:23:49 PM
A few witnesses have mentioned that they have replayed after upgrading, while the documentation states that reindexing will be required.

Replaying and reindexing are the same thing.

I'm used to thinking of it as "reindexing" because that's what Bitcoin and BTS 0.x called it, so I'll often say "reindexing" when I'm talking / typing on autopilot.  But "replaying" is the more "official" term used by Graphene and probably better describes what's actually happening (especially because Graphene has a ton more state than Bitcoin to support the markets, etc.)

A link to this should be posted in the witness status thread, https://bitsharestalk.org/index.php/topic,19040.15.html -- the thread is read-only to me, so I would appreciate if @bytemaster or a mod could post there.

New release 2.0.151209 at https://github.com/bitshares/bitshares-2/releases

Re-indexing will be required.  Hardfork takes effect at 2015-12-16 at 18:00 UTC.

This release incorporates numerous improvements and fixes.

List of changes
---------------

Market mechanics changes

- Refund order fee on cancellation #445
- Prevent margin call from executing unless feed < call #436

Improvements

- Several API calls added by community members (wackou, Scott Howard) #339
- Add propose_builder_transaction2 RPC

Bugfixes

- Fix referral reward percentages #449 #453 #455
- Improve wallet fee handling #434 #435
- Minor improvements to Javascript integration #439
- Unit testing improvements / bugfixes #413 #437

Cleanup

- Remove unsupported full_web_node and light_client #457

Hardfork #445 changes how we handle the fee paid to create a limit order.  Order objects will now have a deferred_fee field.  For orders created before the hardfork time, fees will be routed as currently and the field will be initialized to 0 to maintain compatibility.  For orders created after the hardfork time, the field will be initialized to the fee.  If the order is cancelled, the fee will be refunded to the order object owner.  If the order is matched, the fee will be routed normally.

Hardfork #436 ensures that you cannot be margin called if the feed says you have sufficient collateral.

This hardfork also retroactively corrects two bugs affecting the referral program.  First, the wallet incorrectly sets the referral percentage, resulting in most accounts referral balances being 1% of
what they should be.  In addition, annual memberships were not being handled correctly.

To ensure that the new code and old code do not split the network, we recommend vesting balance withdrawals should continue to be frozen until the hardfork date passes.