Taking place in Washington, D.C. today, an important policy event is set to delve into the growing geopolitical implications of Bitcoin as a technology for financial freedom, cross-border payments, and wealth protection.

A collaboration between the non-profit Bitcoin Policy Institute and the Cornell Brooks Tech Policy Institute, the talk, entitled “Strategic Competition & Digital Currencies,” will feature participation from noted Bitcoin advocate Matthew Pines, Director of Intelligence at the Krebs Stamos Group, 

Also featured on the panel will be Bloomberg reporter Daniel Flatley, Chris Meserole, Director at the Brookings Artificial Intelligence Center, and Sarah Kreps, Professor and Director of the Cornell Brooks Tech Policy Institute.

Scheduled for Wednesday at 12:00pm ET, this event promises to be a crucial forum for experts, policymakers, and enthusiasts to dissect the role of Bitcoin in the ongoing Russia-Ukraine conflict and its broader implications, among other topics.

The event comes at a time when Bitcoin’s influence on global politics and economics is becoming increasingly evident. Given its decentralized and pseudonymous nature, Bitcoin has been employed by various parties in geopolitical struggles, raising questions about the potential ramifications for nations, economies, and security.

As cryptocurrencies gain mainstream attention, understanding their impact on international affairs has never been more critical.

Key topics to be discussed at the event include:

1. Bitcoin as a Means of Evasion: How parties involved in the conflict have used Bitcoin to circumvent sanctions and move funds discreetly.
2. Geopolitical Implications: The broader implications of the conflict for international relations, as well as the evolving role of cryptocurrencies in shaping these dynamics.
3. Policy Considerations: How governments and regulatory bodies are responding to the use of Bitcoin in geopolitical conflicts and what measures are being taken to address these challenges.
4. Cryptocurrency’s Role in Future Conflicts: A forward-looking perspective on how cryptocurrencies could play a role in future geopolitical conflicts and what strategies nations may employ to mitigate risks.

For information about future Bitcoin Policy Institute events, visit the group’s website.

Source link

These days we often wax eloquent about the “early days of Bitcoin” and the great visionaries who participated in the discussions on protocol development. However we often forget that the cypherpunks of olde were human too — that early oversights & unresolved disagreements resulted in cumbersome idiosyncrasies that define our sacred blockchain today.

If you weren’t around in 2009 and want to get a taste of what it was like back then, come join the discussion in Ordinals land. We’re speedrunning Bitcoin Consensus.

What is the debate about?

Ordinal Theory describes how to serialize & track satoshis. These satoshis, when serialized, are called “ordinals”. We can associate chunks of data that we call “inscriptions” to these ordinals, thus creating a form of NFT on Bitcoin. It’s a simple concept, but the implementation of the client that runs ordinals is quite complex. Ordinals began as a passion project but exploded into popularity in a matter of a few weeks. Because of the rise in hype and complexity of the client, a lot of “bugs” in the client implementation were discovered. Due to the arcane nature of how the implementation actually works, a lot of these bugs & idiosyncrasies became the subject of market speculation.

The most notable of these idiosyncrasies has arguably become a feature, not a bug. On the OG Ordinals explorer site, ordinals.com, Inscriptions were displayed with a number whenever they were “inscribed”. These numbers were a fun and easy way to track how many Inscriptions there were and immediately became a focus for collectors.

A few weeks ago, the creator of Ordinals published a blog post about how these Inscription numbers have created undesirable consequences and how maintaining these numbers hamstrings further protocol development. Recently, I tweeted my opinion on the matter and it kicked off the first major debate in Ordinals land.

Narrowly, this is a discussion over maintaining or changing the current numbering of Inscriptions. More broadly, this is one of the first real community discussions over how protocol decisions are made. Broader still, this is a question of “what is the protocol, how do we define an ‘Inscription’”.

Important Clarifications

• Ordinal — a serialized satoshi
• Ordinal number — the number given to an ordinal
• Inscription ID — the ID given to an Inscription, derived from the transaction it’s created in
• Inscription number — the number given to an Inscription based upon its order of recognizance by the ord client ← this is what the debate is over
• This is a rapidly developing topic. I don’t address the refactor inscription parsing or sequence numbering PRs in this piece.

