Very interesting article, thanks!

I hadn't considered (1) (cut-through) at all, at least I don't remember discussing it, but I totally agree that it's a very substantial possible angle of usage, and has economic incentive, at least if payjoin is a regular thing. A lot of it interacts with output substitution though, something we didn't discuss much until the end of the BIP78 discussion (and it was mostly motivated by address types iirc). I was and remain leery of it; as you already saw recently, it requires a very "hardened" security model, if anything is slightly off it introduces theft vectors. Still, if people get things right, for sure this kind of flexibility achieves something. It's just more dangerous.

As for (2) it feels very 'meh' to me. Even the concept that a receiver-merchant saves something is dubious because it's just kind of "cheating" the sender. And gains very little percentage wise anyway. Meanwhile you can save overhead, too, if you just accept 100 normal payments and then do a batch send of them later. (i.e. normal non-payjoin batching).

Hmm I'm not sure whether I completely buy what I just wrote there 😆

Take this passage from the coincenter article:

"We’re still researching but to our knowledge the only control that the defendants ever had over the smart contracts was the ability to change aspects of cryptography related to Tornado Cash’s privacy features and never had any ability to actually access, move, or direct the user funds in the contract. If that technical analysis is accurate then it does not seem likely the defendants ever had the sort of “independent control” over the transmitted value that FinCEN describes in its guidance, and, accordingly it seems that this alleged activity would also not constitute unlicensed money transmission."

If the ability to update the contract exists, one naturally assumes that it means ability to update *anything*, so one can sort of claim they have custody of funds.

And then on the other hand, these updates are always going to be 100% public (even if code is obfuscated), so "in theory" people can just not send funds to it when it changes in a way they don't want.

I honestly have no idea at this point 😆

Yes I agree with what I read there, I found myself musing along similar lines: just the ability to *update* the contract shouldn't logically be interpreted as "money transmission" .. although, you could choose to.

Compare with non-blockchain software that's just an open source project - there, updates are made and users can *choose* to download and run the update, so there's even less centralized control, but it's still the same basic type of thing - the developer can at least influence, *very* strongly, what the user runs.

In other words, while we as open source bitcoin software developers can *hope* that the fine distinction between 'update the smart contract' and 'update the software' might make the latter remain legal, it's pretty thin gruel ... I would not trust that line to hold.

Hola ..?

So, I remember when we thought about it "back in the day" we sort of concluded that "well, it doesn't technically reduce the fee costs for a merchant, if they pay for their inputs in the payjoin, but it can allow them to change when they pay fees" which could end up being better for them ... the point is really tricky.

Maybe you've thought about it recently in detail (I haven't!) so you may have a more exact perspective (btw please write it down somewhere if so!).

And then there's the scenario of a non-merchant receiver (which might apply here); it might not be relevant at all, there. Now with your new scheme, that becomes a more likely scenario than it was before.

1. Look at the prices of el salvador government debt as an indicator - the economic developments are very positive, in general.

2. I've been here most of a year now and am resident, and can tell you that all the locals (let's say 90%) view Bukele mostly or entirely favourably because people aren't being murdered any more. This place now has an *extremely* low murder rate (look up the stats and how they changed in the last few years).

The Bitcoin policy is a minor part of what's happened ... that's a different story, lots of positives about it but of course it has only a limited effect on the everyday life of most people here.

Not that there's anything wrong with that position but: payjoin does do something that other coinjoins aren't doing (today): creating additional obfuscation that nobody knows happened ("steganographic"). There are other reasons to do it, perhaps, but that's the main one: a different way to break blockchain analysis and make the history of your coins even more uncertain.

Also, while you may well be paid to take part in coinjoins, bear in mind that nothing is free (e.g. if you're using maker mode in joinmarket there are several limitations, especially if you *only* use maker mode).

Yeah I'm less concerned about the NSA type threat (if they want to "do" my github account I'm sure they can), more the "uh oh because of a bug in the auth protocol or the auth app, hackers can take over accounts" or something like that.

I mean, it is *2* FA, not 1 FA, so in theory it's not that simple, I'm just thinking in very vague terms about "central points of failure" and also "complexity is the enemy of security" (people end up often looking for shortcuts if you make security policies really burdensome).

I'm not best pleased that github is going to enforce me to use 2FA in the next month or two.

Security through trusted third parties is attractive but danger is lurking within that model.

Anyway, has anyone decided to do anything other than the obvious "authenticator app on the phone"? Because I'm pretty wary of it.

This is really big, and really bad news.

The essential point seems to be that there is an argument that they *could* have exerted control. Did they actually have backdoor keys into the smart contract after they wrote and deployed it? I can't remember a clarification on that crucial point.

