I guess if anyone should remember that, it'd be you :)

Or was it Ricardo? Stretching my failing memory here ...

Ping nostr:npub1x9jmsqnjhxaut8tzjeqjy7nueztldsm85hapw2vzn646f204r5mscjr7ny

Answer to this question from a few days ago: mempool.space helpfully shows you a decoding of the scriptSig; in this case you can see that a 2 of 3 multisig was being used. However, there are two things rather strange about this multisig redemption script.

First, the keys are using uncompressed encoding. You can see this because the pubkeys start with "04". Further, an uncompressed pubkey then displays the x and y coordinates of the point, in that order, meaning the total size of each pubkey is 65 bytes. Uncompressed pubkeys, starting with 03 or 02 instead of 04, take only 33 bytes and are therefore universally preferred (in the DER encoding used pre-taproot; taproot uses a 32 bytes serialization, instead).

These uncompressed pubkeys were relatively common in the early days of bitcoin, and famously persisted in isolated use cases e.g. the bitmex deposit account which was something like a 4 of 5 uncompressed key multisig - very space inefficient.

Anyway, that's only part of the story here: you'll notice that the 3rd of the 3 pubkeys, while being marked again as uncompressed ("04") actually only has 33 bytes, not 65. This is simply user error; this is NOT a valid pubkey encoding.

This is a corner case; it does *not* break consensus to have one of the N pubkeys in an M of N multisig be invalid, *if* the signatures provided in the scriptSig are valid for keys other than the invalid one.

It was however, not *standard*, so this transaction had to be submitted manually to a miner.

The question is not trivial of course; if pubkeys are allowed to be invalid in multisigs, does it help people use them to embed data? And, is that something anyone should care about? And, even if you restrict consensus to only allow valid pubkeys here, does that make any difference? Can people embed data anyway (hint: yes)?

nostr:nevent1qqsrged0nafpusc0lwts4dknfq9enfnsw028rl9mcglcvc6a3udc7zgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygr8twz0ua0zz64eglr58rh9r898wafhdh0stkklhf3830gp9cwh9qpsgqqqqqqs6srw67

Here's an answer, any corrections welcome:

in sats, the original subsidy is 5 billion = 5*10^9 = 5^10*2^9

That means that after 9 halvings we have a pure power of 5 number of sats. So after the 10th halving that's no longer true and rounding has to happen.

After 9th halving: 9765625 sats (=5^10).

After 10th, 4882812.5 (no longer whole number so pattern breaks).

I believe it always rounds down, but the internal calculation, for the next halving, includes the full number, meaning the pattern 'internally' continues all the way to the end (think of a decimal number as an infinite sequence of powers of 10)

'Yes but..', sorry

Yes 'at the very least' is weasel words 😄

Fun fact : 3.125 is the new reward after the halving, expressed as sats, dropping trailing zeros:

3125 = 5*5*5*5*5

Little quiz: is this always true (power of 5) for every reward value?

Expect this model to be very successful eventually... wondering what the defense against legal claims will be, though.

A nice, discursive summary of most of the early history of payment channels:

https://cryptowords.github.io/technical-a-brief-history-of-payment-channels

Heh no worries, I think this is a combination of (a more technical topic that less are interested in) and (nostr feeds are just by time, so even people that are interested just never see it, sometimes).

I'll post the answer here at some point :)

Partial credit :)

Well hey, it's a mixed ability question 😀

Little bitcoin technicals/Script quiz:

How many things can you find to criticize about this transaction?

Full credit: why is it surprising that this transaction is in the blockchain at all?

Hiring for a bitcoin engineer? This might make a great interview question :)

https://mempool.space/tx/66a2905f6a26c47f9632c5b93db7cd9f31f47df22fa2c18d1f42933f565421ef

Related to my last question!

I wanted to know, is it possible to have an easily communicable process for users to dump out private keys for taproot addresses in Bitcoin Core? It turns out the answer is ... no! (unless you can contradict me - I'd be very happy!)

Whilst it's easy to generate taproot addresses in the new-brand "descriptor wallets" (bitcoin-cli getnewaddress address_type=bech32m), and you can inspect the descriptors for the wallet with bitcoin-cli listdescriptors and even inspect the master private key with bitcoin-cli listdescriptors true, you *cannot* do what used to be easy with bitcoin-cli dumpprivkey address. Now there's a simple logic behind not exposing raw private keys - they lack context. I've seen sipa explain this to people in a few places, it makes sense. A privkey really needs the context of what address it should attach to (even though possible address types can be iterated, that's not a great counter argument, etc, sidetrack.) So, we have descriptors and we can use them to deal with that. The raw privkey (and pubkey) information will still be inside them. But there's more - see achow's answer to the question here: https://bitcoin.stackexchange.com/a/107956

