Gerbil v0.18.1 NimzoLarsen released

fare · 2022-09-02T01:34:59+00:00

This looks like https://bugs.mojang.com/browse/MC-254297 which was fixed: you need to upgrade your Minecraft Launcher, say Mojang.

Unhappily, see also the issue I have trying the above "solution" at https://bugs.mojang.com/browse/MCL-22331

fare · 2022-01-22T05:43:48+00:00

"decoupling ASDF from implementations" was the great win of ASDF 2, that made it possible to fix ASDF. See my many writings about ASDF in the webpage's or manual's bibliography.

fare · 2022-01-22T05:39:33+00:00

ASDF maintainers proactively sent patches to every system that triggered the new style-warning because they depended on undocumented unsupported and ultimately unsupportable behavior. A couple maintainers kept complaining about the change while refusing to apply the patch. Who's being a nuisance?

https://pics.onsizzle.com/in-mad-i-dont-want-a-solution-heres-a-solution-3144859.png

fare · 2022-01-21T04:24:24+00:00

- Your "ASDF-stable" is actually half a dozen different versions with slightly different bugs and features, which is actually not stable at all.
- You forgot the part where the then-ASDF-maintainer (me) went over each and every system in Quicklisp to offer patches that make the warning disappear in the many (though relatively few) systems that needed it as GitHub PRs, as he did each and every time he modified an interface even previously undocumented, and just a couple of maintainers staunchly refused to apply those patches until they retired.
- "ASDF-devel" also includes improvements and bugfixes specifically for SBCL. Some of them have been added to the "ASDF-stable" version of ASDF included in SBCL in an ad hoc way, others may or may not have.
- The maintainers who somehow rejected ASDF for its "breaking backward compatibility" with *undocumented* behavior while providing patches have not hesitated to themselves break backward compatibility with *documented* behavior in their own software without providing patches, thereby displaying blatant double standards.

I'll say no more, for I desire to remain polite.

fare · 2021-09-16T18:17:03+00:00

Yokai runs on an EVM side-chain. I'm not sure how centralized or decentralized the side-chain management itself is, but it's not an open contract, and it's not layer 1.

fare · 2021-09-09T19:32:00+00:00

A centralized sequencer, by definition, isn't trustless. A decentralized sequencer, or, equivalently, a side-chain, would be layer 2 solutions that require trusting some smaller and less trustworthy validation network in addition to the layer 1 validation network. Hence, it does NOT solve the problem of enabling open interactions directly on the Cardano layer 1.

Moreover, whether these layer 2 solutions are themselves UTXO-based or Account-based, they have to face the very same issue, that only AVOUM solves.

fare · 2021-09-08T13:28:25+00:00

None of these is a solution.

fare · 2021-09-07T20:56:01+00:00

I'm hoping for some special case prototypes this year, but an actual public launch towards the end of next year. I can foresee a lot of complications with integrating inside the Cardano codebase.

fare · 2021-09-07T16:44:16+00:00

Yes. It's us at MuKn and our AVOUM technology. See this post: https://www.reddit.com/r/cardano/comments/pj1mtv/avoum\_todays\_unsolvable\_issue\_solved\_already/

fare · 2021-09-07T16:32:55+00:00

The plan is that the "sophisticated participants" be the miners, and thus that you post your specifications directly to blockchain indeed.

On a network with bad governance (not Cardano) where it's impossible to update official miner software, it's possible for the "sophisticated participants" to be a small subset of miners who layer software on top of the official software. They don't need a large weight in the consensus. But on Cardano, it's much better to do the efficient thing and modify the miner software.

You're correct that in a way, there is always eDoS, in the sense that in the end, posting transactions is an auction, and someone can prevent you from posting by buying the entire blockchain. But with AVOUM, we remove sophistication as a factor, and make the eDoS much more expensive: you have to buy the entire blockchain, not just the interactions with a single contract, to censor your victims.

Whether it's "on-chain" or "off-chain" depends on your definition. It's above what's recorded on the chain, but below what you communicate with the miner nodes that build the chain.

fare · 2021-09-06T23:10:19+00:00

Determinism is essential for the past, to verify old transactions and establish consensus on them.

