Determine trait algorithm

[whoabuddy]

This issue is a placeholder to determine how we'll randomize the traits based on the Bitcoin TX.

[yknl]

Idea 1: Themes for different types of Bitcoin addresses

Different types of Bitcoin addresses could have different themed svgs. This adds some differentiation to the addresses and provides some utility (being able to quickly discern the type of address).

The different types of BTC addresses: https://bitcoin.design/guide/glossary/address/

Idea 2: Make rare or cool traits for older BTC addresses i.e. ones that have made transactions early in the blockchain history. This will require scanning the transaction history though, so not sure if it's feasible.

But this might make it more enticing for OG Bitcoiners.

[Rapha-btc]

idea 2 addition - and mix it up and add a few rare ones at random among the newest created addresses :P

more enticing for OGs and FOMO machine for newer ones :P

[whoabuddy]

@Jamil curious if you have input here - we know the NFT will be unique per Bitcoin address, but how do we want to approach randomization generation of the traits? Do you know of some other projects that would serve as good examples?

[Jamil]

When you mean randomization of the traits, you don't want the traits to be deterministic based on the BTC address?

[larrysalibra]

Expanding on @yknl 's idea.

What about splitting the two ideas into static and dynamic components of the NFT

static - Bitcoin Face

There would be a static NFT generated deterministically from the address - with different themes based on address type.

These could be generated either by the smart contract or client library with only the address as input.

dynamic - Bitcoin Bling

In addition to the static NFT, there could by dynamic "traits" that are added or removed depending on the UTXO state of the bitcoin address UTXO set. Let's call it "bitcoin bling." Perhaps funding an address gets a gold chain or sunglasses added to your NFT. Perhaps the chain spins if there's an zero conf pending transaction.

Some possible inputs for this:

• at least 1 btc at address
• previously used address but now zero balance.
• utxos all older than certain age (HODLer)
• non-zero balance
• new, unused address

These would only be generated client-side.

This would also be useful because you could tell at a glance what's going on with your address.

[whoabuddy]

When you mean randomization of the traits, you don't want the traits to be deterministic based on the BTC address?

Good catch, I was mixing terms - the traits will definitely still need to be deterministic.

My goal here is to start outlining the inputs and outputs that we'll need in order to achieve that in the Clarity contract.

Once we know what we can do in Clarity, we can start developing this as a client-side library as part of #27.

Some possible inputs:

• Bitcoin Address (main seed)
• UTXO Age (if we can access this info)
• Address Type

Output:

• single unique deterministic value?
• how is that applied to each layer selection?

In the case of Bitcoin Colors as a test, we know we have 30 unique NFTs using the colors provided.

Maybe we should open up the color palette to allow for more options? MDN has the full list here and that'd allow for generating more unique NFTs in total to test out the idea.

If we had 140 color options for the foreground/background, with the only restriction that they cannot be the same, how many options would we have?

[whoabuddy]

Following up on expanding the size of Bitcoin Colors NFT collection to better simulate the mint - we could also use a 2x2 grid to expand the number of possibilities, inspired by Ryder's cryptoglyphs, Urbit's sigils, and the Blocks NFT Collection.

That would significantly increase the number of unique NFTs and if we needed more we could add additional color options, and would simulate generating more layers in-line with the expected designs.

A (very quickly mocked up) example:

Also worth noting is the approach Nouns DAO took to traits.

Nouns are generated randomly based Ethereum block hashes. There are no 'if' statements or other rules governing Noun trait scarcity, which makes all Nouns equally rare.

[friedger]

To leverage the on-chain bitcoin view of stacks, users could submit btc txs to NFTs/addresses.

(define-public submit-btc-tx (btc-address ...) (btc-tx ...))
  (if (and (was-tx-mined btc-tx) (or (is-input btc-address btc-tx) (is-output btc-address btc-tx)))
    (ok (update-traits btc-address btc-tx))
    err-invalid-btc-tx))    

The traits could be based on

• the number of txs that uses the address as input, and
• the number of txs that uses the address as output,
• the balance defined by (submitted) txs

These values can be determined on-chain. Any user can submit relevant btc txs, we can run a server/chain hook(?) to do that.

[whoabuddy]

Thanks @friedger - that's similar to what we're doing here actually.

The goal is to have a user mint an NFT by sending Bitcoin to the artist address, and the first input of that TX will be taken as the sender's Bitcoin address and used to mint the NFT on Stacks.

The Bitcoin TX can be submitted to the NFT contract by anyone, and we plan to run a chainhook to facilitate a faster mint.

Given yours, @yknl's and @larrysalibra's feedback I've opened some new issues to track additional changes to the algorithm.

Closing this one out!