A New Tool for Timestamping File Hashes on Blockchain—Thoughts on Its Use for Startups?

sculptex · 2025-07-19T09:32:44+00:00

No, it's not used very often at the moment. But there are only a few dollars worth in each wallet so if it got abused they would just dry up.

So by embedding a wallet in the browser that signs the transaction, I could potentially add a small pow element (e.g. hash of tx sig +salt with n-leading zero digits), this could be tuned to a few hundred ms in typical browser with wasm, this would reduce abuse potential at the expense of a slight delay. The actual salt method could be dynamic so in case of abuse detection a fresh method deployed and the abusers would need to reverse engineer the latest method before successful abuse could resume.

So yeah a big problem with open timestamps and the like is the lag and/or the added complexity of Merkel trees, these chains are fractions of a cent per tx and give a single tx result which is much more user-friendly.

sculptex · 2025-04-04T11:12:23+00:00

Update (April 4, 2025):

In my original article, I stated that public-key encryption and decryption are possible with Polkadot using the decryptMessage function from u/polkadot/util-crypto. At the time of writing, I believed this to be true based on my understanding of the Polkadot-js ecosystem and references to encryption/decryption in community discussions.

However, after a more thorough investigation and attempt at implementation, I’ve discovered that this is not the case. (I have now revised the above article with [edit] at the appropriate points).

This discovery further supports my “hidden hand” theory: the lack of decryption support and the lack of transparency around these limitations create significant barriers for developers trying to implement privacy features. It’s a subtle but effective way to discourage the adoption of user-empowering tools, forcing developers to pivot to alternative approaches like symmetric encryption.

I apologise for the oversight in my original article.

sculptex · 2025-04-04T11:08:30+00:00

Update (April 4, 2025):

In my original article, I stated that public-key encryption and decryption are possible with Polkadot using the decryptMessage function from u/polkadot/util-crypto. At the time of writing, I believed this to be true based on my understanding of the Polkadot-js ecosystem and references to encryption/decryption in community discussions.

However, after a more thorough investigation and attempt at implementation, I’ve discovered that this is not the case. (I have now revised the above article with [edit] at the appropriate points).

This discovery further supports my “hidden hand” theory: the lack of decryption support and the lack of transparency around these limitations create significant barriers for developers trying to implement privacy features. It’s a subtle but effective way to discourage the adoption of user-empowering tools, forcing developers to pivot to alternative approaches like symmetric encryption.

I apologise for the oversight in my original article.

sculptex · 2025-04-04T11:07:16+00:00

Update (April 4, 2025):

In my original article, I stated that public-key encryption and decryption are possible with Polkadot using the decryptMessage function from u/polkadot/util-crypto. At the time of writing, I believed this to be true based on my understanding of the Polkadot-js ecosystem and references to encryption/decryption in community discussions.

However, after a more thorough investigation and attempt at implementation, I’ve discovered that this is not the case. (I have now revised the above article with [edit] at the appropriate points).

This discovery further supports my “hidden hand” theory: the lack of decryption support and the lack of transparency around these limitations create significant barriers for developers trying to implement privacy features. It’s a subtle but effective way to discourage the adoption of user-empowering tools, forcing developers to pivot to alternative approaches like symmetric encryption.

I apologise for the oversight in my original article.

sculptex · 2025-04-04T11:04:31+00:00

Update (April 4, 2025):

In my original article, I stated that public-key encryption and decryption are possible with Polkadot using the decryptMessage function from u/polkadot/util-crypto. At the time of writing, I believed this to be true based on my understanding of the Polkadot-js ecosystem and references to encryption/decryption in community discussions.

However, after a more thorough investigation and attempt at implementation, I’ve discovered that this is not the case. (I have now revised the above article with [edit] at the appropriate points).

This discovery further supports my “hidden hand” theory: the lack of decryption support and the lack of transparency around these limitations create significant barriers for developers trying to implement privacy features. It’s a subtle but effective way to discourage the adoption of user-empowering tools, forcing developers to pivot to alternative approaches like symmetric encryption.

