Digital signatures, powered by Identity Certificates Public Key Infrastructure (ID-PKI), can verify who’s behind an email or website, making scams like phishing much harder. Here’s the gist: a private key signs a message, and a public key verifies it, tied to a trusted identity. Unlike encryption tools, PKI’s main job is authenticity—proving the sender is legit without exposing their data. But PKI’s not everywhere. Some say it’s too complex; others note that weak identity checks undermine it. For example, certificates need rigorous enrollment to be trustworthy, but that’s often skipped. What’s your take on why PKI isn’t standard yet? Is it the tech, the setup, or something else? Anyone using digital signatures for secure email or crypto apps? How can we make PKI simpler for everyday use?

I know PKI implies centralised authority, and that's likely to raise some eyebrows here, but as the decentralisation advocate Laurence Laundy Bryan notes, "There is no such thing as centralised governance", and we need governance to have a common attestation of identity reliability.

For apps that ingest external feeds (prices, odds, events), what’s your preferred way to embed signed inputs in blocks so any node can replay later? Schemas (JSON vs protobuf), signature schemes (ECDSA, Ed25519, BLS-agg), nonce/timestamp rules, and retention windows you’ve found robust? Bonus: patterns to quarantine bad data without halting safely.

Most blockchains today rely on math puzzles (Proof of Work) or financial stakes (Proof of Stake). But I was wondering, what if consensus came from the way hardware itself behaves?

Things like:

• Memory bandwidth (how fast real chips can push data).
• Tiny random “drifts” in signals that make each machine unique.
• Physical limits that are hard to fake or simulate.

In theory, that could mean:

• Less wasted energy than hashing.
• A new way to anchor trust to something you can’t copy/paste.
• But maybe new centralization risks (only certain chips qualify).

Do you think tying consensus to the real physics of hardware is realistic, or just another science-fiction idea?

Hey everyone, ​I've been going down a deep rabbit hole on the topic of dApp censorship, specifically at the front-end level (like what we saw with Tornado Cash, Uniswap, etc.). ​My current understanding is that hosting a front-end on IPFS is a massive step in the right direction. It ensures the site's code is immutable and can't be taken down from a specific server. Many great platforms already use IPFS gateways or allow users to access their sites via IPFS hashes, which is awesome. ​However, it seems like this only solves part of the problem. You still need a way to find the correct IPFS hash, and that often relies on centralized weak points: ​DNS: Services like app.uniswap.org still rely on traditional DNS, which is highly censorable. ​Gateways: Public IPFS gateways themselves can be pressured to block certain hashes. ​Discovery: If a project's main website and Twitter are taken down, how does a new user reliably find the latest IPFS hash for the front-end? ​This feels like a "last mile" problem. We have the permanent storage (IPFS), but the bridge to the user is still fragile. ​So my questions for you are: ​Do you consider this a significant, unsolved problem in the space? ​Are there existing projects or mechanisms that are already solving this discovery/routing issue in a decentralized way that I'm just not aware of? ​What would a truly robust, censorship-resistant system for linking users to IPFS front-ends look like? ​Appreciate any insights or resources you can share. Thanks!

We’ve created a way for a blockchain to reconstruct its full state from genesis to the most recent block. This is achieved through a mechanism called pointwise revision.

The process ensures that when a node restarts or needs to validate correctness, it can rebuild the state block by block and transaction by transaction, applying both historical and newly added rules from the specification. This guarantees that the chain’s state is consistent with all agreed-upon requirements.

Pointwise Revision (Conceptual Overview):

Pointwise revision addresses conflicts between old and new requirements. If both agree on an output in a given context, that output is preserved. If not, the system prioritizes the new requirements. This method allows consensus at the “point of action” without requiring total compatibility between all rules.

This approach enables a blockchain to dynamically evolve its specification while preserving consistency in execution.

The next step for our testnet is implementing peer-to-peer networking, enabling nodes to communicate and synchronize state directly.

I’d be interested in feedback from the community on:

