nft-generator-py

nft-generator-py is a python based NFT generator which programatically generates unique images using weighted layer files. The program is simple to use, and new layers can be added by adding a new layer object and adding names, weights, and image files to the object. You can View The Demo here.

How it works

• A call to generate_unique_images(amount, config) is made, which is the meat of the application where all the processing happens.
• The config object is read and for each object in the layers list, random values are selected and checked for uniqueness against all previously generated metadata files.
• Once we have amount unique tokens created, we layer them against eachother and output them and their metadata to their respective folders, ./metadata and ./images.

Configuration

{
  "layers": [
    {
      "name": "Background",
      "values": ["Blue", "Orange", "Purple", "Red", "Yellow"],
      "trait_path": "./trait-layers/backgrounds",
      "filename": ["blue", "orange", "purple", "red", "yellow"],
      "weights": [30, 45, 15, 5, 10]
    },
    ...
  ],
  "incompatibilities": [
    {
      "layer": "Background",
      "value": "Blue",
      "incompatible_with": ["Python Logo 2"]
    },
  ],
  "baseURI": ".",
  "name": "NFT #",
  "description": "This is a description for this NFT series."
}

The config object is a dict that contains configuration instructions that can be changed to produce different outputs when running the program. Within metadata files, tokens are named using the configuration's name parameter, and described using the description parameter.

• In ascending order, tokenIds are appended to the name resulting in NFT metadata names such as NFT #0001.
• tokenIds are padded to the largest amount generated. IE, generating 999 objects will result in names NFT #001, using the above configuration, and generating 1000 objects will result in NFT #0001.
• As of v1.0.2, padding filenames has been removed.

The layers list contains layer objects that define the layers for the program to use when generating unique tokens. Each layer has a name, which will be displayed as an attribute, values, trait_path, filename, and weights.

• trait_path refers to the path where the image files in filename can be found. Please note that filenames omit .png, and it will automatically be prepended.
• weight corresponds with the percent chance that the specific value that weight corresponds to will be selected when the program is run. The weights must add up to 100, or the program will fail.

The incompatibilities list contains an object that tells the program what layers are incompatible with what. In the above configuration, A Blue Background layer will never be generated with Python Logo 2.

• layer refers to the targeted layer.
• value is the value of the layer that is incompatible with attributes within the incompatible_with list.
• incompatible_with is the list of incompatible layers that will never be selected when layer has attribute value.

As of v1.0.2, the IPFS CID may be updated programatically after generating NFTs and uploading /images to IPFS. This will update all metadata files to correctly point "image" to the IPFS CID.

• This is an optional step, and can be exited safely using enter or control + c.

Troubleshooting

• All images should be in .png format.
• All images should be the same size in pixels, IE: 1000x1000.
• The weight values for each attribute should add up to equal 100.

Credits

This project is completely coded by Jonathan Becker, using no external libraries.

Recurring Payments on Ethereum

October 27, 2021    |    By Jonathan Becker

Recurring payments on the blockchain have been a topic of discussion for some time. First introduced in EIP-1337 in 2018, the proposal never really caught on. My approach to recurring payments on Ethereum takes a simpler approach than EIP-1337 did, which may help it have a larger impact on the community.

You can find this PoC write-up on my research page.

Live demo's of the contract can be found on the Ropsten network at the following links:

RecurringPayments: https://ropsten.etherscan.io/address/0xF4EfF5176bA24156d483Fddf89A09aAA12e67bAB

ERC-20: https://ropsten.etherscan.io/token/0x119b1b4697d31589fa209ba627355BfB20bebDA6

0x01. Abstract

The recurring payment implementation I will explore throughout this paper is an application of the ERC-20 Token Standard's approve(...) function. An unlimited allowance (2^256-1) is approved to the subscription contract address, which periodically allows the _payee to call a timelocked proxy of ERC-20's transferFrom(...) method.

0x02. Detailed Analysis

Consequences

Pros:

