Thanks for publicizing these projects. It's actually quite mind-opening seeing how people are putting these lego pieces together.

Thanks. One detail worth considering, is the spillover effect this message has on customers in their *other* bitcoin usage. They will be given the impression that disabling RBF is a requirement for safety, and dissuaded from its true economic value to them as a user.

Bitrefill's "yellow box" if you send with "rbf enabled":

"The transaction you sent has Replace By Fee (RBF) enabled.

This means that we need to wait for one on-chain confirmation of this order. Consider turning RBF off for 0-confirmation processing in the future."

Nothing but respect for the several excellent bitrefill people I have met over the years, but ... I would politely suggest that bitrefill considers facing reality, instead of me "considering turning rbf off", as if that actually changes the security model.

(To be clear I am not grumpy-posting because this bothers me or affects me in any way. I don't act in a way where it matters to me).

That behaviour in itself is expected, and doesn't reduce the privacy (well, not in any obvious way). You could weirdly argue it's *better* - because, the idea of me signing 1 of 10 (e.g.) would be "that could be any one of those 10 utxo owners", which is even more true if *all* of the utxo owners make such a signature ... it's a debatable point, but you want in an ideal world, that the behaviour of all the utxo owners is similar. For example, they all spend the utxo after the same amount of time (this is of course ridiculous, so the best you can do is "the rules of usage don't preclude spending at any time, therefore spending at any time doesn't leak information about the owner").

I'm sorry that my description didn't cover much detail, I explained the thinking behind *why* you'd want to make these kind of signatures in my blog post "RIDDLE".

Thanks, I'll check it out

Yep, the idea is to have some kind of filter that people agree on.

For example: I own one of all the utxos that were created between block 750000 and 800000, and whose size is at least 0.1 btc. That number is probably not too large, and doing it this way you can get big anonymity sets without too much inconvenience to anyone.

It is pretty tricky practically, but it is clearly possible.

Josie,

thanks for the detailed answer!

So it seems my question was just out of date.

Because I can see now that in the *latest* binary distribution, indeed a full commented bitcoin.conf is right there at the top level of the directory tree.

It wasn't there in v0.21 but it is there in v24+ so it must have changed in between.

So what we have now is exactly how I expected it to be.

I agree that auto-generation from a website isn't great.

Bitcoin Core question:

Am I missing something here, or?

There is no longer a static example bitcoin.conf, so you have to generate it dynamically using a script (contrib/devtools/gen-bitcoin-conf.sh), but that script is not part of the binary distribution? (right?)

And there isn't documentation listing the meaning of all the configuration options to put into the file (which is what you get by running the above script, I believe)? (maybe I'm wrong? my searching is drawing a blank). As an example of that, see this:

https://github.com/MrChrisJ/fullnode/blob/master/Setup_Guides/bitcoin.conf

.. but that's very old, and obv it's better to be able to create your own.

It used to be the case a long time ago that running bitcoind would autogenerate a bitcoin.conf, but that's no longer true either.

How does someone running bitcoind from the binary distribution, figure out how to set config options?

Eh?

"bogosize" : n, (numeric) A meaningless metric for UTXO set size

(part of the help for the RPC `gettxoutsetinfo`)

I've just run it and it does indeed return this stat. What is it?

Interesting comment from Rogaway on clipart in cryptography presentations:

"There is a long tradition of cutesiness in our field.

People spin fun and fanciful stories. Protocol participants are a caricatured Alice and Bob. Adversaries are little devils, complete with horns and a pitchfork. Some crypto talks are so packed with clip-art you can hardly find the content. I have never liked this, but, after the Snowden revelations, it started to vex me like never before."

Reminds me of the magical internet money wizard. I was the grumpy old git back in the day who complained that this was a dreadful meme, and I still stand by it. It conveys literally the exact opposite of what you should convey to curious newcomers about Bitcoin imo. Literally nobody agreed with me though 😆

Remember kids, in the Schnorr family of signatures nonces are *fragile* not robust. Bias them by a few bits and you're in serious danger to lattice attacks. Generating them with an algo where half the bits are public knowledge could be considered ... inadvisable 😆

https://eprint.iacr.org/2023/841.pdf

zerosync.org/zerosync.pdf

Interesting state of play update on this zerosync project.

The most important high-level idea to understand here is: the proofs created here are fixed length, and very cheap to verify, independent of how much history you prove. This mindblowing feat is accomplished (without trusted setup, mind you!) at a cost: the computation required to actually *create* the proof is enormous. It's easy to see why that tradeoff is particularly attractive for initial sync of a bitcoin node - the history is a single, global (very big) thing.

