Connect with us

Opinion

Bitcoin Rollups – The Rock Or The Hard Place?

Published

on



Rollups have become the narrative focus of scaling Bitcoin lately, becoming the first thing to truly “steal the limelight” from the Lightning Network in terms of wider mindshare. Rollups aim to be an off-chain layer two that is not bound or constrained by the liquidity limitations that are central to the Lightning Network, i.e. end users required someone allocate (or “lend”) them funds ahead of time in order to be able to receive money, or intermediary routing nodes requiring channel balances that can facilitate the movement of the payment amount all the way from sender to receiver.

These systems were originally developed to function on Ethereum and other Turing complete systems, but as of late the focus has shifted to porting them to UTXO based blockchains such as Bitcoin. This article is not going to discuss the current state of things being implemented on Bitcoin currently, but going to discuss the function of an idealized rollup that people are aiming for in the long term depending on features Bitcoin currently does not support, namely the ability to verify Zero Knowledge Proofs (ZKPs) on Bitcoin directly.

The basic architecture of a roll is as follows: a single account (or in Bitcoin’s case UTXO), holds the balances of all users in the rollup. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all the current balances of existing accounts in the rollup. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend a user must still sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by crafting a transaction proving their account is part of the merkle tree, they can unilaterally exit the rollup without the operator’s permission.

The operator of the rollup must include a ZKP in transactions that update the merkle root of account balances on-chain in the process of finalizing off-chain transactions, without this ZKP the transaction will be invalid and therefore not includable in the blockchain. This proof allows people to verify that all changes to off-chain accounts were properly authorized by the account holder(s), and that the operator has not conducted a malicious update of balances to steal money from users or reallocate it to other users dishonestly.

The problem is, if only the root of the merkle tree is posted on-chain where users can view and access it, how do they get their branch in the tree in order to be capable of exiting without permission when they want to?

Proper Rollups

In a proper rollup, the information is put directly into the blockchain everytime that new off-chain transactions are confirmed and the state of the rollup accounts change. Not the entire tree, that would be absurd, but the information necessary to reconstruct the tree. In a naive implementation, the summary of all existing accounts in the rollup would have balances and accounts simply added in the transaction updating the rollup.

In more advanced implementations, a balance diff is used. This is essentially a summary of what accounts have had money added to or subtracted from them during the course of an update. This allows each rollup update to only include the changes to account balances that occur. Users can then simply scan the chain and “do the math” from the beginning of the rollup to arrive at the current state of account balances, which allows them to reconstruct the merkle tree of current balances.

This saves a lot of overhead and blockspace (and therefore money) while still allowing users to guarantee access to the information needed for them to exit unilaterally. Including this data in a formal rollup that uses the blockchain to make it available to users is mandated by the rules of the rollup, i.e. a transaction that does not include the account summary or account diff is considered an invalid transaction.

Validiums

The other way to handle the problem of data availability for users to withdraw is to put the data somewhere else besides the blockchain. This introduces subtle issues, the rollup still needs to enforce that the data was made available somewhere else. Traditionally other blockchains are used for this purpose, specifically designed to function as data availability layers for systems like rollups.

This creates the dilemma of security guarantees being as strong. When the data is posted directly to the Bitcoin blockchain, consensus rules can guarantee it is correct with absolute certainty. However when it is posted to an external system, the best it can do is verify an SPV proof that the data was posted to another system.

This entails verifying an attestation that data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot verify anything completely except what occurs on its own blockchain, the best it can do is verify a ZKP. A ZKP however cannot verify that a block containing rollup data was actually publicly broadcast after being produced. It cannot verify that external information is actually publicly available to everyone.

This opens the door to data withholding attacks, where a commitment to the data being published is created and used to advance the rollup, but the data is not actually made available. This renders users funds beyond their ability to withdraw. The only real solution to this is to depend entirely on the value and incentive structure of systems completely external to Bitcoin.

The Rock and Hard Place

This creates a dilemma in terms of rollups. When it comes to the data availability issue, there is essentially a binary choice between posting the data to the Bitcoin blockchain or somewhere else. This choice has massive implications for both rollup security and sovereignty, as well as their scalability.

On one hand, using the Bitcoin blockchain for the data availability layer introduces a hard ceiling on how much rollups can scale. There is only so much blockspace, and that puts an upper limit on how many rollups can exist at one time and how many transactions all rollups in aggregate can process off-chain. Every rollup update requires blockspace proportional to the amount of accounts that have had balance changes since the last update. Information theory only allows data to be compressed so much, and at that point there is no more potential for scaling gains.

