--- Day changed Tue Oct 24 2017 01:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 01:23 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 01:42 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 252 seconds] 01:43 -!- jonasschnelli [~jonasschn@bitcoinsrv.jonasschnelli.ch] has joined #secp256k1 03:57 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #secp256k1 09:31 -!- xinxi [~xinxi@39.109.214.22] has joined #secp256k1 09:31 < xinxi> @gmaxwell Hi, I want to discuss with you about CT. 09:32 < xinxi> Can we remove the range proofs? 09:33 < sipa> no 09:33 < sipa> CT is tribially insecure without them 09:33 < xinxi> @sipa Bitcoin output amount cannot be negative and cannot exceed the group order. If we choose H = xG and keep x small, then it's impossible to overflow. 09:34 < waxwing> xinxi, the point is the network cannot see the amounts, so it can't be verified that they're not negative. 09:34 < sipa> what is x? 09:35 < xinxi> @sipa H and G are defined in https://elementsproject.org/elements/confidential-transactions/investigation.html 09:35 < sipa> xinxi: if the ratio between G and H is known, pedersen commitments can be forged 09:35 < sipa> what is x? 09:36 < waxwing> i could tell you but then i'd have to kill you 09:36 < xinxi> Can we randomly generate x in a way so that no one knows it? 09:36 < sipa> yes, that's what we do in CT 09:36 < sipa> but we can't know x is small 09:36 < sipa> nor do i see how it matters 09:36 < xinxi> I mean randomly generate a small x and nobody knows it. 09:36 < sipa> no 09:37 < xinxi> no? 09:37 < xinxi> no convincing way or no? 09:37 < sipa> first explain me how that would help 09:37 < sipa> you still need rangeproofs to guarantee values are not negative 09:37 < xinxi> values are unsigned so they cannot be negative. 09:37 < sipa> ... 09:38 < sipa> the point is prove to the network that they aren't 09:38 < sipa> yes, i know it is illegal to pick a negative value 09:38 < sipa> but you still need to be able to verify it 09:39 < xinxi> Yeah, you can still pick a negative number for example -1, which needs to be represented by N - 1, where N is the group order. 09:39 < sipa> yes 09:39 < sipa> the point is preventing that 09:39 < sipa> that's what the range proof is for 09:39 < xinxi> But N -1 is much larger than 2^64 -1 and thus cannot be represented in Bitcoin. So by definition, it's impossible to use a number larger than 2^64 - 1. 09:39 < sipa> ... 09:40 < sipa> it is *illegal* to do so 09:40 < sipa> but not impossible if you don't enforce it 09:40 < xinxi> Cannot we enforce that? 09:40 < sipa> yes, we can 09:40 < sipa> using a rangeproof 09:40 < xinxi> I mean without using range proof. 09:41 < sipa> no 09:41 < sipa> i don't see how 09:42 < xinxi> OK, so first make sure the x in H = xG is small, so if you multiply H with your amount, it will never overflow. 09:42 < waxwing> saying 'how can we do it without a range proof' is basically asking how can we prove the range without a range proof; what you really mean is, how can we make the proof smaller. we can publish the exact value, but that defeats the purpose of the system. 09:42 < waxwing> xinxi, the value of x in H = xG is irrelevant here. 09:42 < waxwing> only relevant thing is that no one knows it. 09:42 < waxwing> (otherwise the system is broken) 09:42 < xinxi> If it does not overflow, we won't need range proof. 09:42 < sipa> xinxi: x does not matter here 09:42 < waxwing> nope, not the case 09:42 < sipa> x is not the amount 09:43 < sipa> having a small x in no way prevents you from using amount N-1 09:43 < xinxi> right, x is not the amount. I mean if x is big, then amount * x * H will overflow. 09:43 < sipa> you're terribly confused but i don't see where 09:44 < sipa> x*H is a point 09:44 < sipa> points don't overflow 09:44 < sipa> they just exist, without order 09:44 < xinxi> by overflow I mean amount*x will be bigger than the group order. 09:44 < sipa> if amount is N-1, then amount*x will always overflow 09:44 < andytoshi> xinxi: stop thinking about overflow. these scalars all live in finite fields, they have no notion of sign or magnitude. the problem is that amounts are supposed to be integers but the projection from integers into this field is noninjective 09:44 < sipa> regardless of the value of x 09:44 < andytoshi> please look up every term i just used 09:45 < xinxi> @andytoshi Yeah, I understand how cyclic groups work. 09:46 < sipa> but everything you're saying about overflow is nonsense 09:46 < andytoshi> then i'm even more confused about where your misunderstanding is 09:46 < xinxi> Let me code an example for you guys. 09:46 < andytoshi> ignore `x`. suppose we were in a group and that H and G are generators of disjoint subgroups 09:46 < sipa> it is entirely irrelevant here 09:46 < andytoshi> and also assume the projections are somehow expensive so this doesn't break privacy. now thecre is no `x` 10:05 < xinxi> Please check https://pastebin.com/LkZzBJKJ. The secp256k1 library is from https://github.com/ethereum/py_ecc/blob/master/py_ecc/secp256k1/secp256k1.py 10:05 < xinxi> @sipa ^ 10:07 < waxwing> the amounts are not published to the network, only the pedersen commitments 10:08 < andytoshi> i'm confused how you got inputs of size 16 and 12 when it appears to be a consensus rule that every output is value 14 10:08 < xinxi> @waxwing The key is that can you spend an invalid amount? 10:09 < xinxi> If the amount cannot be represented, you won't be able to spend, right? 10:09 < andytoshi> also `x` is totally irrelevant and `N/x` is either meaningless or 0 10:09 < andytoshi> also this is trivially insecure in multiple ways 10:11 < xinxi> @andytoshi 12, 16, and 14 are just examples. 10:12 < andytoshi> i recommend you study group theory some more. i'm really not sure what to make of this, sorry 10:13 < xinxi> @andytoshi which part of group theory? 10:13 < andytoshi> develop an intuition for all 3 of the isomorphism theorems 10:14 < xinxi> @andytoshi Sure. didn't I make my idea clear enough? 10:14 < waxwing> i don't think this is about group theory. xinxi seems to be thinking that if the amount is not an legal bitcoin amount, then it wouldn't work for some reason. 10:14 < xinxi> @waxwing exactly. 10:15 < waxwing> but i thought gmaxwell gave a very clear example in the original doc of how this could allow the creation of nonexistent bitcoins. 10:15 < waxwing> in a CT to CT transaction the network has absolutely no idea what the amounts are (embedded in the pedersen commitments in the aH part), it just knows that they add up. 10:16 < andytoshi> xinxi: amounts are not encoded or represented anywhere in CT. 10:16 < waxwing> well they're encoded for the receiver :) 10:16 < andytoshi> well, ok, but they don't need to be 10:16 < xinxi> @waxwing but if you want to spend the amount of if the receiver wants to check the amount, they can immediately see the previous transaction is not valid, right? 10:16 < waxwing> right 10:16 < waxwing> xinxi, what if you are your own receiver? :) 10:17 < waxwing> or, well, free bitcoins are always nice whoever it is :) 10:17 < xinxi> Then I won't be able to use that output as an input. 10:17 < waxwing> how does the network know it's illegal? 10:18 < waxwing> it's still in CT outputs where there are no amounts, only pedersen commitments that are guaranteeing the additive property 10:21 < xinxi> @waxwing You can always send that to yourself, but you won't be able to spend it. 10:21 < xinxi> SO you actually lost your coins. 10:23 < waxwing> no; look at gmaxwell's example in the writeup. creating nonexistent coins through negative amounts will not necessarily be visible at all when you spend in non-CT (i asssume that's what you're thinking). the final non-CT amounts may be entirely legal. 10:23 < andytoshi> (a) there is nothing preventing the spend of any coins, (b) you don't need to spend bad outputs to steal money in a rangeproof-less CT 10:26 < xinxi> alright, that makes sense. let me think more about it. 10:35 -!- xinxi [~xinxi@39.109.214.22] has quit [Remote host closed the connection] 10:35 -!- xinxi [~xinxi@39.109.214.22] has joined #secp256k1 11:08 < xinxi> @waxwing I just corrected a few errors in the previous example https://pastebin.com/eYrqMjtq 11:10 < andytoshi> why is H defined insecurely? 11:13 < xinxi> @andytoshi it's secure if no one knows x. the purpose is to make sure if we want to attack like the example, we will use an invalid Bitcoin amount. 11:14 < xinxi> But as there is no way to to check if an amount is invalid or not without revealing the amount, so this methods seems not working 11:14 < andytoshi> ok, sounds like you're halfway toward understanding what we're saying 11:15 < andytoshi> the next half is realizing that `x` doesn't matter and that if it's hardcoded to 1000 then everybody knows it 11:15 < xinxi> @andytoshi well, I did not plan to hard code it. :-D 11:16 < xinxi> it's just for demonstration purpose. 11:21 -!- xinxi [~xinxi@39.109.214.22] has quit [Remote host closed the connection] 11:22 -!- xinxi [~xinxi@39.109.214.22] has joined #secp256k1 12:43 -!- molz [~molly@unaffiliated/molly] has joined #secp256k1 20:19 -!- xinxi [~xinxi@39.109.214.22] has quit [Remote host closed the connection] 20:36 -!- xinxi [~xinxi@39.109.214.22] has joined #secp256k1 23:16 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 23:41 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #secp256k1