05:37 UTC

< March 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 29 30 31

- Console
- #amber
- #apicula
- #arm-graphics
- #arm-netbook
- #bitcoin-wizards
- #buildbot
- #bundler
- #cinch
- #coiniumserv
- #coiniumserv-dev
- #crystal-lang
- #cubieboard
- #datamapper
- #discferret
- #elliottcable
- #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
- #lowempire
- #maemo-leste
- #maglev-ruby
- #microrb
- #milkymist
- #mirage
- ##moved_to_libera
- #mutant
- #nanoc
- #neo900
- #nextbsd
- #nmigen
- #ocaml
- #opal
- ##openfpga
- #openwrt-devel
- #panfrost
- ##panfrost-offtopic
- #Paws
- #Paws.Nucleus
- #picolisp
- #ponylang
- #prjmistral
- #pypy
- #qaul.net
- #qi-hardware
- #racket
- #radxa
- #reasonml
- #river
- #rom-rb
- #rubinius
- #ruby
- #ruby-core
- #rubygems
- #rubygems-aws
- #rubygems-trust
- #ruby-lang
- #ruby-rdf
- #sandstorm
- #scopehal
- #skywater-pdk
- #slime
- #soletta
- #stellar
- #stellar-dev
- ##stm32-rs
- #symbiflow
- #systemtap
- #teamhacksung
- #teamhacksung-support
- #tinyqma
- #videocore
- #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

<kallewoof>
gmaxwell: would be nifty to have a .conf formatted banlist so i could just wget it and "includeconf=banlist.conf"

<luke-jr>
well, you still need to fetch the file, and at that point you could just use RPC.. using the conf file would require a restart

<adiabat>
Hi - I remember this paper being discussed / critiqued here a few months ago: https://arxiv.org/abs/1809.09044

<adiabat>
(Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities)

<adiabat>
I remember people having problems with it, if anyone has pointers to what those were, or maybe even just IRC logs that'd be a good place for me to start

<sarang>
Here's a question I've been thinking about regarding Bulletproofs' MPC construction... suppose you want to take part in an MPC but that any other player could be malicious

<sarang>
In each round of the MPC, the other players (if they don't precommit to their proof shares) could modify their shares relative to yours; you then use them to compute supposed aggregate F-S challenges

<sarang>
I can't identify a way that the other players could conspire to practically leak information about your (honest) values, but I wonder if it's possible to construct a simulator to show that provable zk is still possible (I think not)

<sarang>
But each aggregate F-S challenge is a hash of the sum of all the players' partial proof elements

<gmaxwell>
I think I would reflecively add a precommitment or delinerization there, but I'm not sure if it actually breaks it.

<sarang>
I'm quite sure that precommitment to proof shares makes everything a-ok, but it doubles the rounds

<sarang>
I wonder if you can get away with avoiding precommitment, using straight-up sums (as listed in the protocol), and still be confident of ZK

<andytoshi>
you could get away if you generated all your randomness deterministically and provided a zkp proving that you'd done so

<andytoshi>
you need to be bold in zkps. If you find your protocol doesn't work and think to turn back, don't!, the correct answer is to just add even more ZKPs

<sarang>
It is unfortunate for CoinJoin-style applications that the 3-round version assumes honest-but-curious adversaries only, which seems like a non-starter as a trust model

<gmaxwell>
sarang: huh, for coinjoins if someone jams the protocol, everyone is forced to open their commitments, and anyone who fails to do so (or whos openin was bogus) is kicked out.

<gmaxwell>
If a protocol is actively secure but someone sends garbage, you still have to kick them out and restart.

<sarang>
I suppose it would be fine if it were still provably ZK in the face of maliciously-generated challenges

<real_or_random>
sarang by the way https://eprint.iacr.org/2014/764.pdf Theorem 1 shows that special HVZK => (malicious) witness-indistinguishable for (3-round) sigma protocols

<real_or_random>
at least WI is not enough ***in general*** to make confidential transaction work... I had a counter example somehwere

<sarang>
The practical requirement here is really that the adversary not have a statistical advantage in determining the pedersen blinder, of course (amount themselves being quite limited in practice)

<real_or_random>
okay counter example why WI rangeproofs are not enough for CT: assume for simplicity we have a transaction with one input and one output (you don't need a range proof there but the example can be extended to larger transactions)

<real_or_random>
input c1 = h^x2 * g^r2, output c2 = h^x2 * g^r2, and two rangeproofs. say the range proof is WI but additionally leaks s^r1 (and the second range proof leaks s^r2) for another generator s

<real_or_random>
new attempt: input c1 = h^x2 * g^r2, output c2 = h^x2 * g^r2, and two rangeproofs. say the range proof with witness x,r is WI but additionally leaks f(x,r) = if |x| = 5 then s^r else random group element

<real_or_random>
now for CT you will reveal r1+r2 to open the sum commitment. and then everybody can check whether f(x1,r1)*f(x2,r2)=s^(r1+r2)

<real_or_random>
note that this counter example does not work if we prove in zero-knowledge that we know r1+r2 as the opening of the sum commitment to 0.

<real_or_random>
in general, composing zero-knowledge proofs with other zero-knowledge proofs is fine. composing WI proofs with different WI proofs and other stuff can have weird interactions

<real_or_random>
the problem is that multi-transaction CT is very difficult to formalize then. if everything is ZK, I'm somewhat more confident that there are no weird interactions

<sarang>
The easy solution must be to construct a simulator in the face of adaptively-chosen challenges :D

<real_or_random>
yes the problem is that we don't even know have a proof that the schnorr identification protocol is zero-knowledge (against malicious verifiers)

<real_or_random>
it will be interesting to have a look at variants where the (malicious) verifier outputs x and the challenge is H(x) for a random oracle H. I don't think people considered this case so far

<sarang>
other players send you A1, A2, ..., An and you include your own share A0 to form commitment H(A0 + A1 + ...)

<sarang>
Is it really that different of a scenario (from a simulator perspective) as the adversary choosing whatever challenges it wants?