The psychology around price-per-coin is the same for all eras/times/individuals/groups $1, $10,$100....$100,000 I'm too late... Should I have bought more? Should I sell? Buy? Same for plebs, small companies, corporations, states, nationstates, gov.. dynamic is exactly the same. This is going to get wild.

How many 25k candle months have we had? Any?

Wen rektbot posts?

20k monthly candle

If we pump for another 48 hrs or so we can hit a $20k month candle.

As the shitcoiners migrate over to the only blockchain that matters, don't freak-out, the honey badger is always up for a fight

Biggest threat to Bitcoin remains the longterm fiscal discipline of the USD as the world reserve currency. The current op_return *war* is way, way overblown

"Citrea recently announced that they plan to write data to payment outputs because they need non-malleable transaction data that gets confirmed timely in excess of the current OP_RETURN standardness limit. As the use of payment output scripts cannot be easily prevented, encouraging them to use OP_RETURN outputs instead would be harm reduction as at least the data would not be written to the UTXO set that every node has to retain forever. The proponents in the mailing list thread and pull request further argue that it is more expensive to write large data payloads to OP_RETURN outputs than inscriptions and therefore use cases that already use inscriptions are not incentivized to use OP_RETURN. The break-even point for that appears to be 143 bytes above which payloads are more expensive to be embedded into OP_RETURN outputs" - Murch

"There are currently three ways of embedding data in the Bitcoin blockchain in use. 1. Inscriptions are written to an unexecuted branch of a taproot leaf script. This data appears in the witness stack of inputs. Witness data is only validated once when a node first validates a transaction’s scripts and is stored as part of the full blockchain record. When a pruning node performs IBD using the assumevalid option, witness data doesn’t have to be downloaded or evaluated at all. Witness data is discounted by 75% compared to other transaction data, but is malleable until a transaction is confirmed. 2. OP_RETURN data appears in the output script. OP_RETURN outputs are only validated once when the node first sees the transaction. The data in output scripts is not discounted and not malleable, as signatures on the inputs generally commit to the exact output scripts. As OP_RETURN outputs are unspendable, they are stored as part of the transaction in the blockchain data, but do not get added to the UTXO set. 3. Some schemes (e.g., Stamps) embed data in payment output scripts using either fake public keys or fake hashes. The data for output scripts is not discounted. As these output scripts are not clearly unspendable, these output scripts must be retained in the UTXO set." - Murch

"Instead of referring to transactions that fail Bitcoin Core’s mempool policy as non-standard, we should really be talking about "transactions that are [not] accepted by Bitcoin Core’s mempool policy defaults". It’s a bit of a mouthful, though." - Murch

"There are a bunch of 2nd-layer protocols, sidechains, and rollups, etc. in development that aim to use the Bitcoin blockchain for anchoring, proofs, or data storage in some other way. Dropping the OP_RETURN limit would ensure that they can at least use OP_RETURNs if they must write data to the blockchain instead of writing in more harmful ways like fake pubkeys or fake pubkey hashes. OP_RETURNs would need to be part of a complete copy of the blockchain, but would not live in the UTXO set which needs to be kept highly available. Fake pubkeys/pubkey hashes live in both the UTXO set and the blockchain." - Murch

Paying to transact is the ultimate spam filter. It will be expensive to transact on-chain. You will have to work and provide value to afford it. Perfect incentive for human flourishing.

Bitcoin capturing the suits is a net + NGU is better for everyone: plebs, devs, influencers, businesses, corps, govts..... potentially all humans - are ultimately better off with a money that is separate from the state. With NGU..... more of the wealth, resources, *support*, will no doubt flow to the devs/alternate implimentations of the software

