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
tromp has quit [Remote host closed the connection]
<cjd>
or wait, do we even need to add the signature at all? can we not just make that value become one of the outputs for the miner ?
rhett has quit [Client Quit]
jaekwon has joined #bitcoin-wizards
<cjd>
assuming the miner mines pays out to at least 2 outputs and he knows the sum of secrets, he can make the first value be secret and the second value is what is needed to balance the numbers, he will need to be sure to store this secret key to disk as soon as he mines the block
<cjd>
but being a miner he should be capable of handing that
<andytoshi>
cjd: the sum of secrets is sufficient knowledge to spend both outputs at once
<andytoshi>
so if the rest of the block was created by one person, and the miner does not add a kG, his money can be stolen by that person
<cjd>
argh right :) 3
<andytoshi>
yup :(
<andytoshi>
i had a similar scheme before MW came out that made exactly this mistake
<cjd>
requiring the miner to produce 3 outputs is not a serious harm though
blockzombie has joined #bitcoin-wizards
<cjd>
now what about post-quantum? have you looked at it at all ?
<andytoshi>
cjd: 3 outputs doesn't help, one output plus an extra kG value is sufficent
<andytoshi>
as far as post-quantum, oleganza tells me he has a scheme for making CT quantum-safe, but i don't know any details yet
<andytoshi>
and i haven't thought at all about how that would affect mimblewimble
<cjd>
ok if you find pederson type stuff that runs post-quantum, please ping me
<andytoshi>
probably mimblewimble would be screwed, because "quantum safe" simply means that inflation remains impossible
proslogion has quit [Ping timeout: 260 seconds]
Emcy_ has joined #bitcoin-wizards
<andytoshi>
it does -not- mean that the commitments stay hidden
<andytoshi>
i will absolutely. this interests me as well
<andytoshi>
i might hafta go back to school and talk to the lattice people, i'm sure something similar can be done..
<cjd>
right
<cjd>
lattice or polynomials
<andytoshi>
maybe even LWE
<cjd>
I got really excited by HElib which does homomorphic and is thought by some people to be post-quantum but alas it does not have communitive behavior
<cjd>
but I got to brush up on C++ and have fun with polynomials
<andytoshi>
use rust ;)
<cjd>
no, you have to write things in other languages so you can *rewrite* them in rust
Emcy has quit [Ping timeout: 276 seconds]
<cjd>
(it's a meme, rust community people are constantly asking for everyhing to be rewritten in rust)
<andytoshi>
oh, ofc, otherwise you'll never be able to rewrite everything in rust
<andytoshi>
yep :P
<cjd>
ok I see the problem re sum of secrets
<cjd>
I'm annoyed that there is no solution and you have to sum entries for each block but dammit, 64 bytes per block is not bad
<andytoshi>
welll, with a pairing-friendly curve you can aggregate all the kG values and their signatures
Sleepnbum has quit [Ping timeout: 250 seconds]
<cjd>
I'd rather KISS because I want everything to run twice, once over a curve and second time using something post-quantum
<cjd>
if we're going to do another blockchain, IMO it's mandatory
<gmaxwell>
it appears to be currently impossible to construct schemes like this that are usefully 'post-quantum'.
dEBRUYNE has quit [Quit: Leaving]
<gmaxwell>
The kind of homomorphism that makes this work is also what makes discrete log easy on quantum computers.
<cjd>
that's... annoying
<sipa>
there is not even an efficient equivalent to diffie-hellman exchange in PQC, right?
<gmaxwell>
sipa: depends on how you define efficient.
<gmaxwell>
The isogenies ladder thing is kind of efficient. I've linked to it in here before.
<gmaxwell>
who knows if its even classically secure...
* sipa
hides in a superposition of corners
<cjd>
But we need what is effectively homomorphic encryption but with communitivity
<gmaxwell>
probably only a few dozen people in the world really understand it at a level enough to begin to evaluate its security.
<cjd>
IMO it's not harmful to roll out something without fully understanding it as long as you're backed up by well understood curves
<sipa>
commutativity?
<sipa>
or what is communitivity
<cjd>
x + y == y + x
Tiraspollll is now known as Tiraspolll
<sipa>
yes, commuativity, not communitivity
<cjd>
oh, I can't spell - as usual, sorry
<sipa>
seems i can't either
<gmaxwell>
cjd: if you just define the requirement as have commuativity, then that alone is pretty much sufficient to make it insecure against quantum computers.
<cjd>
I'm probably using the wrong word here, I mean that basically for any given plaintext there is a single ciphertext
<sipa>
gmaxwell: did you copy paste my misspelling?
<cjd>
yeah, that's annoying
<gmaxwell>
yes.
<gmaxwell>
I can't spell that word either, I was waiting for one of you to use it.
<cjd>
btw is there any plan to add an opcode to do like NTRU or something ?
<gmaxwell>
ugh. no.
* andytoshi
gets to use his math degree!
<andytoshi>
"commutativity"
<gmaxwell>
There is a straightforward path to have PQ secure bitcoin-- use hash based signatures.
<cjd>
ahh cool
<cjd>
that would make a neat press release
<gmaxwell>
Virtually all other PQ signature schemes are a pile of hopes and handwaves and also slow enough to verify to be problematic.
<andytoshi>
interestingly we can get a OWAS-like system that is also purely hash-based
<andytoshi>
that gmaxwell wrote about a couple years ago .. lemme see if i can find it
<sipa>
cjd: we even know how to introduce PQ crypto in such a way that the blockchain isn't burdened before EC actually becomes insecure
<gmaxwell>
I implemented hash based signatures eons ago, but just didn't publish it because I didn't want to deal with it showing up in idiotic altcoins.
<sipa>
cjd: by making all wallets use a 1-of-2 (EC or PQ) keys
<cjd>
anything which is PQ should be 2 of 2
Ylbam has quit [Quit: Connection closed for inactivity]
<cjd>
EC & PQ
<gmaxwell>
What sipa is referring to is a construction where you do a IF { AREWEPOSTQUANTUMYET_VERIFY standard checksig } ELSE { HASHBASED_PUBKEY }... and then after doomsday you just turn AREWEPOSTQUANTUMYET abort on execution.
<cjd>
oh wait, this is hash based, so indeed it's really boring and you can trust it
<andytoshi>
you could make it so that the 1-of-2 is softforkable into a 2-of-2
<andytoshi>
oh greg beat me to it
<sipa>
into a 1-of-1, really
<gmaxwell>
andytoshi: well I described it a bit differently. 1 of 2 into a 1 of 1. but same kind of thinking aplies.
justanotheruser has quit [Read error: Connection reset by peer]
<cjd>
Personally I would want to have PQ addresses
<sipa>
!hi5 gmaxwell
<gribble>
Error: "hi5" is not a valid command.
<cjd>
I mean we're not going to know when we're PQ, just the number of tin-hatters will grow slowly until it includes everyone
tromp has joined #bitcoin-wizards
<sipa>
nah, i'm sure there will be quantum denyers
<cjd>
:)
<gmaxwell>
the address reuse problem though is especially annoying with space efficient hash based signatures.
<cjd>
oh right, there is a security issue using an addr after you spent from it, right ?
justanotheruser has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 276 seconds]
<cjd>
In addition, our construction yields two more interesting features: 1) the ability to "convert" a Pedersen commitment into a lattice-based one
<gmaxwell>
I haven't seen that paper, but I've seen one of the papers it references; and IIRC it only gave a PoK but does not have full additive homorphism.
<cjd>
ok that's no good, I'm trying to seek in on the spot where they make their promises now...
Sleepnbum has joined #bitcoin-wizards
<gmaxwell>
it's not difficult to make a plain pedersen like commitment unconditionally sound, (but not unconditionally private)-- an elgammal ciphertext is an example of that.
<gmaxwell>
though it's easy to prove that something cannot be both unconditionally sound and unconditionally hiding, at least one of the two must be only a computational guarentee.
renlord is now known as pocoyo
<cjd>
if you can't add them up, what is the value over a concatinate-and-hash commitment ?
<Cloudflare>
quit
<Cloudflare>
this
<Cloudflare>
channel
Cloudflare has quit [Quit: WeeChat 1.5]
<gmaxwell>
because their scheme is still unconditionally hiding.
bumtime has joined #bitcoin-wizards
Sleepnbum has quit [Ping timeout: 244 seconds]
<cjd>
so basically they're rules-lawyering their paper into relevance :)
<andytoshi>
this appears to be weakly additively homomorphic, if you add too many commitments together then it'll fail to be binding to the sum
<cjd>
hmm interesting
<andytoshi>
it's possible (though i'd have to run through their calcs precisely) that you can add two commitments together while retaining bindingness, without compromising security, and then do this "reblinding" thing
<cjd>
right, the HElib does this
<cjd>
they keep a noise parameter and you can reEncrypt to bring down the noise
<gmaxwell>
andytoshi: AFAICT though their reblinding requires you know the commited value.
tromp has quit [Remote host closed the connection]
<andytoshi>
maybe we don't need unblinding. if you say that within a single transaction everything has to add to a commitment to zero, maybe this forces the noise on all outputs to be small (but still hiding? i dunno)
<andytoshi>
s/unblinding/reblinding/
<andytoshi>
will need to look into SVP lattice ring signatures .. *handwave handwave* this almost looks like we can import your rangeproofs into this system, it's so pedersen-like
<andytoshi>
but the security parameters in quantum crypto are weird. it's hard to say "x bits", you've got these radii and gaussian probabilites, i don't know how to think about them
<cjd>
hmm
<cjd>
I'm bad at math but I caught on to this HElib and I was playing with it, it allows you to encrypt a value with a public key and then add encrypted values
<cjd>
and it's based on NTRU
iwilcox has quit [Remote host closed the connection]
<cjd>
I can encrypt, add, decrypt but if I encrypt and add a set of polynomials which sum to zero, I do not get the same encrypted content at a plain 0 polynomial
tromp has joined #bitcoin-wizards
Cloudflare has joined #bitcoin-wizards
Cloudflare has quit [Quit: WeeChat 1.5]
Cloudflare has joined #bitcoin-wizards
<Cloudflare>
yo
<Cloudflare>
pocoyo: sup
jaekwon has quit [Remote host closed the connection]
<waxwing>
TLDR prove you DDoSed a server by using returned server sigs as proof of work, heh
mdavid613 has quit [Quit: Leaving.]
tromp has joined #bitcoin-wizards
<katu_>
cute :)
mdavid613 has joined #bitcoin-wizards
<cjd>
andytoshi: I am thinking that the problem you raised of the transaction payers robbing the miner later on is possibly acceptable in practice, if the miner creates his own transaction (e.g. paying money to himself) then he should be safe...
<cjd>
and the benefit of such a scheme is you can "sync the chain" by asking a peer for the most recent block and then asking for the txout set, then validating it and asking for (say) 1000 block headers or whatever it takes to make yourself happy that you are not being fed bullshit
tromp has quit [Ping timeout: 250 seconds]
<cjd>
you just take the block header number and calculate the amount of created money at that point, point multipliy that value and add it to all of the UTXOs
<andytoshi>
cjd: by "asking for the txout set" you mean also all the kG values
<cjd>
yes
<cjd>
and I guess the header contains [ HASH(utxoSet), HASH(prevHeader), number, difficulty, time, nonce ]
<cjd>
*blockNumber
<cjd>
oh crap you can fiddle with the difficulty, that's annoying
<andytoshi>
well the utxoSet needs to have proofs that the utxos have been committed to by the blockchain
<andytoshi>
i think
<andytoshi>
maybe not, maybe the header commitment is sufficient
<cjd>
the reason for the hash over the utxoSet is just so that somebody else cannot steal your mining fee
<cjd>
oh yeah also double-spend
<cjd>
there might be still another way to compress the header chain, if the header with the highest "work" each day points at the header with the highest work from the previous day, I think you can just skip blocks
<cjd>
so since you don't know if you're going to be the winner of a "checkpoint" block, just every block points at the checkpoint from the previous 144 blocks or such
<andytoshi>
cjd: are you familiar with compact SPV proofs?
<cjd>
uhhh I have heard this before but my memory is not working
<andytoshi>
i'm still unsure if it's OK that utxo inclusion proofs point to blocks other than the one they were included in
<andytoshi>
i guess so
<Taek>
[14:25:21] <cjd> andytoshi: I am thinking that the problem you raised of the transaction payers robbing the miner later on is possibly acceptable in practice, if the miner creates his own transaction (e.g. paying money to himself) then he should be safe...
<Taek>
would the transactors have to do something similar to make sure the miners couldn't steal from them?
<Taek>
supposing you ended up as the only transactor in a block
<gmaxwell>
andytoshi: I don't see why a tip commitment isn't fine (other than perhaps performance reasons)
<andytoshi>
Taek: presumably you, the transactor, would put a kG value in here
<cjd>
> the presence of lower-than-necessary hashes is in fact statistical evidence of more work done in the chain[Mil12]. <-- ok we're on the same page here
<andytoshi>
gmaxwell: yeah, i think it's fine
<instagibbs>
can someone reiterate the problem being discussed? I don't see in backlog
<cjd>
instagibbs: optimizations to mimblewimble
<instagibbs>
cjd, a little more than that :)
<cjd>
crap maybe we need to start a pad to keep track of the backstory here :|
<instagibbs>
> I am thinking that the problem you raised of the transaction payers robbing the miner later
<Taek>
(andytoshi is going to write a paper never fear)
<andytoshi>
lol. yeah, i'll write something, once things stop being in such flux
<cjd>
basically I'm proposing an optimization wherein each transaction is broadcast with the sum-of-secrets and the leftover money (fee) and the miner is the one who makes the signed emptystring rather than the transactors
<cjd>
instagibbs: ^^
<instagibbs>
oh i see, a problem with an optimization
<instagibbs>
I was confuzzled
<cjd>
yes, we're going over optimizations to try to make it require O(n) storage (n being unspend outputs) :)
<andytoshi>
cjd: if you make a transaction and broadcast the "sum-of-secrets" which is just your secret you can be robbed
<instagibbs>
cjd, I think you will lose a lot if you drop the chain stuff
<gmaxwell>
It's useful to take a step back and consider what MW actually does.
<gmaxwell>
It's constructs a proof interactively that (under relevant assumptions) no theft except double spending could have happened.
<instagibbs>
and inflation, at least in a particular history
<gmaxwell>
I don't think that property can be maintained if coin creation doesn't introduce new randomness.
<andytoshi>
instagibbs: no inflation can happen within a single tx
<cjd>
Can you elaborate? "new randomness" ?
<instagibbs>
andytoshi, no current inflation ;P
<cjd>
oh I think I get it, you're arguing that block rewards could be ripped off unless we check each block
<instagibbs>
yep
<cjd>
I need to showerthink about that one, I really want to not sync block headers :|
<instagibbs>
the newly generated coins also probably need to be blinded, otherwise they can just be extracted
<andytoshi>
cjd: i think you can decrease the block header length to log(n) as long as you commit to everything in each block
<andytoshi>
using the compact SPV stuff in the sidechains paper
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
Ylbam has joined #bitcoin-wizards
byteflame has quit [Ping timeout: 264 seconds]
<cjd>
I'm thinking you might get away with just downloading headers until the sum of difficulty goes over K (some comfort factor)
<cjd>
because in order for any money to be stolen as gmax suggests, the mining fees would have to have been stolen which is equivilant to mining a fake chain and you have reached your comfort factor of difficulty which is warranting that this did not happen
dEBRUYNE_ has joined #bitcoin-wizards
dEBRUYNE_ has quit [Read error: Connection reset by peer]
dEBRUYNE has quit [Ping timeout: 265 seconds]
<cjd>
I have to think about it more, in simplistic contexts I feel like I understand it but when I take it to bigger contexts I'm completely lost about it's security properties
<nsh>
what's the fee-stealing attack against miners?
<cjd>
so this is an attack against an imagined optimization of mimblewimble only
dEBRUYNE has joined #bitcoin-wizards
<cjd>
my optimization is when you create a transaction and you calculate ( (secretKeyInput + valueInput) - (secretKeyOutput + valueOutput + secretKeyChange + valueChange) )
<cjd>
instead of signing the emptystring with that result (as a secret key) you instead bcast the result along with the value of any leftover money
<cjd>
then the miner needs constructs a block knowing sum-of-secrets from each transaction and thus can create only 1 signature for the whole block
<cjd>
you following ?
<nsh>
roughly
Chris_Stewart_5 has joined #bitcoin-wizards
<nsh>
how many signatures would be required otherwise for mining a block?
<cjd>
one per transaction
<cjd>
did you read MW ?
<nsh>
oh, you mean this obviates the need for the signing at all when authenticating receipt of transaction?
<nsh>
only the miner signs?
<cjd>
you read mimblewimble? I just want to make sure we're talking about the same thing here...
* nsh
nods
<nsh>
we were talking about it notverymany hours ago
<cjd>
ok so right, you can get to 1 signature per block if we are ok to bcast the sum-of-secrets and the remaining value (fee) to the miner
<cjd>
because the miner merges everything
<nsh>
hmm
<cjd>
now for my next trick, I want to replace the signature which the miner creates with a simple output, now andytoshi reminds me that I have created a bug because now all of the outputs by the miner sum to a value which the creator of the transaction knows
<nsh>
ah, okay. took me a moment to understand this still authenticates
<cjd>
basically the creator of the transaction (knowing the sum of secrets, change amount, block reward and that the final sum is zero) can just deduce a transaction which spends all of the outputs from the miner
<nsh>
creator of which transaction?
<cjd>
lets imagine there is only 1 transaction being created in this block
<cjd>
1 person paying 1 other person and 1 miner
* nsh
nods
<cjd>
the payee knows the sum of secrets and if the final sum is zero, this implys he also knows the miner's secret and cna steal the fee
byteflame has joined #bitcoin-wizards
<nsh>
i think you need external-to-pederson consensus logic for blocks anyway
<nsh>
(for e.g. maturing block subsidies)
<cjd>
But I respond that if the miner includes an *input* for which only he knows the private key, he has masked the result and the creator of this single transaction cannot rob him
<nsh>
ah, right
<nsh>
(i think this problems goes away when you have lots of transactions anyway, or it's a very tight lottery)
<nsh>
no transaction recipient is especially privileged in being able to infer the final excess
<cjd>
having no signature per block may seem unimportant but once I have convinced you that this works, I go on to suggest that validating the chain does not require downloading even the whole chain of headers
<nsh>
heh, i think we need to process moonleaps one at a time
<cjd>
just download the "unspent txo set" (the commitments) and the most recent block header and as many block headers as you like, then calculate based on the block number the amount of money in circulation, point multiply that and add this to all commitments and expect zero
* nsh
nods
<nsh>
you can have some security comfort parameter; falsification of the past can still be made dependent on a fast-growing function of hashpower
<nsh>
just not clear exactly what needs to be committed yet
<cjd>
but gmax points out that I'm now violating some basic assumption of MW because I've completely dropped validation of who gets the block rewards and so I am wrestling with that as we speak
<cjd>
it makes so much sense the way I go but taking a different path it sounds so broken :)
<nsh>
hmm
<cjd>
it is as though any ring of commitments can be valid as long as it adds up to zero and spends X money
<cjd>
so you must only create 1 block to fool someone
<nsh>
no party with merkle
<cjd>
I think there is a very simple bypass of that issue but I need to think more
<cjd>
anyway even if you put a signature in each block, what you need to download to reconstruct a block header is [ sig, time, nonce ], everything else can be inferred
<cjd>
so you're looking at like 4.2MB per year with a 10mn block rate
<cjd>
*10 minute
proslogion has joined #bitcoin-wizards
<cjd>
actually 5.8 with the public keys which are also needed
<proslogion>
in MW, can i send someone some coins, then get around to manage to receive a tx from this pubkey of him as another identity so i can get his blinding factor, then next time when i do business with him, i would use the same blinding factor and amount as i used last time, so i can replay the second tx despite him not wanting to send the other identity coins this time?
<cjd>
are you assuming no change address ?
<proslogion>
yes
<cjd>
also consider that a pubkey is never used twice
nonaTure has quit [Ping timeout: 250 seconds]
<proslogion>
what if somebody does? anything other than client-side check?
<cjd>
because you have to interact with his computer in order to make the transaction so it's the decision of the programmers, not of the user
<cjd>
side-effect: you can't get paid if your computer is turned off
<cjd>
but that's part of MW that we can't seem to fix
<nsh>
(well, you could use pegs with another chain that allows interactionless payments for certain situations)
<cjd>
oh crap I have a problem with my whole optimization, once the payee reveals the sum-of-secrets the payer can rob him :(
<proslogion>
ah, no, no, you cannot reuse the same r, like bitcoin, the r you use is dependent on the tx a pubkey receives as well!
<proslogion>
it's a chain
<cjd>
so we're back to 5:1 chain compression which is not great
<cjd>
unless the payee adds an input to the tx which is going to kill off some use cases
<andytoshi>
proslogion: yes, replay attacks are possible if you reuse addresses. but you create the addresses when you receive payments, and you're the one who'll get robbed. so don't reuse keys.
<andytoshi>
s/address/keys/ everywhere, MW really doesn't have addresses
<cjd>
I'm really unhappy that we can't get rid of sig-per-tx, not only does that mean a large chain but it also means that anyone who downloads each block (a miner for instance) can reconstruct the transactions from that block and effectively de-anonymise the money flows
<gmaxwell>
huh?!
<instagibbs>
the original MW paper allows this, but it's not necessary at all
<cjd>
Maybe I'm talking shit but my approach would be to try to fit groups of cancelled inputs and created outputs with signatures
<cjd>
it's computationally expensive but I don't feel like it's expensive enough
<instagibbs>
<andytoshi> ah, there's a simple fix, publish k1G and k2, sign with k1G but make the transaction excess be (k1 + k2)G
<instagibbs>
<andytoshi> and when combining transactions all the k2's just get added together
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
<cjd>
is that not a variant of publish k1G and k2G ? in which case I just need to fit 2 sigs together with a handful of inputs and outputs...
Chris_Stewart_5 has joined #bitcoin-wizards
<andytoshi>
cjd: no, there is no sig with k2
<andytoshi>
it's an explicit value
<cjd>
ahh right, so you just add up k2 every time you merge transactions in memory
<cjd>
very good :)
dEBRUYNE has quit [Ping timeout: 244 seconds]
<proslogion>
andytoshi: i don't get it, your r is determined partially by the r of your sender, i wonder if reusing a r is at all possible
<andytoshi>
heh, yeah, this was what i had before MW came out (without the k1G, so it was insecure for the same reason your optimization was). i realized my mistake when MW came out, but i feel a bit better that voldemort made the opposite mistake :P
<andytoshi>
proslogion: i think you'd be able to do it, at the very least by creating two outputs, skewing one to reuse r, and skewing the other in the opposite direction
<cjd>
dammit why do we need these signatures floating around everywhere :|
<proslogion>
andytoshi: right you can just adjust the k value to achieve that effect, i forgot
dEBRUYNE has joined #bitcoin-wizards
<cjd>
so what makes the signature-over-emptystring work is the fact that it's not cancellable
<cjd>
you can point to a utxo (a commitment) and cancel that when you are spending another transaction but the signature is forever
<cjd>
if you could cancel a signature then the spender can still rob the recipient
<andytoshi>
cjd: well if you can aggregate the proof of discrete logs that's still not possible .. so it's not as morose as you make it seem
<andytoshi>
we could use BLS sigs for the kG values, in a pairing-friendly group, and then you could aggregate all the sigs into one and it'd still be ok
<cjd>
ok, aggregatable sigs, that would be cool
<andytoshi>
hmm actually maybe there is still a risk here, unsure
<cjd>
but I fear the more cool math we use, the more difficult it will be to take this to post-quantum
<andytoshi>
yeah
<cjd>
but 5:1 compression means a 16GB blockchain assuming every tx in bitcoin was replayed into this chain...
<andytoshi>
so we need two things right now: commitments that can be shown to sum to 0 (we don't need full homorphism, just sum to 0); some overflow prevention (right now we use a rangeproof); some extra randomness and a way to prove knowledge of the randomness
<cjd>
IMO overflow prevention is not needed, we just need to prove knowledge of r
<cjd>
a.k.a prove that they're not making up garbage to balance the books
<andytoshi>
cjd: but then the outputs themselves could overflow. i make a 10BTC output and a -10BTC output and just never spend the latter
<andytoshi>
(and put zero in)
<andytoshi>
this is why we have the overflow protection in "traditional C"
<andytoshi>
"traditional CT"
<cjd>
uhh why would you use signed integers?
<andytoshi>
cjd: everything works in finite rings
<cjd>
oh I see, you're protecting against overflow of the whole 256 bit number
<andytoshi>
if you take the group order minus n, that's -n
<cjd>
got it
<andytoshi>
yep
<andytoshi>
none of the quantum stuff i've seen changes this (i don't see that anything could be zero-knowledge without it actually)
<cjd>
changes what?
<andytoshi>
changes the fact that every number is modulo something, and can thus be "negative" in a way that's not intrinsicly definable
<cjd>
ahh ok
rusty2 is now known as rusty
<cjd>
anything I can read about the types of range proofs used here ?
<cjd>
yeah, I was looking really for the gritty detail of the rangeproof
<gmaxwell>
you could redesign it from the text file, and borromean paper; though you'd miss some of the optimizations.
<cjd>
all right, thanks, going to get some food and then I'll take a look
<waxwing>
gmaxwell: shame in MW you lose the whole data-embedding thing 'cos can't share the blinding factors, right
<gmaxwell>
waxwing: correct.
<proslogion>
the data embedding sounds like a weird sales pitch though
<waxwing>
proslogion: well useful for amount, too
<waxwing>
altho' not necessary
<proslogion>
can you give that space to counterparty people etc?
<waxwing>
when you consider how loudly people complain about not being able to embed stuff in blockchain :)
<waxwing>
yeah you beat me to it :)
<waxwing>
although, hmm, it's private to sender/receiver by default
<gmaxwell>
it _must_ be private.
<gmaxwell>
or it blows up the ZK property of the proof.
<waxwing>
i was just thinking of auditors
<gmaxwell>
the reason in works in CT is that the value being sent and blinding factor is non-private to both the sender and reciever.
<gmaxwell>
so the proof doesn't need to be ZK with respect to them. :)
<gmaxwell>
for MW it does, so no data storage in it.
<andytoshi>
well you do still have free s values, you can bastardize some storage into them if you've got an out-of-band key. but you'd need to structure the data heavily so your recipient can determine which s-value is forced (and therefore has no data)
<andytoshi>
doing so will reveal the value to anyone who can decrypt, though not directly
Chris_Stewart_5 has quit [Ping timeout: 264 seconds]
<andytoshi>
waxwing: as for auditors, if i've got a commitment C = vH + rG, i can give them v and sign with rG and that'll prove the value
<gmaxwell>
yes you could carry a tiny amount of data to people who knew the value without meaningfully disclosing the blinding factors.
<andytoshi>
if people already know the value, you can use every free s value as an encryption channel, that doesn't reveal anything about the blinding factor
<proslogion>
just curious, do you guys read every link drop? someone just show up on this channel and send one message is so easy to miss
Giszmo has quit [Quit: Leaving.]
<andytoshi>
proslogion: probably every link drop gets noticed, that's pretty weird behaviour. and this one happened to be on a quiet time.. then it was forwarded around a lot outside of IRC