On the other hand, using a different layer for data availability removes the hard ceiling on scalability gains, but it also introduces new security and sovereignty issues. In a rollup using Bitcoin for data availability it is literally not possible for the state of the rollup to change without the data needed by users to withdraw being atomically posted to the blockchain. With Validiums, that guarantee depends entirely on the ability of whatever external system is being used to resist gaming and data withholding.

Any block producer on the external data availability system is now capable of holding Bitcoin rollup users’ funds hostage by producing a block and not actually broadcasting it to make the data available.

So which will it be, if we ever do get to an ideal rollup implementation on Bitcoin that actually enables unilateral user withdrawal? The rock, or the hard place? 



Source link

hardware wallets

Celebrating 10 Years of the Hardware Wallet Revolution

Published

on



As we celebrate the 10th anniversary of the first hardware wallet, it’s remarkable to see how far Bitcoin security has come. From the early days of precarious self-custody methods to the game-changing creation of the Trezor Model One, this revolution has transformed the way we protect our digital assets. With a decade of this experience behind us, it’s worth revisiting the challenges of early Bitcoin self-custody, the pivotal impact of the first hardware wallet, the essential role of self-custody in today’s Bitcoin landscape, and the innovative advancements continuing to shape the future of crypto security.

The Origin Story

It all began in 2011 when Marek “Slush” Palatinus logged onto his mining pool server and discovered 3,000 BTC were missing. A mining pool is a collective of miners who combine their computational resources to increase their chances of successfully mining Bitcoin blocks. Slushpool, now known as Braiins Pool, was the pioneering mining pool in the Bitcoin community, established in 2010.

This incident highlighted a significant issue: even tech-savvy Bitcoin enthusiasts could fall victim to online attacks. At that time, securing and managing Bitcoin was a daunting task, involving storing private keys on a computer. However, securing information on a computer is difficult; these complex machines are vulnerable to many threats that allow thieves to steal private keys controlling Bitcoin. The hack that cost Palatinus 3,000 BTC was a reminder of these early vulnerabilities.

Recognizing a pressing need for a simple, stand-alone device that could securely store Bitcoin, Slush, along with Pavol “Stick” Rusnák, embarked on creating the world’s first hardware wallet. Their vision was to develop an offline computer specifically designed to store Bitcoin securely and make it accessible to non-technical users. The concept was straightforward yet revolutionary: a small, single-purpose device that would keep private keys in an isolated environment, protected from online threats.

Before Hardware Wallets

Before hardware wallets became widely available, users had to rely on software wallets installed on computers or smartphones, which exposed them to a range of security threats. Malware infections and other attacks were common. Paper wallets were considered more secure but still required a computer to create the wallet. More secure methods, such as using air-gapped computers for cold storage, required significant technical expertise, and even these methods lacked an adequate level of security for larger amounts of Bitcoin.

The usability of early Bitcoin wallets was also a significant issue, with clunky interfaces and complicated backup processes. Many users failed to back up their wallets properly, leading to permanent loss of funds if a device was lost or damaged. Users were frequently unaware of best practices for backups, and the lack of standardized backup methods further increased the risk. A major improvement in backup standardization came with the introduction of Hierarchical Deterministic (HD) Wallets with BIP32 in 2012, allowing for easier and more reliable backups. Despite these advancements, there was still a lack of easy and user-friendly options for newcomers. In short, the period before Hardware Wallets was marked by significant security and usability challenges, making Bitcoin self-custody a complex and risky endeavor.

The First Hardware Wallet

In the years leading up to 2014, various attempts were made to develop simple, single-purpose devices for cryptocurrency storage. However, these efforts failed to gain traction or meet the necessary security standards. Recognizing the need for a robust solution, Slush and Stick monitored the landscape for two years before they finally decided to create their own hardware wallet.

In 2014, they released the Trezor Model One. This device was the first ever hardware wallet, combining user-friendly design, truly random private key generation, and the ability to easily sign transactions completely offline. In addition, it implemented the BIP39 standard, a new standard created by the Trezor creators to back up wallets using a list of 24 words representing the private keys, a standard adopted by many wallets and familiar to anyone who has put their Bitcoin in self-custody.

When the user first connects the device, it guides them through the setup process to create a new wallet. The device generates a recovery seed, which represents a human-readable version of the wallet’s master private key and enables wallet recovery in case of device malfunction. The user is prompted to write down this list of words on a piece of paper, ensuring the wallet is backed up, and the private keys remain offline.

This onboarding process ensures that users create a backup and keep it secure. The user-friendly design offers advanced security, making hardware wallets accessible to both beginners and experienced users.

The Open Source Advantage