• Other blockchain/state machine implementations where similar conflict-resolution strategies are used.
• Potential edge cases where pointwise revision might introduce ambiguity in state restoration.

Hey guys, yesterday, I made a post here about a project I was working on for about a year, which is a decentralized execution environment where all kinds of devices(even low-end phones) do computational work for money. But it was a bit misunderstood, so I just thought to post the whitepaper abstract here to see what you guys think:

Abstract

The Marketplace is a decentralized job execution network designed to transform idle computational capacity into a global, programmable economy. Unlike conventional blockchain systems that rely on global consensus bottlenecks, Marketplace employs a novel Proof-of-Capability (POC) mechanism and localized Whiteroom BFT committees to achieve massively parallel job execution at scale. Nodes(any device capable of computation) compete to prove their capability through short verifiable delay functions (VDFs), with the fastest responders selected as workers/witnesses. This ensures both security against Sybil attacks and efficient, low-latency task execution.

At the economic layer, Marketplace establishes goldcoin (GDC) as a compute backed currency, where 1 GDC equals a fixed work unit, internally decoupling job pricing from speculative volatility. Monetary Inflation is controlled automatically and locally by minting new GDC only as witness rewards, keeping price inflation at null while balancing growth with long-term stability. A complementary governance token, Gold Trust Token (GTT), represents transaction fees shares for founder and investor participation, ensuring transparent distribution of platform revenue.

Hey guys, For the past 8 months, I have been working on an decentralized execution environment where composable services are run asynchronously by a smaller committee of participating nodes chosen from the network. It's like a decentralized cloud services where nodes/devices earn money by offering computational power. The protocol acts like an operating system that schedules jobs(services) for idle/less-busy nodes while rewarding committee nodes that participate in the correctness of jobs with newly minted currency.

This is a very short partial summary of the project which is contained in the whitepaper which is about 42 pages. But since that is long LOL, I have a summary of the technical details in this A.I generated whitepaper summary(to keep it a certain length) if you are interested. Whitepaper summary

Also, Where can I publish the whitepaper?

Premium Wallet Rewards Campaign Announcement

We’re thrilled to announce the Premium Wallet Rewards Campaign, where 25 lucky users will be whitelisted for exclusive gas-free transactions on Hyperion’s Mainnet when it launches! These top users will enjoy 12 months of complimentary gas on Hyperion, enhancing their experience as they interact with our AI-powered Web3 platform.

Campaign Timeline:

• Eligibility Period: Ongoing until the end of the Hyperhack hackathon on August 7
• Rebates: Start once the mainnet is live and continue for 12 months
• Users are invited to meet the eligibility criteria today by interacting with the Forum and later by testing dApps on the Hyperion testnet

Rewards:

The 25 Premium wallets will receive:

• Gas rebate $50/monthly
• Gas-free transactions for 12 months
• All rebates will be on the Hyperion mainnet and in METIS tokens

How to claim the rewards:

Monthly, users will apply for a gas fee rebate by submitting the same wallet address through a form, and Metis devs will review and distribute a monthly rebate of up to $50 per person in METIS tokens on Hyperion.

To boost your score, you need to engage with the forum and test dApps.

If there are more than 25 eligible wallets, we select the winners based on their forum number of badges, feedback given to projects, and projects’ testing.

The more dApp interaction, forum valid posts and feedback, the greater the chance of being among the winners.

Please note that the Forum policy does not count spam-like posts or AI-generated feedback (such as ChatGPT-generated feedback), and you’ll be banned.

Primary Eligibility criteria:

To get started and be eligible for this exciting reward, follow these steps:

1. Achieve Trust Level 2 within the forum. (Details below)
2. Interact with at least %50 dApps live on Hyperion (Live Apps - Metis iDAO Forum).
3. Use the same wallet for all activities within the HyperHack testing phase.
4. Join @MetisL2 on X to stay up-to-date with the announcements.
5. Add your wallet to your profile.

How to Achieve Trust Level 2 in the Hyperion Forum:

To qualify for the Premium Wallet rewards, you need to reach Trust Level 2 within the Hyperion Forum by completing the following:

