I think it's worth separating price squeezes from liquidity. Staking/"liquid staking" reduces circulating float, which can make thin books move +127% in a day… but that usually hurts liquidity depth, not pumps it. Liquid staking derivatives can even be rehypothecated as collateral, so you get more leverage on less float, great until unlocks or funding flips.

For that PUMPBTC move, what's the combined 1% depth and venue mix? And beyond staking, which lever have you seen add real depth rather than just a weekend squeeze?

You say "infinite supply," but what's the per-block subsidy, emission schedule, and expected yearly inflation? Any halvings or is it a Doge-style tail reward?

What's the difficulty/retarget, you list 60s blocks and a 4-hour target timespan, are you on DigiShield/LWMA/stock Dogecoin rules, and is retarget per block or per window? Where can we see the 10M premine addresses, vesting, and who holds the keys (n-of-m multisig, signers named)?

Also, you mention "enhancements in speed, scalability, and security", beyond params, what's actually changed from 1.14.9 (mempool policy, block/tx limits and fee rules)?

Cool concept. If you're embedding a signing chip in the piece, I'd suggest you make an extra effort to be precise about what lives where: the ordinal stays on-chain, the chip only holds a key that can attest "this specific physical object is bound to inscription X."

Biggest risks are clones and key loss in my opinion, as Resin isn't tamper-proof, so you also might want t add tamper-evident features, publish a verification spec and perhaps open-source whatever glue you can. Also, what's the recovery story if the chip dies? Can the attestation be rotated to a new chip without breaking provenance?

Flaky mains usually trip the PSU's under-voltage protection, so the miner just dies and reboots. It's worst at sunrise/sunset when your solar/inverter hands off and the line sags for a moment. A 1.5 kW rig at 230V is around 6.5A.
A 10-15% dip spikes current and many ASIC PSUs say "nope".

You should isolate your mining device from the power grid with a UPS and/or a hybrid inverter that always outputs a steady voltage. Size this at least 2x bigger than the miner's wattage per unit.

I love this mission!

My "first 15 minutes with a total newbie" playbook would be something like:
Explain keys vs. coins: "You don't own bitcoin, you own a secret (seed). Lose secret = poof."
Do a $5 worth of sats demo on a clean phone wallet. Write the 12 words on paper, restore on a second device, then delete the first. (Nothing sticks like a restore test.)
Two habits: no screenshots of seeds; and the 3-2-1 backup (3 copies, 2 media, 1 offline).
Fees happen, prices wiggle; 21M cap doesn't.

Nice thread.

A few that work for me (kept simple, repeatable):
Sleep first, same bedtime/wake time + 5-10 min morning daylight. Everything else gets easier.
Fat, Protein & plants, ~25-30 g protein each meal + aim ~30 g fiber/day (beans, veg, oats).
Do not to eat sugar at all. Exercise regularly.

Honestly these are the most important "life hacks" you can do that will have the most impact

Fun meme, but can you post the basics so people can verify?
SPL contract address + explorer link, whether mint/freeze authority is revoked, total supply & initial LP (with lock tx/locker link). A non-Canva page/README would help too.

I think so. I personally am holding a whole bunch of PEPE Unchained (PEPU)

Neat idea, but before I toss some USDT at it, can you fill in some due-diligence blanks?

Which chain are you on, and what are the contract addresses (USDT you accept, your core game contract, and the WBTC jackpot vault)? Is the code open-source and audited (link to report, not just "audited")? Any admin keys, who can pause, change fees, or move funds, and are those keys timelocked or multisig?

Where is WBTC for the jackpot held and how is the carry-over enforced on-chain if nobody hits? If you're using WBTC, note it's custodial, are players taking that risk knowingly?
Which Chainlink feed address, heartbeat/deviation, and what exact timestamp do you sample for the "final price"? Is there a lock/freeze window so people can't place last-second bets after the price is effectively known? How do you handle oracle delays/reorgs or feed outages?
What's the house edge/rake that funds bonuses and referrals? A clear formula for pool to winners after fees would help. Also, how do you prevent multi-account farming of the early-bettor and referral bonuses?

Totally hear you on fee flexibility. One way to get both properties is to split responsibilities:

Anchor input (strict) - one signature with SIGHASH_ALL that binds the sidechain header commit, prev pointer, and the exact payout template.

Fee input (flexible) - a second signature (your "puzzle/work" sig) using ANYONECANPAY so anyone can RBF in extra inputs right before broadcast.

This keeps the "work" valid while letting fee-payers add coin at the last minute without you re-grinding. It also prevents a relayer from reshaping the payout you intended.


Agree CPFP isn't the right tool for a CSV-locked input across months. With the split above, you don't CPFP the locked input. You simply wait until near maturity, assemble a fresh replacement with extra fee inputs (thanks to ANYONECANPAY on the fee side), and RBF it in. Mempools won't keep a txn for months anyway, so "fee planning" happens at broadcast time.


