This is a 4 minute vid demo-ing how to verify the 'private proof of assets' using a desktop app. See https://reyify.com/blog/privacy-preserving-proof-of-taproot-assets for details and links.

https://video.nostr.build/8893d5a569ebec61c4cbbde491882159d9fda0ef35dc99cb78455c17033cd698.mp4

Definitely not my area but after a bit of reading it seems like this blog post does a really good job of explaining the pretty complex reasoning behind the double ratchet (used to be 'axolotl') setup:

https://signal.org/blog/advanced-ratcheting/

It seems like they're trying to address the difficulties of *asynchronous* messaging (users often offline for a while), as well as both forward and 'backwards' secrecy.

No, there are several variants of ecash, most based on blinded Schnorr signatures. Cashu uses a different algo, based a kind of blinded Diffie-Hellman, similar to that used in privacypass.

Fedimint uses blind signatures plus federated mints.

Good points.

Covenants 'open the door' to doing a whole range of things *trustlessly* or *efficiently* that are currently already being done inefficiently and/or with trusted third parties...

Sorry that last part about snapshots was dumb; not that it isn't a valid idea, but in no way is it some kind of peg, because it's new issuance, even if controlled. The two way peg concept is the most interesting, and it seems really unclear/difficult with bitvm (given fraud proos onchain a la arbitrum) (not that i know any easy way!).

Interestingly, something I've just worked on could help with that: issuance based on a utxo snapshot could be made private with https://reyify.com/blog/preserving-proof-of-taproot-assets

... but it could also be simpler, without privacy. Don't see the need to burn, a la spacechains, if you just use a one time snapshot.

This is an attempt to develop a better version of ideas RGB and Taro. There's a perception amongst many that these kind of protocols are useful only for gambling on tokens, and not helpful to BTC, but I have disagreed on that before, and still do.

The root idea came from Peter Todd many many years ago, namely this nuance: blockchains are only needed for double spend prevention, not for consensus on what is and is not a valid coin. Hence the content of transactions can be garbled junk to everyone except the spender and the receiver. While there's a ton of stuff to figure out before that can actually work, it's obvious what the advantage is, and it's huge: transactions are more private, and (a twist on the usual way of looking at it): the computational burden of validation is reduced for nodes, which is actually very *healthy* for the base p2p bitcoin network!

On that "ton of stuff": that's exactly what RGB and then Taro worked on for several years; this new paper claims (I suspect correctly, but there's some details to work out) to have made a better version. The principal advantage is compactifying the validity proof of a coin that you're receiving from being the size of your coin's history, to being a constant, small size (asymptotically down to 64 bytes). But it seems like the exact details have not been worked out; they don't yet have working code, for example.

So finally, is this "just for gambling on tokens" and not for exchanging BTC? Kinda yes, kinda no. As the paper points out in an Appendix, you can definitely create a proper (trustless) atomic swap construct for exchanging (whatever token is in your Shielded CSV "account") to BTC and back. You could also do this with e.g. the Liquid sidechain, though at least there you don't have currency exchange risk in doing so. I don't know if it might be possible to create a 's-csv-btc' token in this system and then 'sideswap' like that, i *guess* so? How stable is the "peg" if there is no unilateral exit, only swaps? .... it would be very attractive if it all worked as planned, since you would have *very* private transactions with ~ immediate transfer and very small fees (assuming publisher aggregation of the type described in the paper).

They also mention that unilateral exit with ZKPs is theoretically possible with bitvm, but nothing concrete.

Disclaimer: this is all from an hour of 'generally reading', not detailed review.

nostr:nevent1qqsqf2sl802c07ztncafvancc6mnvnsp7tsaw7aesn7ju8g8fvwce6qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygyj99zh08unl59nwk03z4lrm8azpulaynzt3u4u75sv4nmyntmhd5psgqqqqqqsjd8s67

I don't agree with the Epstein analogy; it's a different thing entirely. The fundamental point here is that ethics are expensive.

