I have now fixed my feed prices and released a new version of my feed script adding Fixer, CurrencyLayer, Quandl, AEX, ZB, Livecoin as feed providers

Quote from: Fox on November 12, 2017, 08:34:59 PM
I support your worker proposal. Thank you for all your contributions to date and upcoming.
-Fox

couldn't have said it better!

Well, thank you @roelandp, SteemFest was a blast!! Organization was top-notch, people were awesome, and I haven't spent 3 days like that in a long time (if ever), my brain is still buzzing with ideas and discussions I had with people there (and ok, maybe, just a little bit of alcohol as well :P ).

It was very interesting to see that people had lots of ideas that they actually realized they could implement on top of BitShares, had they only known about it or its possibilities. I have been told more than once that people loved user-issued assets and it could help them implement their business ideas.

We, as a community, have always put forward the market-pegged assets (which are awesome in their own right), but UIAs actually solve a lot of problems for a lot of people, so maybe marketing efforts should focus a bit more on them in the future.

In any case, I think that this worker proposal was money well spent, as I could see that lots of people grasping the potential of BitShares, a "sleeping giant" (not my words), and I'll definitely be there for SteemFest 3!

btw, slides for my introduction can be found here: https://github.com/wackou/slides, and it would be great to ask @Chris4210 for his slides as well, his presentation was kick-ass and put BitShares under a really good light.

wackou - witness

I have signed NDAs as part of my daytime job which is completely unrelated to crypto, hence no conflicts of interest whatsoever. Have never signed an NDA related to my work in BitShares, and do not plan to.

Quote from: alt on September 18, 2017, 10:45:23 PM
remove my vote for wackou

fixed my feed, also thinking about how to make this more robust in the future when facing changing market conditions.

anyone has the hash of a recent block? I think I always end up on a minority fork (re-synced twice already), although close to 100% with mostly the init witnesses...

here's what I got:

info
{
  "head_block_num": 10806310,
  "head_block_id": "00a4e42671894c00043e33f98551e3e3e21b499f",
  "head_block_age": "8 seconds old",
  "next_maintenance_time": "2 minutes in the future",
  "chain_id": "39f5e2ede1f8bc1a3a54a7914414e3779e33193f1f5693510e73cb7a87617447",
  "participation": "91.40625000000000000",
  "active_witnesses": [
    "1.6.1",
    "1.6.2",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.23"
  ],

Finally, I am glad to announce that witness "wackou" is operational on the testnet, and eagerly awaiting some votes :)

Also ready to test BSIP-018 when the code is deployed to the testnet. Let's revive those black-swanned assets!

Quote from: George_Bitspark on July 22, 2017, 02:07:26 PM
Thanks for the investigation Wackou, so am I correct in saying that if the price feed had more witnesses for this asset and if the price feed is an average of witness feeds, this can help reduce black swans in future? Although such a sharp divergence in feed pricing likely still would black swan the asset even with twice the amount of witnesses correct?

that would have helped a bit maybe, yes. What is really needed is more implementations of the feed script. We currently had 3 witnesses publishing the feeds, but using 2 different scripts only (fox has his own, verbaltech and myself use bts_tools). So when my feed started failing, it automatically also failed for verbaltech. If we would have had more witnesses, but running only 2 scripts then maybe we could have noticed the issue earlier (when the first witnesses started to fail) and could have stopped it or started publishing manually before the median went off the rails. That is not a real solution, though, as it could have bought us a bit more time, but it would have happened anyway (as long as more than half of the witnesses are wrong).

But really, I think that what should be done is to have a maximum difference allowed between 2 consecutive feed prices to ensure that the price doesn't shoot up or down due to a bug. If needed (because the market really did go up or down that fast), this can be overriden manually to still publish the feed. I believe that xeroc's script work like that but I haven't implemented it yet myself. It jumped up a few places on my priority list, though...

so I investigated a bit, but I'm not really sure what caused it yet... if I run it now I get the correct results
given that that coincap returns no result for BCC, VERI, QTUM it is not used, meaning that the data is coming straight from CoinMarketCap only

let's look at the last feeds published for wackou, verbaltech2, fox:

wackou

FeedPrice: 1.75457e-06 BTWTY/BTS  569940.2132716278  (2017-07-20T20:59:57+00:00)
FeedPrice: 1.47023e-08 BTWTY/BTS  68016568.8361685  (2017-07-20T20:35:33+00:00)
FeedPrice: 1.47023e-08 BTWTY/BTS  68016568.8361685  (2017-07-20T20:29:27+00:00)
FeedPrice: 1.47023e-08 BTWTY/BTS  68016568.8361685  (2017-07-20T20:23:18+00:00)
FeedPrice: 1.70705e-06 BTWTY/BTS  585805.9224978765  (2017-07-20T20:11:06+00:00)
FeedPrice: 3.39766e-06 BTWTY/BTS  294320.20861416386  (2017-07-20T19:28:27+00:00)
FeedPrice: 3.39766e-06 BTWTY/BTS  294320.20861416386  (2017-07-20T19:16:15+00:00)
FeedPrice: 3.40805e-06 BTWTY/BTS  293422.92513314064  (2017-07-20T18:51:51+00:00)
FeedPrice: 3.40365e-06 BTWTY/BTS  293802.24171110423  (2017-07-20T18:27:27+00:00)
FeedPrice: 3.4317e-06 BTWTY/BTS  291400.7634700003  (2017-07-20T18:03:06+00:00)


verbaltech2

