--- Day changed Wed Oct 25 2017
00:00 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket     
02:19 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
02:51 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has joined #joinmarket     
04:12 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has joined #joinmarket     
04:16 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has quit [Ping timeout: 255 seconds]     
04:17 -!- quitobro [~quitobro@pool-108-41-0-186.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
04:18 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has joined #joinmarket     
04:19 -!- wxss [~chatzilla@89.238.178.92] has joined #joinmarket     
04:32 -!- Giszmo [~leo@190.8.79.154] has joined #joinmarket     
04:37 -!- Giszmo [~leo@190.8.79.154] has quit [Ping timeout: 246 seconds]     
05:12 -!- Giszmo [~leo@ip-52-226-107-190.nextelmovil.cl] has joined #joinmarket     
05:22 -!- wxss [~chatzilla@89.238.178.92] has left #joinmarket []     
05:23 -!- akrmn [~akrmn@88.red-83-52-44.dynamicip.rima-tde.net] has joined #joinmarket     
06:00 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has quit [Ping timeout: 260 seconds]     
09:13 -!- MaxSan [~user@91.214.169.69] has joined #joinmarket     
09:16 -!- Giszmo [~leo@ip-52-226-107-190.nextelmovil.cl] has quit [Ping timeout: 240 seconds]     
09:25 -!- quitobro [~quitobro@gateway/vpn/privateinternetaccess/quitobro] has quit [Quit: quitobro]     
09:31 -!- Giszmo [~leo@ip-121-236-219-201.nextelmovil.cl] has joined #joinmarket     
09:57 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 264 seconds]     
10:02 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined #joinmarket     
10:21 < trotski2000> waxwing: why does Joinmarket sometimes imports some coinjoin destination addresses and adds them as "watch-only" to Core? Example, I do a coinjoin and I send you some coins - I now see the coins in your address in the "watch-only" tab of Core.
10:25 -!- MaxSan [~user@91.214.169.69] has quit [Ping timeout: 248 seconds]     
10:27 < waxwing> trotski2000, if you are doing a sweep to an external address, then none of the output addresses belong to you. So it imports one of those addresses to allow it to monitor the transaction.
10:28 < trotski2000> waxwing: I understand. Is there a log where I can see which external addresses were imported?
10:30 < arubi> debug.log :)
10:31 < arubi> oh probably not which address..  read that as txid at first
10:32 < trotski2000> arubi: mmm... that's going to make it difficult for me :)
10:32 < arubi> but you will see txids, which will lead you to transactions, which will lead you to addresses, which you could run against 'validateaddress' and see if any of them is yours\watchonly :)
10:33 < trotski2000> :)     
10:33 < arubi> assuming the wallet got to hear about that tx broadcast
10:34 < waxwing> in jm-cs it gets imported into 'joinmarket-notify' account
10:34 < arubi> oh if it actually watches the address, then you'll see it in debug.log too when the node hears about a block with it
10:34 < arubi> ah, there you go
10:34 < waxwing> can't remember the other version, i have a feeling it imports into the existing account.
10:34 < waxwing> you can check in add_tx_notify in the blockchaininterface.py
10:34 < trotski2000> ok, it works!
11:16 -!- Giszmo [~leo@ip-121-236-219-201.nextelmovil.cl] has quit [Read error: Connection reset by peer]     
11:30 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has quit [Ping timeout: 260 seconds]     
11:33 -!- Giszmo [~leo@ip-228-233.219.201.nextelmovil.cl] has joined #joinmarket     
11:45 < waxwing> i did a lot of update of  https://github.com/AdamISZ/snicker-poc ; the readme shows a workflow for testing that seems to work ok, although it's very basic. if anyone feels like trying it out on regtest or testnet let me know.
11:49 < arubi> ah I was just looking through the .py earlier
11:50 < arubi> cool, will read
11:52 < waxwing> i think i'll write a separate doc with a spec for the encrypted message format (it's very simple), that way anyone else could write code for either side.
11:52 < waxwing> also the whole 'scanning the blockchain' part is .. an exercise for the reader :)
11:53 < waxwing> the ecies part is the same as electrum, i.e. compatible
11:54 < arubi> an indexing node is just a bit more useful :)  I didn't get to the encryption part yet, in my mind it's just been "we xor" and I left it at that
11:55 < waxwing> sure but it's more analogous to rsa
11:55 < waxwing> i.e. you encrypt *to* someone's pubkey (admittedly it's actually ecdh under the hood but that's what it replicates)
11:56 < waxwing> arubi, re scanning the blockchain it did occur to me that anyone could scan and publish it (perhaps regularly)
11:56 < arubi> oh yea, even just block explorers
11:57 < arubi> you'll have to have some index or re-used scripts
11:58 < arubi> I was kinda toying with a different bulletin board of the makers, publish the sha256(pubkey), if the rmd160 of that has funds in it, you're either an idiot or willing :)
11:59 < arubi> er, it's the hash160(pubkey) of the output in a tx, not the input where we get the pubkey from
11:59 < arubi> something like, I consolidate a bunch of inputs into an address, I tell you the preimage for its rmd160, then you can just get one of the pubkeys from the tx that paid it
12:00 < waxwing> oh i think i follow
12:00 < arubi> but telling you the rmd160 preimage, you can re-use it, so I left the idea for now..
12:00 < arubi> maybe the hash itself can be used in some way, but it's not like in jm where the taker does the gymnastics, and it's supposed to be not too interactive
12:01 < waxwing> yeah, im assuming we want zero interactivity. (for testing we can mess around of course, but in real version).
12:02 < waxwing> but i take your point there's at least some wiggle room in as much as the receiver may take some action in advance, without interacting with the proposer.
12:02 < arubi> right, that's the best feature really even if it's requires pubkeys on chain.  with bip114-vault, there's p2pkv0 which is actually pay to bare pubkey again
12:02 < waxwing> such as the obvious one of deliberately creating a reused key
12:03 < arubi> if the preimage can be used in some single serve manner, than maybe, but I couldn't think of a good one
12:03 < arubi> s/than/then
12:20 < arubi> waxwing, 
12:21 < arubi> there is a way I can communicate a secret to you without knowing what it is by signing something
12:21 < arubi> if that message depends on my identity, then it's single serving
12:22 < arubi> writing this down
12:23 < arubi> so say I sport a tx paying some address, that tx has a signature in it, it's the one belonging to the spender
12:23 < arubi> if I come up with some message that's worth your while, I can do pubkey recover on that message + your signature, and get a pubkey
12:24 < arubi> you immediately know the private key for that pubkey, because you know the DL for the pubkey that made that signature, and you can know the k value from that
12:24 < arubi> and from the k value, you can know the DL for the recovered key
12:25 < arubi> if the message is something that pays to that pubkey, then you obviously are getting paid
12:25 < waxwing> i haven't understood what you mean yet
12:25 < arubi> well, considering all other possible shenanigans
12:25 < waxwing> first, you 'sport' a transaction?
12:25 < arubi> er, spot*
12:26 < waxwing> so you see a transaction and you want to send a message to the spender, is that it?
12:27 < arubi> yea that's it..  actually the only thing about it is that it doesn't need a pubkey in the script
12:27 < arubi> in the scriptsig*
12:28 < arubi> yea, maybe not so revolutionary as I first thought it was :)
12:28 < waxwing> i still don't get the part at the start 'i can communicate a secret without knowing what it is'
12:29 < arubi> what it's meant to read as is, I can produce some authenticated message to you where the result is some private key that only you know.  and really now re-thinking it's not even cryptographically possible..
12:30 < arubi> waxwing, thanks for rubber duck, it helps :)
12:30 < waxwing> well but that was part of the snicker idea; you can send a 'k', encrypted to the pubkey on the blockchain, and then only they know the private key of P + kG
12:31 < waxwing> (same idea used in tons of other things e.g. p2ch as andytoshi said)
12:31 < waxwing> rubber duck?
12:31 < arubi> right, I just went over this part in the repo, still a bit confused about the hmac stuff but not so bad
12:32 < waxwing> hmac part is just part of ECIES, as i noted in the comment there i just reproduced electrum's implementation with different underlying libraries.
12:32 < arubi> rubber duck, re. when you explain your code to someone who first just looks at it :)
12:32 < waxwing> oh ok; never heard that one
12:33 < arubi> right, ^, I don't have a lot of experience for things like needing to authenticate encrypted messages, so I'll need to look into that for why it's done at all
12:34 < waxwing> it depends, but there are nasty things that can be done with block ciphers if you don't authenticate.
12:34 < waxwing> not knowing the plaintext doesn't prevent an mitm from achieving things by modifying ciphertext alone.
12:35 < arubi> yea I figured something has to exist for when you're not friends with the sender
12:35 < arubi> ah, I see, malleability strikes again
12:35 < waxwing> yes similar, except the effects can be much worse, in some protocols anyway.
12:35 < waxwing> no particular claims about the effects here
12:37 < arubi> cool, I'll go read some more before dinner.  maybe go over some encryption stuff on the weekend :) 
12:38 < waxwing> for that type of stuff i found the cryptopals/matasano exercises very enlightening.
12:38 < arubi> that's where I'll head then.  not the first time this is being recommended to me
12:43 -!- lnostdal_ [~lnostdal@77.70.119.51] has joined #joinmarket     
12:45 < arubi> oh I should probably rephrase re. no cryptographically possible, it /is/ possible for one party to produce random secrets that only the second party can know, but it's impossible to include the public point for that secret in the message itself, unless you know the secret in advance
12:47 < waxwing> hmm not sure, see above P+kG=Q you can know Q but not know its privkey, whereas your counterparty does (knows x st P=xG and you tell him k)
12:48 < waxwing> i wonder if you're maybe thinking about signatures, looking at your wording
12:49 < arubi> it's the same equation like a signature, yes
12:49 < arubi> only the terms are moved a bit
12:50 < arubi> sec     
12:51 < arubi> I guess I could just try to derive it, we have sR = zG + rP right
12:52 < arubi> so the recovery operation would be P = (the other side) times in inverse of r
12:53 < arubi> so if you know the DL for R, you can just go backwards
12:53 < waxwing> i think you must be considering a more complicated case than the one you stated; according to what you stated in "oh i should probably rephrase...", my counterexample Q = P + kG provides a contradiction.
12:54 < waxwing> the public point for that secret is Q, and its privkey is k + x, and the owner of P knows that if k is transferred, whereas the creator of k does not.
12:55 < arubi> wait, so there's P = (zG - sR)/r, right?
12:56 < arubi> anybody can derive P, that's easy, but only someone with the DL for R can do the other way,  dG = (zG - s*k*G)
12:56 < waxwing> sure but i don't want to consider a more complicated construction when a simpler one P+kG provides an answer, no?
12:57 < arubi> yes!  just wanted to clarify that the reason it doesn't actually work like your solution is because I can't make the message z to contain P in the first place :)
12:57 < waxwing> but that's what i wanted to clarify, are you specifically talking about signatures.
12:58 < waxwing> because that has a more specific set of parameters/constraints right.
12:59 < arubi> ah yes, I got what you meant now.  I guess it does, not every spending tx has a pubkeys in it, but really the vast majority do
12:59 < waxwing> no, don't assume i know what you're thinking about, i don't necessarily :) i was directly addressing the statement in your msg starting with "I should probably rephrase", not anything else
13:00 < waxwing> if you're thinking about a specific setup with tx, signature and so on, then we'd have to rewind a bit
13:01 < waxwing> so i think maybe you're trying to reproduce the effect of encrypting to a pubkey somehow, but using an ECDSA signature?
13:01 < arubi> okay, so I'll restart.  the current setup works beautifully, except for one thing which is pubkey reuse
13:01 < waxwing> right, so your goal is to remove that.
13:01 < arubi> yes, that's the final thing
13:01 < arubi> yes     
13:01 < arubi> it's not really encrypting at all though
13:02 < arubi> it's generating a secret for the other party, that's mostly it
13:03 < arubi> the idea initially was that I can encrypt to the R in the signature, and also produce an authenticated message in one go
13:03 < waxwing> oh right. hmm that's interesting, i have a vague memory of proslogion suggesting something similar
13:04 < waxwing> annoyingly rfc6979 in libsecp256k1 makes that hard, but anyway, go on
13:04 < arubi> not very, you don't need those because if you know the private key for the pubkey that was used with the sig, you can get k from algebra easy
13:05 < waxwing> so since R is broadcast, proposer (Alice) can encrypt to that and use R + k'G as the destination address?
13:05 < waxwing> "from algebra easy" - oh ok, good point
13:06 < arubi> yes, but alice can't place the produced random key in the message itself, only carol can do that, but she doesn't know the message :(
13:07 < waxwing> terminology here: i'm using Alice for the one who scans the blockchain and creates the proposal, and Bob for the one who receives the proposal
13:07 < arubi> bob = carol then ^
13:07 < waxwing> so iiuc (probably not) there is no problem then.
13:07 < waxwing> Alice chooses random k' (' because not the k in the sig), takes R, encrypts (k' || proposed_tx) with R in ECIES, sends/broadcasts it
13:08 < waxwing> the proposed_tx contains an output whose destination pubkey is R + k'G
13:08 < arubi> oh!     
13:08 < waxwing> Bob does algebra to get k for his signature, then the new privkey is k + k'
13:09 < arubi> yes, it's like reverse contracthash 
13:09 < arubi> alice tweaks and reveals a signed message
13:09 < waxwing> reverse sign to contract maybe? well whatever :)
13:09 < arubi> yea :)
13:11 < waxwing> why didn't i think of that? :) i would say because i've been ignoring ECDSA for Schnorr, except, it's really no different at all i Schnorr.
13:11 < waxwing> in     
13:12 < arubi> for me it was pretty weird learning about schnorr after pursuing ecdsa for so long, suddenly you're like "that's it..?"
13:12 < arubi> really makes you hate patents :)
13:12 < waxwing> right
13:12 < waxwing> right +1
13:13 < waxwing> well if this is right, it makes the idea about twice as appealing to me. and it was already very appealing.
13:14 < waxwing> but i'm still suspicious why we weren't interested in this kind of approach before, when we thought about it a year ago.
13:14 < arubi> I didn't know about the tweaking being possible
13:16 < waxwing> "Simple Non Interactive Coinjoins with Keys Encrypted to R" ? ;)
13:16 < waxwing> SNIC is just no good now :)
13:16 < arubi> so I tweak your R, and I can obviously sign a message to a pubkey that is my tweaked R' + your R..  you can validate everything.. it's pretty sweet!
13:18 < waxwing> now we just need the whole of Amazon AWS to store all the encrypted coinjoin proposals
13:18 < arubi> maybe bloq could host it
13:19 < waxwing> :)     
13:29 -!- Giszmo [~leo@ip-228-233.219.201.nextelmovil.cl] has quit [Read error: Connection reset by peer]     
13:29 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: lnostdal]     
13:51 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has joined #joinmarket     
13:56 -!- zxccxz [5db781f6@gateway/web/freenode/ip.93.183.129.246] has joined #joinmarket     
13:56 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
13:58 < arubi> oh I just noticed proslogion is actually highlighted, hi :)
13:58 < waxwing> he doesn't hang around with the filthy hoi polloi on irc nowadays ;)
13:59 < arubi> pfft, maybe he's onto something
14:00 < waxwing> well he's on slack so i'm not sure :)
14:00 < arubi> one time I tried to get an invite and couldn't even figure out how, it's like you have to actually talk to the owners
14:01 < arubi> maybe it was some specific channel, not sure what it was
14:01 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has quit [Ping timeout: 252 seconds]     
14:08 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has joined #joinmarket     
15:16 -!- coins123 [~coins123@unaffiliated/coins123] has quit []     
15:44 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 240 seconds]     
17:01 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer]     
17:22 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #joinmarket     
18:05 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer]     
18:19 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #joinmarket     
18:53 < proslogion> arubi hi
19:54 -!- Giszmo [~leo@pc-224-130-104-200.cm.vtr.net] has quit [Ping timeout: 260 seconds]     
20:08 -!- Giszmo [~leo@ip-140-236-219-201.nextelmovil.cl] has joined #joinmarket     
21:48 -!- proslogion [~proslogio@45.116.80.169] has quit [Ping timeout: 264 seconds]     
21:48 -!- proslogion [~proslogio@104.236.136.185] has joined #joinmarket     
23:21 -!- coins123 [~coins123@c-208-25.net-185.wadsl.it] has joined #joinmarket     
23:21 -!- coins123 [~coins123@c-208-25.net-185.wadsl.it] has quit [Changing host]     
23:21 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket