With Candy Machine V2 is there any way to limit the number of usages for each whitelist token to a certain number? For example, I would like to send each whitelist user one token that can be used to mint 3 times, and then it is burned so it can't be used more than that. This would be ideal.
Or would I need to send each whitelist user 3 different tokens and then burn each one after it is used once?
You have to read the whitelist docs (deprecated js-CLI and sugar).
You have 2 options about how the whitelist token will be used: burnEveryTime or neverBurn.
If you set burnEveryTime then each time the user mint 1 WL-token will be burned (make sure ur WL-token has 0 decimals in order to burn exactly 1 unit).
If you set neverBurn then the user will be able to mint with 1 WL-token any number of NFTs.
So in order to allow the user to mint X times with its WL-token you have to send him the exact amount of WL-token that you wanna allow each user to mint and set burnEveryTime, so the person will be able to Mint X NFTs and he will burn 1 WL-token per mint, so X burned WL-tokens.
Related
I would like to get all minted NFTs mint accounts in correct order(0 to last).
Like:
NFT#1 mint address: "2aiHs4d7nN8EZJAaMMeQ6LE856NJUEwZP2VRdtf8vXAJ",
NFT#2 mint address: "4E637AnAEQXYaPVSyBzgqGVuWF1oiruskNT2pfvmULHT",
..
I am using metaboss, but it doesn't give back the mint addresses in the correct order from 0 to last. Thanks
First of all, the order doesn't matter I believe, but if still you want them in order, you can use one of the following:-
Magic Eden Hashlist tool
Pentacle tool
I use GetSystemIdForPublisher() to identify machine IDs. According to the documentation they are unique, but I have a handful of machines which return the same ID. These machines are completely unrelated and have no common history. They are located in different countries and belong to different users. The Windows version of these machines is the latest Windows 1909 10.0.18363 update.
The documentation clearly states:
The method will first attempt to use the Trusted Platform Module
(TPM), if present, to get an ID. If a TPM is not present, the method
will try to get an ID from the Unified Extensible Firmware Interface
(UEFI). If neither of these sources is available, this method will
return an ID that is backed by the Windows registry. In the case of
the Windows registry, the ID will not satisfy all the above
guarantees. For example, if a system does not have a TPM or UEFI
support, and thus an ID was obtained from the registry, a clean
install of Windows will result in a new, different ID being returned.
Callers of this method should refer to the Source property of the
returned SystemIdentificationInfo to determine where the ID was
obtained from in order to understand the guarantees provided.
As far as I can see, none of these statements explain to me what is happening here. Does anyone else have an idea whats going on? Any help is highly appreciated!
Addendum:
we got feedback in form of a cpu-z report from 2 persons on 2 different continents with the same machine id:
user A:
Mainboard Model Z87M Extreme4 (0x00000444 - 0xECE9B6D4)
UEFI Yes
BIOS Vendor American Megatrends Inc.
BIOS MSG 63-0100-000001-00101111-1xxxx5-Chipset
BIOS Date 12/10/15
Mainboard Vendor 000001
user B:
Mainboard Model 151-BE-E097 (0x0000025D - 0x0A74C7F0)
UEFI Yes
BIOS Vendor American Megatrends Inc.
BIOS MSG 63-0100-000001-00101111-0XXXX5-Chipset
BIOS Date 09/10/15
Mainboard Vendor 000001
both got the same identifier when calling GetSystemIdForPublisher():
XlPRXXXlAPXk-yFXXXJUv3-XXXXXXXXXXXXX = [source is UEFI, ]
==> X included for obfuscation
We have around 60 customers worldwide whose computers return this exact ID.
Lets take the 1st step when the CRTM measures the Bios it extends the hash value to the PCR located in the TPM. Before passing control to the bios it must be a verification of hash values. My question is there an agent (third party) to commit this verification? or PCRs has a default set, so each time extending hash values these values must correspond to the PCR default hash before passing the control to bios?
It depends. In some implementations, the CRTM is a part of BIOS, so you have to implicitly trust the first boot block of BIOS to be loaded, which then verifies the rest of the BIOS. In other implementations, such as with Intel's AMT, the CPU measures the BIOS independently.
What you asked is the PCR values from so-called "golden measurement" or "baseline measurement", which can be conducted by the platform manufacturer such as DELL or platform administrator like your department IT. Those values are saved and used for verification by TPM. This is part of the "provisioning process".
Please check the book "TCG TPM v2.0 Provisioning Guidance" for section 10 and section 11.
I need to get an unique device identifier in Windows 8 application. I have few applications and I need to determine device ID that have one or more apps installed (e.g. a bonus for a gamer installing other game in the series). Using following methods provides me with per-app IDs which won't tell me that device have some other apps installed.
I've tried three different approaches but they all return different UDIDs on the same PC.
1) This was used before, since I needed unique id per app, now I need UDID, so it's predictably doesn't work for me:
GUID g;
std::string ret;
CoCreateGuid(&g);
Platform::Guid pg(g);
std::string udid = WStringToUTF8(pg.ToString()->Data());
2) I've tried EasClienDeviceInformation, which was suggested as a sure thing, but got different results for 2 apps on the same PC:
EasClientDeviceInformation^ info = ref new EasClientDeviceInformation;
ret = WStringToUTF8(info->Id.ToString()->Data());
3) And I've tried the commonly used way to get ASHWID, without any hope and it obviously shown different UDIDs:
auto token = Windows::System::Profile::HardwareIdentification::GetPackageSpecificToken(nullptr);
ret = WStringToUTF8(Windows::Security::Cryptography::CryptographicBuffer::EncodeToBase64String(token->Id)->Data());
_RPT1(_CRT_WARN, "TOKEN UDID IS %s \n", ret.c_str());
I know only about one option and it's to use MAC-address, but I'm not sure if it's a valid option. Users can have a PC where MAC-address could be changed or duplicated (I've heard of batches of chinese network adapters having the same address), or have a device without a network whatsoever (e.g. use a PC without a network adapter and connect to the internet using USB dongles).
So the questions are:
Did I do everything right, or I made a mistake that caused my examples to return wrong UDIDs?
Am I right to assume that MAC-address is the only viable way to get a trutfully unique per-device identifier? I could've been inattentive and missed some obvious way.
Am I wrong in my assumptions of MAC-address identification insecurities like those I've described above?
UPD: I also would like to know the right way for WP8, while we're on it.
How to uniquely identify computer (mainboard) using C#(.Net/Mono, local application)?
Edition. We can identify mainboard in .Net using something like this (see Get Unique System Identifiers in C#):
using System.Management;
...
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_MotherboardDevice");
...
But unfortunately Mono does not support System.Management. How to do it under Mono for Linux? - I don't know :(
Write a function that takes a few unique hardware parameters as input and generates a hash out of them.
For example, Windows activation looks at the following hardware characteristics:
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
You can pick up a few of them to generate your unique computer identifier.
Please see: Get Unique System Identifiers in C#
You realistically have MotherboardID, CPUID, Disk Serial and MAC address, from experience none of them are 100%.
Our stats show
Disk serial Is missing 0.1 %
MAC Is missing 1.3 %
Motherboard ID Is missing 30 %
CPUID Is missing 99 %
0.04% of machines tested yielded no information, we couldn't even read the computer name. It maybe that these were some kind of virtual PC, HyperV or VMWare instance, or maybe just very locked down? In any case your design has to be able to cope with these cases.
Disk serial is the most reliable, but easy to change, mac can be changed and depending on the filtering applied when reading it can change if device drivers are added (hyperv, wireshark etc).
Motherboard and CPUID sometimes return values that are invalid "NONE", "AAAA..", "XXXX..." etc.
You should also note that these functions can be very slow to call (they may take a few seconds even on a fast PC), so it may be worth kicking them off on a background thread as early as possible, you ideally don't want to be blocking on them.
Try this:
http://carso-owen.blogspot.com/2007/02/how-to-get-my-motherboard-serial-number.html
Personally though, I'd go with hard drive serial number. If a mainboard dies and is replaced, that PC isn't valid any more. If the HDD drive is replaced, it doesn't matter too much because the software was on it.
Of course, on the other hand, if the HDD is just moved elsewhere, the information goes with it, so you might want to look at a combination of serial numbers, depending what you want it for.
How about the MAC address of the network card?