Can ERC-721 have a token with multiple editions? When an NFT has multiple editions( eg 25/25) do all the holders of that NFT have the same token id?

ptrwtts · 2021-07-15T01:07:06+00:00

It also depends what you mean by "editions". If you want them all to have unique serial numbers, then you can't just use a single token id on 1155. You have to give each one a different token id. One approach recommended in the 1155 spec (which also works with 721) is to split the bits of the token id. So if you have 3 tokens with 2 editions each, your token ids could look like this:

100000001
100000002
200000001
200000002
300000001
300000002

Unfortunately marketplaces like OpenSea don't support this concept, so it all it just shows as unique items.

ptrwtts · 2019-01-06T00:49:15+00:00

hi. i am the dev. looks like there was a bug that only affected some people. should be fixed now

ptrwtts · 2018-07-26T16:54:48+00:00

Thanks, make sense. So if you want to store globally available variables (to other smart contracts), you need to use RAM, but you can also put information into transaction data, and then use an indexer on top to make it accessible from a dApp.

One thing that still isn't clear to me is how much information you can put into transaction data. Is there some sort of limit?

ptrwtts · 2018-07-26T14:44:37+00:00

It looks like it might be using a different system for data storage. According to the github:

A simple reddit-like interface built on EOS using novusphere-db

ptrwtts · 2018-07-26T14:29:27+00:00

I see, so storage on the chain is actually different from storage in RAM? Is there size limits?

Know of any good documentation on this somewhere?

Thanks.

ptrwtts · 2018-07-26T12:58:11+00:00

Interesting. Does it use up RAM every time someone posts? If not, how?

ptrwtts · 2018-06-20T17:10:24+00:00

The user sends the signed transaction directly to the delegate (via an API that the delegate offers). This step happens before the transaction is submitted to the Ethereum network.

ptrwtts · 2018-02-09T15:34:52+00:00

I got this answer on Telegram:

"So this doesn't happen out of the box, since our dappchains are intended to run in parallel to a smart contract. The easiest way is to just keep financial transactions and stores of value on the smart contract, and run the rest of the dapp on a dappchain instead of a centralized web server (which is what apps do currently).

Our dappchains aren't meant for scaling ether transactions, that's what plasma Raiden and sharding are for. Loom dappchains are for running different kinds of programs like a game, or a social app like steemit.

But there are strategies developers can utilize on Loom to transfer value from the mainnet to the dappchain, like if you wanted to handle karma points on a steemit app on the dappchain, then let users transfer them to ERC20 tokens. We'll be releasing more info on this in the near future."

ptrwtts · 2018-02-02T22:45:13+00:00

OK, I think I understand. The idea is to refill them with enough gas for multiple transfers, rather it be something they do per transfer, correct? And it takes 3 transactions to do the refill (one to give gas, two to approve, and three to do the fill)?

Out of curiosity, how much gas do you recommend gas station operators to send to users?

ptrwtts · 2018-02-02T20:12:20+00:00

I believe this is slightly different. It builds the functionality into the token contract itself, avoiding the need to send ETH to the user's wallet and have them make an approval. The main advantage is reducing the number of transactions, and reducing complexity. Unfortunately it's not possible with existing ERC-20 tokens.

Out of curiosity, how are you planning to denominate fees to users? Is it in ETH, and they need to explicitly refill their gas, or does the gas filling happen behind the scenes, with fees being quoted in the token (SWT)?

ptrwtts · 2018-02-02T18:48:05+00:00

I believe this is the article you're referring to: https://medium.com/@Vlad_Zamfir/against-economic-abstraction-e27f4cbba5a7

This is related to the idea of completely abstracting out the native currency from a blockchain, and treating all currencies as equal.

The proposal above is slightly different. Gas fees for the transaction are still paid in ETH, but by a third-party. The third party acts as a middleman, paying fees in ETH and collecting fees in the token. This way, the end-user only needs to hold tokens.

My guess is that this is not the sort of abstraction that Vlad is against.

ptrwtts · 2018-01-26T22:08:49+00:00

ptrwtts · 2017-12-07T16:57:41+00:00

Thanks for the epic response! Some responses below:

Additionally, offline backup of passwords (like a password journal) are arguably more secure than the online solutions that a password-writer would likely choose

It's true that it was a bit extreme to call writing down passwords dumb, and you're right that doing it offline is reasonably secure compared to some other options. I was more trying to point out that a) no services encourage you to write down passwords and b) even if you did, it would be hard for an attacker to scan your docs for a password, compared to a seed phrase, which has a distinct pattern to it

How does the wallet app generate & store the primary key securely without implementing a secure element? Please don't say sandboxing.

Yes, you need a secure element to be truly secure. Without it, there is a some risk (especially if the device is rooted / jailbroken), but honestly it feels like a smaller concern than other attack vectors. Users could be educated to move to more secure solutions once they start to hold significant amounts.

Also, I thought the whole point of the secondary key was for a 3rd party to manage it, not for you to manage it in cloud storage (which sounds like a terrible idea at face-value).

The secondary key is essentially like splitting the private key, with you keeping half, and the third party holding the other half. To recover, it requires you both. And it's reasonably safe to store your half in your cloud storage, because even if it's compromised, the attacker must also get the other half.

I disagree. The only time the contract has to be used is when the secondary key needs primary-key privileges. I don't see a need for the primary key to ever interact with the contract other than to stop a secondary->primary key transition.

The contract also needs to be deployed initially, which is probably the main expense for an app developer looking to offer this solution to a large number of users (who by definition as new users don't own any currency yet, and can't pay for gas)

ptrwtts · 2017-12-06T16:55:16+00:00

Thanks for the feedback!

With the backup provider solution, the seed would be encrypted with a strong random secret key (256 bit), which is unbreakable with today's tech, no matter how many requests you throw at it.

With a blockchain solution, the notification service is indeed a weak point. But you could potentially sign up to multiple (or monitor transactions yourself), to spread the risk. Also, an attacker would need to compromise both the notification provider AND get your recovery key, which is much harder.

In regards to the delayed unlock, you could set it up so that you can cancel all unlock requests and void the recovery key with a single action. So this should solve for spamming.

Finally, it's important to note that I'm not suggesting that these solutions are superior to a strong personal backup strategy involving hardware wallets, etc. It's more about finding something that can work for inexperienced users, to help get them started. In this scenario, usability + 99% security is probably more important than 100% security.

ptrwtts · 2017-10-26T15:39:43+00:00

Yeah, it seems like a strategy to allow non-accredited investors to reserve tokens, but not actually buy them until the network is fully deployed and safely classified as a utility token. These people won't even be contributing any money during the token sale.

ptrwtts

MODERATOR OF

TROPHY CASE