Tulip 1637
To despise flowers is to offend God. - Alexandre Dumas
Why Tulip 1637?
Reminiscent of the Tulip Mania phenomenon that occurred during the Dutch Golden Age of the 17th Century when prices for Tulip bulbs reached extraordinarily high levels, Tulip 1637 explores this relationship to the contemporary craze for crypto currencies and NFTs. By utilizing modern technology, tulips continue to extend their reach worldwide. These natural oddities, known for their variegated properties, are forever encrypted within blockchain technology, thus becoming everlasting. Like all tulips, some varieties can take years to propegate, while others are inclined to go extinct. Tulip 1637 is the continued search for these marvels.
The Artist
Anna Condo is a filmmaker and a photographer, born in Armenia and raised in France. Some view the flower as naive. Anna’s work proves the opposite. Her photographs are portraits, imposing respect. The flower is no longer fragile; she is strong. She symbolizes this nature that bends to the elements. A real break in the world in which we live. The flower is a lady first and foremost. A feminist before its time. A cornucopia of culture, stories, and emotions.
The Photographs
Tulip 1637 is a collection of floral portraits created by artist/filmmaker/photographer Anna Condo in collaboration with an anonymous group of cypherpunks. Only once a proof-of-work is found, is a new photograph added to the collection. As each tulip blossoms, it becomes increasingly difficult, and eventually impossible, to cultivate another - until the next growing season.
Author Caroline Weber: “Anna Condo discloses beauty in the subtlest gradations of color and contrast, drama in the most delicate nuances of texture and tone, wisdom in an ever-fluid interplay between fragility and strength. Her work is at once a revelation of and an invitation into a world of singular enchantment—a world the viewer will be unable to forget and most unwilling to leave.”
Higher resolution
The tulips you see listed on the marketplaces have a medium resolution default image. If you would like a high resolution version of the original images, you can look in the metadata blob for each tulip in the collection and pull the high resolution image with the following instructions.
- 1. Go to the collection and find the tulip you’re interested in.
- 2. Find the id in the tulip’s title (e.g. Tulip 1637 [0] has an id of 0)
- 3. Go to the collection -> contract -> read contract contract tab
- 4. Under tokenURI you can put in the id and see the resulting IPFS hash.
- 5. Copy this hash and prepend https://ipfs.io/ipfs/ to it, and then visit that in your web browser
- (Example: https://ipfs.io/ipfs/QmNyBy1CT57rcBcYxE9p68VfgmGpY9XriJKycQQrDP2zS2 )
- 6. You will see a JSON metadata blob with a highres_url entry, again copy this and prepend https://ipfs.io/ipfs/ to it and again visit that in a web browser (Example: https://ipfs.io/ipfs/QmNyBy1CT57rcBcYxE9p68VfgmGpY9XriJKycQQrDP2zS2 )
- 7. This will download a high resolution tiff file. You can view the EXIF metadata for easter eggs, or print a high resolution print and frame it for your home. Anyone can do this, but only you own the original.
The Frame
If you look closely at the collection address of Tulip 1637, 0xa1111ac011d00888DD91751A4b98769862213cf5 you will notice that it starts with a number of hexadecimal characters that look slightly improbable to occur randomly. This is no accident, and is in fact the result of solving a large computational problem that resulted in a very specific solution we call a “frame”.
What is a Frame?
A frame is a custom collection address for an NFT. All NFT collections on ethereum are just addresses that contain the code that indicates the rules of the NFT collection. So what makes a frame different than an address? A frame allows those interacting with it to visually recognize the address is unique, and also proves that work was completed in the creation of this entire collection. While the blockchain holds the details to determine if a work is authentically created by an address, the artist must prove they are in control of that address, and portals to view the collection must make sure to display all the necessary details. By creating a custom frame, we are adding an additional point of authenticity to the collection, while also lending a measure of rarity to all NFTs in that collection.
The Artist’s Signature
In the case of Tulip 1637, one can see that the address starts with the signature of the artist’s name:
0xa1111ac011d0 == 0xANNACONDO. Anna chose this address for her collection, it’s a visual indicator that she is the creator, and that copies must minimally put the work in to solve this problem too. That work takes time and computational effort, making it hard to reproduce, while also lending rarity to the collection.
Proof-of-Work
The problem of finding Anna Condo’s frame, her signature, can be described as a proof-of-work. Each character in the frame adds an additional 24 bits of complexity. From 0xa1111ac011d0 we can see we have 248 bits of complexity, which is a total difficulty of 281,474,976,710,656 or 281 trillion! This means that 281 trillion attempts were made before finding her address.
In addition to the rarity of the collection address, each flower minted to the Tulip 1637 collection must provide a proof that work was completed to find it. With every new tulip added the difficulty of that proof doubles, until it’s so difficult it would span years, decades, and centuries to add another. This increase in difficulty with each flower constrains the supply of tulips in the collection, which in addition to causing the artist to carefully curate every tulip, means that each flower is increasingly rare for collectors.
A more detailed technical description of the frame and scaling difficulty can be found below.
A Technical Dive on Difficulty
Let’s start with the frame address. A contract address on ethereum is created by taking the hash of a public key of the deployer’s address and the current transaction nonce . To find Anna’s frame, we needed to generate a random ethereum private key and use its derived public key in combination with nonce 0 , and then check the resulting hash to see if it matched the 248 bits of 0xa1111ac011d0 we were targeting. If it didn’t, we had to do the entire thing again, taking us ~281,474,976,710,656 attempts to find a match. This algorithm can be demonstrated in the following pseudo-code.
We can get an idea of time it would take to solve this problem by measuring how many hashes per second it would take a modern graphics card to find a solution. On a very modern graphics card ( GeForce RTX 2060 ), we can solve approximately 232 MH/S . To find a solution to our problem requiring 248 hashes, it should take:
As you can see, finding Anna’s frame address took some provable effort, and the value of that is now shared amongst the owners of every NFT in the collection.
A Happy Coincidence
Since the private key is generated at random, and that in turn is how we derive the public key which is combined with the nonce to find our hash that we were trying to match, it’s easy to see that the public key of the deployer address is also random. As a happy coincidence, the deployer address, the address Anna will use to sign messages and mint more NFTs to the collection, just happened to be: 0x51BABe262C7B6013F726b20530c6e5C025153463 , or 0x51BABe.
Proof on Mint
In addition to the frame address, each tulip in Tulip 1637 requires a proof-of-work in order to call mint() . Once the new flower is added to the collection, the difficulty increases making the next proof twice as hard to find. Every new addition to the collection becomes more and more difficult. The proof is checked
- here
Only the 0x51BAB... address can call mint() on the collection, and if the check passes, the difficulty is increased
- here
The contract was initially
- deployed
Tulip 1637 [0]
Let’s take a look at the first tulip in the collection Tulip 1637 [0]
The mint() transaction for this tulip can be seen
- here
-
•
guy
is the
0x51BAB...
deployer address
-
•
uri
is the IPFS hash pointing to the
- metadata
-
•
nonce
is the proof that work was done
-
•
gal is a contract for splitting royalties
- • fee is the secondary sale royalty fee
Let’s try to prove that this nonce is indeed the correct solution to the proof. In another browser window, open up the Tulip 1637 collection and go to the read tab by clicking this:
At the bottom of the page, you will see a work dropdown, expand it and let’s put some values in.
If you put in the Tulip id 0 , the nonce 9328816 , and a difficulty of 24 and click the Query button, it should return true . Change the nonce to any other value, say 1637 , and click Query , and the value will be false . This is what that require() above is validating.
There can be more than one solution to the proof, it’s just a matter of how long it takes one to find it. To test this, try again, but put the nonce in as: 5315968668133950973687082075489170302398770405515228041493141117804034407010a
Work
The work() check can be viewed
- here
What this code is doing is checking that the first hard bits (224 in this case) of the hash of the collection address, the id , and the nonce match the first hard bits of the Tulip 1637 collection address.
That’s right, the proof for each tulip, is checked against the proof for the collection.
Now try validating the proof yourself using [ Tulip 1637
- 11
Too Hard
The good news is, you don’t have to manually validate this each time. You can see from the immutable code deployed to the blockchain that hard only goes up with each mint() and that mint() won’t succeed unless work() is true, indicating the next nonce is correct.
These facts together mean that any tulip in the collection must have solved the proof.
Now that we know each tulip in the collection gets harder to find with each mint() . Let’s see exactly how much harder each one gets. That is, how much time should it take for us to find each new tulip in the collection.
The table above is based on a javascript solver running on a Intel i7 @ 2.80GHz with a hashrate of 54KH/s.
The formula:
This hash rate can, however, be parallelized across many computers. Stay tuned, as we plan to allow you to help solve these proofs.
IPFS and Royalties
A dirty secret of this wave of NFTs, is that many of the original files the NFTs point to, the actual digital works themselves, have disappeared off the Internet.
That’s right, many of the IPFS hashes that point to the metadata or the images where NFTs are hosted, are no longer pinned. This means the original content they post to is gone! Many marketplaces cache the image from the original collection, so they continue to look active, but the truth is, without that caching, the owner of the NFT simply owns the blockchain record of its existence, and not the bits that make up the original content.
To ensure this NEVER happens with Tulip 1637 we collect a royalty that is split out to a number of parties that will continue to pin the IPFS hashes for the collection. If you own a piece in the collection, check back here and we will post a docker image that can run on your computer, in the cloud, or a raspberry pi that will pin the collection for you.
For the full press kit PDF, please click
- here