pull down to refresh
100 sats \ 0 replies \ @justin_shocknet 14m \ on: Does anyone know of any bitcoin mines using old jet turbines? bitcoin_Mining
Miner arb was on stranded energy using regular generators
AI squeezed that arb, no energy left stranded, generators manufacturers backlogged... Jet thing is relatively recent because of the generator crunch
GEV has been doing this awhile, taking engines out of the desert bone yards, but the super sonic engines are more efficient allegedly in hot climates like Texas
GrapeRank uses mutes, engagements, zaps, reports etc... nymrank is built over that
Biggest limiting factor is what nostr is used for: fugazi Twitter. Limited data to actually glean from... zaps are inadequate economic activity.
Cooking up a few things that, with any traction, will provide new vectors for WoT calculations
The hardest working man in Bitcoin, @Car, asked for some help with a kiosk for the PlebCafe
Uses CLINK Offers so the Lab can take sats for the snack area with a static web page that fetches invoices over Nostr, menu and offer is just a json file
Realized we never implemented purely nostr-based callbacks in Lightning.Pub... we were focused on web-hooks... so addressing that real quick... derp. Fortunately CLINK Spec and SDK already handles it.
Bingo. Need to wipe out every non-dollar fiat first.
undermine the monetary sovereignty of non-US currencies
Thats the point, dollar supremacy... all other fiats are propped up at the dollars expense (American's blood and treasure). Tariffs are the other part of this.
hands of the Federal Reserve
Fed is already cooked, it's not so slowly being merged back in to the US Treasury.
It becomes much easier for foreigners to adopt Bitcoin once their local currency collapses, and they have a stablecoin wallet installed. Dollar wrecking ball facilitates that.
Nice to see another, I recently went back to your HORNET thread, a similar concept... library-ification is where the puck is going (rightly IMO)
libbitcoinkernal
Probably more pragmatic, but any attempt is good, as a failed attempt can still fail-forward
I recently went back to your HORNET thread
Roughly the same subject came up between @k00b and I in his thread about L1 vs L2 multi-implementation risks #1317912
TLDR being a distinction between "implementations" and "distributions", a really good library decentralizing distribution is the cure to the Politburo effect that's plaguing Core. BTCD is a great example of a long term stable working alt-implementation, that's rarely used as an implementation, but widely distributed as a library (LND).
backup power option
Yep, money is where my mouth is on this one. Love my solar generator, cost on batteries and panels has come down so much it's no-brainer insurance where I live... even though I'll really get sick looking at how much it cost me in Bitcoin terms several years from now.
I am increasingly fatigued by those who claim to be genuine Bitcoiners yet claim disinterest in its price in fiat currency. If you fall into this (unfortunately large) category, you should not consider yourselves Bitcoiners.
Your understanding of monetary fundamentals is virtually nonexistent; you merely virtue signal with Bitcoin opportunistically, desperately, as your self-esteem has otherwise failed.
I will never regard anyone as a Bitcoiner unless they meet at least the following minimum criteria:
-
Self-sovereign: They maintain understanding that Bitcoin is un-controlled, and that user choice in all forms is the cure to the group-think plague.
-
Operate as a mental node: They make up their own rules independently, contributing to network robustness by ensuring how they participate is not dictated by an arbitrary third-party.
-
Engage in mining, even on a small scale: Whether through modest hardware or simply mining fiat at a normie job to buy Bitcoin, they participate in Bitcoin’s security model.
-
Demonstrate a deep understanding of Bitcoin’s monetary principles: They grasp optionality.
-
Use Bitcoin in real economic activity: They charge and discharge Bitcoin when appropriate for their needs, recognizing Bitcoin is a battery, a tool they may yield as a buffer against economic turbulence.
-
Contribute to the ecosystem: This may include challenging orthodoxy, supporting proprietary development, disillusioning privacy larp, or advocating for parallel infrastructure.
-
Commit to long-term stewardship: They view Bitcoin not merely as an investment, but as a return to tradition.
It's certainly possible and available in some areas, but rare. Mesh and 4G enabled meters are a step in that direction, but the head-end/SCADA in most places would still buckle if it were to happen at scale. At my last fiat job with a big utility we couldn't even get permitted stuff connected in a timely manner, massive solar fields sitting unproductive for years (thanks government subsidies!)
Back-feeding at peak rates would certainly help accelerate amortized recoup of gear, but if you ran the numbers I have no doubt you'd find it would still be a cost, or a risky to break-even investment at best.
There's trillions of dollars chasing any whiff of energy arb that may exist, if you can plug in a panel to arb it, so can industrial scale solar. The real arb is going off-grid completely, but that's still a risky to break-even investment given the duration over which you'd have to amortize it.
Back-feeding is generally a complicating variable for the grid operator which is why most utilities/regs forbid it without some kind of registration.
I assume these plug in devices, or at least the ones they're trying to make not require a permit, are designed to prevent back-feeding and just slow the rate of delivery.
These things are still fiscally unwise, and that's why solar relies heavily on subsidies.
An example from the video was $1600 to save 5-10% on the bill cost... let's assume 10% of a $250 bill... thats a 5.5 year recoup, assuming you otherwise would have let the $1600 melt by not putting it to work in another way like debt service, coin, or even a money market.
Will the panel last 5.5 years? how much time will you spend fucking with it to get that 10% payback? Once it does pay itself back, did you really make anything after depreciating the panels, how much longer to make an actual return given that?
The only real use-case for these panels is backup if your grid is unreliable, that requires another cost in a battery... and thats not saving you money, thats you paying a premium for reliability.
Hooking a solar/battery setup to a dedicated bitcoin space heater may offset some of the premium you're paying for having the backup/reliability, but there's no math that will ever make these an investment unto themselves.
This has been hashed over a number of times, this was written without any actual research into the problem space. Child keys are too much work on the client, among other inanities with this approach.
A UX warning “New epoch key detected. This profile rotated.” That’s it.
lol.
It's actually much simpler, remote signing and a policy engine: https://auth.shock.network
This is how so much works in the enterprise, and for a social network to gain real traction big brands need to adopt it and that means delegating revocable scoped permissions to interns and social media management suites, policy engines and remote signing are inevitable.
Focus is on wallet/pub rn of course but an SDK and enhancement to Sanctum is on the roadmap.
They had to scrap their design last year, great ticker for pumpamentals but not sure they're executing well. Letting gains ride but cashed out my principal. I like that BWXT is actually the Navy supplier hense the rollover, and ofc Oklo for the Los Alamos connection
gonna roll some SMR to BWXT too, per #1313297
Trimmed TMC and CENX last week
Rolling REMX over to SETM
Adding URI and EOSE, and maybe some more HON
something generalizable
mutual dependency vs. one-way dependency maybe, participant behavior vs. environment behavior, relationships vs. language
the risks of having different lightning implementations
Yea I think its a bit of a paradox, everyone has taken for granted that its less risky on the L2 because the L1 is what's notoriously consensus driven... ignoring that its a loose-consensus on L2 that's inherently more fragile
Incentives are likely a factor in this narrative remaining undisputed, there's service layers to offer in L2 stacks that influence the implementations, there's not really any services that coupled closely to the L1. The Lightning implementations are all very modular, the bolts necessitate it, yet they all ship as part of value-added ecosystems (even if they're optional)
we'll never break free of a dominant distribution
Likely, but even Debian, RedHat, Arch and their children is more distributed than Bitcoin is at this stage.... all generally dividing up the same hardware.
My issue with Core is that, due to its legacy, very few even think about distribution and are never forced to make a decision. That default distribution had made it a politburo more than it is an implementation, leaving both ossifists and expressionists dissatisfied.
Archiving it would at least shake that up, even if it was a 1:1 Team/NGO migration to a new repo under a new name achieving a similar share of update distribution, Core loyalists would stand to benefit the most in affirming such a mandate.
This has become apparent with the Nostr NIP's repo already too, the repo is a politburo for the distribution channel that is nostr-tools and dictates by default how any number of things are done. This despite really only a handful of the NIP's resembling a level of network-wide consensus.
Would the framing of L1 is asynchronous where L2 is synchronous help? Or broadcast/unicast?
If you wanted, you go as far as signing a transaction to miners via carrier pidgeon, since there's not any sort liveness or quorum inherent to that communication.
Even miners which do need to stay online to function are dealing only in broadcast traffic, and implementation chooses only to listen and shout correctly, having no implications on its peers.
Even a minor implementation mining a block out of spec (shout correctly) would have that block rejected, with the user having their tx mined in that block remaining unaffected as it would still be mined in both forks, all without any handshake happening first.
nodes running the minority implementation
In Lightning it effects all nodes if its size-able enough to cascade given the interconnected-ness of the network, not necessarily just those running the breaching implementation as would be the case in an L1 situation.
Would these accidental forks be more common with a plurality of implementations?
Likely, the trade-off of that being more isolation. Better to have 10x more fork issues at 1/10th the size, like forest fires, controlled burns prevent uncontrolled ones.
90% of the network running one distribution is a risk even with its own prior versions, new version can quickly become a large share of the network just given that distributions overwhelming share.
If so, wouldn't that be enough to create a network effect that defaults the network to one implementation?
That's the effectively case now, I'd expect it to remain so. However, it would demarcate implementation from distribution, which is more important given how a large break on either layer likely has to come in the form of an "update".
Archiving Core would decentralize that distribution, but not necessarily the consensus code, since replacement distributions would largely be forks of it.
Any changes to consensus code, or new/ported implementations, would then be either graceful or ungraceful based on its ability to gain distribution first. The more likely it is to break something, the less likely it is to be widely distributed.
The result of that would I think inevitably become library-ification, and a lexicon shift to Bitcoin distributions rather than Bitcoin implementations. To further analogize to Linux, the equivalent to consensus code there is the hardware.
BTCD has shown this is possible, its a differing implementation with a solid track record of "just working", yet the majority of its users use it as a Library (LND). Libbitcoin literally intends to be a library.
Apples and Oranges to compare disparate implementations of Lightning vs. Bitcoin
Issue at hand is explicitly due to the nature of it being interactive, where Bitcoin L1 isn't
It's also not a disaster for a minor implementation of Bitcoin to fuck up, that specific implementation either doesn't get its transactions mined or crashes. Network unaffected. Would take a large share to be a disaster, which is precisely why no implementation should have a large share by default. #ArchiveCore
Lightning is much more dangerous for network health to have disparate implementations, one bad mass-upgrade of a given lightning implementation could take a lot of peers down and storm force closures in a cascading shit show.
Fortunately the minor lightning implementations are extremely minor, more so than say knots vs. core... and generally edge nodes vs. backbones of the network.