Here is what I learned arguing with people on both sides of the op_return argument. Cunningham's Law in full effect for sure.

1. The Bitcoin blocksize limit is unaffected by the PR. A full archival node is going to grow hard drive storage at up to 4MB every 10 minutes, that number does not change.

2. That 4MB is with maxed out witness data. The base block limit is 1MB, also unchanged.

3. Op_return is base block data while most current arbitrary data schemes store in the larger witness data area.

4. The true limits were always only at the block total level. The total can be made up of any combination of sizes of the sub fields, this is unchanged. My initial assumption on this was backwards. I thought the block limit came from the collection of limits of sub types of data because of my background in networking where that is how the TCPIP packet limits are set. See my incorrect posts earlier where I got this wrong and got corrected.

5. Any "limit" on any particular field size that you set only affects your mempool. This means those limits affect what is in RAM on your node only, not drive space or bandwidth consumption.

6. Your node always validated blocks with any op_return that fits into the base block. This is true of core, libre, and knots. This is why the large op_returns during the dispute did not cause a chain fork even though knots had a limit of 80.

7. More bluntly, nothing changes about what blocks validate. The node runners still have full control over validation and they are not being asked to change validation rules.

8. Only what is carried in mempool will change and no hardware usage changes for nodes.

9. From a TX side, getting nodes to carry the larger op_returns in mempool means they don't have to pay miner accelerator markups. Removing the markup will make op_returns cheaper than the witness data schemes used by most current arbitrary data. This is the entire purpose of the change.

10. Changing op_return to be cheaper than witness data should get arbitrary data users to prioritize using op_return.

11. Witness data cannot be purged from a pruned node without losing economic transactions. Op_returns can be purged in a pruned node, though this may change if future L2s require op_return arbitrary data. That would only affect node runners who wanted to support that L2.

12. 11 means that after the change pruned nodes should have lower hard drive capacity requirements for the same amount of arbitrary data stored on chain.

13. Very slowly for the back of the class. It should be easier for people who don't want to store arbitrary data to not store arbitrary on their node hard drives after the change.

14. Not keeping large op_returns in mempool means you have an incomplete view of who you are bidding against when you set fees for your on chain transactions. Right now this is not a big deal because there aren't many large open_returns. Once there are more, particularly during arbitrary data rushes like the taproot wizards craze, you may wait many blocks after paying what you thought was a next block fee.

15. 14 is most important for lightning where timely automated transactions can be critical such as justice transactions.

16. Mempool has a user set size limit. It drops transactions based on fee. Only the highest fee TXs stay in mempool if mempool size exceeds your limit. This means that storing large op_returns in mempool does not increase RAM requirements for your node.

17. Satoshi stored arbitrary data in op_return not witness data.

So TLDR.

I support the change now. For people who don't want their node resources used for arbitrary data, this makes it easier for you while Knots actually makes it harder. I'll be staying on core and I will be upgrading.

That said, I still think core and the insiders who support this handled it like a bunch of asshats. Pathetic public relations and they need to do much better in the future if they want to be taken seriously. If one person doesn't get it they may be an idiot, if the entire class doesn't get it you are a shitty teacher. Stop condescending and work on your teaching skills.

Reply to this note

Please Login to reply.

Discussion

Great summary thanks

Thanks. The real shocker detail to me is that if you follow the rabbit hole all the way down running knots increases the likelihood of storing arbitrary data.

Is that because the data would be stored elsewhere (like current state of things somewhat), and that is not prunable?

I haven't tried to follow too closely, figured I'd let dust settle.

Yep, current cheapest place is witness data because pool accelerators that bypass nodes charge a markup. Witness data is needed to know every economic transaction. Removing the accelerator markup makes op_return cheaper. Op_return can be pruned without losing any info about economic transactions.

Your post distilled down most of what I've gathered nicely. The noise then would seem to be mostly about process and other drama on GitHub.

Or maybe it's that default changes to core are as good as law (for now). Thus it is signaling that bitcoin wont resist spam and will make it cheaper and easier, even if the data is prunable...

I probably need to think about it more.

Yeah, core definitly fucked up the public relations on this and a lot of people are just opposed out of spite.

If you've never dealt with trying to filter data it is easy to think it should be easy to filter however you want. The reality is it is impossible if you have a determined adversary, this is why spam emails still get through after all these years.

We will never stop them but we can engage in harm reduction. Getting them to put their data into prunable fields instead of fields we can never prune reduces harm.

Since the block size is unchanged I don't see this affecting the ability of regular people to run full archival nodes. Note that the knots people aren't switching to pruned nodes, they just get a mempool filter that causes them to not have accurate mempools.

