SatsAndSports

When my node discovers there is a new block, I want statistics on the following:

• transactions that were in my mempool
• transactions that weren't in my mempool, but would have been accepted by my mempool
• transactions that wouldn't have been accepted

Any idea if this can be done? I'm hoping that Core already has a debug option for this

(I'm running Core v26, configured to be more relaxed on relay policy, so I'm curious what I miss)

#Bitcoin #Mempool

Idea: Proof of burned sats, but where the burned sats are not taken by the current miner and are taken by a random future miner instead.

If I create a #Bitcoin transaction with an anyone-can-spend output, but with CheckLockTimeVerify to delay the expenditure until some future block, then that future miner will (if rational) just spend that output to send fees to itself. Is that correct? #AskNostr

(I'm asking about this for a fascinating idea I've heard in today's NostrHackDay where we want to provably 'burn' some sats but - due to miner misincentives - we don't always want the miner of the next block to get (all of) the burned sats; we want some future miner to get it)

[

]

[

]

When a #Bitcoin blockchain re-org happens, are the transactions in the old blocks moved into the mempool again by all the nodes, or are users expected to manually re-broadcast the transactions?

Anyone else see this video title and think it was about the cost of a #Bitcoin blockchain reorg? 🙂

What is the red here in this block?

Running my own node (Raspiblitz), which came with Core v26. I don't think I've ever seen this on the public mempool.space, so I'm surprised to see it on my self-hosted MempoolSpace

I recently added minrelaytxfee=0.00000100 to my config, could that be related?

#Bitcoin #Mempool #AskNostr

Fun, and weirdness, with #VibeCoding

While processing the #Bitcoin blockchain, I have a function to compute the block reward of a given block. I asked it (Claude Code) to check around the time of the first halving, to make sure there wasn't any off-by-one error.

It was working correctly, and Claude Code was happy that it was working correctly, but then it suddenly panicked and decided that the logic was wrong, see the end of this first screenshot:

It followed up with this false claim, and tryied to add this off-by-one error in the code: "Ah! The issue is that at block 210000, height / 210000 = 1, so we're calculating 1 halving, giving 25 BTC reward. But block 210000 itself should still have the 50 BTC reward - the halving takes effect
starting from block 210001. "

I think responded with "i don't think that's correct. A few questions. Is the genesis block considered to be block 0 or block 1?"

and it immediately corrected itself:

I could give lots of examples like this, where it did stuff that was slightly crazy or just wrong, and I have to overrule it, but I guess I don't want to bore you all; I'm very new to VibeCoding and I guess all of you that already have more experience with it have already learned all these fun lessons.

For now at least, humans are still badly needed to help the coding agent. But that could change of course ...

While researching this scam video and looking at the scammer's address I see this strange warning about "address poisoning". What does it mean?

https://mempool.space/address/bc1qualxuc5cqdmr986h3vsvnp3q09y86nghne963r

SCAM video:

#Bitcoin #Mempool

Any tips on how to run a Bitcoin node? And maybe I'll run other things too (Lightning, a personal Nostr relay, maybe an ecash mint for fun)

I've been using Linux as my primary OS for 25 years, so happy to do deal with that

But I have zero experience with hardware such as the Raspberry Pi

So I guess I just need to buy some Pi that's powerful enough for all that, but still quiet so that I can run it 24/7 in my apartment

(I won't be debating Core versus Knots here; I'm mostly asking about hardware and similar practical matters)

#Bitcoin #Linux #RaspberryPi

I don't claim to fully understand Finney's zk method here, but - in the context of quantum resistance - I've come up with a two-transaction approach to allow us to spend from P2(W)PKH addresses, even when powerful quantum attackers already exist.

My method is probably either wrong, or unoriginal, as I'm newish to this. I studied cryptography twenty years ago in university, but have probably forgotten a lot. I'm just thinking out loud here, as I guess I might get good quality feedback on Nostr 😊

=== The problem, and my proposed method: ===

Let's assume that we have a balance in a P2(W)PKH address. The private key (s) and the public key (k) are known only to us, while the hash (h) is the address and is public as it's in the block chain. I want to spend my funds from that address, but an attacker wants to steal them.

Let's assume there are attackers with very fast and powerful quantum computers. To spend from that address (ideally to send it to a new - quantum-resistant - address) we need to show 'k' to the mempool along with a message signed by 's'. A fast attacker can see 'k' in the mempool and use their quantum computer to compute 's' and therefore quickly replace my genuine transaction with a transaction that spends to the attacker's address.

To prevent this, we can change the consensus rules to allow us to pre-register the address we want to spend to. First, we need to combine the public key 'k' and our target (hopefully quantum-resistant) address and then compute the hash of that pair. Call this hash 'h2'

The pre-register transaction doesn't spend anything (apart from any fees necessary to get this pre-registration on to the chain), it just records - perhaps inside an OP_RETURN - the following two pieces of information on the chain:

• the original address, 'h', that I (claim to) own,
• this secondary hash, 'h2', which is as described in the previous paragraph

Of course, any attacker could also make a similar claim to the same 'h'. But they don't know (yet) the true 'k' and therefore they are unable to compute the correct 'h2'

Later, when I'm satisfied that this pre-register transaction has enough confirmations, I can broadcast the real (signed) transaction. As this exposes the public key, it means that both hashes can be computed and it's easy to see that my claim - not the attacker's claim - are genuine. At this point, the quantum attacker can compute the private key. But they can't steal the funds as my 'claim' has been proven correct and therefore the target address that I chose in the pre-registration is 'locked in'

This is a change to consensus rules, to 'lock in' any claims that have been proven correct, and it might take a long time to agree and implement it. But the point is that we can use a simple scheme like this to safely spend.

So, as long as your funds are in P2(W)PKH addresses that you have not already spent from, you don't need to panic when quantum computers become very powerful. Just wait patiently for this scheme (or something better!) to be implemented

#Bitcoin #Quantum #QuantumResistance

To decrease variance in the time between blocks, we should require multiple nonces in a #Bitcoin block, not just one nonce.

Currently, #BitcoinMining is a Poisson process, with 10 minutes on average between blocks. But it can vary wildly, from just a few seconds to more than an hour. I want to decrease that variance because I think it would make certain attacks more difficult.

I propose that, instead of requiring one nonce which hashes to a string with many leading zeroes, the block should actually be a set of ten "miniblocks", where each mini-block has a distinct nonce and each of the miniblocks has a suitable hash.

I know this is a big change, and so arranging the necessary hard fork would be difficult, but it's fun to think about these things!

Decreasing this variance would, I think, make certain attacks more difficult; an attacker with 40% of hashrate would find it more difficult to build a short lead