03:30 UTC

< February 2019 > Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

- Console
- #amber
- #arm-graphics
- #arm-netbook
- #bitcoin-wizards
- #bundler
- #cinch
- #coiniumserv
- #coiniumserv-dev
- #crystal-lang
- #cubieboard
- #datamapper
- #discferret
- #elliottcable
- #etnaviv
- #forth
- #glasgow
- #gridcoin
- #gridcoin-dev
- #homecmos
- #huawei-g300
- #imx6-dev
- #imx6-dongle
- #ipfs
- #jruby
- #libreelec
- #libreoffice-ru
- #lima
- #linux-amlogic
- #linux-exynos
- #linux-rockchip
- #linux-sunxi
- #lisp
- #litex
- #logarion
- #maglev-ruby
- #microrb
- #milkymist
- #mirage
- #mutant
- #nanoc
- #neo900
- #nextbsd
- #nmigen
- #ocaml
- #opal
- ##openfpga
- #panfrost
- #Paws
- #Paws.Nucleus
- #picolisp
- #ponylang
- #prjmistral
- #pypy
- #qaul.net
- #qi-hardware
- #racket
- #radxa
- #reasonml
- #rom-rb
- #rubinius
- #ruby
- #ruby-core
- #rubygems
- #rubygems-aws
- #rubygems-trust
- #ruby-lang
- #ruby-rdf
- #sandstorm
- #scopehal
- #skywater-pdk
- #slime
- #soletta
- #solvespace
- #stellar
- #stellar-dev
- #symbiflow
- #systemtap
- #teamhacksung
- #teamhacksung-support
- #tinyqma
- #trilema
- #wallaroo
- #xiki
- #xtompp
- ##yamahasynths
- #yosys
- #zig

sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja

<nsh>
(springer DCC is not open access. paper also available here: https://eprint.iacr.org/2018/068.pdf )

<luke-jr>
I wonder if there's a good way to make it so if you don't run a full node, your coins can be stolen trivially

<luke-jr>
maybe keeping a running UTXO-set-history hash that needs to be committed to in the tx somehow, and if it doesn't match, the outputs can be malleated?

<waxwing>
interesting reading: https://z.cash/blog/zcash-counterfeiting-vulnerability-successfully-remediated/

<waxwing>
"The Zcash Company adopted and maintained a cover story that the transcript was missing due to accidental deletion. "

<nsh>
it'd be interesting to compare the process to bitcoin's recent inflation vuln and how that was handled

<nsh>
it'd be nice to have an phylogenetic tree of zk cryptosystems so it'd be easy/easier to see which inherited the vulnerability

<nsh>
also it's an interesting cost to this remediation that the MPC protocol transcript is now unavailable [unless you know someone who archived it]

<waxwing>
this is why i've been leaning against blinding of amount based on hardness assumptions even though it's a heretical position, including against myself :) it's not the hardness assumpmtion or the QCs that get you, it's the implementation (likely).

<nsh>
it seems [very] hard in general to prove that you haven't introduced fresh assumptions while implementing or adapting from previous results

<nsh>
"Ariel Gabizon, a cryptographer employed by the Zcash Company at the time of discovery, uncovered a soundness vulnerability. The key generation procedure of [BCTV14], in step 3, produces various elements that are the result of evaluating polynomials related to the statement being proven. Some of these elements are unused by the prover and were included by mistake; but their presence allows a cheating prover to circumvent a consistency check, and thereby

<nsh>
transform the proof of one statement into a valid-looking proof of a different statement. This breaks the soundness of the proving system."

<nsh>
so i guess one thing to do is add a proof that a transcript of a protocol doesn't just satisfy the verifier but it also does so minimally, ie without any extraneous data whatsoever

<sarang>
From a non-technical standpoint, I'm now interested in seeing how many company posts/statements/comments dance around the issue of a flaw without outright misleading, prior to disclosure

<nsh>
if every result in known mathematics was encoded into coq theorems it would be significantly smaller

<nsh>
some treatment here: https://hackernoon.com/bitcoin-core-bug-cve-2018-17144-an-analysis-f80d9d373362?gi=77fe6f45bf2c

<jtimon>
oh, yeah, the consensus rule that was temporarily removed from bitcoin core by mistake, right?

<nsh>
over several pull requests and refactors a consensus check against doublespends was lost in translation

<sipa>
jtimon: there was also a 0.8 thing where master briefly removed the subsidy limit check, but that was discovered before release

<jtimon>
this one is just the check that the inputs being spend haven't been spent already within the same block, right? we removed that thinking that was duplicated with analogous checks in the mempool, but they weren't the same checks so we put them back

<sipa>
or rather, two pieces of code whose authors believed the other part was responsible for checking within-block double spending

<sipa>
but both got optimized removing the check, leaving only a cross-tx assertion in place, and nothing for within-tx

<gmaxwell>
The zcash announcement is shocking. It appears to me that zcash basically spent months slandering Petertodd, who noticed the highly questionable disappearence of the mpc transcript, in an effort to cover up a total lack of soundness (unbounded undetectable inflation), and zcash company employees continued to double down on the integrity of their trusted setup even when they knew in fact that

<gmaxwell>
I could understand them not doing that, but they could have remained silent. Rather than vigourly doubling down in defense of a system that they had actual knowledge of an insecurity in.

<vfP56jSe>
Hello, I am reading about Taproot. In the cooperative case, what would the signature look like for P?

<vfP56jSe>
In the mailing list it says "one of them just needs to add H(C||S) to their private key", but if it's only one of them, then it isn't cooperative? Please help me understand.

<vfP56jSe>
My understanding (which might be completely wrong)is that the signature looks like "a + H(C||S)", and since this is supposed to be cooperative, both parties need to agree to sign, so if Alice knows a, C, and S, in this completely wrong understanding, she would be able to sign for P by herself?

<gmaxwell>
It's not describing the signing algorithim. The signing algorithim is just a standard signing algorithim for 2 of 2 schnorr.

<gmaxwell>
With the only modification is that instead of signing with their private key, one of the signers needs to sign with a tweaked private key.

<gmaxwell>
(or, alternatively, treat it as a 3 of 3 schnorr, with the taproot commitment being one of the private keys, its equivient)

<vfP56jSe>
The "tweaked key" part isn't part of standard schnorr is it? And the tweaking is what is described by "one of them just needs to add H(C||S) to their private key"?

<gmaxwell>
sarang: thats a weird and distracting claim. Yes, any bleeding edge hardly reviewable cryptosystem could have unsoundness vulnerablities.

<gmaxwell>
It wasn't a violation of the trusted state, it was a flaw in the additional complex procedure that was needed to try to patch over the insecure setup.

<gmaxwell>
it's also weird that their disclosure does not make clear that they do not, and cannot know, if it was exploited. (only that the total funds that have exited from the unshielded addresses are below the maximum, so any inflation-- if their was any-- was instead converted into theft to parties that were slow to get their funds out of the old accumulator.

<nsh>
it would take some computation over all honest accumulator participants to prove there was no counterfeiting

<nsh>
do coins in the old accumulator retain [migrateable] value indefinitely or is there some sunset period?

<vfP56jSe>
Looking at the Schnorr BIP, in the generic description of Schnorr, does the signer pick R, e, and s?

<vfP56jSe>
andytoshi: Because when R is picked, we can get e from "e = H(R || m)" and s from solving "sG = R + eP"?

<vfP56jSe>
sipa: That's very clear. I'm wondering, in the case where we don't consider k and just consider R, it's mentioned in the BIP that the signer can either reveal e or R, I'm curious why s can't be revealed

<vfP56jSe>
s can only be computed by the signer because only the signer has k and x, in which x is the signer's private key and k is picked by the signer

<vfP56jSe>
I'm trying to see why (R, e) ___necessarily___ can't be validated, my tentative answer is that since given m they HAVE to satisfy e = H(R || m) by definition, so that equation becomes unuseful...

<vfP56jSe>
because the satisfy conditions for both (e, s) and (R, s) combine "e = H(R || m)" and "sG = R + eP"

<sipa>
i understand you're asking this from a perspective of "oh A and B are possible, why isn't C possible too?"

<sipa>
but on itself, it's already quite surprising there are two formulations of schnorr to begin with

<sipa>
typically there isn't some random transformation of this type that you can do on a cryptographic scheme without breaking it

<petertodd>
gmaxwell: for the record, they never gave me any indication there was an issue... other than well after it was fixed being really weird about the missing transcript - zooko really didn't want the communication about it being made public. but that was after everything was fixed AFAICT so I don't see why

<petertodd>
sipa: sorry, if they just told me "please shut up, we have a really good reason" I would have

<petertodd>
sarang: thanks, though frankly I'm worried at whether or not I lost work over that - whisper networks suck

<sarang>
I noticed the Zcash Foundation is calling for an examination of Sprout address deprecation without defining what that means

<vfP56jSe>
For "Implicit Y coordinate," I understand why out of the 2 possible Y coordinates, one and only one is the quadratic residue, but I cannot find how "quadratic residue of the Y coordinate can be computed directly for points represented in Jacobian coordinates"

<petertodd>
sarang: it'd be because the old-style scheme is still allowed, albeit with a new proof system, so best to depreciate it asap

<sarang>
Is this supposed to imply eventual unspendability? Because zooko advocated for that, and it seemed bonkers to me

<sipa>
vfP56jSe: the (affine) y coordinate is a quadratic residue if either both or neither the Y and Z jacobian coordinates are quadratic residue (but not if only one of them is)

<sipa>
because y = Y/Z^3; if you multiply with Z^4 (which is definitely a quadratic residue, so it doesn't affect the residuosity of the result), yiu get YZ

<vfP56jSe>
So when we encode `R` for the signature, we only encode its x-coordinate (affine). But during verification we never reconstruct the y-coordinate from this affine x-coordinate, but rather, after we calculate R = sG - H(r || P || m)P, we check that the x-coordinate of R is r and that the y-coordinate of R is a quadratic residue?

<vfP56jSe>
it seems that after calculating R = sG - H(r || P || m)P, we want 1. The affine x-coordinate of R, to check that it is the same as r 2. The jacobian y,z-coordinate of R, to check the residuosity of YZ ? Is that correct?

<sipa>
you can compare an affine coordinate pair with a jacobian one (to see if they refer to the same point) without converting from jacobian to affine

<vfP56jSe>
1. Check if it refers to the same point as an affine pair, 2. Check the residuosity of its affine equivalent's y-coordinate

<vfP56jSe>
1. Check if its affine equivalent's y coordinate is in the lower half, 2. Check if its affine equivalent's y coordinate is even

<gmaxwell>
your understanding is correct. Converting to affine is expensive because it requires a modular inversion. But you can do an exact comparsion by converting the affine value to jacobian with the same denominator, by multiplying.

<gmaxwell>
Also really, QRness is really a much more natural tie breaker for point compression. Even/oddness is pretty non-algebraic but just happens to work because the field is prime.

<gmaxwell>
more natural in the sense that the ___reason___ that there are even two possibilities is because the sqrt has two possibilities.