How did we get here?

On January 20, 2023, Casey Rodarmor announced that his ord client was “ready for mainnet”. Casey had been incubating Ordinal Theory for years and workshopping the client with friends. Ord also enabled inscribing, identifying, and reading Inscriptions. Casey & the gang would spend their time casually coding and discussing Bitcoin heresies such as “art on other blockchains is actually kind of cool”.

When Ordinals & Inscriptions went viral in early February, this once personal project spawned an entire vibrant ecosystem overnight. As hype grew we saw the genesis of 2 narratives: a tale of the Code and a tale of the Culture. At times they are interlinked but they could also be entirely distinct, much like a lot of Bitcoin today.

The Code

The ord client existed entirely on Casey’s personal github repo throughout the past spring. Hundreds of issues piled up as the entire NFT userbase piled into a handful of discord servers. Casey’s code and Bitcoin itself were stress tested.

A couple weeks into the frenzy, it became clear that some inscriptions weren’t being recognized by ord. These inscriptions mostly had to do with edge cases in either how Bitcoin works and how the ord client parsed through inscriptions. That led to some “missed inscriptions” that went into Bitcoin blocks but weren’t displayed on the ordinals.com frontend, therefore they didn’t receive an Inscription number. It wasn’t very clear how many were missing or what we even thought about those inscriptions… …were they actually “inscriptions”? This topic was discussed very little because there was a new kind of Bitcoin culture forming, one that brought with it a cacophony that drowned out much further technical discussion. For the time being, most of the rules of the protocol had to be intuited from how ord worked.

The Culture

The entirety of interest in Ordinals came from outside Bitcoin — from NFT collectors & degenerates alike. These are largely nontechnical folks, but also highly motivated to jump through whatever hoops needed in order to buy a jpeg (syncing a full Bitcoin node, running ord in command line). These newly christened bitcoiners immediately began collecting, trading and speculating on the hot new digital assets.

As Inscription activity heated up, ordinals.com quickly ticked towards Inscription #10,000. An iconic Twitter spaces bore witness to crossing the historic number — that same twitter spaces evolved into the de facto Schelling Point for Ordinals culture & events: The Ordinals Show. Casey was inundated with requests for interviews while the legacy Bitcoin community criticized & clutched their pearls at this new beast, slouching towards Bitcoin. It was an incredibly overwhelming period — the best of times and the cursed of times.

The topic of missing inscriptions was brought up in a couple confused github issues and discord threads. In mid-February the subject of these missing inscriptions came up on a podcast Casey was on. He put the issue up for vote to the hosts who voted to keep the Inscription numbering as-is, and then Casey tweeted this out:

The Curse

So what should we do about these missing inscriptions? Some projects began intentionally producing these “missing” inscriptions and created a sense of urgency to resolve the issue. In April, Casey put out PR #2307, coining the term “Cursed” for these missing inscriptions. The PR proposed giving these cursed Inscriptions negative numbers, with the plan to at some undefined point in the future “bless” the inscriptions by recognizing them in the ord client. They would then receive numbers whenever they were recognized.

Diving a little deeper, there are multiple ways an Inscription can not be recognized & parsed by ord. Raph describes 4 types of Curses:

The 4 Curses (so far)

• More than 1 inscription in a transaction
• ord only recognizes inscriptions in the first (reveal) input, so inscriptions in other inputs are cursed
• If there are uneven tags (most popularly OP_66, but can be any OP_evennumber) within an inscription envelope the client considers the inscription unbound to a specific satoshi
• More than 1 inscription on a sat (now called “reinscription)

While these are the 4 types of clearly identified curses, we do not know what other curses may be discovered in the future. Perhaps these 4 are all that will ever exist (I doubt it), but this is an unknown unknown. Each of these existing & future curses would require community coordination to “bless” and such coordination is hard, often controversial. To commit to an unknown amount of future coordination events is generally bad protocol design especially when it could all be addressed today by not committing to preserving inscription #s.