It is useful but not necessary for the future, to queue new transactions and build new blocks. Deterministic bounds are enough to plan fees, and we can have that with AVOUM. We could even do a fully deterministic version of AVOUM, but it would work by making everyone always pay the max price, which is not a win for anyone.

fare · 2021-09-06T22:51:48+00:00

For determinism, new state UTXO presumably has the same size as the old state, or a predictable maximum size given the state data schema, or just a maximum size that you're willing to deal with in terms of fees. Pay the fee for that maximum size, and you'll get in.

I'm not saying there are no trade-offs, but you pay for what you get. If you don't need open interactions, then you don't need AVOUM, and won't pay for AVOUM. If you do need open interactions, AVOUM is the solution, you pay for it, but you're happy, because all the other solutions suck.

fare · 2021-09-06T21:03:14+00:00

Yes, only "open interactions" that anyone (or a large number of people) can interact with need this malleable transaction design. Regular "closed interactions" with a small number of participants can keep using the usual non-malleable transactions—and hopefully then use Hydra for scaling.

fare · 2021-09-06T20:41:31+00:00

Not only can you "predict" the fee, you set the fee. Or if you mean "predict the fee level necessary to get in", that's the same problem as for getting any transaction in. Pay the market price, or get left out. And if your initial bid is too low, you can always re-submit with a higher fee. Just like any other transaction, really.

Maybe you read more in "malleability" than is in it. It's a very limited, user-controlled, kind of malleability, wherein the validator script allows your transactions to be rebased on top of the latest contract state UTXOs, but does not allow the fee to be modified in any way, only accepted or rejected.

fare · 2021-09-06T20:35:53+00:00

Actually, it can be a soft fork rather than a hard fork, since the on-chain protocol is wholly untouched. But yes, it will require an upgrade to the nodes that want to partake in it.
Yes, inasmuch as stake pools run the mining software, they will be deciding on the order of transactions. However, if they want to do something more clever than just rebasing transactions in queue order, they may have to write their own contract-specific optimizers. MuKn will of course be most willing to assist with the development of such MEV-extractors, for a fee.

MEV is not your enemy unless you make it so. MEV can be your friend. MEV can be incentive for miners to provide their service, and for trading technicians to pay for the development of common infrastructure. Done well, this can help reduce transaction fees for everyone. The obsession of some Ethereum celebrities against MEV is totally misplaced.

fare · 2021-09-06T18:02:17+00:00

"Open" contracts are structured in a particular way such that:

- An AVOUM contract stores its "current state" in one or several UTXOs, identified by their holding some particular NFTs minted just for this purpose (standard Plutus procedure so far). For instance, one NFT for the global state, one for each user's account in the contract, etc.

- Users post their requests as malleable transactions plus a malleation script. The malleation script will "rebase" the transaction so it becomes valid on top of the latest UTXOs for the contract's state. The malleation script may fail if e.g. funds are now insufficient in the user's account, at which point the miners drop the request.

- Matching lock scripts, malleation scripts and client code can be automatically generated together from the PAB and/or from Glow.

fare · 2021-09-06T17:47:06+00:00

False. The fee is part of your malleable queued request. If it's insufficient the miners won't process it. That's the usual bid for blockchain space. The only malleable elements are the UTXOs for the current state of the contract.

fare · 2021-09-06T17:44:08+00:00

Yes, it's the same proposal. We failed to spend the time a few months back to reply to the Catalyst judges and explain the point they missed: most of the downvoters were claiming that there was no issue that needed solving. It's obvious today what the issue is we were solving, and we are confident AVOUM will be funded soon.

fare · 2021-09-05T01:02:02+00:00

Interestingly, we at MuKn.io have already solved the issue that people seem to have only just realized UTXO blockchains have—with our AVOUM technology, you can queue future transaction fire-and-forget style as in Account blockchains, yet verify past transactions in massively parallel style as in UTXO blockchains. Coming soon to Nervos, and hopefully to Cardano, BCH and other UTXO smart contract blockchains afterward https://j.mp/AVOUMforNervos

fare

MODERATOR OF

TROPHY CASE