Lol whatever happened with this? Stan sounded so excited about it back in October, then it just kind of faded away. Feels like ever since STEEM came around all these huge possibilities for BitShares just went down the shitter. And why did Stan allude that the BTS market cap would "catch up to ETH this summer" not even three weeks prior to the STEEM announcement where the devs effectively put BTS on lockdown? I had naively assumed that all of Stan's rumblings of "something huge in the works", "just wait and see", et al actually meant that something HUGE was coming, but it seems that "secret sauce" was just STEEM all along. The whole series of events these past 2 months is completely bizarre to me.

...and I wish the forums here were active again. I've been here for nearly the past 2 years, and to see forum activity dwindle away to nothing hits right in the feels. And no, the steemit forums aren't a suitable replacement. 

In fairness to Stan, I think he has very little involvement with STEEM and is not an employee of Steemit. To the best of my knowledge, his primary role at Cryptonomex is still that of looking for opportunities for BitShares and graphene technology.

We now have two 100k-burn worker roles that are receiving pay ahead of the refund worker. See http://cryptofresh.com/workers. What's the difference -- this BTS doesn't go into the reserve fund? Is there any purpose to these workers?

EDIT: why is there even a distinction between burning and recycling? I must be missing something.

Funds put into the reserve pool can be used in the future as a "stockpile" to pay worker proposals. Burned funds reduce the supply of BTS instead of going into the reserve pool. So you vote for the refund workers if you want to have BTS in the future to spend for workers or you vote for burn workers if you don't want there to be as much available funding for workers in the future. The twist on all this is that voting for either decreases the chance for worker proposals to get funded.

I would expect (but don't know) that some are also using my python code for decoding of the memo.
Could you give me some more details of the error so that I can check if my code decodes correctly? Do you have a breaking example?

We put up a pull request with the fix here to allow for easy viewing of the change: https://github.com/cryptonomex/graphene-ui/pull/849

Quote from: dannotestein on May 18, 2016, 03:28:14 am

Quote from: arhag on May 18, 2016, 03:12:35 am

Why not include the flawed version of the algorithm as a backup in the web wallet (and maybe even the cli wallet) in case the correct version is unable to decrypt the memo? I know keeping this legacy cruft in the code would be annoying, but isn't it better than users being unable to view their old memos in a convenient manner?

We can do it if there's a significant interest, but I think this will effectively double the computational cost of decoding memos since the wallet tries to decode the memo in every transfer it sees and most of them won't be decodable. This still might not be that significant a cost, I really don't know, but also bear in mind only a very few old memos wouldn't be decryptable without this code.

I'm not sure why the wallet should attempt to decode the memo of every transfer it sees. It just needs to do so for transfers either to or from the accounts that are "My account". But even if that additional cost is too much, there could be an option in settings to only enable it for transfers dated prior to some specified date.

It does it because you can decode memos from transfers that aren't to or from your account as long as you have the memo key for one of those accounts (which is actually a very handy security feature).

I considered enabling it for transfers dated prior to the some date in the near future, but it's more work to figure out how to do that since the date will have to be piped into the decryption routines (I don't think it's readily accessible there now) and I'm not sure if it's worth spending time and money on to support a few old memos no one is looking at anyways, since there's a pretty hard limit on how many transactions you can see into the past in the web wallet anyways (a much more annoying limitation, from my point of view). As a practical matter, I suspect we use memos for automated processing more than anyone else except other exchanges and even we have no real use for those old memos. But if this rare case of backward compatibility is deemed an important enough feature, we can spend more time to get in, it's just a matter of cost (I'm charging half the cost of this work to the remaining balance in the blockchain maintenance worker that I've been saving for emergency work).

The biggest question I think is: Are any exchanges or other auto-processors of memos using the webwallet as their method for decoding memos? If so, I think we should add support for backwards compatibility for a little ways into the future. And if so, we could just add in the patch for the keys and leave it to SVK to handle the rest of it to keep the cost lower (he can probably do it faster than we can).

I was looking at how the fees worked on UIAs.
I see that a token can get transferred back to the issuer through transaction fees paid.

However, what if the issuer wants to take the token out of existence on receiving it.
Or simply remove tokens the issuer issued to himself thereby reducing the number of issued tokens.

Is this possible to do?

EDIT: I see the option to 'reserve asset'. Is this the equivalent of burning/destroying it?

From the source code docs, looks like you found the right command:

      /** Burns the given user-issued asset.
       *
       * This command burns the user-issued asset to reduce the amount in circulation.
       * @note you cannot burn market-issued assets.
       * @param from the account containing the asset you wish to burn
       * @param amount the amount to burn, in nominal units
       * @param symbol the name or id of the asset to burn
       * @param broadcast true to broadcast the transaction on the network
       * @returns the signed transaction burning the asset
       */
      signed_transaction reserve_asset(string from,
                                    string amount,
                                    string symbol,
                                    bool broadcast = false);

Both the BlockTrades bridge and the OpenLedger gateways depend on the command-line interface (cli) wallet to encrypt and decrypt transaction memos. We recently observed that very occassionally the cli wallet was unable to decrypt a memo that the web wallet was able to decrypt. This is potentially a very serious issue for automated processing of transactions as the platform scales to larger numbers of transactions, so we began analyzing the web wallet and the cli wallet to see where the difference lay.

Our initial suspicion was that there might be a hard-to-trigger bug in the relatively new secp256k1 library that replaced the traditional openssl library, but after some tests we were able to determine that both libraries produced the same results. Ultimately we were able to identify a bug that it was the loss of a leading zero in the shared secret calculation performed by the web wallet that caused the bug.

This bug was never apparent in the web wallet, because both the encryption and the decryption routines use the same flawed algorithm, and it only rarely showed up in the cli wallet in the fairly rare case where the first byte in the shared secret was 0x00 (probably 1 in every 256 memos on average, I suppose, assuming that byte value is randomly distributed).

We have a fix for the bug, but one side effect of the fix is that some small number of old memos will no longer be viewable in the web wallet. If someone needs to decrypt these old memos at some point, it would still be possible to view them using an older version of the web wallet. All future memos generated with the fixed code will be properly viewable in the web wallet and the cli wallet.

I believe this is the only reasonable solution to the problem, but of course it’s up to the community to make a final determination on this issue. If there’s anyone who objects to this change, please let us know as soon as possible.

Quote from: ag on May 14, 2016, 02:58:41 am

Quote from: dannotestein on May 13, 2016, 05:12:11 am

Quote from: freedom on May 13, 2016, 05:07:52 am

Quote from: newtree on May 13, 2016, 03:56:47 am

Quote from: freedom on May 13, 2016, 12:55:06 am

oh，delegate.freedom(1.6.63)，xman(1.6.64)，abc123（1.6.65） are friends。aliyun:2core4G，tthank you everybody!

freedom is a famous bitch in china，we are not friends[emoji34] ，shame you 茄子（freedom） 。

通过我的 MX5 上的 Tapatalk发言

oh no， I treat you as my good friend，you treat me as a XX man？we are all chives，we should help each other。

hmm, I think google translate is breaking under the strain here: "we are all chives"

lol. i've see this before. he means we are all "chive pickers" i think.

More likely he means they are "chives been picked", perhaps you are the pickers.. lol.

Quote from: dannotestein on May 12, 2016, 05:27:52 pm

got my vote, and thanks for your work, guys!

When you started voting (for 3 witnesses atm), number of active witnesses dropped to 25 from 27.

wow, I'm impressed to see our stake has so much impact nowadays. Guess I need to go vote for some more witnesses...