04:51 UTC

< March 2020 > 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

<kanzure>
"Verifiable secret redistribution for threshold sharing schemes" http://www.cs.cmu.edu/~wing/publications/Wong-Wing02b.pdf

<bsm117532>
But I still think it's a nice demonstration of how redistributable, verifiable secret sharing can work.

<bsm117532>
The consequence of omitting hiding is that if you know (or can guess) a few bits of the secret, you can derive some bits of the polynomial coefficients.

<bsm117532>
See CHURP instead if you're interested in this idea: https://eprint.iacr.org/2019/017, or encrypt your secret so that it is uniformly random (adding a hiding element).

<bsm117532>
Is Z_{4p+1} an appropriate ring for committing to values in Z_p? (bitcoin private keys, where p = bitcoin's prime).

<bsm117532>
The above paper requires Pedersen commitments to the secret values. I'm wondering if the prime 4p+1 is generally appropriate for commitments to bitcoin private keys. (independent of that paper -- might be used in other ways)

<bsm117532>
https://tlu.tarilabs.com/cryptography/bulletproofs-protocols/MainReport.html#pedersen-commitments-and-elliptic-curve-pedersen-commitments

<bsm117532>
Such things require a prime 2*p+1, but for the bitcoin prime, 2*p+1 isn't prime, but 4*p+1 is.

<bsm117532>
Sure. The only reason I ask is the above paper uses exponentiated Pedersen commitments, not EC commitments.

<bsm117532>
I was fooling with this years ago, have been wondering about 4p+1 ever since, but never satisfied myself that 4p+1 was secure. Yes it's small. r=(4p+1)+1 has a 133-bit factor. I'm not sure how to use that though...

<bsm117532>
But this is just a Pedersen commitment, not RSA. how would you use a too-small prime to break a Pedersen commitment?

<bsm117532>
I accept your argument, but I'm looking for a procedure to extract the committed value, just to help me understand. ;-)

<sipa>
pedersen commitments are information theoretically hiding (if the blinding factor is random), there is no way to.extract

<sipa>
say you commit to a using an EC commitment with generators G and H, in a group in which DL is easy

<bsm117532>
sipa: (segue from Twitter) The bad idea in my head is to do a multisignature with (e.g. 2-of-3) P = P_1 P_2 + P_2 P_3 + P_1 P_3. This is a monotone boolean function on the pubkeys with + as an OR operation and * as an AND operation.

<bsm117532>
(Insert hashes in front of the terms as necessary to commit to this combination being allowed)

<bsm117532>
Parties 1 and 2 could then construct a signature by using the ideas from 2p-ECDSA (multiplicative aggregate keys), and possibly abusing the Schnorr related key attack to remove the extra terms.

<bsm117532>
Is something along these lines impossible? Or is it just that no one has described how to do it?

<sipa>
but there are schemes (somewhat related to VSS) that can translate any monotone boolean function over keys to a setup for that policy

<sipa>
make a Merkle tree where every leaf is a MuSig of some subset of the keys; and you have one leaf for each of the (n choose k) combinations

<bsm117532>
related key: just saying it's in general possible to sign for P+a if you have the private keys for P. (you called it a "related key attack" in bip-schnorr) Or pubkey tweak, or whatever.

<sipa>
bsm117532: that's VSS; the signers effectively use shamir shares to reconstruct the (partial signature for) the secret keys they are missing; the linearity of the keys and signatures means that's enough

<bsm117532>
I'm asking for an algorithm for 2-of-3 parties to construct a signature for the aggregate pubkey P = P_1 P_2 + P_2 P_3 + P_1 P_3, without using Shamir sharing.

<sipa>
i know you mean "something representing and", but if you're not concrete then the question is meaningless

<bsm117532>
It probably wouldn't because of the factorial number of terms involved. I'm just curious...since this is what was in my head naively as "native threshold Schnorr".