Avatar
Dikaios1517
b7274d28e3e983bf720db4b4a12a31f5c7ef262320d05c25ec90489ac99628cb
│Christian│Husband│Father│Presbyterian│Bitcoiner│ In that order. Find my reviews at nostr:npub1rsv7kx5avkmq74p85v878e9d5g3w626343xhyg76z5ctfc30kz7q9u4dke Bolt12: lno1pgz95ctswvtzzq3kw0eghxwlgwrsq84tp28uqc8cewk83vhendsnz3jdum7hut3y75

Particularly as part of a multisig quorum, they are fantastic.

Different trade-offs for different situations. I am not in a place where it is difficult to get my hands on a dedicated hardware wallet, such as a ColdCard, but for those who are in such a jurisdiction, by all means take advantage of the fact that the Seed Signer uses hardware that is available for general purposes.

There's no "let it happen" or "don't let it happen" in Bitcoin. Luke can do what he wants with the blocks his pool mines, and anyone who disagrees with him won't mine on his pool.

As long as there is a substantial amount of miners willing to include Ordinals in blocks, then there is no way to ACTUALLY censor them. So far, it is looking like that will be the case for the foreseeable future, since OCEAN is the only option for taking a firm stance against including Ordinals and yet they haven't attracted even 1% of the hashrate.

It's the same thing with OFAC sanctioned transactions. As long as there's a substantial amount of hashrate out there that won't exclude them, they will make it into a block.

For being an "attack on Bitcoin" it's a pretty pathetic one.

They haven't found a block since the 3rd of the month, and no one can point to a single transaction that was effectively censored (was never confirmed into a block) due to their actions.

Point your hashrate elsewhere and get on with your life.

nostr:note1k4765svkcg0qgzrea208qcp98vhj80gph62a6e4hr9pnhz3clhmsrkmla5

This episode of TFTC was interesting, if for no other reason than hearing a very different perspective on the prospect of Bitcoin ETFs likely getting approved in the near future.

There is MUCH to disagree with, and it highlights just how much work we have ahead of us. Yet, it it also gives a clear view into how mainstream investors will likely view Bitcoin ETFs.

https://tftc.io/the-etf-will-push-bitcoin-to-500-000-with-fred-krueger/

I am pretty sure the point is that he can't decide it unilaterally. He can only decide it for his mining pool, and anyone who disagrees can mine on any other pool.

This was a great read with a great points about the rights of miners to include or exclude transactions using whatever criteria they deem best. Those who disagree, which seems like plenty of folks out there, will simply point their hashrate elsewhere.

nostr:nevent1qqs0twcug7vsrd2gysu2hyvx4v5f5gxw2prt74ch9yhh4apyzuu6nksprpmhxue69uhhyetvv9ujucm4wfex2mn59en8j6f0qgs964yyepyk02krnpkd2y403hxa2fpn6zgp4kamty3kqyvgg2p658srqsqqqqqpc3prm6

An argument against OCEAN filtering out inscriptions that I have been hearing is, "If they pay the fee and don't violate the consensus rules, they shouldn't be censored."

Setting aside the fact that one mining pool with a pittance of hashrate can't censor anything if they tried, doesn't this argument cut the other way, too? So far as I know, the consensus rules entirely permit a mining pool to include or exclude whatever transactions they like from a block, so long as they succeed in finding a valid hash. There is NO consensus rule that requires miners to maximize their short term profits by using sats/vbyte as the sole determining factor for what transactions they include.

I am more of the opinion that yes, Ordinals and the other BRC-20 garbage will get priced out of Bitcoin's real value proposition as sound money, but there is also nothing wrong with a mining pool deciding that they don't want to participate in perpetuating their existence in the meantime.

Recognizing that inscriptions will almost certainly continue to be included by other pools, yet they have the right to say, "Not in the blocks we mine, and anyone who agrees with that stance is welcome to mine with us. If you don't, that's fine, too. There are plenty of other pools that would be happy to have you."

Replying to Avatar jb55

I’m going to be on an ordinals panels as one of the people who is counter arguing the claim that they are good for bitcoin. I decided to brush up on the technicals on how inscriptions work. I am starting to see luke’s perspective on how it is exploiting a loophole in bitcoin’s anti-data-spam mechanisms.