• _spender must only call 2 transactions to create a subscription; approve(...) and createSubscription(...).The burden is on the payee to call the transferFrom(...) proxy, meaning they must pay the gas fees to process future payments.
• Subscriptions can be cancelled at any time, by either the _spender or the _payee.

Cons:

• This approach requires an unlimited^* approval to the smart contract handling the recurring payments.
  • * Technically, this approval can be any amount as long as the _spender approves at least enough to pay for a minimum of 2 transactions. Although unlimited approvals of ERC-20 tokens are against Solidity best practice, this PoC allows for recurring payments on Ethereum in a generally secure manner, where the only potential losses lie in the smart contract's integrity.
• We rely on block.timestamp for the timelock. This is generally not an issue, but should be noted.

Specification

Methods

• getSubscription

  Returns the Subscription of _customer to _payee.

  function getSubscription(address _customer, address _payee) public view returns(Subscription memory)

• subscriptionTimeRemaining

  Returns the time in seconds remaining until the subscription payment may be charged again.

  function subscriptionTimeRemaining(address _customer, address _payee) public view returns(uint256)

• createSubscription

  Creates a Subscription which allows _payee to charge the caller _subscriptionCost every _subscriptionPeriod, until the Subscription is cancelled.

  This may only be called by the customer, and will automatically charge them for the first billing period. Requires an approval to the subscription contract address of _subscriptionCost * 2.

  Emits a Transfer, NewSubscription, and SubscriptionPaid event.

  function createSubscription(address _payee, uint256 _subscriptionCost, address _token, string memory _name, string memory _description, uint256 _subscriptionPeriod ) public virtual

• cancelSubscription

  Cancels a subscription between _customer and _payee and disallows further executePayment(...) calls.

  This can be called by either party.

  function cancelSubscription(address _customer, address _payee ) public virtual

• executePayment

  Charges _customer for the subscription between _customer and the payee a total of _subscriptionCost, given that they have enough token balance and _subscriptionPaid is false.

  This must be called by the payee.

  function executePayment(address _customer) public virtual

• _subscriptionPaid

  An internal function that returns true if the subscription between _customer and _payee has been paid for the current period, or false if otherwise.

  function _subscriptionPaid(address _customer, address _payee) internal view returns(bool)

Events

• NewSubscription

  MUST be called whenever a new subscription is created.

  event NewSubscription(Customer, Payee, Allowance, TokenAddress, Name, Description, LastExecutionDate, SubscriptionPeriod);

• SubscriptionCancelled

  MUST be called whenever a new subscription is cancelled.

  event SubscriptionCancelled(Customer, Payee);

• SubscriptionPaid

  MUST be called whenever a new subscription is paid.

  event SubscriptionPaid(Customer, Payee, PaymentDate, PaymentAmount, NextPaymentDate);

0x04. Conclusion

This method of allowing smart-contracts to recursively call transferFrom(...) based on an timelocked proxy function enables subscriptions on the blockchain, one of the most important aspects when it comes to running a service or business. The approach this PoC takes is also trustless, and can be revoked any time by the owner, allowing for a truly decentralized form of recurring payments & subscriptions on Ethereum.

0x05. Resources & Citations

• Fabian Vogelsteller, Vitalik Buterin, "EIP-20: Token Standard," Ethereum Improvement Proposals, no. 20, November 2015. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-20.
• Kevin Owocki, Andrew Redden, Scott Burke, Kevin Seagraves, Luka Kacil, Štefan Šimec, Piotr Kosiński, ankit raj, John Griffin, Nathan Creswell, "EIP-1337: Subscriptions on the blockchain," Ethereum Improvement Proposals, no. 1337, August 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1337.

Jonathan Becker's Research

This repository contains research papers & studies that I have worked on or am currently working on. I also plan on publishing / posting whitepapers and writeups here for projects, CTFs, vulnerabilities, and more.

Visualizing the Repository

This repository is automatically rendered on my website https://jbecker.dev under the research tab. Using the GitHub API and PHP, requests to https://jbecker.dev/research/ will query this repository and try to find a matching paper.md file.

pleonexia

Pleonexia is a minimax based chess engine that calculates the best move for the machine to make by material counting as well as positional scoring. You can View The Demo here.

How it works

Pleonexia utilizes the popular minimax method to search for and calculate ideal moves within two-player games such as chess. In order to reduce the amount of total calculations, we also implement aplha-beta pruning which removes possibilities if they result in worse positions that previously calculated moves.

• We start off by creating a chess.js Chess object which we will use for the duration of the game for calculations, moves, and more.
• The Chess object has many useful methods, such a Chess.moves() which lists all possible moves found for the current position for that player.
• To begin calculating, we wait for it to be our turn within the updateGame() function which interacts with Chessboard.js's frontend to take in plays from the player. This function calls make_best_move(depth, game) after checking that the game is not over, with depth being the amount of moves to calculate ahead, and game being the current Chess object.
• make_best_move makes a call to get_best_move(), which is just a simple wrapper that begins a timer, counter, and handles other statistics before making a call to our minimax functions.
• The minimax functions loop through the array of possible moves from Chess.moves(), giving each a score using minimum and maximum, with minimum being the minimum score for the AI if it plays this line, and maximum being the maximum player score if the AI chooses this line.
  • Within chess, scores are calculated using material values, pawns being 1, bishops and knights being 3, rooks being 5, and the queen being 8.
  • Our calculations use these basic ratios but also include a 0.5 score bonus if the player has both bishops remaining, since having both bishops is more powerful than having both knights.
  • In addition to these material scores, we also give each piece additional value based on which of the 64 squares it resides on. Chess is a game about control, so the AI will try to prioritize controlling and keeping control of the center, giving these squares more weight for pieces like pawns, bishops, and knights.
  • The AI is incentivized to avoid checkmate and find checkmates by giving lines that end up in checkmate a massive score boost. This also helps us avoid ending up in checkmate.
• Each call to minimax calls a scoring function which returns the total difference in score for both white and black, with negative scores being worse than positive scores.
• minimax will continue to call itself, saving the highest minimum and maximum until it runs out of possibile moves for the depth provided. If a move line results in a worse minimum or maximum than we currently have stored, we will skip calculations for that line to save time.
• minimax returns the move, and we make it using Chess.move(move).
• The game continues until a draw or checkmate is reached.

Statistics & Specifications

• Default depth: 3
  • This parameter can be edited on line 299 within the updateGame() function.
• Lichess Winrate: 40.39%
  • A lichess bot is currently running and playing 2 games concurrently with a depth of 3. Since we are only material counting, its not a very good AI.
• AES: ~3100 Evaluations per Second

Credits

This project is completely coded by Jonathan Becker, using Bootstrap & Chessboard.js for the frontend, with Chess.js powering the basic chess functionality.

node-temp-mail

Node wrapper for creating and fetching temporary, disposable emails, as well as their new messages.

Installation

npm install node-temp-mail

Usage

var TempMail = require('node-temp-mail');

// Let's create an address object so it can be accessed by the module.
var address = new TempMail("testAddress");

// We already have the address object, so now let's access it and get a list of the emails in a nice & neat json object.
address.fetchEmails(function(err,body){
  console.log(body);
});

// If for any reason you need to see the full temporary email address, you can use the following function.
address.getAddress()

node-provably-fair-shuffle

Getting Started

node-provably-fair-shuffle is a node project that demonstrates generating provably fair and predetermined deck shuffles using a server and client seed, as well as a shuffle nonce. This has uses in online casinos where users can verify that their decks were generated and shuffled fairly.

As a demonstration, we will use the following seed pair when verifying the shuffle.

Client: able able able able able able able able able able able able

Server: abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon

Along with these seeds, each shuffle has a nonce. This nonce is a number that is used to determine how many times the deck has been shuffled, and changing the nonce will result in a unique shuffled deck. For this demonstration, we will be using nonce 0, meaning this is the first shuffle that has been preformed using this seed pair.

Practical Uses & Demonstration