It is worth noting that during the writing of this article we have discovered a new kind of cursed inscription, emphasizing the point I make above.

Some of us at the time, myself included, tried to bring up our concerns with the approach to maintaining Inscription numbering and the challenges it could introduce to future development. Ordinally, a key developer on the project, encouraged consensus on Inscription ID and leave numbering to the market:

The Consensus

Consensus in Ordinals has pretty much respected Casey’s hegemony & unilateral decision making. The personal repo era, migration to a github org, promoting Raph to lead maintainer, the various PRs & updates — all of these have been celebrated & embraced by most. Updates have been pushed with little community input and scrutiny but have largely been deemed desirable. We even changed numbers before with no community pushback when an inscription was created but not associated with a sat (“unbound”) resulting in an off-by-one error in inscription numbering. A major reason why there has been little community input is because very few people actually understand how the client works under the hood.

Today there are various forks of ord which power the ecosystem: marketplaces, wallets, aggregators, etc. These forks are updated with each iteration to the reference client. Each client generally seeks to maintain parity with ord. We at OrdinalHub have opted not to fork but instead rebuild the entire client in Golang and call it “gord”. Going through this development process has given us an intimate understanding of how the ord client works and the challenges in addressing current & future edge cases.

The Community however is largely unaware of work on github and the technical state of indexing. Very few users seem to understand how their Inscription gets identified & presented on a marketplace or in their wallet. Because of this, the Inscription number is their identity because it is their primary reference point to the asset & ecosystem.

The Case

To summarize my case: I wish to convince the “Cultural Layer” that it is not worth it to the long term success of ordinals to design the protocol around maintaining inscription numbering. I recognize that these numbers are special & cherished, but I think it’s more important to prioritize the long term sustainability of ordinals. If we continue to try to preserve legacy numbering going forwards it complicates protocol development and reduces its likelihood of survival.

Casey recently changed his mind about renumbering and laid out the reasons Cursed Inscriptions make development problematic in his blog:

The logic required to identify & track these cursed inscription types requires custom hard coding of each type and later reordering them back into the series. The process of “blessing” the inscriptions creates more surface area for community debate & potential governance disagreements. It also requires more coordination among ord forks & indexers, in many cases they would have to implement their own custom logic as well. From a technical standpoint, this would result in unintuitive ordering when there exists an extremely intuitive ordering: Block Height & txindex within the block.

Since we do not know the future types of curses that may be discovered, committing to keeping the Inscription numbers potentially brings more scenarios where we have to create weird technical solutions & require social coordination to solve a problem that does not have to exist.

Thinking long term — my personal opinion is that the primary use-case of Inscriptions will not be JPEGS & collectibles, but rather things that take advantage of Bitcoin’s data layer: rollups, state updates, data preservation & documentation, etc. In such a case we should be designing the protocol not for collectibles but for diverse functionality. Our descendants will look back on us and wonder what we were thinking adding this unnecessary complexity (and then they’ll just go back to Timechain sequencing).

All this said, I think there are very promising compromises & middle-ground solutions which reduce historical numbering changes while providing a less-encumbered way forwards. I hope to support some of these options as they develop.

The Collections

The most painful friction is with collectors & collections. The outcry against renumbering has produced “Love Letter[s] to Inscription numbers”, polls, and s to numbering. Many times, those of us most concerned with technical implementation discount the importance of the cultural layer. The Sub1k twitter makes a strong appeal:

Initial estimation suggests renumbering would have minimal change to earlier inscription numbers, but I don’t think that’s a very strong point as the outcry is against any change. I do think there are ways to accommodate for a change in numbering for many collections, by honoring “legacy” numbering or by expanding the collections (is it wrong to have ~100,092 in sub100k?). Sadly, there isn’t a solution for having a specific number like a birthday or a lucky number.

I also love the numbers and I want to keep numbering inscriptions. I just hope to convince you that going forwards it is not worth it to the longevity of the protocol to commit to keeping numbers stable. As I mentioned before, there are compromise proposals out there that preserve historical numbering while reducing emphasis on stable numbering going forwards. I think those may be reasonable solutions.