I get that no one node has a perfectly accurate picture of the entire global mempool. That doesn't make it smart to intentionally make your own mempool innacurate.

Yes, as someone who doesn't deeply understand the mechanics of this particular spam nor the general theory of spam mitigation, agree.

It's a bit more than bad PR because of blind reliance on core implementation by majority means they get to make this type of call. Silver lining might be that awareness raised over a lesser issue than one that may come in future, at which time we can hope for more diverse options and more educated users, and changes to core defaults won't be law necessarily 🤔

$2T USD total market value and we are still letting the devs talk directly to the users. No corporation that size would dream of doing something so stupid. Big companies use a translator for Dev <-> User communication for a reason.

I don't like the idea of some suits interfacing with node runners more than devs...

Conclusion is maybe there should be no such thing as "The devs"?

I'd be willing to take the job of translating between dev and human for the core team. I promise not to wear a suit.

You need more conflict of interest to gain interest from Opensats.

I hear Vitalik is having public relations issues too. I could apply for the same role for him and be one of those people with 2 full time do nothing jobs. That should be conflict of interest enough, slinging ETH got Loop in after all.

With a name like Bill Cypher, I think I might support that.

The problem is allowing the culture to degrade and encourage shitcoins on Bitcoin

This does not make it easier to store arbitrary data. It only changes incentives for shitcoiners to store it in a place in the block that is easier for non shitcoiners to not store that data without losing economic information.

I truly believe that knots makes it more likely you have to store arbitrary data after everything I learned.

Both store the same data if it’s a full archive node

Only the mempool would be different.

Again, it’s not a technical problem it’s political

But after the change pruned nodes should be able to store less arbitrary data.

Pruned nodes are gay

Well do you want to avoid storing arbitrary data or not?

Appreciate the details.

If you update your node you are joining the ass hats that think node runners shouldn’t be able to set their own mempool polices you cuck.

Well reasoned arguments rebutting all my technical details above.

I'll still answer though.

I value the option to better control arbitrary data on my node hard drive for all eternity over control over what floats through my RAM temporarily.

I’ve spent the last week giving my points of view. You are dead wrong if you think filters do not work. The dust limit is a filter that was created to make it 500X more expensive for satoshi dice to spam the chain with 1 sat tx that said “you lost”.

Push a PR that gets all that arbitrary data out of the witness data I can't prune if you are such an expert.

Some problems are genuinely harder to solve and your inability to spot the difference between addition and calculus doesn't make calculus easy, it makes you bad at math.

Do you seriously not see the difference between a > test and eliminating all possible future encoding of arbitrary data without breaking any possible valid economic transaction?

Only filters that works are the block size and the fees.

Violation…

Where did Satoshi used OP_RETURN?

Whoops, Cunningham strikes again. That was not an op_return.

Also if you filter your mempool, then you would have to download these tx's you're trying filter twice.

This is the way.

Points 1, 2, 3, 4, 6, 7, 9, 10, 11, 12, 14, 16, 17 are outside the scope of the discussion and for all intents and purposes, irrelevant.

5 & 8. This is the entire point of the debate. Also, it is a private property issue. I can, with my node, store whatever data I want (given the right software).

13. Incorrect. Not accepting transactions in the first place reduces the spam not pruning it later. (which you can still do if the transaction gets included in a block)

All of these other included tangential points are utilitarian nonsense. The "You can't save everyone so, why save anyone?" mentality. Filters don't work but remove them because they don't work... Nonsense. A non propagation of spam using a personal mempool policy allows you to vote what a miner sees FROM YOU. The fact that other people have a different opinion is irrelevant to what you do with your machine.

Yessir! Our nodes tell the miners what they want to see in the mempool. It shouldn’tmatter what everyone else has set as a policy filter.

From my understanding I would say that if you want use your node to ‘vote’ on what is in the mempool then you are correct. But, if you run a node and want to know the actual state of the network then filtering specific transactions from your node puts you at a disadvantage because you don’t see the whole picture.

You literally do though. You can see rejected peers. There's a blocked peers list.

Blocked peers don't tell me the sat/vbyte of my competition in other mempools.

Yeah, and neither does a self run node... Only well connected nodes would like Mempool.space or whatever. Your personal node never had the full picture and never will.

Pictures of my vacation aren't as cool as being there so I should use a flip phone camera instead of my DSLR.

The Mona Lisa has damage from its age, so we should let middle schoolers graffiti it.

It is silly to say just because it is never going to be perfect we should intentionally make it worse.

A better analogy would be filtering out photobombers by cutting them out of your family vacation photos or cutting out graffiti that was put ontop of the mona lisa. From YOUR photos. It gives you the picture YOU want to see. If you want to see the graffiti and photobombers to get a "clearer" picture of what is happening YOU can by deactivating the filter. I PERSONALLY edit those annoyances out. Stop pretending to be Bitcoin King and know what's best for other People's computers.

