I realise you're not a lawyer but, any sense of how this judgement might have the potential to affect other judgements in the EU (or even perhaps outside it)?

This is the response I'm wondering about, i.e. is this perspective the reason we don't hear much about it? Algos can be user chosen so that argument has always seemed dumb.

I used to use mastodon and the developer had a similar reason for not having algos. I think it's incoherent and stupid. Time ordering is an algorithm, just an extremely simple one.

It's totally different in a FOSS scenario.

Is anyone working on algorithms for feeds on here?

It just seems so obvious that this is one of the two things that will determine whether nostr *as social media* (sure it can be other things) is going to achieve any scale ... but I never see anyone talking about developing this?

The other is scaling, but that's a very vague thought, I have no idea what the issues or solutions around running a relay are (except, paying for service with LN is great).

https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf

New paper from some Monero researchers (really new it seems - update date is last week!), in which they're proposing to use CurveTrees (the same construct I put into aut-ct as per my recent work) to get much larger anonymity sets (and I do mean *much larger*, from like 10ish to 100000000!).

One very notable thing (to me) is that the very easy and natural secp/secq 2-cycle (you realistically need a 2 cycle of curves for CurveTrees), has to be replaced with something more complex, because their DJB ed25519 curve has a cofactor of 8 (yet again non prime order curve biting them on the ass, lol).

Another interesting tidbit is that they propose to use Liam Eagan's recent work https://eprint.iacr.org/2022/596  (posted almost contemporaneously with Curve Trees); I remember Andrew Poelstra pointing me at this work in '22 and I said to him "I don't understand this" and he responded "yeah it was difficult so I got Liam to come round to my house and explain it" 😁 .. so yeah i'm sure some people can follow the ideas there but I am alas not yet one of them :)

They've also done a review of the generalized bulletproofs construction that Kamp et al used in their CurveTrees implementation: https://github.com/cypherstack/generalized-bulletproofs

Also interesting is that they talk about acheiving a "forward secrecy" property here, which linkable ring signatures can't have, by design: if a future ECDL breaker is found, it can always see the trace of payments in prior Monero because the linking tag reveals the private key if you can crack ECDLP. I'm not sure how this works but I believe it's to do with the Liam Eagan research just mentioned.

Finally, the extremely esoteric and dense mathematical concepts aside, it's worth mention a 1000 ft view: this proposal ditches ring signatures (and somehow they get backwards compatibility for the historical chain, though I absolutely don't understand that yet), and goes to a full ZKP proving system (bulletproofs arithmetic circuits) for full anon set. I can't help wondering if this direction makes sense - if we look at Zcash, they do the same thing, but using bilinear pairings they can get far more performant proof, proof size and verification stats, I believe (but, curvetrees can be very efficient so I'm not 100% sure about the details here). Ring sigs, as I've observed elsewhere, even with the fanciest algorithms, never quite cut it at the verification step to be able to support huge anonymity sets. If you're going to ditch them, you may just as well go with a Zcash style design, no?

There's a little blurb on the CT website about how you can run your own nodes.

No idea how it all works in practice. I guess it's like a signet and they just never roll back?

Whilst the idea of a 'private' blockchain is *almost* ridiculous, and a non-sequitur, it isn't quite; google introduced Certificate Transparency about a decade ago, and from my limited understanding, it is a pretty useful construct, as it allows key revocations/updates to be propagated much more efficiently.

You don't have to call it a 'blockchain' but it's a very similar design/protocol.

As CT descriptions make clear (see certificate.transparency.dev ), there should be some element of distributedness, though, for that construct to have value. I don't know if or how that applies to protonmail. Without that, you can still have non-repudiable update and public transparency, but it's harder to see much value. A bit tricky.

Yep, that's kind of why I wrote my comment - it really is different. What you did (maybe?), i.e. scrambling but keeping endpoints the same, doesn't get quicker, i.e. we don't learn how to read it, we just ... can. Arguably it's a more interesting phenomenon.

Over the years I've come to realize that my intuition is a lot smarter than I am.

Sometimes I spend hours bumbling around making 100 mistakes before I can finally understand *why* a thing is true, even though I "knew" it "in my gut" at the start.

(Disclaimer: I take no responsibility for any drastic mistakes you make following your gut reactions)

Displaying datasets in time order is an algorithm... just a very simple one :)

Excellent, pretty sure the reason people find it easy is because our brains develop extremely powerful font 'decoders' from a pretty early stage of reading, from being exposed to so many different writing styles (both printed fonts and handwriting, though the latter is much less true nowadays).

Thanks, and in the spirit of doing something useful and not only complaining, I opened an issue on your coinjoin-workshop repo to get a bit more into the weeds of how blame would work for that kind of protocol.. well, 'useful' might not be the right word but anyway ;)

'Tweet' was always a cringe-inducingly stupid verb; you just got used to it.

'Notes' is pretty good, admittedly it's a bit bland and generic, but it's fine; 'nostr' is already distinctive enough and it ties into that.

Just thank your lucky stars you didn't get into mastodon because they tried to popularize 'toot' 😄

Listening right now. Incredible stuff.

So I searched 'joinmarket' on birdsite and found some interesting discussions.

nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s I want to take issue with something you wrote: "In contrast, the coordinators in samourai/wasabi/joinmarket interact with the other users, creating/sharing psbts, validating info, kicking trolls out, and taking fees".

Note that (and this is common to other of your posts there) you're referring to Joinmarket as a protocol with a coordinator, because the taker is the coordinator for each coinjoin that it wants to do; but please realize that almost every person reading this will not grok the subtlety. To them a coordinator is a static coordinator. Also you say at the end "taking fees" and this is *in no possible way* a correct description of Joinmarket, since even if you treat the taker as "one time coordinator" (correct), they pay fees, they do not take them. Considering the sensitivity of this issue I *really* don't think it's OK to write that, since it's not true.

The whole paragraph *strongly* suggests that Joinmarket uses the same model as the other two, whereas in fact it's almost purely p2p, especially in the recent structure where directory nodes act only as name servers essentially, and peers then negotiate coinjoins over their own ephemeral onion services.

(Taker/maker is not a static role and in fact it's good for people to switch between them).

I suppose you're more talking about people moving to JM from the other system ... I guess mostly I agree, then (though obviously we'll never get any data on that).

The only public attempt to measure coinjoin volumes showed, for years, the number of btc going through joinmarket to be much higher than Samourai and Wasabi combined. Now, I think that statistic is misleading (also that website stopped reporting a couple years back) but, bear that in mind - unless you have concrete data you shouldn't be too sure.

Actually both that example, as well as the xkcd posted here, remind me of the really big problem - the bar you try to set very high for signing a key, resulting in keys just ... not getting signed. Still, all the same ...

It's rare that someone posts something on the internet that actually embarrasses me, so congrats on that, 😄

But WoT exists in gpg? It isn't very widely used, in practice, but it has to at least be mentioned that it does work.

... In what sense might nostr combined with WoT fix it? Because a lot more people will have keypairs I guess?

Timothy May's writings are so much better than Eric Hughes' 'cypherpunk manifesto' imho.

I'm not sure about blame on round 3 though, would need to think more about it.

Yep, you are describing there a "blame" protocol pretty similar to what happens in coinshuffle. Basically an "open the commitment" thing. The most crucial element is as described both in coinshuffle and in your protocol.: say 10 participants, the blame kicks out the bad behaviour and the remaining 9 continue, etc. I think a linkable ring sig makes a lot of sense though, as it cleans up one form of delay of the process. To note: there is another nuance in ring sig design that's relevant (I discussed it in https://reyify.com/blog/ring-signatures#culpability-exculpability-and-claimability ; it's the idea of "exculpability". Some versions of ring sig have a property that, if you reveal the private key, you still do not reveal whether it was *your* private key that signed; in your description, you would need the type that do not have that (so "culpability"). The LWW LSAG, Back-LSAG and MLSAG types are indeed "culpable" so you're probably OK just with that, but: if you have linkability, I don't *think* you even need culpability.

It's a proof of concept website for the cryptographic protocol described; I'm not trying to start a new popular discussion forum 😄

I've previously suggested it for nostr, so the question may *eventually* be the opposite - why aren't nostr relays using this protocol?

https://hodlboard.org

To sign up for writing on the forum, you need to prove current ownership of one utxo (which you do not reveal; zkp) of taproot type of value 500K sats or more.

Instructions on how to do it linked from that main page. It's a bit fiddly but not difficult if you have tech experience. You can use Sparrow for accessing the coins after creating the ZKP of ownership, or you can use Core.

(Also it *should* be easy, not 'fiddly' but wallets don't support accessing private keys).

Despite the 'hodl' name, the coins are not locked after you make the proof, you can spend them immediately.

General background reading, first half of https://reyify.com/riddle

The anonymity set is about 200-300K utxos, but the server can verify your proof ~immediately!

The proving tool is at https://github.com/AdamISZ/aut-ct ; follow installation instructions on readme or choose binary release for macos or linux.

Still a WIP. Keep a copy of the private key until you spend it! Bear in mind the keyset updates once per 24 hours. Make sure your utxo was confirmed before the blockheight of the current keyset in /keysets.

Not like breaking news, but:

Utxo set now up to 180 million, and I think more than 12GB. Was 160 million about a month ago.

At what point do small nodes just keel over I wonder.

There is no official website. I hope there will never be one, either.

Unsurprisingly, the attack site joinmarket DOT net is succeeding in stealing people's funds (at least one person reported having their wallet swept).

Reported it to Google literally years ago (me and one or two others at least).

Nothing happened. Any ideas or actions welcome.

You need to have not only nothing to hide, but also nothing to defend - or, absolute power - for privacy to not be helpful. This applies to absolutely no humans whatsoever, with the exception of mystics/saints who own nothing and do not fear physical threats.

(Even then i am ignoring normal societal taboos like sexual organs and defecation etc. not being exposed in public, but that's very minor by comparison)

No, haven't heard it. What are the other 2?

There is such a project. https://joinstr.xyz/ ... though i haven't kept up to date with exactly how it's evolving.

In case people were curious about SNICKER but it wasn't easily discoverable:

https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79

I have this vague memory that Adam Back had ideas about that many years ago, but it was more about avoiding miner censorship of transactions, not about coinjoin.