I think we need to find a way for price discovery to happen with the TF still present, because otherwise the TF disappears at some point and all the dev work will stop until hopefully we figure out a pricing strategy.
It can take many different forms and I’m planning to write a blog post soonish about it.
@Cryptium:
Do you have an academic research background in CS or do you rather consider the Cryptium Labs leadership team members to be “hackers” who got into functional programming primarily through passion; or both?
How do you prioritize dedication to the projects you are involved in? How high is your commitment to the Tezos project in particular?
We DaiLambda are working on a new storage sub-system called Plebeia, version controlled append only file system using Merkle Patricia trees. Keeping Merkle hashes of tree nodes, it can provide Merkle proofs very quickly, we can use them to implement trustless wallets. We are currently testing a Tezos node with Plebeia and soon publish a blog/agora report about it. Since Plebeia’s Merkle hash is incompatible with the current Tezos context hash, if we want to fully use Plebeia in Tezos we need a protocol change for the context hash. It requires some more time, maybe in 008.
We also have a very little side project called SCaml, yet another high level language compiles to Michelson. It was born in our joint research with ReFX team of Kyoto university who studies a refinement type system for Michelson to produce sample smart contracts quickly. It is not very powerful language, but small and stable, and we love the name.
I’d say yes. You’d need the following markets:
In this scheme, it does not matter who funds the project (inflation / TF / Fangs).
Having a bittorrent style system for nodes to download snapshots would make bootstrapping a node a breeze.
Adding in a messaging layer for dApps to use for authentication is certainly worth looking into. I want to start by looking into what the state of Ethereum messaging (whisper and ssh) currently is, because then I can give a better fundamented answer.
It would be best to have price discovery begin naturally with individuals or teams that are not receiving a grant or subsidy. Otherwise it would be difficult to separate the two. There is additional work required in research, signaling to see if a proposal is useful, and the added risk of paying for development upfront.
We’d like to see static proofs of gas consumption, at least for some subset of Michelson with reduced expressivity. This would allow to have faster interpretation for those contracts. The Zen protocol had something like this, if I’m not mistaken.
I am personally working on trying to refactor Michelson. The idea being that it should then become much easier to improve it. Some people on the LIGO team might then dabble a bit.
I created two issues (bug reports #513, #516) on Tezos gitlab repo… wait, wait… 9 months ago! They are still open.
Are you working on fixing bugs?
I love the fact that there are several core development teams on Tezos. I’m wondering how existing core devs ie. you will react once previously unknown teams push out potentially competing proposals on chain without communicating this to you at all. Would that be fine? What’s the best way to behave as a new core dev team, from your perspective?
An alternative would be having two different peer-topper networks one that is responsible for handling protocol related tasks and the other that can be used more generically for example in such a wallet dApp communication layer.
Adding to this, besides dApp authentication and communication there are probably various use-cases where it does not make sense to put data directly on the chain but having such a separate communication layer that is still decentralized.
We actually recently started having dedicated people to triage issues. The hope is that they can go through the backlog eventually, but of course it will take a while and some may slip through.
Of course we are always working on fixing bugs 
Hey
I would like to understand how Tezos consensus mechanism differs or is similar to Algorand’s approach to solve the blockchain trilemma
What’s your view on core developers also running businesses like validators, on the same blockchains that they’re developing for, at the same time? Do you see potential conflicts of interest and what is your reasoning?
It would be interesting to see that happening in practice. From a core dev perspective I think we would look into the proposal and evaluate it and let the community know what it does.
In the end it would be up to the community/token holders/bakers to decide whether to adopt such a proposal though.
I hope this happens. It will be very interesting. So much more action and friction at that point, which I love about true decentralization! I see competition as a means for more innovation.
I split off from Nomadic Labs a year ago.
When I want to contribute to Tezos, I mostly discuss the different things I am working with the different parties to reach consensus. I found this consensus reasonable and not that hard to reach multiple times.
I am pushing to move those discussions in the open, as right now, a big part of it is still quite informal
and private (for lack of process/time than lack of will).
First of all, thanks a lot for the new Michelson docs, very handy 
Without an intention to start a holy war, are there any thoughts on migrating the economic protocol onto a lower level (and also a common compilation target) like wasm? Could it facilitate a multilanguage development (which is probably a good thing, some networks make this a cornerstone), or not worth it? Could it also ease/speed up interoperability between the shell and the protocol (afaik things weren’t smooth when connecting rust <-> ocaml)?
Nice. What is your view on someone not communicating beforehand and unexpectedly making a significant proposal on chain? Do you think from the perspective of the current core dev teams this would likely be frowned upon?
I think adding WASM as an execution target for smart contracts is an interesting choice that probably makes sense. The rest of the industry is moving towards it.
Whether it is feasible (or desirable) to execute the entire economic protocol in WASM is yet to be seen. Most chains that take this approach, such as Polkadot, Near and Solana aren’t multi-language on the protocol level, but rather the economic protocol is written in one language and all future versions are also written in that language.
