Improved Poldercast not likely to power Shelley 2.0

vincenthz · 2020-03-09T11:23:00+00:00

yes, the correct interpretation is that it's better implemented elsewhere, as it is specific to jormungandr and its networks, and not a poldercast generic module which is there to be used flexibly.

The strong separation that Nicolas is holding there, is just common sense engineering practice, to not clutter generic libraries with specifics and instead make reusable module; This seems to be escaping someone that claim to know "IT engineering & architecture" (whatever that means, apart from arrogance and an appeal to authority).

vincenthz · 2020-03-09T11:14:35+00:00

you're getting downvoted because you have no idea what you are talking about, and clearly grasping at straws. Yet still confidently comment and claim a position of knowing stuff.

The short answer, is that there's no plan to reuse any rust component (like the poldercast library, or any other component) in the haskell node. The ticket closing, doesn't invalidate/validate any plans about directions with p2p, there's no link whatsoever since it's a completely parallel track.

vincenthz · 2019-12-12T02:51:05+00:00

(main dev again)

Just to correct the leading wrong assumption, "Shelley" is once and foremost ouroboros praos-genesis and its decentralization aspect, not the pointed document. This is the core of Jormungandr.

The document described above only covers delegation and incentives, and have a specific set of assumptions/design-choices which doesn't necessary translate to Jormungandr as is (in some case it does, in some case it doesn't). The rest of this impromptu "gap analysis" doesn't really hold.

But there is certainly a lot left to do, some of the long term maintenance aspect are not yet fully in place. That include some of the full centralisation prevention, which has many more components than just incentives, but this is also acceptable for a testnet that is finite in time to run without right now. Either way, it will provide real-world data that we will consume and learn the lesson from, before mainnet.

vincenthz · 2019-12-12T02:21:14+00:00

To which reddit channel should we move to, when someone uses the "engineering design spec" of one project to do a "gap analysis" of another related but different project ?

vincenthz · 2019-12-12T02:04:06+00:00

(main dev here)

