Avatar
Geek
b1fe47d95b312cff5f7b84c62aa4340e894f3b0c397d40be56c6ee927868671c
Christian, Geek, #GoPackGo, #Bitcoin, Pilot Anarcho Christian? Maybe Happily Married 30+years

Merry Christmas!!! 🎄🎄🎄

I'm posting this below the 2000 sat limit because I don't need you to read it on the pod but I know you read all of these and wanted to give a different perspective

As a pilot, there are some outcomes that are so catastrophic that we build in lots and lots of mitigations so that we don’t EVER encounter them. An example is fuel. Running out of fuel increases the likelihood of a crash to nearly 100%. Meanwhile the actual incidence of fuel related crashes in commercial aviation is very close to 0. The fact that the incidence is close to 0 doesn’t mean we can safely remove fuel reserve requirements, or proper fuel planning processes.

This is how I see the SPAM debate. There are some outcomes (e.g. illegal data in the chain) that are so bad that, even if we haven’t seen it yet, we have to build as many mitigations as possible. If the US government can prosecute the samourai developers despite Section 230, it’s hard to imagine that node operators that knowingly host illegal data would also be immune from prosecution as a way to attack Bitcoin. So we have to build in multiple layers of mitigation to prevent that catastrophe. With Core deciding to open up OP_RETURN to 100k bytes, they’ve taken away one of those mitigations.

For me personally, best case scenario: OP_RETURN goes back to 83 bytes and the inscriptions bug gets fixed.

Barring that, what is the next best mitigation in order to prevent the catastrophic result of illegal data on the chain? Certainly a soft fork is a far worse option. But it might be the next best option.

Still I’d much rather that core come to their senses. If not, that more people run knots - or some other bitcoins that allows for filtering OP_RETURN. Only after both of those fail, would I like to see a soft fork. Because we can’t tolerate the catastrophic result of illegal data on chain.

https://fountain.fm/episode/LCHvtqGAP4hoU4nsJY12

nostr:nevent1qvzqqqpxquqzp9ejn6sg6jskmyrcd465cwmvmhkcucny6mwu4n7y6d9c6sc3ss289exu9h

Personally I like 4. But you should not trust my sense of style.

As a pilot, there are some outcomes that are so catastrophic that we build in lots and lots of mitigations so that we don’t EVER encounter them. An example is fuel. Running out of fuel increases the likelihood of a crash to nearly 100%. Meanwhile the actual incidence of fuel related crashes in commercial aviation is very close to 0. The fact that the incidence is close to 0 doesn’t mean we can safely remove fuel reserve requirements, or proper fuel planning processes.

This is how I see the SPAM debate. There are some outcomes (e.g. illegal data in the chain) that are so bad that, even if we haven’t seen it yet, we have to build as many mitigations as possible. If the US government can prosecute the samourai developers despite Section 230, it’s hard to imagine that node operators that knowingly host illegal data would also be immune from prosecution. So we have to build in multiple layers of mitigation to prevent that catastrophe. With Core deciding to open up OP_RETURN to 100k bytes, they’ve taken away one of those mitigations.

For me personally, best case scenario: OP_RETURN goes back to 83 bytes and the inscriptions bug gets fixed.

Barring that, what is the next best mitigation in order to prevent the catastrophic result of illegal data on the chain? Certainly a soft fork is a far worse option. But it might be the next best option.

Still I’d much rather that core come to their senses. If not, that more people run knots - or some other bitcoins that allows for filtering OP_RETURN. Only after both of those fail, would I like to see a soft fork. Because we can’t tolerate the catastrophic result of illegal data on chain.

Not all of it. But you not willing to type out a single sentence makes me think you don't have an answer. Care to prove me wrong?

Don't we all agree that the law fair imposed on tornado cash developers and samurai developers is a travesty?

And it's that kind of power you're assuming won't be leveraged against CSAM on a node?

If software developers are at risk what makes you think that node runners aren't?

I don't know what the percentage is. But it seems to me that if 80% of nodes will accept non-BIP444 blocks then why would miners care about the 20% of nodes that reject those blocks?

Wow. That's quite a leap. I have not argued for the spam chain. I run Knots. I think that a soft fork is probably a good idea.

But I still don't see how only 20% of us can force miners to mine blocks that follow BIP444 if 80% of the nodes will accept non-BIP444 blocks

The UASF during the block size wars is a little more complex than the fact that few nodes signaled support. It was supported by exchanges and waller providers. And that amount of support is what forced the miners to capitulate.

Do we have that level of support for this soft fork?

It takes a 58 minute video, not made by you, to answer what you think is wrong in nostr:nprofile1qqspnlha0uuujmf07ahc0amz0tnez3dujuwc4v3jq5q9jwd94yfmctcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qguwaehxw309ahx7um5wgkhqatz9eek2mtfwdhkctnyv4mz7e8azdv's 29 word statement?

I'm happy to agree that busting open OP_RETURN is stupid. I'm running knots. But I still do not see what is wrong with what Livera said.

Re: a soft fork, I have posted a question on Matthew Kratter's videos: if we only have 20% of node runners switching to knots why do you think we have sufficient consensus to force the miners to mine the soft fork blocks?

https://fountain.fm/episode/WOslYaeXHkGPni8BznUK

nostr:nevent1qvzqqqpxquqzp2zlqylc5unn2p8n4k9y2mt870nv5hl2s2j6e5rup8ewu65205hxv9azaq

Re video, it's great when there are visuals that help convey information. But as soon as people do that the audio version suffers and I tend to switch to the video version only. Is there some way to stream sats while watching the link to the video feed?

https://fountain.fm/episode/NJ9Vr8mMPTAt9Q7GUgCb

nostr:nevent1qvzqqqpxquqzqyn2lnw2lxppve7z94rm58un5zr788afh4tzdff70qjua8c8anvdx9p4xe

The time frame on the right picture is a lot longer than in the left picture. I think if both covered a span of 9 years they wouldn't look as similar.

Really great episode. I kindly request more like this, where the topic is about how one might help convince my skeptical church leadership to save on Bitcoin.

This is particularly relevant to me as I've been saving my tithe in Bitcoin on their behalf for a few years now. (With their blessing.) But I don't want to give it to them yet because their policy is to immediately turn it into USD.

So any advice or discussion on how to get them to change their mind/policy is very much appreciated.

https://fountain.fm/episode/mJib1qwQMTyFnDzT8oew

nostr:nevent1qvzqqqpxquqzq2vpq45s08uqsgwd02rsyhaphauhqk9uzekf6mpsztjha574clstfnm3vy

Back to the grind. Stacking continues.

Interesting how you seem to think that technical process is all that matters and yet you resort to an argument to trust.

Ok.

Running 29 will continue to work until there is some issue identified and fixed in a later version.

Running 30 you lose the ability to filter OP_RETURN > 80 bytes.

Running knots you get all the fixes applied to 30 and later plus you retain the ability to filter OP_RETURN size. But you can also turn that off if you want.

To me knots gives me the most options. 30 removes an option that I wish to exercise. So for me, it's knots.