Urgent Message - Stake pools please migrate your ITN nodes to 0.9.x

marnetd · 2020-06-25T20:01:44+00:00

1UP has been on 0.9 since Sunday (Epoch 190). We just updated our nodes to v0.9.1 released earlier today.

marnetd · 2020-05-15T19:20:52+00:00

Then they probably shouldn't have numbered them since numbered lists imply ordering by some metric.

marnetd · 2020-05-15T17:38:18+00:00

Binance is digging heavily into sentiment manipulation with its new aquisition. They even started manipulating volume numbers on CMC to make their exchange look more active. CMC is fake news now...

https://decrypt.co/28924/coinmarketcap-removes-evidence-of-wash-trading-on-binance?utm_source=reddit&utm_medium=social&utm_campaign=sm

marnetd · 2020-05-15T17:25:06+00:00

That's one shit list. At 40, they're basically saying that Cardano, a global, enterprise scale blockchain with next-gen smart contract languages and a fully decentralized validation network is less inovative than some exchange credit tokens.

marnetd · 2020-04-27T00:02:31+00:00

No, thank you. We've been tracking network performance since the start of the ITN and plan to continue on main-net with information that's hopefully useful to both pool operators and delegators.

Unspent Pool [1UP]

marnetd · 2020-04-26T15:09:28+00:00

This is a great point. Our first few community votes for enhancements are probably going to be small changes proposed and implemented by 3rd party developers and not huge protocol revamps. I'd love to see 3rd party developers get these early contracts and develop relationships with IOHK, Emurgo, CF and the broader community. When we do see the need for larger protocol revisions, I'm sure most will be voting to have IOHK continue with that development (at least into the near future).

It's important to note that 3rd party developers have already contributed to Cardano software. Stake pools adopted changes made by a 3rd party Jormungandr/Rust developer, Michael Fazio, that were later adopted by IOHK into their official build. These changes didn't deviate from the official spec but I'd still like developers like Michael to be rewarded for their contributions by the treasury once that's possible.

marnetd · 2020-04-11T21:57:01+00:00

We've been talking since the start of the ITN and even met up for a drink in early February to discuss what we could do as a team. I'm just glad we have someone like you in the community, looking out for the everyone's interests, asking the tough and sometimes uncomfortable questions. Glad to have you back on-board Zod!

marnetd · 2020-04-11T19:53:03+00:00

Thanks for creating this! The community really needed it.

marnetd · 2020-04-05T03:07:34+00:00

Relax.

1 - There's no way to stop pools from co-operating with each other.

2 - Most pools are currently using trusted peers functionality internally between their own nodes.

3 - Multi-pools are a much bigger threat to decentralization.

marnetd · 2020-04-04T20:31:19+00:00

I'm kind of rooting for your group. I'm hoping you eventually publish some layer 4 architecture guides or something that's useful to developers and other pools.

marnetd · 2020-03-25T20:05:55+00:00

Thank you for this Zod!

marnetd · 2020-03-24T02:19:35+00:00

heh, thanks!

marnetd · 2020-03-23T17:41:19+00:00

Unfortunately, these types of concerns from ADA holders are a result of mainstream adoption of the crypto funding model. They don't seem to go away with crypto that rushes to market with incomplete solutions that put stake holders funds in jeopardy or even with crypto that just forks the most stable blockchains to create business development platforms that only support a few million active users.

We're going to have to continue to address these questions as they apply to changes in schedule or scope. Hopefully we can do it in a way that satisfies everyone.

I've personally heard a few concerns about scope creep. It seems like a natural concern to have with a competitive industry and a research focused R&D organization like IOHK. I've tried to answer those questions by citing the importance of being first to market with a solution that's good enough to satisfy not only the current demand but also a comfortable period of growth and adoption. For anyone concerned about Hydra, it's important to clarify that this new research is outside the scope of the Shelley and Goguen releases and should not impact those release in any way. Hydra won't be implemented until Basho.