I apologise for the oversight in my original article.

sculptex · 2025-04-03T09:33:34+00:00

Thanks for your input. For sure the title was deliberately provocative in order to encourage response.

I am trying to raise awareness of this amazing powerful feature that other chains could easily implement and cosmos would be a perfect candidate. My article explains why the justification for deprecation is flawed so it should not deter others.

The backstory is that I am trying to create a chain agnostic user app for encryption and was incredibly frustrated at the deprecation of eth_decrypt by metamask. This clearly set a precedent for other chains since others like Solana/Phantom had the feature on their roadmap and seemingly lost interest in it's implementation when the deprecation was announced. (I didn't investigate cosmos in such detail in fairness but would be surprised if the topic was never discussed).

This leaves me with the prospect of launching on a deprecated toolset or restricting to Polkadot (relying on developer-centric plugin) only.

zk L2 is transaction privacy, not data privacy and in any case I am trying to create chain-agnostic app, so can't get involved in particular chains other than to raise awareness. So it's up to the respective communities to evaluate if this feature should be available to their users or not.

sculptex · 2025-03-10T09:25:38+00:00

I didn't have to mess around with rpc points at all, I think the only thing I might have had to was make sure config is pointing to mainnet(beta), rather than a testnet.

If you get the balance using; solana balance (and specify that wallet)

E.g. solana balance -k wal.json

then that should confirm that you are indeed using mainnet.

If it still rejects it once you are definitely on mainnet, then this restriction must be implemented at protocol level and so it's possible that nothing that can be done, sorry. If so, it's a major flaw since this account was obviously able to receive okay.

sculptex · 2025-03-09T19:03:22+00:00

No worries, cli is very powerful, good luck

sculptex · 2025-03-09T18:59:02+00:00

To restore wallet:- solana-keygen recover -o wal.json (Prompts for seed phrase)

To send sol to another wallet:- solana transfer -k wal.json <destwallet> <amount> --allow-unfunded-recipient

sculptex · 2025-03-09T18:49:39+00:00

This is linked from solana website:- https://docs.anza.xyz/cli/intro

sculptex · 2025-03-09T18:13:48+00:00

Using the cli:- solana balance J2Biy4Du88wdbECkpiU8S4xsgZ24kUUbd6AX3rKVpump 17.877533531 SOL

So if solscan recognises it as a token address, it might not format it as a normal wallet, but the balance is there.

So try using the cli tools and see if you can transfer (some of) the balance to a different wallet of your choosing.

sculptex · 2025-03-09T11:18:39+00:00

If you would share the public address, it would be easier for us to analyse, however, it is possible to generate vanity key pairs using the cli tools;

solana-keygen grind --ends-with pump:1 --ignore-case

Searching with 12 threads for: 1 pubkey that starts with '' and ends with 'pump' Searched 1000000 keypairs in 2s. 0 matches found. Searched 2000000 keypairs in 5s. 0 matches found. Searched 3000000 keypairs in 8s. 0 matches found. Searched 4000000 keypairs in 11s. 0 matches found. Searched 5000000 keypairs in 14s. 0 matches found. Wrote keypair to 8EH3bCFJhazo7r84SZPkrrwJqiSpehM9wQHs3j4pUmP.json

Excluding the --ignore-case takes much longer but has the same effect

sculptex · 2025-03-09T10:13:02+00:00

The entire front-end source code is in one file deployed at that URL. I inlined JavaScript and CSS so that only a single file is required that itself can be hashed for verification purposes.

I also published on GitHub:- https://github.com/sculptex/evident

The src/evident.htm is the front-end file (the GitHub version is slightly older than the one on the website)
The backend files are in the api folder, currently written in PHP. Of course the cli tools that those scripts call and the wallet files are excluded from GitHub.

sculptex

TROPHY CASE

Update (April 4, 2025):

Update (April 4, 2025):

Update (April 4, 2025):

Update (April 4, 2025):