A key aspect of Bitcoin is its commitment to open-source principles, and that’s why the founders of Trezor adhered to the same principles when developing the Trezor Model One. This approach has been adopted by most manufacturers in the industry. Open-source software allows the community to audit and verify a system’s integrity. This transparency ensures that potential vulnerabilities can be identified and addressed promptly and allows improvement by the global community. The first hardware wallet was open source, and many in the industry have embraced this approach for transparency, emphasizing the Bitcoin ethos, “Don’t trust; verify.”

The Importance of Self-Custody

Throughout Bitcoin’s life, we have seen many crypto exchanges and custodians collapse or suffer severe security breaches, showing the importance of holding your private keys. The mantra “not your keys, not your coins” emphasizes that relying on third-party institutions means trusting someone else with your assets, which can lead to big problems if the exchange gets hacked, mismanaged, or faces legal issues.

The Mt. Gox incident in 2014, one of the earliest and most notable exchange collapses, saw the loss of 850,000 Bitcoins, valued at hundreds of millions of dollars at the time. This catastrophic failure was due to both hacking and mismanagement, leaving users unable to recover their funds. Bitfinex also suffered a significant hack in 2016, resulting in the theft of nearly 120,000 Bitcoins. QuadrigaCX in 2019 saw users losing access to their funds after the sudden death of its founder, who was the only one with the keys to the exchange’s wallets. Cryptopia faced a debilitating hack in 2019, and Binance, the largest cryptocurrency exchange by volume, has also experienced breaches and faces increasing regulatory scrutiny. More recently, the FTX collapse in 2022 further reinforced the dangers of entrusting assets to centralized entities. Overall, mismanagement and fraudulent activities led to the loss of billions, impacting countless users and shaking confidence in centralized exchanges.

By using hardware wallets, individuals can achieve true financial independence, keeping their digital assets safe from the vulnerabilities of trusted custodians.

The Evolving Landscape of Hardware Wallets

Over the past decade, the hardware wallet industry has greatly expanded, with many companies offering a variety of products and features to meet different needs. User interfaces now range from simple button-based navigation to touchscreens and full keyboards. Many devices now support multiple cryptocurrencies, while some focus exclusively on Bitcoin. This range of devices caters to both beginners and advanced users, ensuring everyone can find a suitable option.

Another advancement has been the inclusion of secure elements—specialized chips designed to protect devices from physical attacks. However, all secure elements currently available on the market are closed-source, which raises transparency concerns. To address this issue, companies like Tropic Square are actively working on developing open-source secure elements to enhance trust and security.

Other significant advancements in the industry aim to enhance the security and robustness of wallet backups. Techniques such as Shamir’s Secret Sharing, Multisignature Wallets, and SeedXOR allow users to remove single points of failure, making it significantly more difficult for thieves to compromise the wallet.

Looking ahead, we can expect more improvements in hardware wallet security and usability. One notable development is the wider implementation of a new enhanced standard, SLIP39, which uses Shamir’s Secret Sharing. This method is becoming preferred over the traditional BIP39 standard due to its enhanced security and user-friendliness. With SLIP39, users start with a single list of words to back up their wallet and can later upgrade to a “sharded” backup with multiple shares. This approach provides a flexible and highly secure solution, making advanced security measures more accessible and practical for a wider range of users.

Looking Forward to the Next Decade

As we celebrate the first Hardware Wallet, it’s clear that this revolution has fundamentally transformed cryptocurrency security. From humble beginnings as a hobby project to becoming a trusted name in the industry, Trezor has pioneered innovations that have empowered countless individuals to take control of their financial future. The journey from the first prototypes to the sophisticated devices that we now use today is a testament to the vision and dedication of the Trezor team.

With the continuous evolution of Hardware Wallet functionality and a commitment to security and transparency, the future looks promising. As we look forward to the next decade, the industry remains dedicated to securing and innovating Bitcoin security and usability, ensuring that self-custody becomes increasingly accessible and secure for all.

This is a guest post by Josef Tetek. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.



Source link

Continue Reading

Fractal Bitcoin

Fractal Bitcoin: A Misleading Affinity

Published

on



Fractal Bitcoin is a recently launched project that bills itself as “the only native scaling solution completely and instantly compatible with Bitcoin. In essence it is a merge mined system portraying itself as a second layer sidechain for Bitcoin, where multiple levels of “sidechains” can be stacked on top of each other. So think of a sidechain of the mainchain, a sidechain of the sidechain, a sidechain of the sidechain of the sidechain, etc. It is not.

Shitcoins Are Not Second Layers

Firstly, the entire system is built around a new native token, Fractal Bitcoin, that is issued completely independent of Bitcoin. It even comes with a massive pre-mine of 50% of the supply being split between an “ecosystem treasury”, a pre-sale, advisors, grants for the community, and developers. This is essentially the equivalent of the entire first halving period of Bitcoin when the block subsidy was 50 BTC per block. From here the network jumps to 25 Fractal Bitcoin (FB) per block.