I don't know everything, but I do know enough to be convinced you are confused. I'm not trying to tell you what to do, I'm trying to clear up your confusion so you can make the best decision for you. Remember, I'm not a random internet douche, we've shook hands in person. Once you understand, do what you want. I just want you to make an informed decision and I'm taking time out of my day to try to help you get there.

To use your photo bomber analogy. You are obsessed with what is in the photo on your camera (mempool) but putting every photo bomber on your Olas feed (blockchain). I'm saying by ignoring them on camera you can help make it easier for you to keep them out of your Olas feed.

I can agree that we are both using intense language here. Not discounting the in person(fantastic soap by the way)meeting. I am telling you I am not confused. But I am also saying you aren't confused. We have different moral outlooks.

To use an analogy: A girl walking on the beach finds 1000 starfish have beached themselves. She throws them 1 by 1 back into the ocean. Another person says "you can't save them all why waste your time? What does it matter?" And the girl says "It matters to that one."

I am the little girl.

You are the other person.

It's fine that you think my actions are futile, I do not.

If you can't see why I included those I don't think you understand the issue.

I know why you included them. They are just irrelevant to the PR. If I remove a color option on a desktop environment. TECHNICALLY websites all around the world will be affected. But in reality it is just the end user that can't render the color.

I don't think you understand the issue either. This is not about spam in valid blocks. Period. This is about spam in individual mempools.

They are not irrelevant to most of the people I see arguing about the issue who consistently have one or more of those facts wrong. I didn't write that for you, I wrote it for the community at large.

I can set a limit on my mempool size. Mempool is RAM only, the least constrained resource on any node I've seen. Mempool is transient and constantly changing. Mempool is far less important than what gets validated in a block to go on chain and be on my hard drive for all eternity. If spam is in op_return instead of witness data I gain the option to not store that spam on my hard drive for all eternity.

Unless you plan to stop validating those blocks and hard fork you accomplish nothing but making your own view of pending transactions less accurate by filtering your mempool. You also remove options from yourself for not storing monkey jpgs because they get put into witness data you can't eliminate without losing economic information your way.

You picked a side, good for you. You picked the wrong side for your stated goal of limiting spam stored on your node. You hold an inconsistent position. You must now change your position, change your goal, or concede to being irrational. If you really think mempool is more important than on chain I can't help you.

There is no way (outside of using DATUM) to filter that spam in the witness. Period. So, all of what you said is conjecture. They are CHOOSING to use OP_RETURN, that is non-binding. Which given a toggle is my perogative. Also, as I said before no single node has an accurate view of pending transactions. So having a few less transactions in my mempool is no different now than it was before.

My goal as far as you are aware is to filter my mempool. Spam on valid blocks is an inevitability but their proliferation using my broadcast node is not.

"On-chain" is what the Miners and Nodes agree is on-chain. We will see what a less performant Ethereum gets you, but I don't think this concession will work out the way you hope it will.

You have setting block templates for your miner and validating block by other miners on the chain on your node confused in your datum statement. Even so, Ocean let's you run pretty strict filters on your miner without datum so it is double wrong.

What exactly do you gain by keeping a TX out of your mempool that you have every intention of considering valid on chain? I know what you lose but I can't see any gain for you. Tell me please?

You said all my OP points we're useless but you missed #1. 4MB block limit before and after the change. No change in what blocks are considered valid to add to the chain by anyones nodes. How does changing nothing about valid blocks on chain destroy performance?

Firstly Ocean and DATUM are two distinct things, I do not use Ocean but I use DATUM. Secondly other miners don't "validate" so if you want to just be pithy and pedantic, I can too.

I'm not confused, you either misread or didn't understand.

As for the why, beyond the bulwark of property rights and I can do whatever I want, refusing to propagate spam forces it to got through other channels that are more fragile. Where as Shinobi seems to think spam centralization is bad, I see it as good because it has one avenue of propagation and if that method fails, no spam.

I never once argued about performance. This is a property rights issue. And compelled speech issue. I don't want to "say" to the network I am passing along a spammers message. The fact that the spammer found another way to "say" that message is irrelevant. But on my property, with my speech, I refuse or at the very least reserve the right to refuse.

You node validates blocks from other miners that include the spam no matter what you do with datum and your miner. Perhaps I was unclear but I wasn't wrong.

Property rights is an argument I can respect. I think they should have changed the default but left the setting. I still think you are destroying your own property to spite your neighbors by running the mempool filter.

You absolutely said a slower ETH. Don't lie to my face about it 1 post later.

