Hey guys, just letting everyone know here that after a long hiatus that I'm back in business with helping with recoveries! I'm going to do my best to get back to people, but if I've missed your messages, please feel free to DM me again. Thanks :)

alt, did you really lose 1M (one million) BTS?

Settlement takes 24 hours.

If this is your account:

http://cryptofresh.com/u/kongblom-79

Simply create a new account and abandon that one. There are no funds in it so it's not worth your (or my) time to figure out how to get it back.

I would recommend you create a new Cloud Wallet, and make sure the generated password is kept safe, ideally in a password manager like LastPass or 1Password.

You must have been using a different account. The only thing that account has done is register.

http://cryptofresh.com/u/abfbv.adfvv-advavay

Quote from: chichagof on December 07, 2017, 06:40:55 AM
Hows it going,

Very simple but annoying mistake: I accidentally Sent >5000 BTS to http://bitshares-explorer.io/#/accounts/spectrum
When it should be here: http://bitshares-explorer.io/#/accounts/inward-spectrum

Is it possible to get this premium name? It doesn't look like its in use.

Any help would be greatly appreciated. Even if its a harsh reality check.

Thanks.

I'm sorry, but there's nothing that can be done here.

Hi everyone, I've just updated the main thread. I unfortunately have to start a minimum fee of $500 due to high demand. If you sent me a message before and I did not get back to you, please send me another message only if you are ready to pay the minimum fee.

Thank you,
Julien

askshare, if you need some recovery help, please add me on Skype at fluxanomaly627 and I will be able to assist you.

We will likely do conversion from BTS->USD->CNY to attain the feed price, but I'm not sure if the witnesses have this all figured out yet.

Never, ever use something like this.

Since the private key was generated by a 3rd party, it must be considered compromised. NEVER use a private key that wasn't generated on your own computer! THIS IS NOT A COLD WALLET

It's a good thing he didn't post the registered account name, because this has led you to post here, and see this warning.

If you really want a cold storage solution, please follow these instructions:
http://docs.bitshares.org/bitshares/user/security-cold.html

I would do a test run first, following instructions, depositing funds into the cold wallet address, adding the key to a hot wallet, and finally transferring the funds to a different account to confirm that you still have access. Once you are confident, you can do it for real.

Sorry this is so complicated, but it's the best option we have right now.

Quote from: pc on August 27, 2017, 02:55:51 PM
We have a mechanism in place, in the form of worker proposals.

But the overhead of creating worker proposals is rather high and not really appropriate for stuff like small bugfixes.

I read this as "Thanks for the suggestion, but we already have a mechanism, and that mechanism isn't suited for this."

Do you have any direct criticism of the method I outlined?

Quote from: lakerta06 on August 27, 2017, 07:41:10 AM
that must be the blockchain itself

While I ultimately agree, pragmatically it makes sense to not halt everything else to implement an on-chain solution. Besides, how would we implement this on-chain without a hard fork?

I think there should be a decided, known place where these bug fixes / hard forks are announced, with a "please speak now or forever hold your peace" kind of setup. If there is a big controversy about something, then we can take it to stakeholder vote. If not, then the update can be done without it.

Ideally, this should be done on-chain. This is how I imagine it:

1. A committee member creates a "hard fork proposal", which includes a brief description of the problem to be fixed or feature to be implemented.

2. At this stage, other committee members are assumed to a "yes" vote and must veto to "no" proactively. Otherwise, the feature is green-lighted to be developed after a certain amount of time, perhaps 15 days. If shareholders don't like the proposal and there are not enough vetos, then they can vote in committee members that agree with them.

3. After the feature/bugfix is developed and a release candidate is created, a committee member creates a "hard fork commitment proposal" which references the previous "hard fork proposal", and also includes the release hash and block number for the fork.

4. Witnesses commit to this, and when a supermajority of witnesses do, then the hard fork will activate at the block number.

@pc, would you be in favor of this being implemented if it did allow for price offsets?

Also, I think we should decidedly not support "offsets" from the price feed, as this loses easy parity with other tracked buyers/sellers. The only way to match these offset-tracked orders would be through normal limit orders (other than using the exact same offset, of course) which is at odds with this feature's intended benefit- reinforcing the peg. It's also a lot easier to implement without this, both core/UI wise.