devtooligan

// @author original POC by @z0age


library pureConsole {

    /*********************
     * string + uint256
     ********************/

    function log(string memory errorMessage, uint256 value) internal pure {

PaulRBerg

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.19;

import { Script } from "forge-std/Script.sol";

abstract contract BaseScript is Script {
    /// @dev Included to enable compilation of the script without a $MNEMONIC environment variable.
    string internal constant TEST_MNEMONIC = "test test test test test test test test test test test junk";

    /// @dev Needed for the deterministic deployments.

wmitsuda

This gist was deprecated and promoted into a real repository!

Please see: https://github.com/wmitsuda/one-liner-archive

pagreczner

NFT Proxy

Overview / Goal

Proxy your NFT into a provable ERC-721 ownership format that can live in a different wallet from the proxied NFT. The proxied NFT can prove ownership while maintaining safety from the true asset by living in a different wallet. This proxied NFT can then be used safely for whitelists and other functions where signing a transaction may be connsidered "dangerous". This proxied NFT in theory could also be safely leased to other users in a way that NFTs can not be be done today.

Motivation

Many high end NFT collections that are have both significant underlying financial value and emotional value to users have become besieged by scammers and hackers. Part of the value in holding one of these NFTs is showing it off and being part of the community. However, in order to provably show it off you must expose your wallet to sign messages. Given the nascent UX in web3, it's not always easy to discern what is a trusted UX from an untrusted. And given that, there "should be a better way"

danopia

FROM hayd/alpine-deno:1.10.1
WORKDIR /src/app

ADD deps.ts ./
RUN ["deno", "cache", "deps.ts"]

ADD *.ts ./
RUN ["deno", "cache", "mod.ts"]

ENTRYPOINT ["deno", "run", "--unstable", "--allow-net", "--allow-hrtime", "--allow-env", "--cached-only", "--no-check", "mod.ts"]

spalladino

export async function tryGetRevertReason(to: string, from: string, data: string): Promise<string | undefined> {
  const provider = ethers.getDefaultProvider();
  const tx = { to, from, data };
  try {
    await provider.estimateGas(tx);
  } catch {
    const value = await provider.call(tx);
    return hexDataLength(value) % 32 === 4 && hexDataSlice(value, 0, 4) === '0x08c379a0'
      ? defaultAbiCoder.decode(['string'], hexDataSlice(value, 4))
      : undefined;

0xAnonymous

Anonymous: a proof-of-unique-human system

Anonymous is a coordination game for global proof-of-unique-human, through monthly pseudonym events that last 15 minutes, where every single person on Earth is randomly paired together with another person, 1-on-1, to verify that the other is a human being, in a pseudo-anonymous context. The proof-of-unique-human is that you are with the same person for the whole event. The proof-of-unique-human is untraceable from month to month, much like cash. True anonymity.

When you register for Anonymous, you use register(). You need a “registrationToken” that you got if you were verified in the last event. You can see one be deducted from your account with registrationToken[msg.sender]--. The purpose of the registration tokens is that you can easily mix them, so that your personhood is not traceable from month to month.

function register() public scheduler {

require(isReg(msg.sender) == false && data[schedule].tokens[1

ryanberckmans

// Augur's oracle can be used to bring information on-chain,
// allowing money to move automatically based on real-world facts.

// Augur's oracle is secure so long as money that depends on Augur
// is properly tracked in the Augur system.

// Money that depends on Augur's oracle, but isn't tracked in Augur,
// is said to be "parasitic" and is at risk of attack and a threat
// to Augur itself.

djspiewak

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

MiloXia

import scala.language.higherKinds

object Conditions {
  //based on: An Introduction to Functional Programming Through Lambda Calculus
  trait BOOL {
    type body[e1 <: E, e2 <: E, E] <: E //select: (E, E) => E
  }
  trait TRUE extends BOOL {
    type body[e1 <: E, e2 <: E, E] = e1 //true = select_first
  }