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