Metaprotocols

One criticism about changing Inscription numbering is its effect on metaprotocols utilizing inscription ordering. Regardless of my personal criticisms on design or feasibility of these metaprotocols — should a nascent, pre-1.0 protocol like ord, make poor design decisions in order to prevent confusion for metaprotocols built on top of it? I emphatically say no.

That said, I think there are an abundance of solutions these metaprotocols have at their disposal. In the case of BRC-20 the ability to rebuild current token balance state would be broken — “cursed” BRC-20 deploy/mint/transfer functions would distort entire token balances. However this can be addressed by coordinating block heights to update inscription recognizance to parity with ord, “freeze” with a version of ord, and/or “snapshot” balance state. Domo, the creator of BRC-20, has proposed similar ideas.

The same techniques could be utilized by all other metaprotocols such as Bitmap, Satsnames, etc. Some have pushed back on these ideas saying that “coordination is quite difficult”. To that I say no shit, that is why we can’t commit to it at the base protocol level.

Going forwards

This is really a discussion on protocol definition and governance.

Comparatively, this is the most careful & thought out proposal to ord since its initial release in January. This is the first blog post Casey has written in a year and the most public discussion he has participated in since February. While it may seem that decisions are rapid & sweeping, this is by far the most we as a community have discussed any changes to the ord reference implementation.

It’s an open source protocol so the community is free to fork from ord parity. You can choose not to update or implement a client you disagree with. However this is the absolute worst outcome and I would rather do nothing than have a significant community fork and I doubt ord would make a decision that creates such a split.

There have been various proposals for an Ordinals Improvement Process (”OIPS”). It’s clear the community wants to discuss governance now and I welcome this conversation.

As for definitions & documentation, my view is that we should have consensus around the following: core parts of Ordinal Theory (sat origination, tracking, & inscription association), inscription IDs, and valid ord envelope definition. From there we can discuss how the protocol might evolve and how the reference client may be built. Personally, I believe that a “valid ord envelope” should be as permissive as possible.

Overall, I think the community has handled this pretty well. There have been some unnecessary spats but it’s quite minimal compared to the scorched earth at the height of the Blocksize War. Ordinal Theory is Casey’s love letter to Bitcoin. He & those close to the project have devoted a significant amount of their lives to this idea and we all wish to carry on in this happy shared delusion. I am confident there are productive paths forward.

I would write way more on this, but this piece is already way over my word limit so I’ll see you on Twitter.

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

Source link

After only four months since the protocol was launched, ord has its first contentious debate about what are known as “cursed” inscriptions.

The simplest definition of a cursed inscription is any inscription that does not currently get indexed and identified by ord. This term came about as a catchall when some people incorrectly used or purposefully misused opcodes to create inscriptions that were not able to be indexed by ord and would therefore be unrecognized and not given an inscription number.

This issue was first mentioned on April 25 in the ord github and the interim fix proposed by then lead developer Casey Rodarmor was to, “Modify ord to recognize the above currently invalid inscriptions, including retroactively in old blocks, but consider these new inscriptions ‘cursed’ and assign them negative inscription numbers.”

Funnily enough, the example inscription code on the Ordinals docs website would have been a cursed inscription.

Link to embedded Tweet.

There are many ways cursed inscriptions can be created. Any inscription with multiple inputs/outputs would be considered cursed. As shown above, certain misuse of opcodes such as OP_1 can lead to cursed inscriptions. Alternatively, the introduction of OP_66 using a value of “cursed” intentionally made these types of inscriptions by having an even numbered opcode which is not indexed by ord. Unless already defined in the spec, even numbered opcodes are not recognized because they are reserved for future protocol development. The full list of ways to create cursed inscriptions from issue #2045 is as follows:

• Multiple inscriptions per transaction, for efficient batching.
• Inscriptions on inputs after the first, which is useful for collections.
• Multiple inscriptions on the same sat, so that the entire history of a sat doesn’t need to be checked to determine if a new inscription is valid.
• Inscriptions with unrecognized even headers, so that new even headers don’t cause upgraded clients to disagree about inscription numbers.