What speech is more important to you? Transient in your mempool gossip or what you share as valid block data with everyone for all eternity? If you help encourage them to op_return you can drop op_return entirely from your chain for all eternity, jokes on them.

I get that you see you node data as speech and don't want to stupid shit. I agree on principle. I'm valuing hosting that monkey jpg on chain for all eternity more than 10 minutes in my mempool gossip. You are choosing the opposite. No one knows a way to never share the monkey.

The ETH comment is the end result I forsee when the spammers use the witness anyway when Nodes start pruning OP_RETURN. I don't know where I lied exactly but I take your word that I wasn't clear either.

A year and a half ago there was an initiative to fix the filters but that was pushed aside as "censorship" so, that's perhaps why we never solved the monkey sharing problem.

Regardless, I think we see each other's postion we just disagree on outcome which neither of us know.

My assumption is that the kind of person who would trade in monkey jpgs isn't informed enough know any of those details about where on chain it is stored or going to take any path other than the cheapest possible to the next block.

1MB base and 3MB witness. I think they will end up split on chain once base is full and witness is empty.

2 problems with filters that combine to keep block validation filters from being taken seriously.

1 is they are just way harder than you think to get right if you've never had to write a regex.

2 is that any filter on valid blocks must allow all existing blocks or fork and rollback. we don't know what our adversary has cooked up to sneak through the filter till it hits mempool, or in your case gets in a block. That is too late to get the fixed filter in place.

Points taken. I have tried to write regex, did not go well. Put me off of coding entirely.

As for my filter removing my info on current attacks, I watch attacks outside of my own nodes. I query mempool.space nodes and a few others to keep up on what traffic that I don't relay. I still get the info just not on my own node.

That is fine for setting fees for manual on chain transactions but not very sovereign. It also not helpful for lightning justice transactions.

nice point of view again and thank you for your digging work.

i focus only on one point 10.

"10. Changing op_return to be cheaper than witness data SHOULD get arbitrary data users to prioritize using op_return. ".

I have often read this technical issue about "OP_RETURN' was only a little technical problem.

How can all the clever guy only imagine a technical solution based on a "should" ?

And "if" extra data is used in both place ? "OP_RETURN" AND the current "witness data".

It is true, core devs have a lot of work to do to explain their choice to the node owners, and it is as normal as only write code.

You can't ignore doubts or questions, you have just to answer all, until doubt are left or another solution is found.

It is how consensus works when you don't host the code you produce.

You'll never get more than "should" when attempting to limit adversarial behavior from a learning and adapting enemy. You simply cannot imagine every way they might attempt to attack.

You WILL lose if you let that paralyze you into doing nothing.

Bill!!!! I really really enjoyed your post. I was sent here by nostr:npub1dryseu6yv7evgz2f7pfzk6wht8flapcfv5l6r4y65pg5px293awqlwwfpc. I started reading and couldn’t stop. It was elegant and thoughtful. I don’t think that I have all of the answers, but I do have a response. I believe most of them are questions to foster more discussion and to enlighten my point of view. Thanks!!!

nostr:npub1dryseu6yv7evgz2f7pfzk6wht8flapcfv5l6r4y65pg5px293awqlwwfpc nostr:npub1wnlu28xrq9gv77dkevck6ws4euej4v568rlvn66gf2c428tdrptqq3n3wr nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze nostr:npub126ntw5mnermmj0znhjhgdk8lh2af72sm8qfzq48umdlnhaj9kuns3le9ll nostr:npub1aghreq2dpz3h3799hrawev5gf5zc2kt4ch9ykhp9utt0jd3gdu2qtlmhct nostr:npub1xapjgsushef5wwn78vac6pxuaqlke9g5hqdfjlanky3uquh0nauqx0cnde

This is a great write up by Bill. I hope that I can do it justice by replying and or asking questions.

#5: My Reply: Yes, I love this aspect. I get to choose the settings for the transactions that I want to go into. Something that I don’t get to do in the legacy world. They dictate everything.

#7: My Reply: Are the node runners are being asked to forgo the option to choose what size op return? Instead of the legacy system dictating policy, now it is the Bitcoin Core developers that tell us what the limit is??? Right???

#8: My Reply: It sounds like the Core Developers are choosing what is carried in the mempool by their wishes?

#9: My Reply: Can’t we just use RBF (replace by fee) instead of paying an accelerator? I have used rbf and it worked good. The fees do happen to go up. I don’t remember how much, but let’s say I send a transaction with 1sat/vB it went up to 5 or 6 sat/vB.