This project has practical uses within the online gaming and gambling field where websites can allow users to verify that the games they played using these shuffled decks were generated fairly and without alteration by the server.

When a user plays a game, the server would generate a unique serverSeed which would be kept a secret from the client, until they request it. The first time the deck is shuffled, nonce will be set to 0. Clients will always be able to see their client seed, and can also change it as they wish. Changing the client seed should automatically set nonce to 0, because it will reshuffle the deck using the new seedpair.

If the server or client wish to reshuffle the deck, the nonce should be increased by 1, which will generate a new seed for the deck and reshuffle it, while still keeping the clientSeed and serverSeed the same.

Example:

In order to follow along the uses of this project, please navigate to the demo page, where you can both view the code behind the shuffle function, as well as preform test deck verifications.

var clientSeed = "able able able able able able able able able able able able";
var serverSeed = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon";
var nonce = 0;

After inputting the required seeds & nonce, all that's left to do is see the resulting shuffled deck. You can do this by clicking the run button. After a moment, the result will appear in the console tab on the right. Users may use this data to verify that your games were played correctly and legitimately, without alteration.

Going back to our example, you can see that with the given clientSeed, serverSeed, and nonce, we are given the shuffled deck below.

[
  '2 of Diamonds',    '10 of Clubs',       'Queen of Clubs',
  '10 of Hearts',     'King of Diamonds',  '6 of Diamonds',
  'Ace of Spades',    '8 of Hearts',       '2 of Diamonds',
  '2 of Diamonds',    'King of Hearts',    '4 of Hearts',
  '5 of Spades',      '5 of Clubs',        'Queen of Clubs',
  '3 of Spades',      '8 of Diamonds',     'King of Spades',
  '10 of Diamonds',   '10 of Spades',      '10 of Spades',
  'Ace of Diamonds',  '2 of Spades',       '8 of Diamonds',
  'King of Clubs',    'Ace of Hearts',     'Ace of Clubs',
  '5 of Clubs',       '7 of Diamonds',     '3 of Spades',
  '9 of Clubs',       '6 of Spades',       '3 of Diamonds',
  '2 of Diamonds',    '9 of Diamonds',     '4 of Diamonds',
  '7 of Hearts',      'King of Diamonds',  '6 of Clubs',
  '2 of Clubs',       'King of Hearts',    '8 of Spades',
  '10 of Clubs',      '10 of Diamonds',    '9 of Diamonds',
  'Jack of Hearts',   '2 of Spades',       '3 of Spades',
  '2 of Hearts',      '9 of Hearts',       '4 of Spades',
  '8 of Hearts',      'King of Hearts',    '4 of Diamonds',
  '5 of Clubs',       '7 of Spades',       '5 of Spades',
  '5 of Spades',      'Queen of Diamonds', '8 of Hearts',
  '10 of Hearts',     '3 of Clubs',        'King of Spades',
  'King of Diamonds', 'Jack of Hearts',    '8 of Spades',
  '4 of Diamonds',    '6 of Diamonds',     '6 of Clubs',
  '9 of Clubs',       '9 of Diamonds',     'Ace of Spades',
  'Ace of Clubs',     'King of Spades',    'Ace of Hearts',
  '10 of Clubs',      '8 of Diamonds',     '5 of Clubs',
  '2 of Spades',      '2 of Hearts',       'Jack of Spades',
  '10 of Spades',     'Ace of Clubs',      '10 of Hearts',
  '9 of Spades',      '9 of Clubs',        '9 of Spades',
  '3 of Diamonds',    '8 of Clubs',        '8 of Spades',
  '6 of Spades',      '5 of Hearts',       'Jack of Clubs',
  '5 of Clubs',       'King of Hearts',    'Jack of Clubs',
  '4 of Hearts',      '3 of Hearts',       '5 of Diamonds',
  '4 of Spades',
  ... 212 more items
]

Credits

All credits go to Jonathan Becker, who developed this provably fair shuffler in its entirety with the use of NPM module shuffle-seed by webcaetano.