00:00:28shen_noe:what if we change this to check that the blinding factors don't add exactly to zero, but rather the sum of inputs and outputs commitments leaves zG
00:00:39shen_noe:so sum of input commitments - output commitments is a commitment to zero
00:00:51shen_noe:secret key only known to the sender
00:01:26shen_noe:now, take a ring signature over C_1, ..., C_s, ..., C_n where C_i are possible input commitments taken ad-hoc from blockchain
00:01:35shen_noe:C_s being the one belonging to signature
00:01:47shen_noe:actually a ring sig over C_1 - outputs, ..., C_s - outputs, ..., C_n - outputs
00:02:02shen_noe:so sender can prove that 1/n of these is a commitment to zero
00:02:28shen_noe:(the LLW ring sig's are nice for this purpose)
00:03:33shen_noe:after this, proceed as in normal CT (proving outputs are commitments to positive values), using boromean sigs if that helps,, etc
00:06:31shen_noe:*C_s being the one belonging to the "signer"
00:14:18andytoshi:shen_noe: i'm not quite sure what you gain here .. you need that every `inputs - outputs` is zero, so proving that 1/n of them are seems like it'd just be wasteful
00:14:47MRL-Relay:[shen] andytoshi, I want to prove that 1/n of inputs - outputs is a commitment to zero
00:15:08MRL-Relay:[shen] to not reveal which input index belongs to me
00:15:31andytoshi:oh, i see 1/n of inputs
00:16:44andytoshi:i guess, you are combining this with monero's usual ringsigs..
00:16:58shen_noe:yeah, or the LLW that you guys used (which are more efficient)
00:17:01andytoshi:and what it gets you is that you can ring-sign with arbitrary input sets, and not care about their sizes
00:17:21shen_noe:and hide amounts better than currentlyy
00:18:22andytoshi:yeah, the exact scheme is not so important, what i'm trying to get is the high-level .. you have (a) a ringsignature over several inputs which proves you own one of them, (b) a "ring-CT proof" that one of these inputs is the right size
00:18:46andytoshi:so, you need to link these two signatures somehow to make sure the input you're spending and the input whose value you're using are the same one
00:18:54andytoshi:but i'd guess this is easy once you write out the algebra
00:19:35andytoshi:but off the top of my head i'm not certain how
00:20:31andytoshi:or maybe the original ring signature is not important actually..
00:20:38shen_noe:so you need to link the two sigs: I think you can include all the original C_in's so a verifier can recreate the original sig themselves
00:20:49andytoshi:you use the delta from 0 in the `input - outputs` as your verification key
00:21:13andytoshi:then if you are able to prove that `input - outputs == 0` this also proves you own the input
00:21:26andytoshi:(i think)
00:21:37shen_noe:so in language of CT paper, (x+z)G + aH = y1G + b1H + y2G + b2H
00:21:44shen_noe:where x+z = y1+y2
00:21:48shen_noe:and a = b1+b2
00:21:54shen_noe:then z is sk
00:24:27andytoshi:so, let's think how this would work for a one-input-one-output tx, with a ringsize of one
00:24:39andytoshi:so there is no ring sig magic here, i'm just trying to figure out when/how the pubkey is determined
00:25:33andytoshi:with the current CT setup you've got something like an output value of `rG + vH` where r is secret and v is the hidden value
00:25:36shen_noe:ok, so above equation I guess becomes (x+z)G + aH = xG + aH
00:25:48andytoshi:yeah, sure, let's use your notatin
00:26:18andytoshi:the output is (x + z)G + aH? z is the key, a is the value, what is x?
00:26:40shen_noe:x + z = y is constructed as an equation of blinding factors
00:26:53shen_noe:oh no y
00:27:05andytoshi:ok i think you don't need both x and z
00:27:42andytoshi:oh, no, you do, cuz you have to reveal zG at some point here
00:27:48andytoshi:which if z was the only blinding factor, would reveal a
00:29:18andytoshi:so my question is: what is the output? a value commitment (x + z)G + aH as well as a verification key zG?
00:29:47shen_noe:output is yeah, yG + aH, where a is the sent amount, y is blinding factor
00:29:57andytoshi:kk gotcha
00:30:34shen_noe:so let's see (x + z)G + aH - yG + aH = zG
00:30:41shen_noe:if z = y
00:30:55shen_noe:and presumably you know log_G zG
00:30:57andytoshi:if x = y you mean
00:30:58shen_noe:since you made it
00:31:24shen_noe:(sorry been up late)
00:31:44shen_noe:so if x = y, then (x + z)G + aH - yG - aH = zG
00:32:16shen_noe:now, you know log_G zG, so you can sign make a signaturre from the above difference
00:32:45andytoshi:yeah, understood
00:32:56andytoshi:can you remind me what normally happens? basically z = 0 in that case
00:33:29shen_noe:normally, z = 0, so it's more like xG + aH - yG - aH = 0 if x = y
00:33:32andytoshi:oh, never mind, i'm being silly
00:33:38shen_noe:the network verfies it's actually "is" zero
00:33:41shen_noe:rather than commitment to zero
00:33:49andytoshi:i was like "how do you prove you know the input" but that's not the commitment-proof's job in the original system
00:34:38andytoshi:kk so now i need to think for a few mins about if you can game this somehow .. i guess not if zG is in the output and can't be changed
00:35:07shen_noe:greatly appreciated
00:35:43andytoshi:ok, so i think i can choose {z, zG} then spend any output like this by taking the input point and adding zG to it to get my output point
00:36:21andytoshi:so i don't actually know x or a in this case
00:36:39shen_noe:hmm, let's see how that would work
00:36:55shen_noe:so C_in is chosen arbitrarilyy
00:37:12shen_noe:you don't know C_in = xG + aH (you don't know x or a)
00:37:46shen_noe:so zG + C_in - C_out = zG if C_in = C_out
00:37:59andytoshi:(i'll let you work thru this, meanwhile i think i have a fix, tho it's a little bigger than a single sig)
00:37:59shen_noe:is that what you mean?
00:38:16shen_noe:so basically you can send funds back to their outputs?
00:38:20shen_noe:I mean inputs
00:38:40andytoshi:hmmm, maybe that's all this wolud do..
00:38:55shen_noe:it still might cause a problem somehow
00:40:32andytoshi:is zG part of the output that's being spent? or is the idea is it's only computed as C_in - C_out?
00:41:09shen_noe:so I'm thinking the input you know is xG + aH, then you decompose x into x = z + y
00:41:24shen_noe:and then use y = sum outputs blinding factors
00:41:27shen_noe:and z is sk
00:42:30andytoshi:my question is whether z is forced by the output that you're spending
00:42:38andytoshi:i think the answer should be yes
00:43:24andytoshi:like, what i'm saying is the output will be {C_in, zG}
00:43:24shen_noe:it seems like it's forced not by output, but by the blinding factors you pick
00:43:32andytoshi:ok, so the output is only C_in?
00:43:57shen_noe:yeah C_in is something you've received from previous transaction
00:44:14andytoshi:then i can choose C_in from an arbitary output, choose z randomly, and produce a tx whose output is C_out = C_in + zG
00:44:24andytoshi:now i know z and can sign anything with it
00:44:43andytoshi:i think putting zG in the output fixes this
00:44:44shen_noe:lets see
00:45:12shen_noe:C_in = xG + aH, C_out = xG + aH + zG
00:45:32shen_noe:then C_in - C_out = -zG
00:45:56andytoshi:..right, and then i know -z and can sign for that
00:46:17shen_noe:so you can find z, then you can send funds to C_in + zG
00:46:42shen_noe:let's see
00:46:50shen_noe:what about the range proof in this case?
00:47:06andytoshi:there should've been a range proof attached to C_in right?
00:47:08andytoshi:i just copy that
00:47:19shen_noe:now it's a range proof for C_in + zG though
00:47:32andytoshi:oh hmm
00:47:37shen_noe:does it still work the same?
00:47:48shen_noe:(this is extremely helpful btw thx)
00:48:14andytoshi:one sec i gotta find the rangeproof writeup to remind myself
00:48:49andytoshi:it's about:blank
00:48:53andytoshi:lol https://people.xiph.org/~greg/confidential_values.txt
00:50:23shen_noe:so it looks something like C_in + z_G == C_1 + C_2 + ... + C_5
00:50:56shen_noe:where C_i represent proofs of the binary coefficients of C_in + z_G
00:51:18shen_noe:so C_1 proves that first binary coefficient of C_in + z_G is 0 or 1
00:52:17andytoshi:yeah, so actually what you do is add zG to one of the C_i's
00:52:18shen_noe:so to prove C_1 you have to know either log_G (C_in + z_G) or log_G (C_in + zG - H)
00:53:06andytoshi:so if i have a signature for xG on m, can i mar this into a sig for (x + z)G on m, knowing only z?
00:53:25andytoshi:(x is just an arbitrary secret value, it doesn't correspond to anything we've mentioned so far)
00:54:03andytoshi:one sec,gotta do this on paper..
00:54:33andytoshi:yeah you totally can for schnorr sigs
00:54:47shen_noe:using homomorphic prop?
00:55:00andytoshi:yeah, s -> s + zH(m||r), r -> r
00:55:31andytoshi:if s = k + xH(m||r) this gives you s' = k + (x + z)H(m||r)
00:55:49shen_noe:so that would be like signing with x + z, without knowing x, and only knowing xG
00:56:14andytoshi:being unable to do this is -not- a standard security property that i'm aware of, i doubt it holds for any standard sig system
00:56:38shen_noe:so how do you sign with (x + z) without knowing (x + z) ?
00:56:56andytoshi:oh, wait, i was assuming you had a signature on x
00:57:06andytoshi:but obviously you don't, not on your new transaction..
00:57:38andytoshi:i'm beginning to think this is ok
00:58:19shen_noe:my super-caffeinated brain which slept 2 hours thinks its ok
00:58:28shen_noe:but that's not usually enough to actually "be" ok
00:58:42shen_noe:as my advisor has shown me numerous times
00:58:42andytoshi:i do think this is gonna be a bear to argue correctness for
00:58:46andytoshi:yeah lol
01:00:07andytoshi:ok, my next attack is, maybe you know (x + z) but not x or z..
01:00:25andytoshi:i think you can't do this because x is gonna be different for each bit of the range-proof in the output
01:00:45shen_noe:yeah, as long as output is not 1H
01:00:58shen_noe:also, to show commitmment to zero, you have to know z?
01:02:33andytoshi:ok, so, you ringsign with (C_i, C_i - H) to proof either 0 or 1, and there are always multiple random C_i's
01:02:53andytoshi:-but- i think we can attack this only marring one of them, you do C_1 -> C_1 + zG say
01:03:29andytoshi:now, the remaining C_i's have unchanged so you can keep their part of the rangeproof
01:04:04andytoshi:and you set things up so that you know the DL of (C_1 + zG) even tho i don't know z or the DL of C_1
01:04:12andytoshi:now you can reproduce that part of the rangeproof
01:04:27andytoshi:-but- i think you're screwed now because you have to produce a signature with z on top of this right?
01:05:01shen_noe:yeah, at the end you need to sign with z
01:05:12andytoshi:ok, i think this is safe actually
01:05:15shen_noe:to prove inputs - ouputs = commitment to zero
01:05:31andytoshi:cuz you always have to sign with (a) z and (b) z + r, where r is some randomness from the input's rangeproof
01:05:57andytoshi:you don't know r unless you own the output, so you can't do both unless you own the output
01:07:20shen_noe:I think that's right
01:08:04andytoshi:oh, but now have we broken the value proofs?
01:08:22andytoshi:like, can you go spending with outputs > inputs?
01:08:40andytoshi:(i think) the answers is no, as long as nobody knows the DL of your generators
01:09:36shen_noe:I was hoping the value proofs were pretty much the same as in CT
01:10:21shen_noe:so.. I think outputs = inputs is guaranteed by commitment to zero of the original summation
01:11:14shen_noe:and then value proofs are just to prove C_out has aH with a in the right range
01:11:57andytoshi:i think you're right
01:13:33shen_noe:gmaxwell invented ct also: so I was thinking of modifying the summation equation (In1 + In2 + In3 + plaintext_input_amount*H...) -
01:13:33shen_noe:(Out1 + Out2 + Out3 + ... fees*H) == 0.
01:13:41shen_noe:to be instead a commitment to zero
01:14:35shen_noe:now take a ring sig over (C_1 - \sum outputs, ..., C_s - \sum outputs, ..., C_n - \sum outputs)
01:14:40shen_noe:where s is secret index
01:14:42andytoshi:shen_noe: i think 100% of CT was gmaxwell and adam3us, i had nothing to do with it
01:14:55shen_noe:ahh i see I saw your name on the boromean paper
01:15:06gmaxwell:shen_noe: adam proposed in his original thread that showing knowedlge of the discrete log of the blinding factor as a replacement for the normal signature (so long as you don't mind losing all the useful script properties)
01:15:11andytoshi:yeah, i wrote the paper but all i invented was the time travel stuff
01:15:23andytoshi:which was purely an explanatory device
01:15:36shen_noe:gmaxwell, ahh nice
01:15:55shen_noe:I've just seen your writeup of it actually
01:16:00gmaxwell:shen_noe: but if I send you coins I also know your blinding factors, so the send is not a payment (as I can claw the funds back) unless we use an interactive proptocol to have you generate the blinded coins.
01:16:50gmaxwell:(and their range proofs, etc)
01:17:05andytoshi:oh, i see it now, yeah, you can't hide z from the payee without interaction .. dammit
01:17:14shen_noe:oh i see... hmm yes sender would know the receivers blinding factors obviously
01:17:30gmaxwell:so it didn't really seem like a big gain, also since the rangeproofs can often be omitted.
01:17:54andytoshi:well, the gain was really for monero, so you could ringsign over inputs of varying values
01:18:00shen_noe:the reason I was considering this, is if you modify for CryptoNote, then you need someway tto hide the input index
01:18:37gmaxwell:Adam actually had a proposal to for a ringsig version, but I'm not sure if it was complete or correct.
01:19:15shen_noe:would love to see that.. hmm
01:19:25shen_noe:do you remember how many steps in the interactive protocol?
01:19:32gmaxwell:I think the ringsig is not very exciting though since coninjoin works so will with the CT approach... and the ringsig has other costs.
01:19:52shen_noe:i.e. most sigma protocols (3 steps) can be made non-interactive
01:20:15andytoshi:shen_noe: it won't be a sigma protocol, here both parties need knowledge of secret data
01:20:17gmaxwell:shen_noe: it requires interaction because the reciever needs to have a secret.
01:20:25shen_noe:yeah, it was more of a thought exercise, since the size with ring sigs included makes it fairly large
01:20:49shen_noe:I see, so something like receiver passing you their blinding factor
01:21:52gmaxwell:shen_noe: they can't do that or you can spend their coins. Rather the reciever has to create two outputs and their range proofs and tell you their blinding factor sum and value sum.
01:21:52shen_noe:I wonder if you could "key-image" outputs
01:22:07shen_noe:and then since change-addresses are one-time keys...
01:22:29gmaxwell:then you can create a transaction which includes their outputs where only you know the discrete log of the sum of the blinding factors.
01:22:36andytoshi:shen_noe: yeah, the LWW paper has a really generic way of making key images, you just have another generator H, then the key image of xG is xH, and you provide a proof-of-equal-discrete-logs
01:22:51andytoshi:or ring-proof-of-equal-discrete-logs or whatever
01:24:06shen_noe:andytoshi, I'll have to read that more carefully
01:24:33gmaxwell:(but then you get into problems where you have to prohibit spending those two coins in the same transaction and other stupidity.)
01:24:57shen_noe:so.. maybe it would work, with some caveats on how you spend coins..
01:25:11CodeShark:are many of the insights in partially homomorphic crypto using the discrete log problem applicable to lattice-based crypto?
01:25:11gmaxwell:and interaction on send.
01:25:43shen_noe:like all oupts are otk's by force, and can be spent once
01:25:46andytoshi:CodeShark: i don't -think- so
01:27:19andytoshi:CodeShark: lattice crypto is about having a secret basis in which matrices can be efficiently manipulated in sorta ad-hoc ways, i'm not aware of something similar to this "have two generators so given aG + bH nobody can know its discrete log"
01:27:38gmaxwell:shen_noe: double spending is not an issue there; the problem is the symmetry of the reciever and the senders knoweldge. It can be broken, with a cost, but the benefit is pretty small.
01:28:00CodeShark:my understanding (which admittedly isn't as good as I would like) is that lattice based homomorphic encryption is based on ideals
01:28:41CodeShark:as in ideals of rings
01:28:49shen_noe:gmaxwell, right, I was momentarily confused - so makes the transaction with the coins first wins
01:29:02CodeShark:but I really need to read up more :p
01:29:08andytoshi:CodeShark: oh, i'm only dimly aware of that side of the literature
01:29:19andytoshi:if you have any intuitions they probably trump mine
01:29:53gmaxwell:gmaxwell has left #bitcoin-wizards
01:30:19CodeShark:* CodeShark pulls out his old algebraic geometry texts :)
01:34:21shen_noe:so maybe it would need a "coins" received function where receiver scans blockchain and when they find their coins, send it to a new address.. I'm not sure what that implies
01:34:53shen_noe:andytoshi thx for feedback
01:35:00andytoshi:np shen_noe
01:35:05andytoshi:but i think now the complexity is not worth it
01:35:15andytoshi:interaction is pretty much a dealbreaker
01:35:32shen_noe:yeah: there is a much simpler method (but not as good) which already works in monero actually
01:35:46shen_noe:just split up your amount into like n = n_1 + n_2 + ... + n_m
01:35:56shen_noe:and the cardinality of possiblities is 2^m
01:36:55shen_noe:(since one-time keys for change addresses and receive addresses)
01:38:08shen_noe:although I think you could get away with not full interaction: receiver only interacts by scanning blockchain and "accepting" their transaction
01:38:22shen_noe:by sending it to a new address they control
01:38:40shen_noe:with new blinding factors
01:38:42andytoshi:i see what you're saying, yeah, that works
01:38:59shen_noe:so it's open to chargebacks until the receiver decides they want it
01:39:23andytoshi:i think
01:39:41shen_noe:and (unless other problems) it costs an additional transaction fee
01:40:53shen_noe:in any case, gotta run
02:57:26MatrixBridge:MatrixBridge is now known as 5EXABJ6GG
05:38:12gmaxwell:https://github.com/scipr-lab/libsnark/commits/master < got code for sha256 15 days ago
05:53:21CodeShark:so you can compress many levels of sha256 into a single proof whose size does not depend on the number of levels in a tree?
05:55:46CodeShark:oh very cool
05:57:10CodeShark:so it's an optimized "gadget" within an NP-complete language
05:57:55Luke-Jr:hm! is it possible, I wonder, to design a PoW that *must* be performed in a SNARK? <.<
05:59:32CodeShark:creating the proof is expensive - but in principle verification could be made much simpler than just brute force hashing
05:59:50CodeShark:that's why the NP-complete part :p
06:00:54Luke-Jr:right, I'm wondering this as a way to prevent block withholding on even p2pool
06:00:55CodeShark:substitute "in practice" for "in principle" :)
06:01:09gmaxwell:Luke-Jr: you've asked this before. The answer is no.
06:01:18Guest30532:Guest30532 is now known as amiller
06:02:37gmaxwell:CodeShark: yes, you can, so long as you're willing to take on a whole host of new strong cryptographic assumptions; and a long (like 30 seconds to minutes) proving time. And verification that runs on the order of 200 proofs per second.
06:03:40CodeShark:it's based on paired crypto?
06:04:24gmaxwell:_pairing_ crypto; though it has many more assuptions than just the hardness of discrete logs in bilinar groups and the normal stuff for most pairing crypto.
06:04:57CodeShark:pairing crypto, yes. that's what I meant :)
06:05:43gmaxwell:(I'm not dissing the approach I think it's just important to keep in mind Magic's Price)
06:06:12CodeShark:are the other assumptions largely surrounding statistical vs. computational zero knowledge?
06:06:20gmaxwell:no, absolutely not.
06:06:46CodeShark:so all these approaches don't assume anything more than computional zk, right?
06:06:48gmaxwell:(well the non-falsifyable one is)
06:06:55CodeShark:or specifically, this library
06:07:13gmaxwell:CodeShark: the ZK in this is perfect. The soundness is computational.
06:07:24CodeShark:ok, got it
06:07:34gmaxwell:No succinect proof system for genral NP can have better than computational security in any case (owing to a counting argument).
06:07:46gmaxwell:(er better than computational security for soundness)
06:09:24gmaxwell:but I'm not talking just about the hardness, I mean there are new strong assumptions; e.g. that certant functions cannot be efficiently computed; for which no proof currently exists that reduces them to an existing prior known strong assumption. (like the hardness of the computational discrete log problem in a bilinear group). They sound plausable and fortunately its an interesting enough area t
06:09:30gmaxwell:hat people are actually working on breaking them and such.
06:09:53CodeShark:so what are the other big assumptions with bilinear group stuff?
06:10:15CodeShark:besides difficulty of discrete log, of course
06:12:47CodeShark:oh, hmm
06:13:10CodeShark:nvm, I was late on the keyboard :p
06:14:44gmaxwell:The papers go over them, though unless you're a current postdoc in that subfield you'll probably (like me) mostly just shrug at them. :)
06:17:45CodeShark:this whole zkSNARK thing does seem too good to be true...so yeah, there's a price for that magic
06:18:06gmaxwell:CodeShark: one of them is that it has trusted setup.
06:18:25CodeShark:is there no known way around that still?
06:19:25gmaxwell:There are proposals to potentially use multiparty computation for it, so the trusted setup gets some threshold security.
06:20:10gmaxwell:People are also working on other schemes for NP proofs with a totally different cryptographic basis which won't have that problem; but their proofs will be less efficient.
06:20:25CodeShark:less efficient for the prover? the verifier? or both?
06:20:57gmaxwell:Less space efficient. They may well be faster to verify.
06:22:34CodeShark:by totally different cryptographic basis you're referring to something other than bilinear crypto or pairing crypto?
06:24:01CodeShark:but still using discrete log? or LWE or something else?
06:28:14gmaxwell:No; likely using using just random oracle assumptions.
06:29:15gmaxwell:PCP theorem plus fiat shamir tell us that at least in principle there are efficient computationally sound, statstically private proof systems for NP; that have no strong assumptions except the RO used for the fiat shamir. Though making them pratical is hard.
06:30:06gmaxwell:(as the most direct routes require you to e.g. build a hashtree over a set of bits with substantially more entries than atoms in the universe)
06:42:52gmaxwell:andytoshi: do you see any obvious way to do an _efficient_ proof of polysig equivilence. E.g. say there is a set of keys for a polysig, and some unknown permutation, and I want to prove to you that a given polysig series corresponds to that set without revealing the permutation?
08:05:18barjavel.freenode.net:topic is: 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
08:05:18barjavel.freenode.net:Users on #bitcoin-wizards: andy-logbot davi ThomasV binaryatrocity_ OneFixt Mably sneak damethos arubi_ spinza drwin mjerr d1ggy Xh1pher gmaxwell prodatalab Zooko-phone amiller [7] thrasher` 5EXABJ6GG moa Dr-G2 gielbier DougieBot5000 SubCreative sparetire_ PaulCapestany GAit jmcn_ melvster btcdrak AaronvanW SwedFTP JackH bosma gill3s c0rw1n BigBitz dc17523be3 SDCDev NewLiberty_ Aquentin nuke1989 ebfull Tiraspol Luke-Jr Starduster paveljanik alferz nsh AlexStraunoff
08:05:18barjavel.freenode.net:Users on #bitcoin-wizards: Graet bedeho veox Emcy maaku go1111111 execut3 mkarrer_ akrmn UllrSkis goregrind barthG K1773R fkhan Alanius sparetire luny justanotherusr mengine devrandom sdaftuar narwh4l adam3us cdecker badmofo Madars roybadami LeMiner waxwing digitalmagus lnovy MRL-Relay theymos stonecoldpat epscy dgenr8 mountaingoat pollux-bts Jaamg rustyn forrestv espes gnusha Cory tucenaber bliljerk101 elastoma ThinThread jonasschnelli huseby null_radix catcow adams__
08:05:19barjavel.freenode.net:Users on #bitcoin-wizards: Taek rasengan cfields phantomcircuit kanzure sadoshi TD-Linux GreenIsMyPepper richardus sl01 michagogo otoburb isis ttttemp kinlo nephyrin` Krellan vonzipper larraboj_ mariorz coryfields_ optimator stevenroose BlueMatt eric afdudley warptangent ryan-c crescendo prosodyContext mappum wiz nickler_ jbenet kyuupichan livegnik pigeons davout Fistful_of_Coins mikolalysenko fluffypony BananaLotus Logicwax scoria andytoshi superobserver STRML jouke
08:05:19barjavel.freenode.net:Users on #bitcoin-wizards: jaromil fenn gribble nanotube Guest87353 grandmaster indolering BrainOverfl0w [ace] catlasshrugged throughnothing poggy guruvan dignork yoleaux gavinandresen Anduck helo grubles heath roasbeef ggreer Iriez starsoccer Muis Xzibit17 comboy petertodd wumpus a5m0_ jessepollak dansmith_ [d__d] sturles HM midnightmagic merlincorey warren azariah_ jrayhawk qawap Meeh_ mm_1 tromp_ koshii _whitelogger dasource jcorgan sundance bsm117532 CodeShark
08:05:19barjavel.freenode.net:Users on #bitcoin-wizards: gwillen lclc wizkid057 ajweiss so s1w yrashk CryptoGoon artifexd runeks kumavis platinuum yorick Apocalyptic iddo smooth weex berndj harrow harrigan brand0 leakypat Eliel xabbix @ChanServ AdrianG morcos
14:33:21andytoshi:gmaxwell: (a) no, and (b) i think this is pretty hard actually, adam and i ran repeatedly into a related problem (proving a sum of keys was actually computed using the keys, without eg adding r to one and -r to another) when we were trying to make constant-size ringsigs. i don't remember the details but it was related to permutations (since the real key had to occupy a specific "slot" or something
14:33:23andytoshi:like that which ofc should not be revealed) and we got nowhere
14:33:36andytoshi:i'll think about how to do it in say linear time wrt the size of the permutation tho..
14:35:14andytoshi:but what was killing us was not so much our efficiency requirements, it was that you can't do much of anything to aggregate keys except adding them together, and that loses a ton of information
14:36:41kanzure:would there be any value in limiting the number of transactions in each block? rather than block size.
14:36:46kanzure:or, in addition to block size.
14:37:31andytoshi:kanzure: it'd encourage coinjoining
14:48:37maaku:kanzure: value? yes it'd make the merkle trees smaller
14:49:13maaku:but while it encourages coinjoining, it works against OWAS or some p2p market ideas
14:52:32nsh:tends towards signer/coalition centralization
14:53:26nsh:[even if there exist privacy-enhancing coalitions, you can bet dollars to donuts they will be sparse among the types of coalition that emerge when you incentizive them]
14:58:39kanzure:is there a good reason we don't have a good aggregatable signature scheme yet
14:58:53kanzure:like a million-to-one aggregation?
15:04:47kanzure:"Secure proxy signature schemes for delegation of signing rights" https://eprint.iacr.org/2003/096.pdf
15:09:32nsh:kanzure, scaling behaviour is probably a factor
15:10:18maaku:kanzure: what do you mean by "we have"? there's good proposals
15:10:26kanzure:coinjoin is not sufficient
15:10:30maaku:though the one I like involves the pairing assumption
15:10:39kanzure:not sure which other proposals you are talking about
15:10:51maaku:kanzure: do you know OWAS? one-way aggregate signatures
15:11:21kanzure:i'm aware of the concept, but not of any specific bitcoin proposals
15:11:39maaku:well it'd be a hard-fork change, so it hasn't got much attention
15:11:40kanzure:this seems to be focused on anonymity
15:11:48maaku:(but it's something you could do in a sidechain!)
15:11:58kanzure:i'd be fine with an aggregate signature scheme that has no anonymity
15:12:05maaku:kanzure: for what purpose then?
15:12:28kanzure:abridging intermediate transaction history
15:12:41kanzure:instead of dumping all transactions into a blockchain
15:12:45maaku:kanzure: oh, well lightning
15:12:49maaku:and micropayment hubs
15:12:52kanzure:lightning is only a bi-directional channel
15:13:19kanzure:i want to send 100k payments and have each of my 100k different receivers also send 10k payments, and none of the intermediate transactions should need to be on the blockchain itself
15:13:35kanzure:and also, it would be nice if there could be arbitrarily-deep transaction chains that bridge the history of an even larger transaction chain
15:14:08maaku:kanzure: lightning is much more than a bidirectional channel, which is why it needs so many changes
15:14:29maaku:i'm not sure why you think you can't do that with micropayment channels
15:14:42nsh:* nsh listens attentively
15:14:49kanzure:as you increase the number of people on each side of the channel, you increase the probability that one of them will want to throw the transaction into the blockchain to close the channel
15:15:03maaku:so? it only affects their channel
15:15:10maaku:it doesn't require anything else to hit the chain
15:15:23kanzure:well, the other users have to reopen channels
15:15:32maaku:no, channels are direct
15:15:47maaku:if you close your channel with hub A, I don't have to close my channel with hub A
15:16:20maaku:now you move an insane amount of money around in one direction at once, it is true you will saturate one direction of a channel
15:16:32kanzure:closing a channel means putting a transaction on the blockchain....
15:16:51maaku:"well, the other users have to reopen channels" <-- this is incorrect
15:17:01kanzure:i was talking about a single channel
15:17:04kanzure:it's correct.
15:18:20maaku:if you have 100k people receiving payments, and 15 of them decide to close their channel, 15 transactions hit the chain
15:18:32maaku:i'm sorry, I'm just not seing the issue. maybe I'm dense
15:19:24nsh:* nsh doubts there's a way to nontrivially improve on that
15:20:00nsh:sorry, doubts there's a trivial way to improve on that
15:25:31kanzure:so, that's unrelated to a single channel, i think
15:25:52maaku:nsh: me being dense? probably. nootropics?
15:25:55kanzure:the idea was to abridge transaction history, not "hope that they all collectively decide to close their channels after transacting in a way that happens to reduce the total number of transactions"
15:26:17nsh:* nsh is definitely the denser :)
15:26:42nsh:kanzure, abridging without cooperation is... i don't want to say impossible
15:27:00nsh:yeah, moonmathematical
15:27:03maaku:otherwise... nothing i know
15:27:07kanzure:i'd be okay with cooperation.
15:27:09nsh:that's a nice compromise between possible and impossible :)
15:27:13nsh:well, not closing your channel is cooperation
15:27:30maaku:kanzure: well, an active fee market is also important
15:27:31kanzure:no, snarks cooperation would probably involve stuff like "here, sign my fart"
15:27:57kanzure:instead of just "plz don't close your channel"
15:28:28maaku:kanzure: where I'm being dense is I don't understand the concern. closing a channel is not an externalized cost, due to fees
15:28:39maaku:if you want to close your channel, fine. pay up
15:29:07maaku:well, modulo all of bitcoin being an externalized cost to non-mining full nodes, etc. etc.
15:30:10Guest87353:Guest87353 is now known as mr_burdell
15:30:31kanzure:so you believe that large quantities of transactions- perhaps billions- will have users that choose to use software that tries to find ways to close the channels in a way that minimizes the number of fees and number of transactions that get into the blockchain?
15:31:15nsh:no, i imagine the people paying the users will be strongly incentivized to minimise the overhead for the recipients
15:31:21nsh:and that will tend towards streamlining
15:31:22maaku:kanzure: when transaction fees are $100/tx, yes
15:55:26c0rw1n:c0rw1n is now known as c0rw|away
16:05:01andytoshi:kanzure: OWAS is slow and depends on pairing. it hasn't been implemented 'til now because it'd be a controversial hardfork for bitcoin plus it'd have bad scaling consequences (why there has been no "pairing-crypto alt" idk, nobody here has done it because there are better uses of our time)
16:06:07andytoshi:but given gmax's comments above about how OWAS interacts with CT, and adam's periodic musings on a "BDH-secure sidechain" (meaning one where pairing crypto's security assumptions are considered sufficient), i'm sure something will crop up in this area sooner or later..
16:08:03nsh:well, i think once alpha proves the sidechains concept is feasible [assuming it does], then there might be a cambrian explosion
16:08:20nsh:to put it in provocative hyperbolic terms, after my idiom
16:17:32maaku:the only reason OWAS wasn't in alpha was because CT was easier to get out the door first
17:16:24maaku:maybe-interesting observation : with onion routing of lightning payments you can have "hidden" payment addresses
17:21:54Luke-Jr:can't you already? just payment protocol over tor
17:23:48nsh:CT can easily allow for hidden payment addresses by using address-ratcheting [OTR-style] through the side-channel. doesn't deal with the first address issue though
17:24:13nsh:(likewise OTR doesn't deal with identity/presence management)
19:15:06Tiraspol:Anyone here who can help me with some java questions?
19:29:20fluffypony:Tiraspol: ##java
21:47:59c0rw|away:c0rw|away is now known as c0rw1n
22:54:08c0rw1n:c0rw1n is now known as c0rw|zZz