If they didn't, then this is even worse, because it means US LE are prepared to make *really* tortuous arguments to go after privacy software developers.

Does anyone have a contact for Tadge Dryja?

I need to send him an email (or whatever other comms works I guess).

There's a lot of flexibility in what you *can* do, but:

Wallet design, certainly every wallet you're using nowadays, strongly discourages users from re-using addresses. That means, in practice, that when you click a 'receive' button to get an address to send to, you always get a *new* address, i.e. one that hasn't been used before.

That means that in your scenario: I send 0.5 btc, twice, to my hardware wallet (and same for desktop or mobile wallets), you will almost always be sending to two different addresses. An obvious exception would be if you simply copied (or wrote down) one address, somewhere. People literally using paper wallets are tending to stick with one (this is just one, minor, reason that paper wallets are a bit frowned on).

Why does the "don't reuse addresses" concept exist? It's mainly for privacy; reusing an address makes it 100% clear that those two amounts of money are owned by the same user. There are also more subtle reasons to not reuse addresses, but that's a sidetrack.

re "one containing a bulk of the stash".

I feel like it just depends. In my own case, that's never been true, over a decade and multiple different wallets (even just talking about the cold storage wallets). First I don't tend to move a nontrivial amount in one step, I break it up. Second, usage over time (and if you use bitcoin at all, you're going to use your cold storage wallet sometimes), breaks it up further.

So I don't have any data on it, I can imagine it's true for *some* people, I'd bet it's not the majority, but 🤷‍♂️ who knows I guess.

Even if it were the majority, say 60%, that had *most* (not all) of their BTC in one address, we'd still be nowhere near "number of addresses with >1BTC = number of users with >1BTC".

It tends to very wrong "in both directions".

On the one hand, most btc holders that actually use bitcoin at all, will tend to have a lot of addresses.

On the other hand, many big operations (companies, exchanges, investment orgs) tend to aggregate large amounts into single addresses, representing funds that are actually "owned" (legally) by many customers or partners or investors.

I think the former factor is probably more significant here.

So say there are 1.5M addresses with 1BTC. That could easily be say 50000 individuals and a few 100s of orgs each of which owns between 10 and 200 BTC, each of them having 20-30 utxos. For example.

I don't think this is a "it all averages out" kind if situation. It just depends - on stuff we don't know.

How do you know we have 1 million whole coiners? If it's by number of addresses, that doesn't correlate 1 to 1 (in fact one can't know even the correlation). If it's by some kind of study, I'd love to see their methodology.

"a$$word" made me laugh more than it should have 😆

Also, while I did immediately guess it was the length that mattered, i would never have guessed that Solaris did something as ridiculous as that.

Believe it or not some of my first software engineering work was on Solaris servers back in 1999 or so. They were very common in academia and industry in the late 90s iirc.

It's an inevitable consequence of the success of such a protocol imo.

(Not "5 figures", just large. I have no idea what figure exactly).

Important to understand that in various ways, individual on-chain txs are likely to represent aggregation of many actual financial events. Lightning channel opens/closes are just the very early example of this, it will become a lot more sophisticated and layered over time.

Also the page on randomness shows that `bx help seed` shows no warning, either (I haven't checked the latest code, though):

https://github.com/libbitcoin/libbitcoin-explorer/wiki/Random-Numbers

It took a bit of digging but I believe this is the commit that introduced the use of MT19937 into libbitcoin:

https://github.com/libbitcoin/libbitcoin-system/commit/6d5a06e283d81260165e0eab95175069bf03b408

I would like to hear from Eric what was the thought process behind this.

It's widely known (and certainly was, back then) that seeding a PRNG with a mersenne twister is not cryptographically secure. In the case of 32 bit MT19937 it's even comically insecure as you can just brute force every possible seed (you can also 'play back' earlier MT output if you see enough outputs in sequence).

But, the thing is, in that commit you can see that the approach taken is to use uniform_int_distribution taken from the std library, then seed it. As far as I can tell this function is platform dependent/implementation dependent and certainly not claimed to be cryptographically secure. What is going on here? Was there never an attempt in libbitcoin to use cryptographically secure random numbers? There is probably a bit more to the story.

The potential for delusion is mostly intelligence-invariant.

More intelligence means more ability to discern illogical/crazy.

More intelligence *also* means more ingenuity in rationalizing crazy.

The vague term 'wisdom' is the probably the best one English has to describe people who have any immunity to delusion. It's frighteningly uncommon imo.

(If you don't like 'crazy ', think 'highly unbalanced or unrealistic points of view')