For the PoW check: we don't need to enforce it in script at all (tapscript doesn't give us clean 256-bit comparisons). Let the script only enforce spendability (key path + CSV/CLTV). Sidechain nodes verify the "work in the signature" off-chain for fork choice. If you do want to grind safely, Schnorr/keypath is still preferable to ECDSA: you can vary the nonce point safely and avoid RNG/nonce-bias pitfalls that grinding ECDSA tends to invite.


Right, fork choice by cumulative work. To reduce the "grind on invalid body" risk, I'd at least bind a body Merkle root (and maybe body length) into the message you sign and publish a compact "invalidity witness" format off-chain. Nodes that see a body-level contradiction can deterministically orphan descendants of that header; no L1 involvement, but you still deter obviously invalid histories.


Makes sense for delayed finality. In the split-input layout above, put the CSV on the anchor input so no one can front-run settle-outs, while fee inputs remain free to change via RBF right before maturity.

Looks interesting. I have a few key questions:

1. PoW + DAA: Which hash algorithm? Compete with BTC (SHA-256), merge-mine, or ASIC-resistant? With volatile hash early on, why 2016-block retarget with 4× bounds--won't that stall? Any ASERT/DGW-style alternative?
2. EVM config: ChainID, EIP-1559 on/off, gas target per 10-min block, and expected UX (throughput/latency) with such long blocks. Any MEV policy?
3. Client/tooling: Base client (geth/reth fork?), explorer/RPC readiness, and audits. Any dev bounties?

You've got per-tx merged mining: grind a sig so its hash meets a target; commit the sidechain header in that signed message. Miners include the tx for fees; the sidechain uses the "work in the sig" for fork choice.

Key things to nail:
What the sig commits to: bind {sc_header, sc_prev, mainchain height, outputs} with strict SIGHASH_ALL; do fee-bumps via CPFP/RBF.
Use Schnorr/Taproot, not ECDSA DER, safer grinding, fixed encoding, fewer edge cases. Fork choice math, define target and cumulative score unambiguously; publish a reference is_work_valid.
Liveness/censorship: make fee bumping trivial; include mainchain height to avoid replay across reorgs.

Work proves effort, not correctness, consider fraud-proofs/delayed finality to deter invalid headers.

That's a neat project, feels like a "Bitcoin Yellow Pages" but without the sketchy ads. Having it country-specific is smart too, since half the battle is figuring out what even works where you live.

Couple things I'd be curious about:

Will you track whether these wallets/exchanges are actually Bitcoin-only, or if they quietly slip altcoins into the mix? (Some start pure and drift later.)
Any plans to add filters for open-source vs closed-source, or whether a service has been audited? Those little flags could save people a lot of digging.

Also +1 on making it free and open source -- that alone gives it more credibility than most comparison sites floating around.

Bold claim -- "unstoppable as Bitcoin" is setting the bar about as high as it goes. The idea of a decentralized web where nobody's in control is definitely appealing, though. Makes me wonder: how are you handling stuff like spam, takedowns, or just plain bad actors?

Also curious if EpiX is aiming to be a Layer 1 for hosting, or more like a storage/distribution layer bolted on top of existing chains?

Kinda funny how the thing you install to hide yourself ends up knowing you better than your own family. Free VPNs are like "free puppies", sure, they cost nothing upfront, but good luck with the mess they leave behind.

Tor feels safer for wallet checks, but even then, I sometimes wonder if the real lesson is: don't trust tools that make their money by pretending not to make any money.

Do you think people stick with free VPNs out of ignorance, or just because most folks figure, "eh, what's the worst they can see, my YouTube history"?

Funny thing about these "AI vs Human" matchups is the AI might win on consistency, but it doesn't get sweaty palms when it sees a red candle drop like a guillotine. Humans do. Sometimes that panic is the feature, not the bug.

Curious though, if BingX's AI was actually that good, why would they be dangling it in a contest instead of quietly printing money in the background? Maybe the real game isn't who trades better, but who markets better.

Ever tried running your own rules-based bot side-by-side with your manual trades? That might give you a sneak peek at how "AI-ish" your discipline already is.

First, Tor Browser != the Tor service. Bitcoin Core/Knots works best with the system Tor daemon, not the browser bundle. which is also why tor --version is not found.

Here's some setup steps for Linux:

Install Tor daemon and start it
sudo apt update && sudo apt install tor
sudo systemctl enable --now tor

Allow Core to talk to Tor's ControlPort (for your .onion address)
Edit /etc/tor/torrc and ensure these lines exist:

Add your user to Tor's group and restart:
sudo usermod -aG debian-tor $USER
newgrp debian-tor
sudo systemctl restart tor

Minimal bitcoin.conf for Tor
optional if you want Tor-only outbound:

The "cookie" isn't a login/password. It's a local file Tor creates for ControlPort auth; adding yourself to debian-tor lets Core read it automatically. And if you want to use Tor Browser's SOCKS (127.0.0.1:9150), then Bitcoin can route outgoing traffic but won't manage a .onion listener because TB doesn't expose ControlPort by default. For a proper onion service, use the Tor daemon as above.