14:35 UTC

< September 2015 > 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

- 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

wumpus changed the topic of #bitcoin-wizards to: This channel is 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

<psztorc>
slide 30 https://scalingbitcoin.org/montreal2015/presentations/Day1/8-Ittay-eyal-testbed-for-bitcoin-scaling.pdf

<instagibbs>
Out of band isn't double-spend. Like gmaxwell said, you can do OP_TRUE or something to ensure miner gets 100% of funds, leaving none for following miner.

<psztorc>
random note: when I explain Bitcoin to very smart people, a suspicious % of them seem to always think that mining elects the next block-maker (not that all are working on the next block at once)

<CodeShark_>
One even was perceptive enough to suggest voting on a hard fork in principle is no diffrent than the way nodes usually vote on transactions

<CodeShark_>
Hmmm...not happy about adding soft fork thresholds to chain params directly...but perhaps we can use an abstract base class for soft fork thresholds so anyone creating a new alt/sidechain or testnet can inherit from it

<mjerr>
anyone got further information about schnorr signatures vs ecdsa? I hear a lot about schnorr, but I'm not really able to figure out why it's so much better - any paper or similar would be great

<andytoshi>
mjerr: schnorr signatures are algebraically simpler and have a security proof; the naive way of computing them is much faster than the naive way of doing ECDSA

<andytoshi>
mjerr: their algebraic structure lets them be batch-validated, and can also be combined to do multisignatures without increasing their size

<andytoshi>
mjerr: it means you can take a whole much of ec-schnorr signatures and validate them all at once ... so like you can validate the whole block assuming all EC signatures pass, then do a batch validation on them to check that the block is actually good

<andytoshi>
hmmm, no, a lot of this is folklore .. one day https://github.com/sipa/secp256k1-paper/blob/master/paper.tex will be it i think, but for now that's empty :)

<andytoshi>
mjerr: https://www.reddit.com/r/Bitcoin/comments/386vh0/borromean_ring_signatures_new_research_by_greg/ has a bit of intuition about how schnorr signatures work

<maaku>
andytoshi: well there's some stuff written up, no? you're security proof that schorr is non-malleable

<andytoshi>
mjerr: ah, as maaku says there is also https://download.wpsoftware.net/bitcoin/wizardry/schnorr-mall.pdf

<andytoshi>
and http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html talks about how they can be blindsigned (it's not clear to me that ecdsa can be blindsigned)

<andytoshi>
mjerr: the equations for ECDSA are (r, s) where r is the x-coordinate of the point kG (k is a secret random nonce), and s = (H(message) + rx)/k

<andytoshi>
this weird use of the x-coordinate of kG, plus the fact that only the message goes into the hash function, make it impossible(?) to prove secure

<andytoshi>
the division by k means that these signatures can't be added, which prevents blinding and efficient multisig

<andytoshi>
the division by k also prevents batch-validation, which is basically adding several signatures with random weights then validating the sum

<andytoshi>
mjerr: i mean nobody has ever done it, and if you try standard proof techniques you will find you are blocked by one of the things i mentioned

<andytoshi>
mjerr: "proving secure" is a bit of a controversial thing, it means to prove that anyone who can forge a signature can also solve $hard_problem

<andytoshi>
so if $hard_problem (say, solving a random discrete log) is actually hard, then the signatures are unforgeable, given the constraints on the attacker that the proof assumes

<mjerr>
ah so if I would have lots of messages from one party, signed with the same private keys, but received over a long period, I could save lots of space by just adding all signatures?

<maaku>
mjerr: some background -- many crypto systems do not have formal security proofs, or at least useful ones of the sort andytoshi is talking about

<andytoshi>
mjerr: yes ... although you would be unable to prove that any specific signature is actually in the sum

<yoleaux>
"In mathematics, a discrete logarithm is an integer k solving the equation bk = g, where b and g are elements of a finite group." — https://en.wikipedia.org/wiki/Discrete_logarithm

<mjerr>
so these are much more difficult to solve than for example factoring large numbers (thus the lower keysizes vs RSA..)

<kanzure>
"deepmix: high privacy bitcoin mixing service" https://bitcointalk.org/index.php?topic=1175490.0 (i haven't evaluated this yet)

<kanzure>
still confused about this; in person rusty said there was no malleability fix available, and that OP_CLTV and OP_RCLTV and OP_CSV were not enough, but here's a comment saying otherwise? https://www.reddit.com/r/Bitcoin/comments/3lo8mb/serious_question_for_blockstreamcom_will_you_let/cv8ej9p (not from rusty)