FeedPrice: 1.75844e-06 BTWTY/BTS  568685.8806669548  (2017-07-20T21:00:12+00:00)
FeedPrice: 3.38361e-06 BTWTY/BTS  295542.3349617716  (2017-07-20T20:04:54+00:00)
FeedPrice: 3.38991e-06 BTWTY/BTS  294993.0824122174  (2017-07-20T20:00:36+00:00)
FeedPrice: 3.40312e-06 BTWTY/BTS  293847.99830743554  (2017-07-20T19:05:18+00:00)
FeedPrice: 3.4082e-06 BTWTY/BTS  293410.0111495804  (2017-07-20T19:03:33+00:00)
FeedPrice: 3.43005e-06 BTWTY/BTS  291540.93963644846  (2017-07-20T18:03:42+00:00)
FeedPrice: 3.4321e-06 BTWTY/BTS  291366.8016666181  (2017-07-20T18:02:18+00:00)


fox

FeedPrice: 3.3770663424682977e-06 BTWTY/BTS  296115.0  (2017-07-20T19:51:39+00:00)
FeedPrice: 3.397962581636051e-06 BTWTY/BTS  294294.0  (2017-07-20T15:51:06+00:00)
FeedPrice: 3.3295376604004766e-06 BTWTY/BTS  300342.0  (2017-07-20T11:50:33+00:00)
FeedPrice: 3.362994948781587e-06 BTWTY/BTS  297354.0  (2017-07-19T21:13:06+00:00)
FeedPrice: 3.422653172286093e-06 BTWTY/BTS  292171.0  (2017-07-19T17:12:27+00:00)
FeedPrice: 3.470342453393301e-06 BTWTY/BTS  288156.0  (2017-07-19T13:11:51+00:00)


so on 2017-07-20, up until 20:10 every is fine, and then at 20:11 I start publishing a feed price that is slashed in half
at 21:00 verbaltech2 publishes his next feed and his price is also affected

at this point, this triggers the black swan and no one can publish feeds anymore. Fox not having published a feed since 20:11, we don't know if his code would have been affected too or not. Given that the script currently returns the correct feed price for me, I am tempted to say that this was a temporary glitch in the CMC api. I don't have debug logs from then, and the historical data on CMC looks clean, so there's no way for me to confirm this hypothesis either...

I don't think I'm going to spend more time trying to figure out what happened, but rather think about what can be done to avoid this type of situations in the future.

There are 2 areas I want to improve:
- there should be a check that the feed value is consistent with the previously published value. If not, user should be notified, and feed should not be published unless overriden manually (via the config.yaml file)
- we should keep historical data of all queries to external sources and persist it in a local db. This would allow to have a much better traceability with respect to feed queries and publishing.

Let's hope that pc manages to get BSIP-018 finalized quickly so that we can reboot the BTWTY market!

Awesome!! This has been a long time coming, and was (in my eyes) really a pain point and a weakness of the BTS blockchain. Glad to see this is finally getting fixed, and glad to see that pc is on it!  +5%

 +5% thank you very much for all the work you are doing for BitShares!

CAREFUL, this looks like a scam site, please do not use. Visit the official website instead, https://eos.io

Quote from: questionsquestions on June 28, 2017, 07:34:31 PM
Bitshares and EOS are different platforms. EOS is designed to be a generalized smart contracts platform like Ethereum, but borrowing some of the concepts from Bitshares and Steem (both were founded by Dan Larimer who is building EOS).

So, in answer to your questions; If you want to be part of EOS, you need to hold EOS tokens. Holding Bitshares does not entitle you to any share of EOS. EOS is using the Ethereum platform to distribute tokens, so you can buy some Ethereum and then send them to a special address and this will reserve you some EOS tokens. See https://eos.crowdsale.es/ for details. EOS tokens *may* at some point in the future also be available on the Bitshaes DEX (Distributed EXchange), probably via a gateway like OpenLedger.io (https://openledger.io)

Second question; Although EOS was built by the same guy that built Bitshares, its not clear (yet) what concepts (if any) will be applicable to Bitshares. There are lots of discussions going on in Bitshares development circles about how Bitshares and EOS may interact (or Bitshares may enhance itself with new technologies being built for EOS), but since EOS hasn't actually been built yet it's a bit early to know. Certainly, in the past Bitshares has benefited from developments on other platforms like Steem (Not Steam) for example, so time will tell...

great job! I know that personally I'll make use of at least partial-operations and get_block_header_batch to make my witness and monitoring tools more efficient. Thanks to everyone that contributed!

btw, small nitpick, but in the release notes you mention "It's highly recommended to run a NTP daemon". I would replace that with "It's required to run a NTP daemon". IIRC most of the latest issues we had on the network were because someone's clock went off because they didn't have NTP installed. Also, it's not like it's a hard requirement to comply with...

Will be updating soon

Quote from: sahkan on May 12, 2017, 05:19:39 AM

Quote from: fav on May 12, 2017, 05:12:31 AM
if you want to provide feed make sure to talk to xeroc first. last thing I heard was that there are not enough feed providers  registered.

I think @xeroc already knows, he is in our telegram channel and @wackou updated BTS Tools to 0.4.12 with HERO feeds as an option.

I think you need to send an email anyway to feed@hero.global to get on the list of approved publishers. See here: http://docs.hero.global/en/master/feedproducer.html

Quote from: Stan on May 08, 2017, 12:23:17 PM
Xeroc is helping, certafying and formally authorizing all feed providers.  PM him.

will do, thanks for the quick answer!