## Storing data in Bitcoin, the “standard” way

The standard way you add “data” to bitcoin is by calling the OP_RETURN opcode. Bitcoin devs noticed that people were storing data (like the bitcoin whitepaper) in the utxo set via large multisig transactions. The problem with this is that this set is unprunable and could grow over time. OP_RETURN outputs on the other-hand are provably prunable and don’t add to utxo bloat.

Here’s an excerpt from the march 2014 0.9.0 release notes that talks about this:

> On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database.

Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

Much of the work on bitcoin core has been focused on making sure the system continues to function in a decentralized way for its intended purpose in the presence of people trying to abuse it for things like storing data. Bitcoin core has always discouraged this, as it is not designed for storage of images and data, it is meant for moving digital coins around in cyberspace.

To help incentive-align people to not do stupid things, OP_RETURN transactions were not made non-standard, so that they are relayable by peers and miners, but with the caveat:

1. They can only push 40 bytes (later increased to 80,83, I’m guessing to support larger root merkle hashes since that is the only sane usecase for op_return)

Bitcoin also added an option called -datacarriersize which limits the total number of bytes from these outputs that you will relay or mine.

## Why inscriptions are technically an exploit

Inscriptions get around the datacarriersize limit by disguising data as bitcoin script program data via OP_PUSH inside OP_IF blocks. Ordinals do not use OP_RETURN and are not subjected to datacarriersize limits, so noderunners and miners currently have limited control over the total size of this data that they wish to relay and include in blocks. Luke’s fork of bitcoin-core has some options to fight this spam, so hopefully we will see this in core sometime soon as well.

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

The purpose of the witness discount was to make it cheaper to spend many outputs which helps the reduction of the utxo set size. Inscriptions took advantage of this discount to store monke jpegs disguised as bitcoin scripts. Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit. Expect it to be fixed, or at least provide tools to noderunners for fighting this spam.

## Where do we go from here

The interesting part of this story is that people seem to attach value to images stored on the bitcoin blockchain, and they are willing to pay the fee to get it in the block, so non-ideologic miners and people who don’t care about the health and decentralization of bitcoin are happy to pay or collect the fee and move on.

Data should not get a discount, people should pay full price if they want to store data. They should just use op_return and hashes like opentimestamps or any other reasonable protocol storing data in bitcoin.

After going through this analysis I’ve come to the opinion that this is a pretty bad data-spam exploit and bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization of the network are and I’m glad to see it.

Great read! Thanks for the additional context on this!

ThEy pAiD tHe fEe, sO iT's nOt sPaM!

Oh, I 100% think this garbage is going to be a fad and loads of folks who bought into it will get rekt.

I am also 100% fine with OCEAN deciding not to include this junk in any blocks they mine, particularly given that all the other pools are still going to include them.

However, I said this over on the former bird app earlier today, and it still applies here:

Bitcoin is about separating money from state.

NFTs are about separating fools from their money.

Best we discourage mixing the two.

Please make them stop censoring all the so-called spam! We shouldn't have to wait an additional ~10 minutes for a different pool to find the next block so we can have masterpieces like this forever inscribed to the blockchain!

My daughters 100% agree and are interested in reading your script. lol!

Replying to Avatar PABLOF7z

Introducing EXIT

You broke up with your ex; it wasn’t treating you well, maybe it was shadow banning you or your friends; it was manipulating you into becoming your worst possible self.

But over the years you accrued a bunch of quality shitposts, and perhaps some nuggets of wisdom.

Introducing: https://exit.pub:

The last bridge you’ll need to port over your data into the new world of decentralized freedom-tech.

1. Download your twitter archive

2. If Elon agrees, you’ll get a zip file; uncompress it and just use exit.pub to import your data into nostr

✅ original dates are used; whatever you posted in 2009 will show up as posted in nostr in 2009

✅ granular control of which tweets to import (threads, non-replies, replies)

✅ V4V, you choose how much your shitposts are worth

✅ it *should* preserve embedded images

✅ granular control of which relays you want to publish to

Try it out:

https://exit.pub

That was ridiculously easy to do! Thank you so much nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft!