waxwing

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.

2024-09-19 15:54:52

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

2024-09-19 04:28:05

- reply

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).

2024-09-18 19:53:17

- reply

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

2024-09-18 19:49:00

- reply

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.

2024-09-18 19:44:01

- reply

Doesn't it point you to a link that's supposed to help you decide if you're a trader or not?

2024-09-18 19:31:46

- reply

Is what they're saying about the DSA wrong then? I'd honestly never heard of it.

2024-09-18 17:43:50

- reply

Also, thanks for the link to halseth's post, very interesting!

2024-09-18 17:43:04

- reply

Yes, I did see (at least what's publically written) about Binance. It's not really either clear what you are saying (it didn't make a difference to what, precisely?), nor what the right choice is for each situation. A ZkSNARK nor a bulletproofs or other similar ZKP system won't be needed for the *assets* side of a proof of reserves, *if* you don't care about onchain privacy - which Binance doesn't; they just publish all the onchain addresses. While those systems can help a lot with the trickier proof of liabilities. If you do care about onchain privacy, these systems have tradeoffs; to get a bigger anon set on bitcoin than taproot, you have to address the hashing problem. The original Provisions protocol of Bunz completely sidestepped this problem; with zksnarks you *can* address it but it is quite, quite tough because you have to build multiple non-algebraic hash function circuits. The result is that at the very least, pre-processing takes horrendous amounts of time.

2024-09-18 17:08:46

- reply

Yeah there's both a cynical and a non-cynical dismissal of my suggestion to Coinbase custody here.
The non-cynical one would mention that the taproot-only restriction is very significant to them (both smaller anon set and disruption of their workflow; for their security measures they'd probably dismiss such a disruption out of hand; don't underestimate how slowly tech processes can change in big institutions). It would also mention that this is only addressing proof of *assets* not liability proofs which has tended to be the much bigger sticking point. For myself, I would find even *just* a proof of assets from entities like Coinbase custody or Bukele, to be a very good thing.

2024-09-18 16:45:23

I've written a blog with a proof of being a satoshi millionaire, that does not reveal where my funds are on-chain. Bukele and Coinbase take note pls :)
https://reyify.com/blog/privacy-preserving-proof-of-taproot-assets

2024-09-17 21:04:32

- reply

I've thought a little about applications to Layer 2s, but not much. It isn't obvious that it could be a part of such a system, like e.g. building proofs and having them verified onchain, such that a person owning funds in an L2 could claim them back on L1, seems decidedly non-obvious, because these proofs, while sharing the same elliptic curve, use a set of generators, not just the 'G' that we use in Bitcoin for our signatures (note: i am framing the problem based on *not* changing bitcoin with a hard or even soft fork; clearly if new verification code was added, then things like bulletproofs could be added, as was envisaged originally for Confidential Transactions, and as is seen in e.g. Liquid/Elements).
On the other hand, yes, indirectly: my motivation for the token idea was, more than anything, a system like Lightning: you have a lot of potential Sybilling problems, for example Lightning uses gossip of *real* "unencrypted" channel opening utxos to identify channels, so that the gossip system doesn't get swamped with fake channels. I believe this is a promising (and maybe even the best) direction to solve that problem; I've had a few brief discussions with some Lightning engineers, but I don't see much interest/traction for it, at least yet.
Lastly I'd say: this is not just interesting to get anonymized tokens on ownership for anti-Sybil; the same technique can be used to publish proof of ownership of assets aggregated over many utxos e.g. "I prove I own 1btc of taproot utxos but I won't show them" is not only possible with this tech; I've already done it, in the same repo. I'm probably going to post such a proof shortly. I think it *could* be of interest for proof of reserves applications, since it preserves privacy but provides irrefutable evidence of onchain funds.

2024-09-17 07:47:21

- reply

No they aren't, but the conflict he's talking about is very real, and very often overlooked; people like the concept 'censorship resistance requires privacy so that the powers that be can't see what they want to censor', which is true but is also limited in that those powers may try to force communication, or monetary exchange, through channels not private from them.
The dynamic he's talking about is probably best understood by considering the word 'broadcast'.

2024-09-15 20:36:48

- reply

I don't really understand the basic concept, is there not a write up somewhere?
If the main claim is 1 round signing with nonce preprocessing, how is that different to FROST? That was one of FROST's main claims, that you could optionally do that; it's even in the abstract of the original paper.

2024-09-12 20:51:35

- reply

Answer at #nevent1q…sw7n
@npub17fn…5ksh ping also

2024-09-12 14:30:04

Here is Cramer's solution:
The "challenged" does this: choose a random number in 1..1000, r, look up question number r for Komodo dragons and memorize it. The challenger then provides an unpredictable random number in 1..1000, c, and says "give me two answers, one from each list, where the question numbers add up to c modulo 1000. So the challenged calculates c - r (mod 1000) to get r2, which is the number of a question from the Fermat list, which he can immediately provide, along with the r-th Komodo dragon question, and the challenger veries that r + r2 = c mod 1000.
(For anyone interested, this is the extremely elegant solution to how to combine Sigma protocols in OR relations, "first" discovered in CDS-94 (see the first sections of my blog on ring signatures for details: https://reyify.com/blog/ring-signatures )
#nevent1q…39t8

2024-09-11 21:52:09

- reply

Yeah basically variants on 'the two answer sets can be 'encoded' and are chosen to have an identical encoding'.
But can you find a way to do it that doesn't require answering a thousand questions? Based on the concept that, if one were challenged to answer one specific question randomly, one is guaranteed to succeed based on knowing all the answers?

2024-09-11 21:39:29

- reply

No, you succeeded I'd say, that last idea feels like a valid solution ... unless i missed something. I'll post the 'intended' answer later.