Another thought…

We all know Saylor and like are huge advocates of ossification. Maybe they co-opted Core and devised this scheme as a publicity stunt to support their ossification case.

Thanks nostr:nprofile1qqsggcc8dz9qnmq399n7kp2yu79fazxy3ag8ztpea4y3lu4klgqe46qppamhxue69uhku6n4d4czumt99uq3gamnwvaz7tmjv4kxz7tpvfkx2tn0wfnj7ru4snc for making this clear in the most recent videos. Relaying this garbage IS the attack. It’s got nothing to do with the nodes ultimately having to download and store it in their copies of the time chain…it’s about distribution. I totally missed this.

I wonder if this is just a negotiation tactic. In the previous video you referenced an X post that listed two reasons why the devs would do this - because they’re evil or because they want to advance some other business venture. In the post, the former was immediately ruled out leaving just the second option…which, is how all this started to begin with.

In that light, suppose all they needed/wanted was to increase the limit to say 200 bytes (honestly, this has gone on for so long I can’t even remember what the original requirement was). Knowing that a portion of the community would resist even that change, why not go all out and say you’re actually planning to increase it to some astronomical size, let the community drive themselves insane arguing over it, and then, just before shipping the update, make an about face, acknowledge the error in your ways, bend the knee, and set the limit to what you wanted originally?

It’s my understanding that the setting is still ‘tunable’ for now, but the plan going forward is to deprecate even that functionality.

Came here to make the same comment. I love the videos and watch every one of them. I also switched to Knots…even before this op_return nonsense. However, if the transaction is confirmed, your Knots node is going to download and store it whether you chose to relay it or not.

With regard to the ‘attack’, is there some sort of legal distinction between ‘transmitting’ and ‘storing’ this horrific data nostr:nprofile1qqsggcc8dz9qnmq399n7kp2yu79fazxy3ag8ztpea4y3lu4klgqe46qpz3mhxue69uhkummnw3ezum3dw35jumt99uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59up0zady ?

Nuance, but it’s worse than that:

On a bitcoin standard, the only way to justify current/non-falling prices is to deliver more value.

nostr:nprofile1qqsg2zqd8wkhpnxu6lm5c2dyfa2mhpwte57apjae2ldp6g2mmwf3ypqpz4mhxue69uhkummnw3ezummcw3ezuer9wchszxnhwden5te0wp6hyctkd9jxztnwdaehgu3wd3skuep08mhk3q with the AnchorWatch legends…FIRE!

https://fountain.fm/episode/nucsXUKBM3YjxLrMgzT1

Seems plausible…borderline obvious. What I can’t get my head around, though, are the implications to the stock and bond holders when said governments flip the switch and expose the plan. Do they just wait until all the bonds convert, let the market drive the nav premium down to 1, and print a bunch of fiat to pay out all the shareholders? Sounds a little too 6102’ish.

nostr:nprofile1qqsywt6ypu57lxtwj2scdwxnyrl3sry9typcstje65x7rw9a2e5nq8spz3mhxue69uhkummnw3ezummcw3ezuer9wcq37amnwvaz7tmzd96xxmmfdekkz7rfd4skc6tnw3ejummwd35kueg8h22n0 nostr:npub1w8u36xkkjawkuzjhwh2r024fqfgg0z6qccnfp6ygtturt4fstdyqj9zrec

#collapsing

Enjoyed following along…great coverage nostr:nprofile1qqsywt6ypu57lxtwj2scdwxnyrl3sry9typcstje65x7rw9a2e5nq8spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3kamnwvaz7tmjv4kxz7fwvf5hgcm0d9h8qctjdvhxxmmdnq2374 !

Can’t wait to get my hands on a Block based bitaxe!

I don’t know if it’s my cadence of Sunday nostr catching up or @HODL ‘s weekend self reflecting, but these days are starting to feel like church. #churchstr for those skating on the thin ice?

Heavy…like I’ve fucked this up heavy.

Enjoying the show…love the macro. Keep it up, brother!

nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp

TL;DR is in complete contradiction to PoW. If you’re not willing to put in at least enough work to read the personal story @HODL took to time to share, then you don’t deserve a fucking summary (which, by the way, was at the end of the note). Fuck.

I posted similar thoughts/questions yesterday, and after not getting any engagement I searched and found your note.

My note is here:

https://primal.net/e/note14u0gmsa0h9lydu5javn6qf2wdrs4cmf59mp2tg0w0yhwpkz5thdq2p42ra

I watched the logs on my bitaxe for a while today and saw all the stratum client and server messages. I couldn’t figure out how to decipher the nbit field, but it’s clear that the local public pool instance is lowering the difficulty like all pools do. Like you, though, I’m very interested in the block template origin.

nostr:npub1wtgd9ccg76awlp29zl3h466l89wr7hsut0n3ucmtr95h4t29jc6srlsxp2

Sorry…should have tagged y’all in the original post.

#solomining

Solo mining newb questions:

I’m running bitcoin core on Umbrel and just installed the public pool app to learn about solo mining. I’ve got a bitaxe pointed to the stratum address of the local public pool instance.

The public pool app can see the bitaxe activity, and I can see the job information being sent to the bitaxe in the bitaxe logs. It’s hashing away (and occasionally overheating), and everything appears to be working fine.

I’m assuming the bitaxe firmware is getting the block template from the public pool Umbrel app. Is this accurate?

If so, is the local public pool app generating its own block template based on my local node, or is it getting it from the ‘larger’ public pool?

Is the local public pool app decreasing the difficulty that’s being sent to my bitaxe, like most pools do? I’m assuming it is since I can see that many shares have been submitted by the bitaxe.

Is any of this configurable locally?

Is any of this able to be viewed via the CLI?

Appreciate any feedback.

Total mind fuck for sure.