07:33 UTC

< July 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
- #asahi
- #asahi-dev
- #asahi-gpu
- #asahi-re
- #bitcoin-wizards
- #buildbot
- #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
- #lowempire
- #maglev-ruby
- #microrb
- #milkymist
- #mirage
- #mutant
- #nanoc
- #neo900
- #nextbsd
- #nmigen
- #ocaml
- #opal
- ##openfpga
- #openwrt-devel
- #panfrost
- #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
- #symbiflow
- #systemtap
- #teamhacksung
- #teamhacksung-support
- #tinyqma
- #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

<Hansie>
Hi there. In Elliptic Curve Cryptography, is it possible to verify if a Pedersen commitment `vH + kG` only has an element on `G` and nothing on `H`, thus with `v = 0`, by just evaluating the commitment on face value, without trying to solve for `k`? Commitment bases `G` and `H` are known. (`v` is the value and `k` is the blinding factor.) I know t

<sarang>
If you don't want to reveal `k` you can sign with it, since a commitment to zero is a public key

<Madars_>
yes. if dlog holds, then if you know a decommitment of the form cm = v*H, it is computationally infeasible to find another one (as that would break the dlog). but of course for ***every*** v', there exists a k' s.t. cm = v' * G + k' * H, so "have nothing on H" only has a computational meaning

<Hansie>
Thanks, but I am not sure I understand the answer. Is it feasible to verify in polynomial time if `v=0`?

<sarang>
When you say "verify" do you mean that a prover wishes to prove that her commitment is to `v=0` without revealing the blinder `k`, such that a verifier can be convinced of this without attempting to brute-force blinders?

<sarang>
In the case, the prover's commitment is of the form `C=kG` and the prover can simply sign an appropriate message with `k`

<sarang>
If the discrete log between the two Pedersen generators is unknown, the prover cannot do this with nonzero value except negligibly

<sarang>
A successful signature (and properly constructed message involving `C`, etc.) convinces the verifier that the commitment was to zero

<adiabat>
digi_james: thanks, I can answer here, I dunno if it's too noisy / OT as I also made #utreexo (which nobody uses :)

<adiabat>
1) just the inclusion proofs are enough to perform deletion operations, even if you only have roots

<Hansie>
sarang: Ok, so if we have `C = 0H + (k_1G+k_2G+k_3G)` where 3 parties each hold their `k_n` value private but are not present in this final Tx, would it still be possible? The 3 parties can sign an appropriate message with their respective `k_n` when those commitments are created.

<adiabat>
2 & 3) so far I've done everything in RAM and don't have serialization code for partial / sparse forests. It seems like it'd work OK on disk but would be slower.

<sarang>
Hansie: I suppose at that point it's basically a multisignature on the combined key... but I know that andytoshi and friends have been finding all the possible ways that multisignatures can go horribly wrong :D

<Hansie>
sarang: So if we can prove that each individual `C_n=0H+k_nG` is a commitment to zero with an appropriate signature, would it be enough to additionally verify that `C=C_1+C_2+C_3` and in so doing prove that `C = 0H + (k_1G+k_2G+k_3G)`?

<sarang>
If each prover signs for their own commitment to zero, then of course the sum is also a commitment to zero

<Hansie>
Yes, and thank you sarang, this scheme is the answer I was looking for. I basically want to add a bunch of commitments together and prove that the result is a commitment to `0` without the owners of those commitments being present.

<sarang>
The individual signers cannot use their commitments as public keys if they are not separately zero-valued

<sarang>
If some outside entity knew the masks, they could sign for the sum/difference... but at that point they could simply brute-force the values and recover all commitments

<aj>
sarang: i think you just wouldn't be able to tell the difference between "it doesn't add up to 0H after all" and "someone's not following the protocol"?

<Hansie>
I thought the parties could construct their zero commitments with `k_n` and appropriate signatures when they create the actual commitments.

<sarang>
Hansie: I think I'm confused about the structure of your individual commitments... you said "zero commitments" which I assume are not the same as whatever "usual commitments" to non-zero values the signers are working with

<Hansie>
Yes, someone creates a normal commitment, and at the same time a commitment to zero with the same blinding factor and signature to prove it

<sarang>
If you're including both commitments (to zero and to non-zero) it's trivial to brute-force the value if it's in a limited range

<sarang>
You implied that your goal is to make this non-interactive, such that any third party can perform this aggregation-to-zero?

<Hansie>
Yes, that is the goal. The additional metadata can be kept secret by the 3rd party until needed.

<Hansie>
They will be able to brute force the values before the final transaction is posted, but never the blinding factors.

<nsh>
"Abstract: We show how to perform a full-threshold n-party actively secure MPC protocol over a subgroup of order p of an elliptic curve group E(K). This is done by utilizing a full-threshold n-party actively secure MPC protocol over Fp in the pre-processing model (such as SPDZ), and then locally mapping the Beaver triples from this protocol into equivalent triples for the elliptic curve. This allows us to transform essentially {\em any} one-party

<nsh>
protocol over an elliptic curve, into an n-party one. As an example we show how to transform the shuffle protocol of Abe into an n-party protocol. This application requires us to also give an MPC protocol to derive the switches in a Waksman network from a generic permutation, which may be of independent interest."