I've been living there since the last conference :) also was at the first one.

I'm going to give a short talk (and even a little practical demonstration) of PathCoin. Later hopefully a more tech deep dive side session. Looking forward to it.

nostr:nevent1qqszvyry7qjwjasyw9l793r27208fx3vjc525ztxzxjhd3acaythjzgpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c33weskgcmxd3hrgat8wsexswtjw4mhxathw56hvaf4v9kng7rpddsnwurhxeknwctc0ymnjct30958qdn4x4cnj6mww46nw0mzwfhkzerrv9ehg0t5wf6k2q3qad0ptuzte83alpkpqqctvewlaqj5zq23c83m82xw8apg4t6zlynsxpqqqqqqz26rsla

Hope you're enjoying x-only keys as much as everyone else ;)

I haven't read his blog in a while so thanks for the heads up!

I guess if Jerry managed to backdoor the SEC curve parameters then he kinda really *did* deserve a raise:

https://saweis.net/posts/nist-curve-seed-origins.html

Sadly Jerry died earlier this year so we'll never know.

Also, hot take, cofactors are already backdoors, sorry DJB fans.

It's a good question but if people can do something without losing a lot of money quickly, they will do that thing :)

Doh sorry I meant "Samourai and Wasabi" 🤦‍♂️

My best guess about their logic, assuming they didn't just completely misunderstand the systems, is this:

With a chaumian blinding server, you have a situation where none of the N participants know the linkages, and nor does the server. So from a privacy perspective this is decentralized, no one actor is privileged.

However even if you look at it as an academic and not a practicioner, you should see that having a central server coordinating the transaction is a very important centralization, because they can select, and control, which participants are allowed to be in what join event. (*very* relevant for e.g. sybil concerns).

So in short I agree with your question 😄

I'm still blown away by the 2021 paper ( https://arxiv.org/pdf/2109.10229.pdf ), updated twice, about decentralized coinjoin, that states, to explain that it only studies Samourai and Whirlpool:

"While the role of centralized mixing services like JoinMarket, where a trusted third party matches CoinJoin participants, has been studied in the past [ 16], decentralized wallet implementations have not yet been the focus of a comprehensive measurement study."

(It takes extreme, tortuous logic to come to the conclusion that Joinmarket is centralized, but somehow this howling error remains).

More recently this came out, a new paper on address clustering:

https://arxiv.org/pdf/2107.05749.pdf

I haven't read it yet, so it may be very interesting or not at all, fair warning, but the researchers are pretty serious.

However I find this comment of interest:

" Our extraction mechanism relies on change outputs revealed by the multi-input heuristic. This heuristic is effective in practice [15] and widely used, but vulnerable to false positives from techniques like CoinJoin and PayJoin that are intentionally designed to break the heuristic (e.g., [9, 23, 24, 26]). While we take measures to detect CoinJoin transactions and pre-existing cluster collapse, some errors can remain."

Notice how they completely fail to inform the reader of the *crucial*, in this context, difference between traditional coinjoin and payjoin: with payjoin, they will not (in the general case) have *any* way to know it has happened, and therefore not have *any way* to measure whether such a measurement error has occurred, whereas with traditional coinjoin this is emphatically not the case. Disappointing; I hate it when academics gloss over the failures of their method.

I think this was before the 'genius' Mersenne twister addition 😆

It seems there has been some pretty serious impact on their user experience from reading around on their forums, and it's quite multifaceted... they revamped their fee rules in a messy way. And look up 'zcash sandblasting attack' for some interesting stuff.

Hello sir

https://blockchair.com/zcash/charts/blockchain-size

The spam attack on the zcash blockchain looks to be finally slowing down after an entire year. Settling at around 260GB after rising from around 30GB.

I'd be curious to know the real performance implications in terms of syncing and steady state running. 250GB zcash is not the same as 250GB bitcoin.

The reason for their flat fees (part of why the spam happened I believe) is also interesting.

How can i zap negative sats?

Also please tell me I'm wrong, but did they really never spend anything out of their 3 of 5 multisig donation address, after the one test tx they did back in 2013?!

Over 7.35 BTC still sitting there a decade later. Maybe they just lost the keys? 🤦

Somehow got sidetracked into the old darkwallet thread on bitcointalk.

It's full of absolute gold like this :

https://bitcointalk.org/index.php?topic=322328.msg3460051#msg3460051

The drama of those days was priceless. 😄

I'm in the process of trying to code up a toy PathCoin prototype

https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da

No trivial endeavour, even a toy version, but, here's something I realized while doing it: if you have a path A->B->C->D->E, then having B pay D instead of C is pretty feasible, and in quite an elegant way: C runs an external (e.g. in the cloud) service that stores the data that she *would* send to D, if she was paying D. This would be, basically, all of her partial signatures on D's spending path and E's spending path (i.e. further down the line), plus, the adaptor signature on her own spending path, that allows D to claim the penalty if she cheats. (sorry for short version, but you have to read the gist really).

Now, that clump of data she could store in the cloud, *encrypted* to B's key. If B requests to access the encrypted blob, her cloud server sends her a message "this pathcoin is no longer spendable" and she basically deletes it all (she never had it), while B can take that data, decrypt it and send it to D without further interaction.

This way you can hop steps in the path with basically zero interaction, and certainly no signing interaction. (I mused a bit about this in the gist comments, but this is a concrete explanation).

The nice thing is it's very safe to store that data, the only danger is if C somehow doesn't know that B accessed it, then tried to spend the coin after receiving from B, and revealed the adaptor secret, so B could claim C's fidelity bond. But that seems pretty simple to avoid.

Hope that helps the ~ 1-2 people who find this interesting, lol.

The answer to my question is probably related to why you're wrong there: the paper's first reference is to an ETH research blog post about optimistic rollups. Arbitrum is just one of the two popular implementations of that, I'd forgotten.

The main idea is to use challenge-response as fraud proofs.

Yeah I'm being dumb though, the user can always actually specify with op_true etc. It would be pretty weird if they didn't know...

I see, I'd just reached the point of realizing that, but then the fact that IF needs externally provided input for choosing a branch doesn't quute fit.

Concretely i want "key a and cltv OR key b and ctv"; I'm now thinking, i should just use two tapleaves and then it's easy :)

Question for any Bitcoin Script-ers out there:

Taking op codes like OP_CLTV or the proposed OP_CTV, how could you combine them with other conditions in logical OR (using OP_BOOLOR or otherwise)?

I ask because if they evaluate to False, they terminate execution of the script with failure, immediately, right.

More than a little interesting.

I'm surprised they don't reference Arbitrum, it seems like the same paradigm.

I remember thinking along the same lines, but it's great to see people are actually trying to do it (or at least, make a start!)

h/t Bitcoin Optech, this article discusses improving LN privacy by splitting payments into smaller pieces (there are several ways to do it, as explained in another back-referenced blog), in a channel.

https://www.gijsvandam.nl/post/the-effect-of-multi-part-payments-on-the-balance-disovery-attack/

Very interesting ideas, analogous to what is seen e.g. in Joinmarket tumbler and several other financial privacy ideas: by splitting a payment into several pieces you obfuscate the size of the payment and mix it with others.

In the absence of a clean solution to snooping attacks like the 'balance discovery attack' - which means, actually imposing a cost to use the network in a way that makes probing too expensive if it's excessive- this might be the best you can do. It will never be perfect, the defence is mostly 'computational', as the author notes here.