On Thu, May 01, 2025 at 11:29:35PM -0700, Greg Maxwell wrote: (Yay!) > So on this basis I suggest a principle for these sorts of policy: Relay > rules should admit all transactions which are reliably being mined. > I think node software should adopt this principal as a general rule. Hmm, I don't actually think this is a good rule -- if followed strictly, it prevents ever making relay rules more restrictive, even for cases which are provably harmful for the network. > By general rule I mean that should something like a miner begin mining e.g. > quadratic hashing bloat legacy txn, or using unused > opcode/successcode/version number or whatever by mistake or technical > ignorance there is no need to rush off enabling their relay. A general rule > isn't a suicide pact. Alternatively, if it's a rule with exceptions, then it's those exceptions that are the important factor and should be figured out. For example, the reason mining a "quadratic hashing bloat txn" is bad because it causes delayed block validation on its own, potentially in ways that aren't even sufficiently mitigated by running your node on extremely high end hardware. Transactions like that should really be removed from consensus validity not just prevented at the relay level, and BIP 54's consensus cleanup hopefully does that. Miners have accepted out-of-band relay of spends of unknown segwit versions (which I presume is similar enough to the "unused opcode/successcode/version number or whatever" case), in particular txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 in block 692261 (the taproot exception block). Even though that was not done by mistake or out of technical ignorance, I think doing such things extremely rarely through out of band mechanisms is pretty much fine. (Even if miners do it for profit, rather than as a 0-fee tx where the outputs are a donation to a developer funding group) > But if it were the case that transactions misusing a > particular forward compatibility feature were reliably getting mined then > that feature would just no longer be useful for forward compatibility > regardless of what relay policy says about it and it would be better to > relay them than have the downsides of not doing so. If adopted, a policy like that would be fairly easy to use to hold the network hostage: find a miner who doesn't much care and has perhaps 0.1% of total hashrate, get them to mine txs spending segwit versions 2 through 16, and forward a handful of such transactions to them every day. The transactions are getting mined regularly and reliably (at a rate of about once a week), the transactions aren't immediately damaging the network, the miner is making excess profits, and by your relay argument, the miner is gaining a slight advantage in being able to potentially mine two blocks in a row due to the block relay delays caused by not relaying spends of future segwit versions. The LibreRelay project has already followed pretty much that script for pushing fullrbf relay onto the network, and is proposing to do the same approach for data storage in the annex, so I don't think this is just a hypothetical concern. I'd describe that class of policy as something of a "popularity contest" approach -- it's a policy that says that anything that's sufficiently popular is good/permissable. I think that makes sense as a check/balance approach -- "this think is popular, is there really a good reason why it's not permitted?" -- but not as the first thing we think about. > As Antoine Poinsot points out, the existent rule is entirely ineffectual: > Parties current bypass these rules with other transaction forms (such as > very harmful address stuffing which is impossible to block) or by direct > miner submission, which will continue considering the millions of dollars > miners have received mining transactions with violate the relay rules. > Because of this it will not become effectual with time or tweaking. It is a dead parrot^policy. This is no surprise, since it's a product of Bitcoin's anti-censorship properties that *generally* filtering will not > work except on the fringes. As such there isn't practical upside to > keeping filtering beyond what miners currently perform. As a check/balance, I think that argument holds water, and should cause us to ask if your existing policies make sense. I think it's fair to say Bitcoin Core's existing policies (as expressed by its code, and not necessarily matching the policies of various forks of Core) are (in no particular order): 1 limit utxo growth (via block weight constraints, and by avoiding creation of utxos that would be uneconomic to spend) 2 prefer that transaction data be prunable rather than potentially permanent (eg, better to have a 20-32 byte hash in the utxo set and a 160 byte x-of-5 multisig script in the scriptSig or witness, than to have the 160 byte x-of-5 multisig directly in the utxo set; this is the main justification for why witness data should be discounted vs output data) 3 limit block validation time to the ~1s range (on a block whose txs have not been seen before, on reasonable hardware) 4 limit maximum block size growth to ~4GB/week (ie, the worst case from having a 4M weight limit) 5 optimise validation and relay of blocks with txs that we have seen before as much as possible 6 allow anyone to create any sort of scripts they like (via p2sh, p2wsh, p2tr), within the limits of what you can conceivably do with script opcodes, and without causing excessive validation costs 7 encourage people who want to use the blockchain as an anchor for their data to store commitments in the blockchain rather than the actual data 8 allow miners to occassionally generate excess profits by mining non-standard transactions that violate relay rules but comply with consensus rules (There are obviously many other policies, eg the 21M coin limit, but I think the above are the ones most relevant to this discussion) I think all of those policies can be justified (or criticised) on their own merits, independent of their popularity per se, and I think doing that is a better approach than starting with what's popular or not. I think there's perhaps four conclusions you could reasonably draw about the policies above, wrt what's been discussed on this topic: * encouraging data storage people to use commitments (7) didn't really work, and given that could be done via documentation or blog posts where we could provide reasoning, examples and alternatives rather than just a "transaction rejected" which might be more effective anyway. the citrea design also suggests that that policy is interfering with the goal of limiting utxo growth (1). as a result, it probably doesn't make a lot of sense to maintain that policy in code. There's already the obvious incentive pushing people towards commitments instead of raw data, in that doing so reduces the on-chain fees you need to pay. * for (non-commitment) data storage use cases, OP_RETURN limits are probably largely irrelevant in limiting blockchain usage; while OP_RETURN is also prunable, it's not discounted (2), so including data in the witness will still be preferable to the people who wish to publish data in large volumes * people with legitimate concerns about their node being overloaded should probably be concerned more by the "limit maximum block size growth to ~4GB/week" policy (4), rather than commitments vs data (7), complicated scripts (6) or prefering prunable data (2): it doesn't really make much difference if your node is overloaded by spam or by real transactions, either way it's overloaded. I haven't seen any evidence of it being difficult to keep a node operating for that reason, however. * there are two aspects to the "miners generate excess profits from non-standard transactions": * one is that for that to only be "occassional" means that even vaguely legitimate use cases should have a supported way of being exercised via standard transactions without being much more expensive: eg, instead of consolidating 4000 transactions in a 270kvB transaction, you might use consolidate 1333 transactions in each of three 91kvB transactions. That limits the amount of excess profits the miner can generate, in this example the 3kvB of savings would only justify paying about 1.1% higher than the going feerate for standard transactions, eg. * the other is that if you want to disallow this from happening even occassionally, then you want to have relay and consensus rules be the same; but that effectively means that any functionality upgrade needs to be done as a hard fork, which in turn likely has highly centralising effects around the developer team, as running old versions of the software becomes infeasible > Some Bitcoiners are of the opinion that they still want a knob, I think > doing so is a disrespectful placebo[*] I don't agree with that at all: giving people what they ask for, even if it's literally a punch in the face, isn't disrespectful, it's the opposite. (Respecting other people isn't always the highest virtue, of course) > But in this case if there were a knob here I think would make more sense > for it to control mining policy rather than relay policy, since it would > actually have some effect in the mining context (in excluding the txn from your own blocks) while as a relay only thing it is impotent. Core's mempool/standardness policy covers both relay and mining acceptability. I don't think it makes very much sense to separate them -- beyond making the code more complex, accepting txs into your mempool that you'll still relay but won't mine might block you from accepting other (conflicting) txs that you would mine, eg. About 11 years ago, you wrote: ] [...] Right now I've seen a lot of people ] promoting data storage as a virtuous use, and gearing up to directly ] store data when a commitment would work. ] ] If it turns out that encouraging people to use hashes is a lost cause ] it can always be further relaxed in the future, going the other way is ] much harder. -- https://gnusha.org/pi/bitcoindev/CAAS2fgT6qFHBojoB-teCjF_YAd9TePdQ3+NWnO0dwf9Bv583_Q@mail.gmail.com/ Even if they're fundamentally wrong, I think it's respectful to people who haven't yet given that up as a lost cause to leave them with a knob that gives them at least a chance to continue the fight for sometime longer. Let me offer a principle that will never need any exceptions: people who are a mere 10-15 years behind the thinking of the bitcointalk.org class of 2012 are still the brightest 1% of humanity. Cheers, aj

https://youtube.com/live/TqxDr_SjAgg?feature=shared Adam Jonas MIT Expo 2025 day one talk starts @ 5:18

What will back the WLF+Abu Dhabi+Biance stable coin? Will they buy T-bills?