The entire purpose of the change is that people can send transactions that aren’t specifically BITCOIN value transactions…and make it cheaper? This seems like they are encouraging this behavior. I don’t care what people want to store on the chain, on my node, ect. If you pay for it then you deserve the block space. Where I do find it odd is that these Bitcoin Developers are going so far as to make non financial transactions cheaper AND creating a way for them to do it easier. This is where they loose me all together. Where is the motivation coming from to think of this elaborate plan? Who is funding and or pushing this? As a matter of fact…. They are risking changing the code and possibly breaking something for non bitcoin transactions? It doesn’t pass the smell test. I can smell their bullshit from here and it stinks like… like shit. (Excuse my French.)

To top it off with a cherry I watched the interview with Shinobi today and he or Peter said something along the lines of. It doesn’t matter anyway so we are just going to do it.

IF IT DOESN’T MATTER THEN WHY ARE YOU FKNG WITH IT. Yes coders will code and I am happy they have been there so long with bitcoin. I wonder who is the Bitcoin Core Jesus that thinks he invincible and we (the people) have no say?

#11: My Reply: I believe and I may be wrong but one of the reasons to run a FULL node is to know about all of the transactions. One of the reasons to run a PRUNED node is to know about all of the transactions with less block space taken on your hard drive. So this “should be fine” now, but in the future if a layer 2 needs it, then the PRUNED node will no longer be able to purge the op_return SO WE WILL HAVE TO CHANGE THE op_return back to how it is now.

Then you give the option back to us to prove your point that op_return with no limit isn’t a problem by saying… BUT “that would only affect node runners who wanted to support that L2.

You are telling me that both full and pruned nodes are working great with op_return now but you want to change it because it doesn’t matter anyhow but you will need to change it because some Layer 2 might require it in the future. DUDE, you already know this is coming. You have a smell to you Jameson, Peter, and Shinobi. Ya’ll are up to something and I want no parts of it!

#12: My Reply: When setting up a pruned node you can set the storage amount of space on your hard drive or ssd to go down to 1 or 2 GB at the minimum and all the way up to a full node. How much space would you save on this op_return? That is a real question. I bet the photo I took of my BTCLOCK today (because bitcoin hit 100k again today) is a lot larger than the so called “space saver from snatching away op_return.

#13: My Reply: Now this sounds like an honest push for deleting the op_return limit. If they would just say this then I would be fine. I would’ve still run Bitcoin Knots on all of my nodes, but I honor men that don’t try to hide to get their way. It’s sneaky and it makes me think they are trying to pull a fast one because we are not developers so we couldn’t possibly understand the complicated world of developing on bitcoin. Maybe I don’t understand what they have going on, but I guarantee you that I understand when there is a snake slithering around rattling his tail trying to pretend that he is here to give me a few satoshi.

I’m not sure if this is the reason for everyone that doesn’t want to store arbitrary data on their hard drives, but for my purposes I don’t think the “CORE issue” (see what I did there?) is actually storing the data. I believe the issue is that the block space is being taken up by non bitcoin transactions that also receive said block space cheaper or with a discount compared to a bitcoin transaction, then you have to add in the other factors like storing the arbitrary data which have accelerated the hard disk space needed by at least 7 to 10 years. I did the math about a year ago and don’t remember the actual numbers. The point to that is that The block size is compounding super super fast compared to not having those transactions. It doesn’t seem like a problem today, but in 20 years we will have at least 100 years worth of storage requirements because no thought nor action was taken seriously now. BUT THEY WANT TO FOCUS ON op_return. I’m O.J……… OK

#14: My Reply: Do you know anyone that has been affected by not having a complete view of the block fees? I have never ran into that and I send a ton of on chain transactions. I run nodes with mempool installed and I always receive the time that I expect. I may play with the minutia and put 1.17 sat/vB but I always get what I expect plus or minus 10 to 12 hours. If I am unsure then I triple the fee estimate and get into the next block.

#15: My Reply: I would like to know more about this. I don’t know anyone that has ran into a justice transaction yet. I hope it never happens to me because people are acting in good faith. My question is: who is the moderator for the justice transaction? I would think a lightning developer that has the know how and understands the fee estimator to get into a block within a timely matter. I would assume that if there is a justice transaction then the lightning node that is acting in bad faith isn’t getting the transaction and or satoshi back. Why is there such a rush to get a timely transaction sent?

#16: My Reply: Yes that is true, but can’t we just go into the Bitcoin Node configuration and set a higher memory limit for your personal mempool? I have mine set quite high. The default is somewhere in the 333 range? I believe mine is set to 1500. I want my node to keep and to know about as many transactions as there are out there. 1. because it sucks when your transaction has been sitting there with 2 sat/vB for 4 months because “arbitrary” transactions are filling the blocks and the fees are crazy high. (It wasn’t an important transaction so it was worth it to wait and not RBF.) The very first time this happened, I didn’t know that my transaction was dropped out of the collective mempool because I wasn’t running a node yet and didn’t have knowledge of this concept yet. Now, my node is set up so that most transactions will be held by my node and when fees drop to a level that the gossip network relays the transaction that has been sitting for a while it can be picked up by others and mined.