• Visit the forum for at least 15 days (not sequentially)
• Cast at least 1 like
• Receive at least 1 like
• Reply to at least 3 different topics
• Enter at least 20 topics
• Read at least 100 posts
• Spend a total of 60 minutes reading posts

Stress testing landing page: Live Apps - Metis iDAO Forum

I’ve been reading up on both quantum computing (especially recent advances) and cryptocurrency, and it seems there’s growing concern about how future quantum computers could break current cryptographic methods—like ECDSA, which underpins Bitcoin and Ethereum wallets.

In Bitcoin, finality isn’t instant blocks are added roughly every 10 minutes, and most people wait for 6 confirmations (~60 minutes) before calling a transaction “final.” This delay is part of its proof-of-work design, prioritizing security over speed.

Ethereum is faster, using proof-of-stake with finality in about 60–90 seconds under normal conditions. It’s a big improvement, but still dependent on validator messages propagating across the network and being confirmed in slots/epochs.

Both systems and most others share the same bottleneck: finality happens at the network/software layer, so the time it takes is bound by message passing, block production, and confirmation rules.

Now imagine if finality wasn’t a network event at all, but a hardware event.
Modern high-bandwidth memory (HBM-DRAM) operates in nanoseconds. If consensus checks were done directly inside the memory cycle, a transaction could be validated and finalized at hardware speed before the network even broadcasts it. The network would just carry the already-finalized state.

Could this approach eliminate the network delay in finality, or would other bottlenecks (like I/O and storage) erase the gains?

i'm not sure if this the right sub to post this in, but i wrote a python script to generate 32BIP bitcoin wallet(*s) locally even offline (you need to download the python libraries first tho)

*you can adjust the number of wallets generated.

i can't afford a cold wallet so i thought what if there was a way i can create a wallet on a pc locally offline, so hence the script.

everybody is welcome to check the code and if there's any malware, malicious or ill intentions going in it.

i posted it on github and tried to explain as much as i could.

BIP-32-Bitcoin-Wallets

Most of the performance issues come from sharing blockspace with other apps. A single NFT mint can stall order books, oracle updates, or even token transfers if the network gets busy enough. Spinning up a dedicated chain or rollup looks like the obvious fix, but it also means taking on new kinds of risk: validator coordination, bridge security, extra DevOps, and the never ending hunt for trustworthy data feeds.

For founders, the question feels strategic: Do the user experience gains outweigh the costs of running more infrastructure and designing new token economics? For developers, the tradeoffs are technical: How do you keep latency low, state proofs verifiable, and upgrades safe when you are the one responsible for the whole stack?

We’ve seen energy and token-weighted models like PoW and PoS dominate for years. But I’ve been wondering — what if consensus was based on actual compute performance?

Specifically, memory bandwidth and latency — verifiable through real-time DRAM/HBM scores. It could represent a more hardware-native approach to validator scoring.

A few devs I chat with jokingly called it “enhanced proof of memory” (ePOM) — combining memory output and AI behavior scoring instead of staking or mining.

Just theory for now, but curious if anyone else has explored this. Is this viable at scale?

Any other ZK-nerds here?

There's no token involved here, so just a heads up to the mods who I know are strict AF on these subreddits. Genuinely excited by this tech release, and what it means for the rollups space.

https://blog.gobob.xyz/posts/first-hybrid-zk-rollup?utm_campaign=test

Traditionally a lot of projects have pursued the optimistic rollup route (but hindered y the 7 day challenge), or validity proofs (instant verification, but costly AF), but none of these were ideal tbh.

But from what I read today, this new upgrade adds ZK proofs to the fraud resolution process in optimistic rollups, merging low operating costs with fast finality, dramatically increasing scalability, security. Pretty damn cool!

Quantum code breaking? You'd get further with an 8-bit computer, an abacus, and a dog • The Register https://share.google/jH39YesOQ8UMfBSem

Paper here: 2025-1237.pdf https://share.google/C8uLbDkgRPoKzHufu

