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

Settlement takes 24 hours.

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

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

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

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.

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?

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.

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.