Plus I run Datum, Knots, create block templates and it is better to know about all potential transactions so you don’t have to ask the network if it meets consensus. This would take more time for your node to verify.

#17: My Reply: I am so glad that you saved this for last!!!!! We are currently saving in witness data no? How about we do what Satoshi did? Focus on not storing anything in witness data and store it in op_return, but let’s not forget that Satoshi also had a limit on op_return. So it is SETTLED! We are not storing anything in witness data, op_return stays with a limit. I knew your post was worth the read!!!!!!!

The ending and My Reply: My father always said “if you can’t explain something simply then you don’t truly understand it.” The Core Developers understand it, but only at their level. They can’t see why we have different points of view from them. It’s because we care about something different than they do. You want to write and push code. I want Bitcoin not to be touched every 6 months because you want to be looked at as proficient. We all know that you all are brilliant in your unique way. (That is not to put them down in any way.) But video games need coding to make them better bitcoin does not especially when everyone doesn’t agree. Can’t you see that you have the same thing that we have. A BLIND SPOT SOMEWHERE. The difference here is that we have Luke and Knots to go to. Where do the Bitcoin Core Developers run to?

#Bitcoin

#lightning

#BitcoinKnots

#BitcoinCore

#Noderunner

#TothebitcoinCEO

#mempool

#taprootwizards

#Ocean

#Datum

#bitcoinmining

#DIYBitcoin

#runanode

#runyourownnode

#donttrustverify

#Satoshi

#9 I believe the point Shinobi was trying to make was that you can’t stop someone who is incentivised and willing to pay from getting arbitrary data into a block because they can currently go directly to a miner.

What this would change is that the arbitrary data is no longer being stored in a the UTXO set and creating unspendable transactions.

He also made the point that it will help prevent miner centralisation because all miners will be able to benefit from the fees from these transactions containing arbitrary data rather than the few who offer the service now.

BLOCK 895904 Mined by VIABTC There are no op_return transactions nor fees. I also checked

BLOCK 895903 Secpool

BLOCK 895902 Antpool

BLOCK 895901 Secpool

BLOCK 895900 F2pool

BLOCK 895899 BTC.com

BLOCK 895895 Foundry and none of them have any transactions with op_return nor fees. UNLESS I am looking at it wrong. I could be wrong right now.

Does every miner want to offer this “service?” Are they are trying to say that large miners have spent literally hundreds of thousands and millions and millions of dollars on equipment, staff, research, acquisition, buildings, electricity, miner, shipping, internet, computers ect. But they can’t afford to find 1 person that will set up out of band transactions for them?

Come on man. I was born at night but not last night.

Yes, people go to great lengths to accomplish their goals. I for one… I AM THAT GUY!!!! 100% Just because people will pay a miner on the side to get what they want doesn’t necessitate the change to make it easier for them.

Most people usually don’t go around checking front door knobs for open doors because in most places we assume they are locked. (In the U.S. specifically.) Let’s imagine a place that never locked their doors. I would assume more people would probably use the option to try the door knob because it is easy access. So in around about way this would be encouraging people to try to open the front door.

In theory it sounds noble to help the witness data users, but the people that don’t offer this service probably have no interest in it. UNLESS they are talking about something personal to themselves. What would be the incentive to have out of band transactions? Who would need such a service? A large government that wants to go undetected? A military? A large corporation? Have people like you and I needed that service? I haven’t needed it. I just send on chain so I compete with everyone. Or is that a clue? Why wouldn’t anyone want to compete with high fees?

I am not trolling when I ask this question. What is the big deal with an unspendable UTXO? Isn’t a UTXO just a UTXO? As a matter of fact. Isn’t that similar to a double negative? An unspendable unspent transaction output. Please try to understand. Someone is trying to play us.

If I have a UTXO and I never ever send it anywhere isn’t that a (U-UTXO) unspendable unspent transaction output? Satoshi has UUTXO’s doesn’t he? It sounds technical to not want a U-UTXO, but in practice…… how do we know which UTXO are unspendable? When someone looses their keys with no backup isn’t that a U-UTXO? It’s just that no-one knows the UTXO is a U-UTXO. RIGHT?

Someone please tell me that I am off base.

#Bitcoin

#lightning

#BitcoinKnots

#BitcoinCore

#Noderunner

#TothebitcoinCEO

#mempool

#taprootwizards

#Ocean

#Datum

#bitcoinmining