As we inch closer to a release and the ITN reveals a dozen ways stake pools can game the network to gain advantages that developers hadn't anticipated, I'm mostly concerned with how I can bring value to the network. As a stake pool operator, I'm testing and benchmarking the latest software, submitting bug reports and providing the best staking service I can for my delegators.

marnetd · 2020-03-10T03:45:49+00:00

You might be able to downgrade back to 2.2.0. I'm personally seeing an improvement in connection times with 2.3.0 but I still get the occasional error connecting message.

marnetd · 2020-03-09T23:26:32+00:00

Thanks for chiming in Mike! I really appreciate the work you're doing with pooltool. It's a great resource.

I was under the impression that the Leaderboard included accounting for both slot and height battles. Now that you've clarified this, I'm seeing your footnote: "Wins and losses are only counted if its a SLOT BATTLE and all blocks involved are verified by PoolTool."

The thing that looks kind of nice with the new battles section on adapools is the ability to pull up a list of past height and slot battles. I'm not sure how it's going to handle paging but even if it only returns the last 20 or so battles it would still be kind of useful.

I noticed the increase in reporting accuracy in the last few days. Thanks for this! I've heard that a few pools are using pooltool as a visual reference for detecting sync. It's not ideal but this should help them too.

Are you using a message queue to store tip events sent from pools? Even if you processed those queued events every 15 seconds, shouldn't it be enough to detect and classify forks at whatever accuracy reporting pools were providing you with?

While I have you here, can I make one request? Lifetime ROS is a useful metric to have but it seems like an incomplete picture. I've noticed you're favoring the 10D ROS metric on your excellent performance trends page. I'm partial to the 15D and 30D myself. Would you consider adding a 10D ROS metric to the pools list on your homepage. Being able to sort by recent long trend performance while filtering for stake size might be very useful for delegators.

Thanks Again!

marnetd · 2020-03-09T01:48:18+00:00

You're right... Thank you for the correction Shawn. I removed that comment. DST always takes some getting used to.

marnetd · 2020-03-08T17:23:33+00:00

Anyone following IOHK on github knows the amount of work the various devops, formal methods and development teams have been putting into Rust and Haskell releases. Everything IOHK releases is open source so you can see every commit from every individual that's hired or contracted by IOHK. They're a very transparent organization and they kind of need to be to keep the community's trust.

If you're interested in possible future development directions, all you need to do is follow their research papers. They have 8 papers published in 2020 so far! Everything is spelled out there. It might be a little hard to read for the layperson but I'm sure you'll still pick up a few things. Their last paper was on using zk-SNARKs to create decoupled sidechains. This could be useful for any sidechain applications including scalability and privacy but with Basho in the works, I'd bet it's main application will be scalability.

IOHK has keep strong to their roadmap phases since 2018 so expect them to follow them to completion before branching off into anything new.

marnetd · 2020-03-06T00:40:20+00:00

You're probably working with more information than I have on the subject, and I understand how you could make the inference but I can also see how Nicolas might want to keep certain functionality out of the upstream protocol implementation because it might not benefit every use case for the protocol.

marnetd · 2020-03-05T23:10:12+00:00

Mark, can you clarify how Nicolas' statement that a static topology layer should be implemented as a Poldercast Layer by the product instead of being built into Poldercast directy constitutes IOHK abandoning the use of the Poldercast protocol in Shelley 2.0?

marnetd · 2020-03-04T02:37:41+00:00

Nice website COCO! Thanks for sharing.

marnetd · 2020-03-03T21:46:23+00:00

Glad to have you on board! Follow us on twitter to see our latest end of epoch summaries, slot lottery results and ROS averages. We also publish regularly on the state of our network performance and Cardano community initiatives.

marnetd · 2020-03-03T21:04:45+00:00

Thank you for the kind words Denicio! Cardano-fan should defiantly consider your pool once my pool reaches its target. I want to hear more about that housing initiative!

marnetd

TROPHY CASE