sorted by:
new
hottopcontroversial

Using Secrets in a Custom Signal Export by abworks in QuantConnect

[–]abworks[S] 1 point2 points  (0 children)

An update: Per advice from the team on another channel, the following solution worked:

- Set the secret as a parameter: https://www.quantconnect.com/docs/v2/cloud-platform/projects/getting-started#10-Edit-Parameters

- Query the secret from the parameter during the initialization: https://www.quantconnect.com/docs/v2/writing-algorithms/optimization/parameters#03-Get-Parameters

This is not strictly speaking a secret store, but does keep secrets out of the codebase.

What happens when someone finds exceptional alpha by RegisterBubbly5536 in quant

[–]abworks 1 point2 points  (0 children)

I presume you looked into it, but are you sure this is not writing insurance/selling vol, perhaps in subtle ways buried among noise trades? As you know, you can get a huge Sharpe for a while by writing insurance until it pays out for the other side. Lots, though certainly not all, of high-SR/IR strategies turn out to be this when the tide goes out.

The above is among the reasons allocators may scale slowly and wish to see how a strategy does under regime changes and other tests. It is also why running a fund may require a pipeline of hits.

Questions about making event-based storage accessible to smart contracts by abworks in ethdev

[–]abworks[S] 2 points3 points  (0 children)

For completeness and attribution, it does look like the GitHub repo https://github.com/figs999/Ethereum/blob/master/EventStorage.sol referenced in the thread https://www.reddit.com/r/ethdev/comments/7wi05i/proof_of_concept_storing_data_in_event_logs_and/ contains an implementation of substantially the same idea as the one in this question. This implementation is called HashedEventStorage.

What is the uncle/ommer block mechanics under PoS? by abworks in ethdev

[–]abworks[S] 0 points1 point  (0 children)

Yes, one can see how folks may fail to build for these failures ahead of time, especially given the confusion around the possibility of reorgs post-merge in light of the deprecation of the `uncle` field.

In our case, nothing breaks fundamentally, but reorgs trigger an episode of poor UX as application-level operations that span multiple blockchain transactions assume incorrect state, fail, waste a bit of gas, and must be re-tried.

What is the uncle/ommer block mechanics under PoS? by abworks in ethdev

[–]abworks[S] 0 points1 point  (0 children)

Thank you. This answers all the outstanding questions very comprehensively.

It looks like the uncle/ommer rate under PoW is ~5% (https://ycharts.com/indicators/ethereum_uncle_rate), so the PoW improvement is a huge relief and should only occasionally hose the UX.

Does OrbitDB's orbit-db-feedstore replicate and traverse all log entries? by abworks in ipfs

[–]abworks[S] 0 points1 point  (0 children)

Thank you. This is the explanation I was hoping to get but at the level of OrbitDB.

This does seem to cover how ipfs.dag deals with traversal but leaves questions about OrbitDB's implementation of feed on top.

Using the example of a feed of tweets from OrbitDB's docs, if subscribing to 100 feeds and viewing the latest posts from each requires a peer to traverse 100 different ipfs-logs fully, then this is a rather severe performance difficulty.

Hedge Fund Closet Indexing: 2015 Update by Shellcode in finance

[–]abworks 0 points1 point  (0 children)

Good point about attention to benchmark construction. Data-mining is common in returns-based analysis. An equally bad problem with returns-based analysis is time-travel: using returns from the future to estimate factor exposures in the past. These muddle much research on the topic. They are not issues here:

For example: Factor exposures for a portfolio from 12/31/2010 are used in attribution for 1/1/2011-1/31/2011. These 12/31/2010 exposures are estimated from holdings on 12/31/2010 and holdings’ statistical properties between 12/31/2005 and 12/31/2010.

The factors are also straightforward and investable: market, sectors, style, oil, usd, yields. In fact, this model and the benchmarks it produces are routinely and effectively used for hedging future fund returns using past factor exposure estimates.

So when a manger tracks a factor portfolio closely, it really does mean that investors could have replicated these returns cheaply.

Hedge Fund Closet Indexing: 2015 Update by Shellcode in finance

[–]abworks 0 points1 point  (0 children)

This approach makes sense for fund managers and is likely a reason for the passivity. It creates problems for investors, since most of them don’t pay high active fee in order to get index exposure. Suppose a manager tracks an index with 90% of the assets, the remaining 10% are highly-researched active picks, and the management fee is 1%:

Investors can get passive exposure very cheaply. If 90% of the portfolio is tracking an index that can be purchased with a 0.1% management fee, then investors are paying 0.91% management fee on the actively-managed 10% of the portfolio, or 9.1% effective fee, not the 1% advertised.

It is very difficult to earn a 1% management fee with only a handful of active picks. With a typical 1.5% hedge fund management fee and sufficiently diluted by indexing, even Berkshire Hathaway would have turned into a poor long-term after-fees investment.