FWIW there have been a number of thoughts over the years in this general area. I came up with SNICKER in 2017, there's a draft BIP on my gist (AdamISZ), not sure why it was never assigned a number. I actually even implemented it in Joinmarket and the code is still there. SNICKER was the simplest way you could do a coinjoin non-interactively (post encrypted proposals, encrypted to an onchain address pubkey; works better with taproot but can work anyway), this way proposer puts the encrypted blob on a bulletin board half-signed and the receiver can decrypt and broadcast it if they choose. Realistically only 2 party so a very limited model but imho still interesting.

Earlier than that people had ideas around SIGHASH_SINGLE|ACP ... but then always gave up on that because of the index/positioning limitations of *SINGLE.

Somewhat later in 2018 a group of us in London brainstormed around ideas like "stuff floats in the mempool and gets coordinated, perhaps with miner involvement" but it hasn't got anywhere yet. In that same meeting we came up with payjoin (well that was my name; others called in P2endpoint, which is a slightly different idea), not actually novel but just tried to pin down more exactly how it could work. that is also in Joinmarket btw, as well as btcpayserver. Nowadays Dan Gould has worked on a different aspect/version of that idea, which is great. But I still like SNICKER's pure non-interactivity.

When it comes to your thoughts around covenants, I agree. I tried to make case in the last Adopting Bitcoin that we need to understand that that extra bit of power in scripting is going to be needed to make actual steps forward in scalability and privacy, in other words it's not because we want evm style smart contracting, it's because we want bitcoin to actually work as money, and that means it needs both scale and privacy, which will come from offchain contracting (though a little onchain contracting, coinjoin style, will imo always be needed too, for larger entities).

So yeah being able to constrain spending destinations as a way to reduce the coordination requirement of a coinjoin is quite a neat thought, i don't remember offhand if anyone has pursued that yet; it's probably not simple!

Lastly I'd say nothingmuch has been having some of the most interesting ideas about coinjoin coordination recently, but not sure if he's active here nowadays.

He said 18000 not 1800. But still i think that number is way lower than the real one.

'Zerolink' - to me, Coinjoin is not in the same category of protocols as zero knowledge proofs, as that name is trying to suggest.

You can make structures with guaranteed properties in isolation, sure, but taking the context into account it's not so simple what they actually achieve.

But anyway I defer you to the 20 or 30 talks and podcasts and blogs I've done on these topics. People generally aren't that interested in nuanced takes though, they want strong and clear answers, I don't have them.

Saw a discussion about this on twatter so I'll mention it here:

There is a hilariously old PR on joinmarket-clientserver to add a feature to let takers split their change to match makers' change, when possible. You could think of it as babby's first multi denomination coinjoin.

One of the main reasons I created that PR is that the patch is isolated to *one* source file - "taker.py", and that makers already support this or any other way the taker wants to modify the coinjoin template; as long as they see their own outputs, they don't care about anything else.

That's not what prevented it in the past.

Given the recent Stirlingov case, I guess we have to hope on Roger's behalf that that's not true, because apparently a defendant has no right to question, or even *see* such 'evidence'.

I've seen people saying "lol, obviously" in response to the Roger Ver news.

It wasn't obvious to me.