#DIYBitcoin

#runanode

#runyourownnode

#donttrustverify

#Satoshi

Im not sure what you’re trying to tell me with the first bit of the post. Is it that no-one is currently making out if band transactions directly with miners? If so, considering that fees are currently so low, wouldn’t this mean that there is little to no demand for these types of transactions? And if there is no demand now why would that change if the OP_RETURN limit is removed?

I’m not an expert. All I can go on is what I have read and heard and form my own opinion. Write or wrong I just don’t see it as being that big a deal. As long as miners choose what goes into a block people are going to get non financial transactions onto the blockchain if they really want to.

All the JPEG spam stopped not because it was too hard but because it was too costly. I think the same economics will play out here.

That makes 2 of us. I am not an expert either I’m just looking for more clarification on how I see the issues they are dealing with. Thank you for being level headed and responding. I want to learn more. I am under the impression that I could be wrong and my mind will be changed.

People should definitely be able to get their non financial transactions into the chain. What I don’t understand is why does the op_return limit need to be taken away so the non financial transactions can get those transactions into the chain cheaper? Shouldn’t all transactions have to bid the same amount to get into the chain.

I don’t think they would necessarily be cheaper, they would still be competing with all other transactions.

Something Shinobi said on WBD (with a listen if you haven’t already) was that not having visibility about what’s going into a block can be an issue if you need to make a transaction ‘now’ If you don’t have a clear picture of the mempool you don’t know what you need to pay to get your transaction confirmed.

The start of the whole thing was to do with a layer 2 that needed 140 bytes in OP_RETURN rather than 80.

I will have to watch that asap.

I have started the WBD podcast, but couldn’t finish today. I will watch it and reply for sure. Thanks for sending the recommendation. My respect for Shinobi has gone up and I’m only 10 minutes in. He has already said that he didn’t read the Citrea white paper nor the pull request. He is going off of the information he has received from other developers. So far it is worth the watch. It’s not that inscriptions or jpegs bloat the UTXO set that he is worried about. They want this change specifically for Citrea. This doesn’t sound so sneaky anymore because it makes sense. There is a motive. I still will filter my nodes, but I understand why they want to push this. Doesn’t make it right nor wrong.

To make this post not so long and boring… I will try to summarize by making the blanket statement that both sides of this thing aren’t saying that they see things from the other side. I will do that now.

I understand what he is saying when he says “transactions will still end up in the blockchain.” I feel that any jpg, inscription, etc should be allowed in the chain. I also understand that my filter does not prevent it from being in the chain. I don’t want to speak for everyone out there. If another node runner wants higher limits, or lower limits, wants to fit 4mb pictures into a block then I welcome their choice and will defend their right to choose what filters they want. Where we diverge is that I want the choice. I don’t want Jameson, Peter, Shinobi, Luke, Shitcoin Mechanic (I only use that name because he used it during the debate,) WK057 or anyone else to tell me what settings I should have. Satoshi Gave me a way to have a choice and I want to exercise that choice. So when the few developers say that they are unilaterally deleting the choice…. I have to voice my concern and take appropriate steps to ensure that I have a choice.

Thank you for telling me about that video. I learned a lot and it cleared up the real motivation for them wanting to change and change so quickly. When I heard all 3 of them say “it doesn’t matter, but we are changing it anyway…” I knew there was more to the story. They are dealing with Citrea and they developed Clementine which needs the 140 instead of 80. I have no problem with that. My problem is that they tried to pull the wool over like people don’t think, or aren’t developers so we wouldn’t understand. They used the example of lightning or other layer 2 “maybe needing more op_return space in the future… Things weren’t adding up. Now is see… The developers want to help Citrea use 140 of op_return which is more expensive than 80 of witness, but is it more expensive than 80 of witness plus 40 of op_return? I don’t know that answer. Now I am just thinking out loud and rambling lmao

You've been lied to, but rambled on too long to respond to specifics

I know it was a lot from a non developer. I just believe in am passionate about your mission and projects. Thanks!

Core are being condescending pricks so everyone looks at you and this is what you have to say?

Some people are just confused because it is complicated. Telling them off doesn't help anyone but it does increase my conviction to not run knots on my node.

Homie, we need OGs like you to last. I recommend diet an exercise:

These 7 exercises are easy to do with almost no equipment and will work out almost every muscle in your body and give you a six pack.

1. Pushups

2. Bicycle crunches

3. Side planks

4. 45-degree donkey kicks

5. Bear crawl

6. Squat->Bicep curl->Overhead raise and lift heels (holding weight)

7. Dead hangs (work up to Pullups, do both)

True indeed. We need people like Luke here for reasons just like this.

I could use this routine. I might have to adopt this.