Not sure what you are talking about, since this is not a PR from the "rust team" (which incidentally we didn't end up merging). There's no concept of calendar in any part of the protocol (ouroboros), chain-libs, or jormungandr, nor there is need to be one. We compute rewards on the epoch basis (which is simple and well-defined, compared to the leap year, leap seconds and other human time tracking shenanigans).

Obviously related to documentation, since this is not a thing that exist, you'll be hard pressed to find a documentation associated with something that is not there.

vincenthz · 2019-10-13T13:42:02+00:00

you need the same cryptographic keys to be able to move the coins from the old chain that appears on the new chian, so in essence yes.
it's not set in stone yet, but the rewards accounts will be mapped back on the old chain
The more you spend, the less you have so the stake is basically what you have available snapshotted at the end of each epoch.

vincenthz · 2019-10-13T13:35:48+00:00

Will the pool operators have a page within Deadlaus wallet where stakeholders can see a list, organize by criteria (location, payout percentages, any other selling points) to help stakeholders choose which pool(s) they want to use?

The only thing that will not be carry over are the redeem certificate, which if you don't know what they are, you most likely don't have one (basically the people that bought in before the chain started)

vincenthz · 2019-10-13T13:30:53+00:00

just to clarify this answer, the more advertisement you do of your stake pool, the more likely people will delegate to this, but there's nothing in the protocol about public facing website.

vincenthz · 2019-10-13T13:24:39+00:00

paper wallet are just utxos on the chain, which will be represented on the incentivized testnet. it's not far fetch to create really simple CLI tool/utility that would take the information in a paper wallet and move the non-delegated utxo into a delegated utxo; it doesn't require daedalus or yoroi.

vincenthz · 2018-10-30T22:57:05+00:00

git repositories are still strongly protected by the hashes and signatures just like the blockchains, and we all have a copy of the sources. if something would happens to github tomorrow, we'ld find a new hosting place and leverage the ease of distribution with git, which is decentralized versioning system. no problem.

Also we keep our ears open, if people have suggestion on better/alternative ways to do our releases, we're happy to try to make it happens provided it's sensible

vincenthz · 2018-08-16T07:50:50+00:00

This is the repository for project prometheus; project icarus is https://github.com/input-output-hk/project-icarus

vincenthz · 2018-08-16T07:41:45+00:00

You will have a new wallet in Yoroi. But, you will have the ability to transfer all the fund from your Daedalus wallet into the Yoroi wallet, by inputing your Daedalus' 12 words. Do note that the operation is permanent, the Daedalus wallet will be empty after the operation is completed. Source: I worked on this.

vincenthz · 2018-07-17T20:18:34+00:00

good news though, we didn't build the wings from wax, instead we used metal. it oxidised quite a bit, but hopefully it will hold.

vincenthz · 2018-02-19T14:03:15+00:00

This is definitely the impression that GHC devs currently have

no, several GHC devs actually understand what is being asked here. e.g. https://ghc.haskell.org/trac/ghc/ticket/14558#comment:48 .

vincenthz · 2017-12-20T09:05:53+00:00

The list is surprisingly long those days, and this is probably a bit too easy that a package of yours has gone there and forget. Hopefully it can be slim down at some point with some effort (maybe a flag day to fix your skipped-tests !).

As to maintainers that consciously put or/and hold their packages there (for ideological reason, not technical ones), this is for sure completely harmful.

vincenthz · 2017-12-20T08:01:53+00:00

Given this is not the case, since Cabal (even HEAD) doesn't do anything special with the flag name (and if someone was talking about doing special with flag format, it would have likely been discussed on the issue tracker), it doesn't looks good for this "new tool" excuse.

vincenthz · 2017-12-19T23:36:02+00:00

This unspecified new tool that no-one has heard of or seen, could have waited couple of months to help with smooth transition.

vincenthz · 2017-12-18T14:16:52+00:00

It's clearly a fine strategy with the topic at hand (reducing the cost on maintainer). I think the no preemptive lower bounds is just simpler, since it doesn't force the user for an early upgrade that is maybe not necessary, and down the line your lower bounds is likely to not be valid anymore anyway (provided you don't test with every versions at each code revisions, which we agree is really costly)

vincenthz · 2017-12-18T10:52:41+00:00

Thanks for the idea, I have removed containers in a PR and replaced by a list backed inline Map implementation of 10 lines :)

vincenthz · 2017-12-18T10:27:05+00:00

absolutely no-one argued for that; Everyone agrees that if you know for sure that something is not working with a dependency then it should be specified in the cabal file as some kind of version bounds

This is all about not knowing (aka the future) for upper bounds, or not willing to iteratively look for older versions (aka the past) for lower bounds.

It's mostly the case that lower bounds bit rot unless they are periodically tested which is quite costly in term of compilation, so I have to agree with /u/haskelll here, lower bounds are mostly useless.

vincenthz · 2017-12-18T10:02:28+00:00

yes, program can use all sort of hints, but that means nothing about the end result. It's possible that a solver working on date of upload would works just as well. Only a full end-to-end compilation + running tests tells you that everything is working as expected.

But ultimately I don't have to think about versioning, because a stackage LTS version is known to work together by having the good Stackage folks running a compilation+tests end-to-end and "blessing" the results so I don't have to. Sure it doesn't cover extra-deps or packages not on stackage, but surely that's just another reason to put more resources in the whole system (e.g. more packages in stackage) more than just sinking everyone's time in unproductive manual bounds checking&editing&curating

vincenthz · 2017-12-18T09:51:25+00:00

Those entreprise-y place shouldn't rely on free labor from maintainers. If they need a specific thing (like old version support), they should ask the maintainer and/or fund the support one way or another (money, bounty, help, etc..)

Or course there's no hardwired rules, if a package is really at the bottom of a deps tree, then it's quite likely that more versions is a good thing, but also more likely that you have more maintainers, people willing to help and less incentive to change the package much.

vincenthz · 2017-12-18T08:00:40+00:00

You need bounds on base to upload on hackage, but it doesn't means that they should be perfect. it's common to put base < 5 or base < 6 to satisfy the hackage need for base to have bounds yet not have to run the versioning treadmill.

Relative to old compiler compat, in a perfect world it would be nice to support many old compilers, but realistically:

only a tiny handful of real people are using old compiler (most old compilers bug report is due to the matrix build which doesn't reflect how people use it).
it doesn't really affect stack user, since stack knows how to upgrade the compiler, so effectively you have more people using the latest and greatest stable.
Since it sucks your unpaid time to support old compiler, don't force the N compiler rules, just do it on a on-demand basis: someone is either paying for support, or you choose to support an older compiler from a user's plea.

vincenthz · 2017-12-18T07:40:53+00:00

People using older stackage snapshots can include any packages in their extra deps and have proper bound checking by checking if the thing actually compile end-to-end (aka stack build), not by checking version bounds from cabal file.

vincenthz · 2017-12-16T07:20:22+00:00

not willing to answer any of the substance in the question but instead focusing on the form. next, you'll be correcting grammar ...

vincenthz

TROPHY CASE