The guy went through the absurdly unpleasant/ expensive process (from what I've heard) of renouncing citizenship 10 years ago, part of his reason was (afaik) to avoid the worldwide taxation imposed on US citizens. IIRC he principally lived in Japan during all those years. And to state the obvious, he was already *very* rich by 2014, even during that bear market.

Given that he went through that exit tax process, how much sense would it have made to forge and defraud in his filings. Maybe it's just me, but I would have bent over backwards to do everything 100% by the book so I could finally put this behind me. Say you lose 20 or 30% at that point ... it's clearly worth it if you're that rich, and you've gone that far down the road.

Maybe he acted stupidly or sneakily, I'm not discounting it, but I would not take the US 3 letter agencies at their word here; just look at the modus operandi of the SEC as an example - "you didn't follow the rules" - "but we hired a lawyer and there were no clearly written rules" - "lol you got it wrong, your pet gerbil is a security" etc.

Oh wow good point, indeed remarkable. Knew about Rodriguez but didn't know CZ was bc.i

This vid is from several months back, before the election.

Roger Ver renounced his US citizenship (at great expense) a decade ago, an interesting aspect of this case ...

I had the same gut reaction. It may at least be possible, if extremely difficult, to get past the need for good repute ... LN penalty not ideal here, clearly.

Comment to nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm on his article about one-shot RBF:

Section 2, rule 2 and 3: while it is entirely logical that part of the ruleset is some measurement of expectation of confirmation of the replacement, I'm wondering, is there a fly in the ointment as mentioned several other places in the article: you are here referring to *the* mempool, which can only be the local node's mempool. Since almost none of those mempools are the mempool of the node that mines the next block, could that cause a problem? (Ironically, censorship such as seen in Knots/Ocean's policy (i.e. actually meaningful censorship of economically significant transactions) might mean that a node sees N=1 when in "real life" it's more like N=20 depth for "the" uncensored mempool).

I'm guessing the answer is "no, not a problem" because from a local perspective, one-shottedness is achieved, and it's only locally that you need/want that?

Hmm, anyway, I actually do kind of like the one-shot idea; as you pontificate near the end, it's debatable whether the multi-shot behaviour of the simplest possible rule (x% higher fee rate) is really a problem or not, but it's nice to remove it.

https://petertodd.org/2024/one-shot-replace-by-fee-rate#fnref:mempool-consensus

You definitely have a point but, on the last one, it's hard to see a scenario where a state would capture him/her and not advertise it.

The point made by JoeCarlasare (quoted tweet) in this article is very interesting. It might apply to TornadoCash (I haven't tried to think it through) but it definitely doesn't apply to Samourai. Users emphatically do not lose control during th 'mixing' process.

nostr:nevent1qqsx3h8wr7pesmcmdds0hfaj5xtt83km52yml529ys4d6uhf3zv8rlgpzpmhxue69uhkummnw3ezuamfdejsyg9e55m4ywa69lx6aptajrv2wcx7fusnnj0epkvx7aruulgwcrgh85psgqqqqqqs6tr8yh

well but you'd have to define what you mean by 'completely centralized'? 40% or 50% one pool for example? i don't think that's 'completely', but anyway: even if we agree on an unambiguous definition, how do we measure it? maybe we successfully measure it and then they get cleverer about hiding it (which arguably already happened, as you have outlined). If we go by transaction censorship, this seems to be relatively new (last few years?), and it's not a great way of measuring either ...

re: 'has to come from somewhere', yeah. my point was that as it stands, that comes from nation states. to have it come from "the bitcoin community" (which doesn't really exist) seems kinda hard, especially now that bitcoin is a lot bigger than a decade ago.

I don't see it as 'this is all fine', just I think the potential 'oscillation' dynamic is probably pretty important.

To this day the best marketing in Bitcoin. Nothing coming out of big companies with huge budgets came within a million miles of this.

Well, it's arguable, as i said - but the CCP *did* ban mining in China (what year i forget, somewhere between '18 and '21) which led to a huge physical outflow of ASICs to other countries.  When you say 'they have half the hashing power' you're talking about antpool and bitmain as entities right? It's definitely a lot more than a nuance as to whether they have that hash power pointing at a pool controlled by those entities, vs. actually having that hash power under their own control, and inside China or out.

Right, good point ... if the state doesn't do our dirty work for us ("firing" some miners from time to time), we might have to do it ourselves!

The ghash case was interesting, but people over-interpreted it as "oh the market will just correct if anyone hits 50%". clearly not true.

The deeper point: bitcoin is an intrinsically identity-less system, and this means that it will always be fundamentally *impossible* to measure mining centralization occurring, with certainty. The recent example of coinbase tx consolidation just illustrates that it's a matter of luck, or bad opsec, if we do "measure" it. And this means we can only really have arguments about the *effects* of centralization - most specifically transaction inclusion. This limitation will apply to the community trying to 'police' centralization just as it applies to the state trying to leverage centralization.

Voskuil's old take on this should always be borne in mind (with a little of my spin):

The strong natural tendency of bitcoin mining, in a vacuum, is towards centralization. However, since Bitcoin is a threat to the state, the natural tendency of the state is to attack Bitcoin's functioning, which is only really possible if there *is* centralization.

This leads to a possibility of a kind of oscillation, *perhaps* around an equilibrium: very centralized mining gets attacked, then it becomes more fragmented and decentralization, and then it loops.

It is not unreasonable to say that this already happened in China last decade.

nostr:nevent1qqsf8rjf9aep8jqmdh62tazanxzzg5gcqegyr2r03fdm9809ffta6sqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpa9eg4pp5elx8s727mu7j9keeudpl7vss0geku99kepwgg65w4jspsgqqqqqqsdw7qw5

My relays/amethyst can't see that event.

Probably being dense, what do you mean by 'deterministic code' there? Reproducible builds? Bip32 and descendants?

There is actually something new in this statement from the FBI:

https://bitcoinmagazine.com/markets/fbi-warns-americans-against-using-non-kyc-crypto-money-transmitting-services

If you actually read the second and third paragraphs, they are quite explicitly telling you that the primary risk is that *they themselves* are going to steal your money.

So by 'something new' I mean that this is the first time you are explicitly being threatened with confiscation. It would not be surprising if this is the start of a trend, but, who knows.

Good question independent of the facts :) pay to *write* certainly solves it (i didn't know that exists; I only have pay to use), but it does imply a lot more cost and potential privacy loss.

On my global feed I see an endless stream of 'hello world' notes frim afaict an endless stream of newly created accounts.

It's almost as if we need a privacy preserving form of Sybil resistance in the form of proving your account is backed by a small utxo without revealing it .... or something :)

I was recently trying to remember something about lightning: how "LN penalty", the current mechanism, makes multiparty channels not work. This is what I came up with:

Suppose A B C are in a multiparty channel and each hold commitment transactions of the normal form: output 1: to remote X, output 2: (to local Y after time delay, to revoc. secret Y immediately). The obvious problem is, "to revocation secret" - *whose* revocation secret? Obviously "Alice gives revocation secret to Bob and Charlie" makes no sense; then they're competing over the punishment funds.

A little thought and you might come up with "split it equally". So the idea there would be, instead of "to me after delay OR to to them with revocation secret", change it to "to me after delay OR to a multisig script for A and B and C with revoc. secret" and, to revoke old state, as well as sending revoc. secret, sign a payout, from that script, to B and C with a 50/50 split. Setting aside a counterparty going offline, this is still terrible: imagine Alice tries to revert from having 0% of balance to having 100%, then the punishment gives 50% to B and 50% to C. But if Bob was colluding with Alice, Alice now has e.g. 25% (half of Bob's share of the punishment). I'm deliberately glossing over how the B and C balances were at the time of the contract breach, because even this is enough to see that it plainly doesn't work to just say "split the punishment between the honest parties".

This is why both covenants and sighash_noinput ideas are powerful: they can push state forwards, i.e. "enforce a contract" rather than "take corrective action when a contract is broken".

The latter requires *justice*, which is to say, it requires apportioning blame (if A breached, A is clearly to blame, but that doesn't mean B and C aren't!). The former does not; at least, if the contract is well written.

Indeed it is imo underpriced by general nonprofessional users. If we had better more visible metrics of how the market is pricing liquidity it might help, but it seems hard to aggregate the data that exists.

IIRC that's what bitcoin did from as long ago as I remember, and I'd doubt it was the first software project to do it?

"Money laundering" is financial thoughtcrime.

This argument "lol, the USD is way more used for money laundering" is terrible.

If bitcoin is good money, criminals will use it.

Not disagreeing but there is a long history of renting from the state, in the UK - 'council housing'.