Their current code apparently takes 3.5 hours for 3K transactions (i.e. approx 1 block), so they are very far from breakeven (10 minutes per block). Also there are other big limitations still: they haven't yet done segwit, let alone taproot (so can only look at pre-2017), and they haven't implemented witness validation, so can only do a `assumevalid` type of initial sync. They are relying on utreexo but that itself is not much of a limitation.

As much as that list of limitations might seem comical, this feels to me like the start of a slow paradigm shift.

The final section of the paper talks about a rather speculative but fascinating `zkCoins` protocol that is arguing for a much more powerful version of token exchange in a client-side validation model (they claim it's better than existing RGB/Taro stuff and I'm inclined to believe them though of course it doesn't actually exist yet!).

Minting would need either federatiion, or on-chain snark verifying for proper two-way peg, or burning btc (I'd argue perhaps locking, also could do the trick - time value of money etc).

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 😆

Hi, trying to get to grips with this now, a couple of questions:

first, why "Chaum-Pedersen commitment"? It's not a commitment scheme right, it's a proof (I think it's usually called, if not just DLEQ, then Chaum-Pedersen protocol. In Boneh and Shoup they introduce it as a proof of DH-triple-ness (I think we kind of half-discussed that in Telegram, I forget)).

Second, I'm kind of forgetting about a lot of the details of this Wagner scheme (that is now in cashu). The *first* DLEQ was part of the original description right? And the idea was somehow to let the user be confident that the token was valid or something? Even though they have to trust the issuer anyway?

So your second one is 'a publically verifiable proof that the token was signed by Bob without breaking unlinkability', and that's what you're asking for review about.

At first glance, I don't see how you're claiming unlinkability 'if Carol is secretly Bob'? Because Alice has to specify to Bob, the "C" and "Y" values (else he can't actually create the DLEQ, right?), so of course in presenting the tuple containing C, she reveals the link? Probably I missed something.

In general i think it's a good idea to be precise on both the inputs and outputs of the algorithm; in the case of this doc, you didn't for example write out the output tuple produced by Bob as the DLEQ (but also maybe specify sub-steps for actual clarity, what is known at the start, what is communicated etc.).

Yes, in my case it may just be that my node is not currently routeable-to ... I've not paid attention to it for a while.

Interesting, yes.

Hopefully the momentum for dual funding will grow as that will be a big part of payjoin making more sense to people (obviously there are various flavours of ideas that overlap, even splicing as well, but my point is mainly that it's in the LN related niche that this will find its best home, straightforward payments were always a tough sell to merchants so user wallets never got that enthused).

(Side note, but curious as to why JM has a random reddit link instead of the 0.7 release notes or the Payjoin docs in the repo? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/PAYJOIN.md

It was bad enough having to wait literally 2 years for Luke, or whoever it was, to merge the fact that JM supported payjoin in BIP78 references 😆 despite the fact that it was implemented straight away (also we had another version of payjoin originally that was custom, before bip78).)

Published an analysis of the security of signature adaptors.

https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf

It's going to be too dry for most, plus it's currently unreviewed, but a TLDR: the most important application of adaptors is essentially the 'coinswap' primitive where you atomicize two transactions with the same adaptor secret `t`. There's been some interesting previous work on adaptor security (Aumayr, Fournier), but I don't think they really addressed this scenario, so that's what I tried to do (specifically, trying to construct a reduction to ECDLP). As well as noting some other things that are maybe well known but not really written down anywhere.

PRs welcome!

The most recent Arthur Hayes blog post on 'exit liquidity' struck me as very insightful.

https://hackernoon.com/exit-liquidity

I think he characterises well what's happened over the last 3 decades (in particular how 'financial repression' in China and Asia generally was perhaps the key dynamic driving economics in the West), and his assessment of exactly what 'de-dollarization' might look like (including what already happened) looks about right to me.

This case is truly ridiculous. I remember doing "crack the (MT19937) Mersenne twister" as a cryptography 101 exercise 10 years ago - and it was a very old attack back then! Unforgivable, showing that whoever's in charge doesn't give a fuck about security (they didn't have to know it, they could have asked literally anyone with specialist knowledge). This is the problem with business types focused on marketing. Taking that attitude w.r.t. bearer instruments is a never ending category error, it seems.

Ah vultr yeah i have one box with them, for some reason.. forgot about it . Maybe I've been using dirty fiat there, lol