This is an additional step of restriction - it was actively decided not to allow private key export for individual addresses, because of the issue, well known for over a decade by developers in the field, that *individual* private keys of unhardened branches expose *all* private keys in that branch. They're very dangerous in that sense, and it isn't reasonable to expect an every day user to know that.

It's arguable, but I think this decision is dubious at best. A person running the kinds of commands I'm mentioning above is not exactly a normal user; if bitcoin core's wallet is anything, it's a power user wallet, and last and most importantly, dangerous things can be gated behind warnings. A thing should only be *prevented* if there is literally no use case, and I don't think people reading their own private keys quite qualifies there. (And i speak as a wallet dev who has told people countless times "never read your private key!" as a security heuristic..)

A reminder, it used to be literally one-line `bitcoin-cli dumpprivkey

Just a sanity check: am I correct in saying you can't access private keys of addresses in Sparrow?

Just trying to help you maintain your viscount/baron/freeman 1st class status 🙂

If you ever heard the term 'bitcoin baron' (or just heard the ytcracker song) and wondered where it came from:

https://bitcointalk.org/index.php?topic=232802.0

Rpietila was a classic example of the early days of bitcointalk, complete nutjob with delusions of grandeur, but genuinely entertaining in a way 😄

Oof. I remember when revolut used to be the best thing you could get for international travel. Mid market forex rates and no fees. Still, never relied on them.

LN is already a lot better for situations where you can use it, like here in ES.

It wasn't built on my system; it was built on github's continuous deployment infrastructure (so basically on a VM spun up by github).

Which itself is a cause for reflection: suppose I gpg sign a binary built using this workflow, I myself am not in control of the build environment, so should I sign that? Even if it seems ridiculously unlikely that github controlled VM would insert something?

Probably should have people just build themselves (which is relatively painless with Rust, at least on Linux and Mac) and not even distribute binaries - it's a command line tool after all... As for Windows, it isn't very surprising that they false positive stuff, heck, even when they don't flag malware, they make it very hard to run random binaries.

Deleted it for now, will figure out later if there's something I can do to remove the false positive.

If anyone's inclined to help by doing a quick sanity check; can you download the binary for your platform here: https://github.com/AdamISZ/aut-ct/releases/tag/v0.0.2 and then unzip/untar and run ./autct --help to see if it runs OK? Thanks. The main platform I'd like to hear about is Mac; I can't try running that binary myself. Ubuntu latest, Debian12 and Windows 10 seem to be fine (but Ubuntu 20.04 doesn't seem to work). Suggestions welcome, thanks!

Downloaded freedit, took 11.5 minutes to compile. Rust is reminding me of the bad old days of working with C++ ...

https://xkcd.com/303/

Ah ok thanks that's more in line with what I was expecting.

Ah thanks, I wasn't entirely sure from a brief read whether proc macros could do it or not, I will research it more, thanks.

For the Rustaceans out there, a question: I have a set of complex routines all parameterized by a const value L (the 'branching factor' of the curve tree), and that L is used to size various arrays etc. So it's specified as a const generic. Now I want the user to set this value in a config file, because depending on how many pubkeys they're processing, different L values will be appropriate. Now, to be clear, only a few possible powers of 2 are probably ever needed for L (even as few as 3; 256,512,1024 probably covers most practical scenarios, though more values would be nice), but of course, setting it in a config is incompatible with compile-time specification, as a const. What's the most sensible solution? Writing multiple versions of the calling function so the config var can choose which one to run? If so, how to do that most cleanly (macros? how?), or if not, what is another smarter way to do it?

If you're just complaining that people are pushing it as a panacea instead of working on the problems, then, sure, I mean that's just how the world is. There's always a lot of unhelpful noise. Better not to stress out I guess.

No comment on the CEO of Lightning, but the *authors* of Lightning were at at pains to point out to people multiple times in public talks in the year or two after its release, the scaling limitations it had (including specifically that it does not scale to billions).

And it still is a scaling solution, even given its limitations.

Wow, I found the approximately one other person who plays beatsaber and is a bitcoin analyst/coder :)

No coins were premined; the newspaper headline in the genesis block serves the purpose of proving that.

As to the oft-stated-as-fact 1 million, it's not a fact, it's a theory, one that was hotly debated when sergio lerner came up with it. People should be a bit more cautious about spreading it as fact, because of the danger it brings to whoever the real Satoshi is. But, people being people, it has spread everywhere.