There are a couple specific debates around cursed inscriptions. One of the disputes comes from the way that these inscriptions are currently numbered. Cursed inscriptions are numbered negatively in the order of their creation. Because of this numbering system and naming convention, some people purposefully chose to create inscriptions and collections that appear “cursed” whether by flipping the image of a positively numbered inscription or using a more sinister image theme when inscribing. The question is: Should these be appended to the index of positively numbered inscriptions or should they keep their negative inscription number when the code is updated?

Additionally, another contentious conversation is what to do about the certain type of cursed inscriptions that used the OP_66 opcode in their creation. Because this opcode is not recognized by ord and even numbered opcodes are intentionally left out for future development use, it is debatable whether inscriptions using this opcode should be included in the cursed set or if they should be rejected.

At the present time, the issue around the even number opcode is listed in the ord github. There are many comments in support of including these inscriptions in the index, but the lead maintainers of the protocol seem to be against it. As of now, the current stance by the developers is that these inscriptions would be unbound, meaning that they would not be assigned to a specific satoshi.

Remember, ordinal theory works based on a first in, first out tracking system for satoshis. Each inscription is assigned to the first satoshi in the genesis transaction when the inscription is created. This type of lens for looking at bitcoin allows images, files, text, etc. to be tracked and transferred. If a cursed inscription is unbound, it would not be associated with a specific satoshi and therefore would be unable to be transferred to another address. Many people who are inscribing are hoping to be able to sell or transfer their inscription to another person. While the inscriptions using this opcode will live forever on the Bitcoin blockchain, if these inscriptions are classified as unbound and unassigned to a specific satoshi, users who minted cursed inscriptions using this opcode would be unable to sell or transfer them.

Herein lies one of the bigger concerns for people who are spending money on transaction fees to create cursed inscriptions. If they are unable to sell them in the future, significant funds would have been wasted on fees. Many users have responded to the github issue, expressing support for including these inscriptions, but the code’s maintainers are not in favor of recognizing cursed inscriptions using the OP_66 even numbered opcode.

On May 30, the new lead maintainer of ord, Raphjaph, wrote, “As the protocol currently stands inscriptions are not valid if they use an unrecognized even tag, so this change already makes a concession by recognizing them. For now they are unbound but we might reconsider this and bind them in the future if there are strong reasons.”

This response is not what many inscribers were hoping to hear. Similar to Bitcoin, ord is open-source software so users can fork the code if they wish to recognize these specific types of cursed inscriptions. This contentious debate is ongoing and the path forward for ord remains to be seen. Users who spent significant sums on transaction fees may be willing to switch to a new version of ord that will recognize their cursed inscriptions, but this is only a theoretical path forward at this time.

Regardless, Ordinals are a new technology being built on Bitcoin. Whether inscriptions are a flash in the pan or if they have lasting power may depend on how this issue gets resolved.

Source link

Source link

Source link

Source link

This week, the Bitcoin community has been abuzz with discussions about the network’s scaling challenges. As the blockchain’s transfer fees continue to surge, the backlog of transactions stuck in the mempool has hit an unprecedented high. Crypto enthusiasts have been sharing their diverse perspectives on the matter, leading to a flurry of takes across various social media platforms.

Bitcoin’s Scaling Challenges Spark Controversy and Diverse Perspectives

The recent surge in Ordinals and BRC20 token usage has led to a significant increase in onchain activity, causing the mempool to overflow with over 400,000 transactions. Currently, a whopping 194 blocks need to be mined to clear the backlog, which would take more than 24 hours at an average of ten minutes per block. As a result, people have been sharing a wide range of opinions on the matter, with some reveling in the higher fees and increased onchain activity, while others suspect that the blockchain is under attack. Meanwhile, some believe that the so-called attacker’s scheme is unsustainable and will eventually fizzle out.

