Avatar
David A. Harding
813fce4c4e76f1e7b4f4697bf1030a90f1a0b783f187d329800a4dd8697f9759
Co-author of the Bitcoin Optech weekly newsletter (2018-) and the third edition of Mastering Bitcoin (2023). Brink.dev grant committee member (2022-) and former board member (2020-22). Lives in Hilo, Hawaii. All opinions are my own.

Oh, really? I just quick skimmed Amazon and saw they still want a prescription, but I guess I'll have to dig deeper.

For Mastering Bitcoin, the publisher wanted to go with Bitcoin-the-network and bitcoin-the-currency. I was fine with that, as its what I normally used, but I discovered when working with the non-Bitcoiner editor and proofreaders that they had a hard time guessing which was which. I got a lot of queries about whether I really meant to use caps (or vice versa for lowercase), especially since I did occasionally use the wrong case. Next time I work with normies, I'll probably ask to just use common noun casing throughout.

nostr:nprofile1qqsvvk9qy7qx2gzed6wazxtureunuxljam66za6yr3p02zc0qhz57jqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs0dsl3l noted in discussion on Delving that you only need a proof of transaction contents (e.g. the coinbase outpoint) if the tx is exactly 64 bytes. Otherwise, a proof of tx size is sufficient, which is compatible with SHA midstate verification (i.e., ~100 bytes max data).

It's very imprecise. Worse, it's only useful for individuals who contribute large amounts of hashrate, i.e. those who could reasonably solo mine. nostr:nprofile1qqsvvk9qy7qx2gzed6wazxtureunuxljam66za6yr3p02zc0qhz57jqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs0dsl3l makes the point that the difficulty of preventing block withholding could be a significant contributor to limiting pool options: https://mailing-list.bitcoindevs.xyz/bitcoindev/Zp%2FGADXa8J146Qqn@erisian.com.au/

You detect it with statistical analysis. If Mallory is excessively unlucky, e.g. she's submitted 3x as many shares as necessary to find a block but none of her shares were blocks, you ban her.

What auditability? I thought nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0907cz8 was talking about eliminating miner identity, which prevents eviction of misbehaving miners.

I'm all for anon mining, but pools that allow it now put themselves at risk of block withholding.

If there's no traceability, there's no way to ban miners who perform block withholding attacks. nostr:nprofile1qqsvvk9qy7qx2gzed6wazxtureunuxljam66za6yr3p02zc0qhz57jqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs0dsl3l has recently written about this problem and potential solutions (e.g. oblivious shares, which alas requires an invasive hard fork).

I ground slept for about 10 years and thought it was great---except when I was sick and wanted some place to lay when feeling miserable. Alas, my fiancee insists on a bed.

Ejecting garbage into space during battles and fleet maneuvers could damage their own ships, so they had to be prepared to store it for hours or days. But trash is bulky, so they compacted it. Also, maybe compaction was followed by incineration or some other processes to destroy any potentially classified material that accidentally got thrown away.

Isn't that 0.01% error rate over the total number of public keys in the set? E.g. if I follow 1,000 out of the 1 million publeys on nostr, I'll get guaranteed updates from my 1k follows plus updates from about 100 random people (1e6 x 0.0001)?

We'll be covering Dark Skippy in Friday's Optech Newsletter. I'm guessing nostr:nprofile1qqspgwdt6s5cz9j74nxdq34a2ed26x0jx99f8tvm6zdds03ng2lvn8cprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqgdwaehxw309ahx7uewd3hkc2zf4ja would be happy to have you as a guest on the subsequent Recap podcast next Tuesday.

I have an Amazon Basics wireless mouse that's starting to fail, with the scroll wheel having worn down. Looks like I paid $13.99 four years ago, so $3.50/year.

I'm unaware of any evidence of long term storage in any prehistoric society of large amounts of honey or fat. The quantities needed to significantly extend human life during famine are huge and preservation using prehistoric methods was difficult and unreliable. It's much easier to keep animals alive than to store their fat. It's much easier to have bees guard their own honey against predation than to have humans guard it.

Replying to Avatar waxwing

I wonder if anyone here knows enough about Core's internal processing of utxos *in-wallet* to help with this thorny question?

https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1465#issuecomment-1494996171

Problem is easy to state, even perhaps easy to diagnose, but I just don't know how to correct it:

1. user broadcasts transaction, 2. transaction has low fee and gets ejected from user's Core node's mempool 3. listunspent RPC no longer reports the utxo as present and so Joinmarket (as currently coded) shows a missing balance (old utxos are spent but new utxo is uh "memory-holed").

For context, Joinmarket uses a bitcoin core wallet in watch-only mode to track its transactions.

Is it possible to either query Core, or have Core not "memory-hole" those utxos? I'm thinking maybe they would be tracked, but in a different state.

Maybe nostr:npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c you would know about this? Only pinging you because you're the first Core dev I can think of on here 😆