Living in very low development societies, you have very different choices than you do living in high development societies. I have friends in ES that are still in their twenties, that vividly remember times when: as a man, you could be shot for taking the wrong bus and ending up in the wrong suburb; as a parent, you might have to lock your daughter in the house permanently because you know she will be taken by the gangs for their "use" and you will never see her again. These are just a small section of the horrors of living in some parts of ES when the gangs had no pushback.

You could think of Bukele (and this applies to any government that actually functions) as another gang. But he has very broad support because his gang is promoting some kind of traditional/Christian morality in a largely Christian country. But given that context, the undoubted evil of some people (we of course will never know how many) being imprisoned unjustly, along with the more insidious evil of excessive power in the hands of one main, when balanced against the counterfactual of uncountable murders, thefts and rapes that *would* have happened without this, is easier to square off.

Yes, the docs of the repo explain how it can be done (the readme links to auditor-docs at the top).

It's a pretty involved process, for several reasons.

I'm looking into building a GUI right now.

It's a lot more difficult, because the pubkeys are hidden behind hashes, so without the owner's cooperation you would have to use ZKPs of SHA2 and RIPEMD hash preimages, which is very expensive/complex comparatively.

Probably somewhat true across Asia; the value of a strongly decentralized system that isn't controlled by a human hierarchy isn't easily grokked by most people there. Of course there are some exceptions, but in my experience those people are in an even smaller minority there than here.

There is no solution to sybil attacks without imposing real world cost (though the market *usually* settles on the more opaque kinds of cost, because people strongly prefer to be unaware of what they are paying).

It's interesting to consider if and why Bitcoin is an exception to the above parenthesized clause.

I love the 'technicality'. Unlike the German customs office, I *do* have plans to use software that can solve the discrete logarithm problem in polynomial time, unfortunately I am struggling to find any such software 😄

+1 on amethyst

Also, get a paid relay. Didn't find nostr too usable until I had that combination.

Really good post.

Except for not using additive notation 😄

I think there are two different concepts of 'danger' that apply here. One is, that a "new" OP code may cause the potential for technical failures, things that could crash nodes for example by exhausting memory. Another is seen in cases like drivechains proposals, where some argue that, if the proposed change creates economic incentives to do things other than the purest model of 'miners just mine to get fees from onchain monetary transfers', then this is a danger that may be unacceptable.

I agree about the former danger, in that conservatism w.r.t. it is very necessary, but not with the latter: trying to mandate the semantics of onchain transactions is a false trail; if people want to do bitcoin transactions whose purpose is not purely the monetary transfer onchain, you are never going to be able to stop it. The problem with the argument "well there's no reason to *encourage* them, by adding new functionality!" is simply that there is, indeed, a very good reason: in order for bitcoin to be usable at large scale, it may be (and probably is) necessary to change its expressivity so that offchain transfers become significantly more powerful than today (e.g. Lightning cannot scale to the whole planet).

My intuition is that OP_CAT is more dangerous than OP_CTV w.r.t. the 1st danger, not that I really know.

Interesting, long write up on OP_CAT, script, taproot and STARKs on the delving forum:

https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106

The tree is constructed publically (so both by the prover and the verifier, and whoever), from the public data of taproot pubkeys and sat values of the utxos. The privacy comes from the select-and-rerandomize algo, which makes a blinded version of the commitments xG + vH (in this application), adding rJ. So you can't claim a pubkey or amount that is different, and your knowledge of the private key is ensured by the proof of representation (see 3.6 in the paper).

Would you say this is bad on the part of the EU or Apple though? I don't really know anything about this.

Reasons these systems could be pointless: 1/ proof of assets is fakeable by borrowing assets 2/ proof of liabilities too complex for users 3/ proof of liabilities can be made easy but then users are just trusting the custodian anyway. Re: "in the case of ecash mints, they compromise with privacy" - but, that's why i'm posting a *private* proof of assets technique? I certainly agree that it's a nasty compromise to publish assets with onchain addresses as Binance does.