“[The] mempool is spammed with dust payments (546sat) to drive fees high and block normal transactions,” one person speculated. “What if a state is behind this? Or Satoshi itself?” the individual asked. Some people shared the opinion that high fees are meant to prevent spammers. “High onchain fees is the network protecting itself – assuring it is expensive to spam / attack,” another individual tweeted. “From this point of view, the high fees are a VERY good thing. The mempool is a living, breathing, dynamic entity. Fees will eventually go down again when spammer funds are exhausted.”

The recent surge in network fees has left many in the Bitcoin community feeling frustrated. Bitcoin educator Anita Posch took to social media to express her concerns about the impact of these fees on onboarding new users. “Can anyone explain how I’m going to onboard people with these fees?” Posch asked. “Can’t use onchain, can’t open channels. Makes custodial Lightning the only option. And all that because some people think it’s fun to ‘break Bitcoin.’ Why not use Liquid or RSK?” Posch insists that people minting on the Bitcoin blockchain are “privileged.” “The people minting are privileged users,” Posch added. “The ones who really need bitcoin as a lifeboat can’t afford these fees.”

However, not everyone agrees with Posch’s perspective. Bitcoin Stamps founder Mike in Space said it was a “Terrible take.” “No one is looking to ‘break bitcoin’ we’re just USING it and paying for the privilege to do so,” he wrote. “This is what adoption will, inevitably, looks like: HIGH FEES. This is the system working as designed.” People have also been criticizing the Lightning Network (LN) as the dynamic fees have made it difficult to open channels. “The problems that are occurring with LN were known from the start,” Eric Voskuil tweeted. Voskuil added:

I remember this discussion from Scaling Hong Kong. People have been led to believe that chain fees don’t really affect LN and LN doesn’t really push chain fees.

Talks of Censorship Find Their Way Into the Debate

The recent Ordinal trend has sparked controversy in the Bitcoin community, with some individuals taking issue with Udi Wertheimer, one of the trend’s originators. In fact, one Twitter user, Btcbello, went so far as to call for Wertheimer to be barred from the upcoming Bitcoin 2023 conference in Miami. “Dear [Bitcoin Magazine], [David F Bailey], you should cancel/bar Udi Wertheimer from taking part at [The Bitcoin Conference] immediately,” the Twitter account Btcbello wrote. “He thinks he’s more important to Bitcoin than Satoshi Nakamoto, lol.” Further Btcbello asked people to retweet if they agree and 113 people re-tweeted the post.

Meanwhile, Bitcoin developers have been discussing the network’s scaling issues, with some proposing the idea of censorship at the node level. “An alternative would be to enforce this ‘censorship’ at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions. This will be easier to implement, but won’t hit the road until minimum next release,” one programmer wrote. Many people simply do not care about the heated arguments as they insist that people have been warning about these issues for years.

“Cracking up. Bitcoin mempool finally gets some usage and the maxis are framing it as a DoS attack on the network,” the Twitter user Foobar said. “They really have not considered even the most basic scenarios, like ‘bitcoin becomes popular and people are willing to pay to use it.’” Samourai Wallet developer Tdevd tweeted: “LN was priced out? Someone tell The #Kliq. New Jersey burb Dads not paying their landscapers via LN often enough? (“It’s working now.” LOL!) Waiting for pants wearing wifey to bring home the fiat? The Kliq are out of touch… Talk the talk without walking the walk. Street stuff.”

So far, there is no clear solution in sight. The developer who wrote about the possibility of censorship at the node level posed the question of whether action should be taken if the volume does not decrease in the coming weeks. Despite the uncertainty, many people believe that the issues will eventually subside. “It is likely the madness over Ordinals will subside,” one person stated. “Everyone should take a deep breath, Bitcoin will be fine. It will either subside, or we will adapt + grow + build solutions,” another individual said.

What are your thoughts on the ongoing Bitcoin scaling challenges and the heated debates surrounding them? Share your perspective and join the conversation below.

Jamie Redman

Jamie Redman is the News Lead at Bitcoin.com News and a financial tech journalist living in Florida. Redman has been an active member of the cryptocurrency community since 2011. He has a passion for Bitcoin, open-source code, and decentralized applications. Since September 2015, Redman has written more than 7,000 articles for Bitcoin.com News about the disruptive protocols emerging today.