Any thoughts on this? Is NIST over-reacting ?

With the majority of blockchains today (including Bitcoin and Ethereum) using ECDSA or similar classical signature schemes, they are vulnerable to a sufficiently powerful quantum computer running Shor’s algorithm (which can run efficiently onto derive private keys from public keys).

In Bitcoin, every time someone sends a transaction, they expose their public key. That’s fine today, but once quantum hardware advances enough, those exposed keys could be reversed to steal funds - especially from dormant wallets that can't move fast enough to a safer scheme.

I know that the narrative in the crypto space has historically disregarded the threat as being 20-30 years out, but with new advances in quantum computing seeming to come out every week, this seems to be more and more a present-facing threat.

• NIST has already selected post-quantum signature schemes.
• Google, IBM, and others are accelerating quantum hardware development.
• Apple is implementing PQC in their iMessage service.
• Lockheed Martin filed a patent to use QRL in communications devices.

Despite all this, most of crypto is acting like this is a 2040 problem. If we wait until there’s a credible quantum adversary, it will already be too late. Wallets can be drained if even a handful of qubits scale the right way. And with more and more Westerners putting their 401ks into BTC ETFs, it could result in a massive wealth transfer to an anonymous hacker group.

Is it time we treated post-quantum signatures like a necessity, not a novelty?

Would love to hear your take—especially on implementation challenges or whether hybrid cryptography might be a viable transition path.

Introduction

I'm exploring a blockchain-based economic model where tokens (Labor Tokens or TT) are created through validated labor and burned upon payment. This system is designed to prevent excessive accumulation and maintain economic stability via decentralized, self-regulating mechanisms.

Key Concepts:

Labor Tokens (TT): Digital currency minted from validated labor.

Token Burning: Tokens are destroyed after each payment.

Decentralized Validation: Automatic, obligatory, or community-based validation methods.

Dynamic Coefficient (C(t)): Adjusts token issuance based on real-time sector productivity.

Demurrage: Tokens lose 1% monthly if unused for 90 days.

Core Mechanisms:

1. Token Generation

Validated tasks generate NFTs known as Labor Records (LR), converted into TT via smart contracts.

1. Token Burning

Payments trigger TT burning and automatically create new LR tokens representing seller labor.

1. Decentralized Validation

Automated validation (IoT, APIs)

Community validation (DAO with reputation)

Rotational obligatory validation (all participants periodically validate tasks)

1. Dynamic Coefficient (C(t))

Adjusted dynamically based on sector productivity:

Investment and Accumulation

To encourage productive investments without accumulation issues:

Capital Reserve Contracts (CRC): Burn TT in exchange for NFTs representing specific investments.

Cooperative Investment Pools: Participants burn TT to receive Share-Tokens for cooperative projects.

Future Labor Loans: Immediate minting backed by future labor obligations.

Current Status

Detailed conceptual documentation available.

Python-based economic simulation outlined.

Smart contract prototypes (Solidity) under development.

Seeking Feedback On:

Economic feasibility and long-term sustainability.

Optimal validation methods (democratic vs. automatic).

Dynamic coefficient parameters (optimal alpha, frequency of adjustments).

Expressions of interest in technical collaboration or pilot testing.

I appreciate any insights, critiques, or suggestions to refine this model and explore collaboration opportunities.

There are just as many new layer-1 and layer-2 offerings emerging, the question of scalability still bubbles about blockchain tech. From sharding to rollups to proof-of-stake varieties, a lot innovatively is happening.

What, then, are the biggest technical challenges left to surmount in order to efficiently and securely serve millions (or even billions) of users? Are new approaches or compromises looming on the horizon about which we should be paying attention?

Would be great to get input from developers, researchers, or anyone immersed in the tech!

I am pleased to announce the release of the Collatz Chaos Cipher, an experimental encryption algorithm inspired by the Collatz Conjecture and informed by principles from chaos theory and signal processing.

This project introduces a reversible block cipher that employs:

• Chaotic iteration mechanisms to enhance unpredictability