No Luke, he has not.

Liar

No u

I think a couple of these can be answered with single answers.

Nothing about what gets validated in blocks is changing, only what gets carried in mempool changes.

I disagree with core removing the setting even though I agree that for most the new default is correct and you shouldn't change it. They should have just updated the default.

RBF gets you nothing if every node drops the TX from mempool for op_return size. Right now only Libre would keep them but very few people run that.

You have total storage limit but also keep op_returns or not. If you drop op_return you get more blocks in your same storage already.

Go look at block health on mempool, every TX that was predicted but didn't make it was burned by incomplete mempool propagation throughout the network. Maybe that didn't matter for that TX but lightning justice TX count on a timelock for the first close and next block fees for the justice TX.

I had a justice transaction in my favor once.

Total memory size in mempool is different. Even at 1500 large op_returns will not be carried by Knots.

On further review, Satoshi did not use op_return. I was wrong. I did invoke Cunningham in my introduction after all. My apologies.

I agree. The attitude towards the node runners with questions is far worse than the change. They need to do better. If they are mad about the backlash, they should know it is a self inflicted wound.

I can’t say I understand all of the technical aspects but from everything I have read and after listening to Shinobi on WBD I am in agreement. This is not as big a deal as people are making it out to be.

nevent1qqstu20wqfm484dk2v9hm38dvsfj8n90kpmg6yyq62vq5v23t04728qpupmhxue69uhhyetvv9ujuerpd46hxtnfduhj2v3swaehxw309aex2mrp0yhxumm5daeks6fwwa5kute9xgc8wumn8ghj7mn0wvhxcmmv9ujnyvrhwden5te0wfjkccte9eekjctdwd68ytnrdakj7ffjxpmhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6te9xgc8wumn8ghj7mnxwfjkccte9eshqup0y5erqamnwvaz7tmjv4kxz7tjwvhxumm5daeks6fwwa5kute9xgc8wumn8ghj7un9d3shjtnwv4u8getj0ghxxmmd9ujnyvrhwden5te0vejkuunfwgkhxtnwda6x7umgdyh8w6twuuk58q

This was interesting thanks for taking the time to write it all up. Some of it still went over my head because it is a bit technical. I did hear a podcaster say that they want to remove the config options to filter out spam from their mempool. Not sure why they said that.

Right now there is a limit on op_return size in mempool in core. But only mempool, any op_return that fits in a block will be considered a valid addition to the chain. Not really useful for typical economic transactions so most consider them spam.

Core devs wanted to remove the limit because it causes miners to create private mempools, like slipstream by Mara, not very decentralized.

Where I think they went wrong was they wanted to change it to no limit and remove the setting. That got people riled up. If they had changed the default and left the setting half the controversy.

Interesting. And this wouldn’t have exploded if they didn’t ban users from the conversation.

That really set the Streisand Effect into full force.

The bannings were questionable for sure but not outright malicious with no other way to explain it. The official mailing list has a "code only, no comments about the developers" rule. That makes sense as a way to prevent the conversation from going off the rails into ad hominem territory every time. We all know what the average internet argument is like without that and any exception is going to lead there.

The people who got banned were pointing out that the initial vocal supporters had a history of shitcoining and some had financial conflicts of interest. Is that about the code or the person? Both for sure.

The change has been dropped for now. As far as I know there are no plans to change the default or remove the setting at this time.

So the pushback was enough to stop the change interesting 🤔

We can't really say stop forever until the heat death of the universe, but it has been put to rest for now.

One of the big allegations was devs turning on the noderunners so it does matter that things got changed by mass noderunner will. I thought changing the default and leaving the setting was the correct path but that hasn't happened either.

I think it’s good that a significant number of people switched to knots just to decentralize a bit. Would be interesting to see if another implementation comes out in the near future.

There is also a Libre Relay, though it gets far less attention than Core and Knots.

I think you’re completely missing the point and not seeing the forest for the trees, but I’m too tired to type out my rebuttal. GN

Super constructive.

there are wrong and misunderstood points here, but just realized this was posted 25 days ago, just when many core people were spreading misinformation, and trying to miss-guide people.

and honestly im tired of talking about same things over over again. just check my posts and reposts about it.

No. I'm not getting assigned homework based on a random stranger saying go do what I say and I won't explain at all.

I already wrote one of the most comprehensive technical breakdowns of what does and doesn't change if that PR were merged anywhere on nostr. I messaged key players on both sides directly to write that because everyone else was telling half a story overrun by emotion.

I read every reply in here and every knots fans answer has been "I disagree about a factual technical detail even though I got that detail wrong and you just posted the truth" or "I'm valuing what is in my mempool over what chain data I have to store and mining centralization"