Secondly, there is no peg mechanism for moving actual bitcoin into the “sidechain.” Yes, you read that correctly. They are framing themselves as a sidechain/layer two, but there is no actual mechanism to move your bitcoin back and forth between the mainchain and “the sidechain” Fractal Bitcoin. It is a completely independent system with no actual ability to move funds back and forth. One of the core aspects of a sidechain is the ability to peg, or “lock,” your bitcoin from the mainchain and move it into a sidechain system so that you can make use of it there, eventually moving those funds back to the mainchain.

Fractal Bitcoin has no such mechanism, and not only that, the discussion around the topic in their “technical litepaper” is completely incoherent. They discuss Discreet Log Contracts (DLCs) as a mechanism for “bridging” between different levels of Fractal sidechains. DLCs are not a suitable mechanism for a peg at all. DLCs function by pre-defining where coins will be sent based on a signature from an oracle or a set of oracles expected at a given time. They are used for gambling, financial products such as derivatives, etc. between two parties. DLCs are not designed to allow funds to be sent to any arbitrary place based on the outcome of the contract, they are designed to allocate funds to one of two participants, or proportionally to each participant, based on the outcome of some contract or event that an oracle signs off on.

This is not suitable for a sidechain or other system peg, which is ideally architected to allow any current owner of coins in the sidechain or second layer system to freely send coins to any destination they choose so long as they have valid control over them on the other system. So not only is there no functional peg mechanism for the live system, but their hand waving about potential designs for one in their litepaper is just completely incoherent.

The whole “design” is a clown show designed to pump bags for pre-mine holders.

“Cadence” Mining

Another troubling aspect of the system is its variation on merge mining, Cadence mining. The network utilizes SHA256 as the hashing algorithm, and it does support conventional Namecoin style merge mining. But there is a catch. Only one third of the blocks produced on the network are capable of being produced by Bitcoin miners engaged in merge mining. The other two thirds must be mined conventionally by miners switching their hashrate entirely over to Fractal Bitcoin.

This is a poisonous incentive structure. It essentially tries to associate itself with the Bitcoin network calling itself a “merge mined system”, when in reality two thirds of the block production mandates turning hashrate away from securing the Bitcoin network and devoting it exclusively to securing Fractal Bitcoin. Most of the retard is not capturable by miners who continue mining Bitcoin, and the greater the value of FB the greater the incentive for Bitcoin miners to defect and begin mining it instead of bitcoin to increase the share of the FB reward they capture.

It essentially functions as an incentive distortion for Bitcoin miners proportional to the value of the overall system. It also offers no advantage in terms of security at all. By forcing this choice it guarantees that most of the network difficulty must remain low enough that whatever small portion of miners find it profitable to defect from Bitcoin to FB can mine blocks at the targeted 30 second block interval. Conventional merge mining would allow the entire mining network to contribute security without having to deal with the opportunity cost of not mining Bitcoin.

What’s The Point of This?

The ostensible point of the network is to facilitate things like DeFi and Ordinals, that consume large amounts of blockspace, by giving them a system to utilize other than the mainchain. The problem with this logic is the reason those systems are built on the mainchain in the first place is because people value the immutability and security that it provides. Nothing about the architecture of Fractal Bitcoin provides the same security guarantees.

Even if they did, there is no functional pegging mechanism at all to facilitate these assets from being interoperable between the mainchain and the Fractal Bitcoin chain. The entire system is a series of handwaves past important technical details to rush something to market that allows insiders to profit off of the pre-mine involved in the launch.

No peg mechanism, an incoherent “merge mining” scheme that not only creates a poisonous incentive distortion should it continue rising in value, but actually guarantees a lower level of proof of work security, and a bunch of buzzwords. It does have CAT active, but so do testnets in existence. So even the argument as a testing ground for things built using CAT is just incoherent and a half assed rationalization for a pre-mined token pump.

Calling this a sidechain, or a layer of Bitcoin, is beyond ridiculous. It’s a token scheme, pure and simple. 



Source link

Continue Reading

Opinion

The (Zero-Knowledge Proof) Singularity Is Near

Published

on



The broader impact of proof singularity extends beyond individual blockchain networks, as it paves the way for a more interconnected and scalable Web3 ecosystem. As ZK proofs become faster and more efficient, cross-chain communication and interoperability can be greatly improved, enabling seamless, secure interactions between various blockchain protocols. This could lead to a paradigm shift where data privacy and security are inherently built into the infrastructure, fostering trust and compliance in industries that require rigorous data protection standards, such as healthcare, finance, and supply chain management.



Source link

Continue Reading
Advertisement [ethereumads]

Trending

    wpChatIcon