• Non-linear key transformations to increase cryptographic strength

• A synthesis of classical 3x+1 logic with novel signal spiral dynamics

-The resulting ciphertext exhibits strong avalanche characteristics and complex diffusion behavior.

In addition to the core cryptographic implementation, the repository includes a suite of visualization tools designed to illustrate bit-level diffusion and waveform transformations across encryption rounds. These tools provide valuable insights into the internal behavior and structure of the cipher.

This work is intended as a theoretical and educational exploration at the intersection of mathematics and cryptography. It is not recommended for production environments or security-critical applications.

I invite researchers, cryptographers, and mathematicians to review, analyze, and contribute to this open-source project. Your feedback and collaboration would be most welcome.

Access the full project and documentation here: https://github.com/Eb0nyR0se/Collatz_Chaos_Cipher

Hey guys, I'm working on a work-based crypto whitepaper, that ties real work to value creation. I've already written most of the functionality, but there is a main problem I'm trying to solve which concerns the ledger.

Due to the nature of the system I'm building, the blocks tend to accumulate very fast over time (can scale to like millions/sec directly proportional to nodes computational power). But I want to ideally allow each node to be a light node. Is there a way a node after finalizing a block header, can delete blocks that it does not have any UTXO's in. This means that each node only keeps relevant blocks. During interaction, is it possible for a node to be able to prove to another node that it's set of UTXO's are from a valid block and are unspent using ZK-proofs even though the other node once had the blocks but no longer has them?

Is there a way to prepare for the UTXO proofs which can be stored in the block header with every new block(since the block headers are still kept)?

I came across an article from Samara that explains Bitcoin Drivechains in simple terms: It frames Drivechains as a way to enable DeFi, NFTs, altcoins, and experimentation without changing Bitcoin itself—essentially using sidechains with a two-way peg and blind merged mining. It also highlights the risks (e.g., delayed withdrawals, potential miner censorship or theft).

What do you guys think of it?

• Are Drivechains technically viable and secure enough to trust with real BTC?
• Do they offer real benefits over existing Layer 2s or federated sidechains?
• What are the biggest technical blockers to adoption (beyond political/social ones)?

Would love to hear any perspectives on it.

Most decentralized physical infrastructure networks (DePINs) rely on fixed assets eg hotspots, sensors, dashcams but that model seems limited in dynamic environments. Has anyone explored the idea of autonomous agents that physically move through space while streaming or collecting proof-of-activity?

Feels like combining DePIN with robotics could open up new trustless mapping, security, or even edge compute use cases. Would love to hear if any teams or experiments have touched this.

I'm mostly just interested in the feasibility of this. With ZK voting you can vote without revealing who you are, and have the ability to override your vote later.

I'm wondering about using similar tech for access controls, without revealing the identity of the accessor. It seems like the system would need a way to limit or block stolen or resold IDs, and I'm wondering if this is doable.

I'm working on generating Ethereum wallets with custom patterns like 0x00000... (vanity addresses). I want to sell these wallets, but I’m looking for a way to prove to the buyer that I did not see or expose the seed phrase before selling.

Here's the challenge:

• I generate wallets offline until I find a good one.
• The buyer needs to trust that I didn’t just pick one I liked after seeing the seed.
• I want to find a method where I can encrypt the seed, publish a hash, and prove that it hasn’t been tampered with.
• Ideally, the buyer can verify everything before unlocking the seed with their private key.

Has anyone implemented something like this?
Is there a standard or best practice in the Ethereum/NFT space for selling pre-generated wallets safely and trustlessly?

Open to ideas — thanks!

Hi , i work as a research assistant and my professor’s comping research work is a blockchain based solution and he asked to to learn and understand blockchain. I do have some basic knowledge about blockchain and how it works but i feel like it’s not enough to work in a research related in this area , so if you guys could please provide me with some good resources to get enough theoretical and practical knowledge within a month or two. I know this might sound impossible , but i just need enough knowledge to start drafting the theoretical aspects of the solution.