--- Day changed Thu Dec 27 2018
02:30 -!- GitHub165 [GitHub165@gateway/service/github.com/x-llddyagizyfaqnas] has joined #joinmarket     
02:30 < GitHub165> [joinmarket-clientserver] jameshilliard opened pull request #270: zip(*value_freq_list[1:]) needs to be a list (master...history) https://git.io/fhkms
02:30 -!- GitHub165 [GitHub165@gateway/service/github.com/x-llddyagizyfaqnas] has left #joinmarket []     
03:35 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
03:41 -!- bsm117532 [~mcelrath@c-24-61-184-150.hsd1.ma.comcast.net] has quit [Ping timeout: 268 seconds]     
03:47 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
04:29 -!- GitHub117 [GitHub117@gateway/service/github.com/x-fljxauzyncagincg] has joined #joinmarket     
04:29 < GitHub117> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fhks8
04:29 < GitHub117> joinmarket-clientserver/master ad77769 James Hilliard: zip(*value_freq_list[1:]) needs to be a list
04:29 < GitHub117> joinmarket-clientserver/master 9466b68 AdamISZ: Merge #270: zip(*value_freq_list[1:]) needs to be a list...
04:29 -!- GitHub117 [GitHub117@gateway/service/github.com/x-fljxauzyncagincg] has left #joinmarket []     
04:29 -!- GitHub129 [GitHub129@gateway/service/github.com/x-mpdpqmpwbpvnhlao] has joined #joinmarket     
04:29 < GitHub129> [joinmarket-clientserver] AdamISZ closed pull request #270: zip(*value_freq_list[1:]) needs to be a list (master...history) https://git.io/fhkms
04:29 -!- GitHub129 [GitHub129@gateway/service/github.com/x-mpdpqmpwbpvnhlao] has left #joinmarket []     
06:10 < belcher> i think this would be good to do https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/247
06:11 < belcher> uploading pgp signatures to the release page, so people can verify signatures of the stable releases
06:11 < belcher> if people agree i can upload detached signatures signed with my pgp key to the Releases page of the latest release
06:15 < qubenix> yes, that would be helpful for users without `git` installed to verify.
06:17 < belcher> also the releases are likely to be more stable than running from master
06:24 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Remote host closed the connection]     
06:24 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
06:51 < waxwing> belcher, thanks, appreciated
06:53 < waxwing> btw i'm shortly going to publish a WIP of doing p2ep (except just "payjoin") as a PR. it isn't really especially difficult to implement (in restricted form) for payments between joinmarket wallets.
06:54 < waxwing> the 'restricted' part is, just payments from one joinmarket wallet to another, where B gives A the nick in advance, and then A pays B via their two bots. no attempt to have passive receipt of any payment on the receiving bot (i.e. not the merchant use case), which is harder 'cos you have to deal with snooping attacks.
06:55 < waxwing> if anything i'd like to do it mostly to provoke discussion about this style of payment ... also because it's easy for our wallet since everything is already in place to allow it, really.
07:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]     
07:02 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
07:38 < belcher> that would be great waxwing, iv just been thinking p2ep seems to be the lowest-effort highest-impact thing that can be done for privacy, the obvious place to add it would be btcpay server
07:39 < belcher> i will add signatures to the release pages
07:52 < waxwing> yeah. it's a bit harder with the merchant thing, as you know, you remember all the back and forth on that.
07:56 < belcher> yep     
08:36 < AgoraRelay> [agora-irc/CgRelayBot] [cgan/AlexMaroney] fyi: hardware wallet hacking talk at 35c3, running right now: http://streaming.media.ccc.de/35c3/hallb
08:37 < waxwing> thanks AlexMaroney
09:33 < waxwing> pushed a branch ('p2ep') for the above; not PR-ing yet, but it's mostly done (and working on regtest). there are rough edges, but if it interests you you might find the comments interesting.
09:33 < waxwing> i think it might make sense for me to write out the protocol/steps now, so people can point out anything wrong.
09:46 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]     
10:00 < arubi> wow nice!  definitely gonna take a look on the weekend
10:21 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket     
10:44 < belcher> nice
10:44 < belcher> be sure to link the protocol doc here when you write it
10:48 < waxwing> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e
10:48 < belcher> ty     
10:48 < arubi> awesome
10:48 < waxwing> not completely painstaking, but i think it's enough for people to be able to comment on intelligently
10:49 < waxwing> i already realised one thing should change while writing it :)
10:49 < waxwing> ofc (and this was always the idea), Alice should send a *signed* non-coinjoin. atm i have her sending a unsigned version just to hand over the inputs, and signal that she's the right counterparty.
10:49 < waxwing> but signing it is unqualifiedly better here.
10:52 < arubi> wait if it's not signed, how does the merchant know the sender even owns the inputs?  (still reading)
10:53 < belcher> looks awesome
10:54 < waxwing> arubi, it's not intended for merchants. i think there are fairly serious snooping vectors. i think that blogpost i linked at the start talks about that.
10:55 < arubi> alright cool, will read more
10:55 < waxwing> i dont' believe the solutions we came up with were quite good enough, although i'm sort of avoiding thinking about that.
11:02 < arubi> oh hm, there's little use to a pre-signed version of the tx right, if bob is changing it afterwards
11:03 < belcher> i commented one suggestion on that gist
11:08 < arubi> belcher, can use something like LN implementations use, where the invoice is just a bech32 blob.  although it's no longer human readable
11:08 < belcher> yeah, just put (address, amount, nick) concat'd together and bech32 encoded maybe
11:14 < waxwing> yes, it would be nice to have only one string to copy/paste i guess. i wasn't really thinking like that for now, since it's just a cli thing. but, sure.
11:15 < waxwing> at least reading joinmarket nicks over the phone is *marginally* less painful than reading a bitcoin address :)
11:15 < waxwing> and then your tor connection drops out and you have to start again :)
11:17 < belcher> JM nicks have a mixture of lowercase and uppercase, while bech32 doesnt, so bech32 encoding is _much_ easier to read over the phone
11:18 < waxwing> yes good point. at the time i remember thinking that i may as well go with base58 as (a) it has to be short and (b) we already have that code :)
11:18 < belcher> maybe you could also use bip20 (bitcoin URIs)
11:18 < belcher> but yes, overall its not that important
11:20 < belcher> reading over bip21 now, it looks very appropriate, it already defines fields
11:22 < waxwing> i guess that's true; hopefully the 'destination' or 'endpoint' field is sufficiently flexible to allow anything (here just a nick)
11:23 < waxwing> oh, i guess if there's some catch-all 'comment' field then it doesn't matter
11:25 < arubi> some time ago, I was playing around with p2c and s2c, so p2c is pretty cool because you could publish a single pubkey and have many transactions sent to you, but to different addresses made from tweaked pubkeys (tweaked by the contract hash)
11:25 < arubi> the issue with this method is that it's incompatible with deterministic wallets because now you have to backup the contract hash to be able to recover the privkey for the s2c address
11:25 < arubi> with payjoin it becomes interesting because the receiver of the payment now also participates in signing the tx to himself, and could embed s2c information in his signature - basically they can s2c the contract hash and can recover it later on just by knowledge of the privkey used in the payment (I'm assuming they use a deterministic nonce generation eg rfc6979 to recover the pre-tweak nonce)
11:25 < waxwing> yeah. had the exact same annoyance with snicker.
11:25 < arubi> WOF = as usual just thinking out loud :)
11:25 < waxwing> tweaked keys, but now you have to keep track ...
11:25 < arubi> er, EOF
11:27 < belcher> whats p2c and s2c? pay-to-contract i imagine
11:28 < arubi> and sign to contract
11:28 < belcher> ah     
11:29 < arubi> or, the contract hash might be the ecdh of alice and bob's pubkeys used in the payjoin?   so much room for activities hehe
11:30 < arubi> but yea, I don't have anything concrete to offer.  just games
11:31 < belcher> even games can help with thinking and inventing
11:32 < arubi> yea agreed :)
12:04 < waxwing> oh; been distracted but just came back and read your thought arubi , that is an interesting observation - receiver participation may create unique opportunities. not sure whether that specific one works, cool idea though.
12:05 < waxwing> like, receiver creates a destination on the fly, and encodes it in the signature. hmm it sounds impractical on the face of it, but .. not sure.
12:05 < arubi> I was thinking the payer creates the destination, and communicates it to the receiver
12:06 < waxwing> ah, doh, that makes more sense
12:07 < waxwing> is it helpful here, i wonder, the receiver is participating anyway ... the difference tho' is that in the currently described protocol the destination is passed out of band, if you wanted non-participation of receiver then...
12:07 < waxwing> either the receiver sends the destination at the same time as !pubkey, or you do a trick like this one maybe
12:08 < waxwing> but he cant' send the destination in plaintext over an untrusted channel (irc e.g.), so the first has that problem.
12:10 < arubi> so receiver publishes one pubkey (maybe it's also his identity in the pit), and communication to it is authed+encrypted to that pubkey.  the contract might be just some clever hash of the payment (or offer) that the receiver gets
12:11 < arubi> when receiver (bob right) is online to interact with the offer, he knows the contract hash from the payment details.  later on if he recovers his wallet, he can only recover the contract hash from the sig, but not the contract itself
12:12 < arubi> hand wave* of course
12:16 < arubi> the contract here is made up by alice right, so it might be something like "ecdh(alice-payment-pubkey,bob-id-pubkey)||payment_details", where payment_details is details in cleartext that are in the tx already, but the contract itself can't be figured out by 3rd parties from just looking at the chain
12:17 < arubi> so payment_details can't include bob's output or his input, but maybe there's enough being transmitted already by alice in the first communication to allow it (or maybe the ecdh itself is enough)
12:18 < arubi> well no it's not because it doesn't support address reuse by alice :P
12:20 < arubi> what I'm saying, alice "comes up" with a destination for bob which is his pubkey tweaked by the p2c.  bob learns the p2c from alice's offer and signs it into s2c if he chooses to participate
12:21 < arubi> kinda like stealth addresses, but here bob gains the ability to back up the tweak in the same tx that's made to it.  in stealth addresses, you needed op_return and a bunch of resources to recover your payments
12:24 < arubi> like, recovering, bob could do rfc6969(input-priv, sighash) , recover the original k0 value, then solve for k1 which is the actual nonce use in the tx, and then solve for 'k1 - k0 = contract_hash'
12:24 < arubi> this contract hash is also the tweak for his identity pubkey in the payment
12:24 < arubi> *lots and lots of handwaves
12:31 < waxwing> arubi, if the tweak has to have ephemeral data from alice anyway, why not have it just be a random that she creates and communicates along with her proposal?
12:32 < waxwing> you can still play the trick of embedding it in the signature then, but if there's ephemeral data .. Bob still has to store something?
12:32 < arubi> yea that works too really
12:32 < waxwing> but hmm i'd have to think more about what you're saying with this k1-k0
12:32 < arubi> he doesn't if he only wants to recover the contract hash
12:33 < waxwing> so he can recover without storing anything intermediate? oh the tweak = the contract hash, i see.
12:33 < waxwing> oh right i get it now.
12:33 < arubi> yea and really he can recover the contract itself if the contract hash is a positive
12:34 < arubi> I mean, could just figure it out from the tx on chain
12:34 < waxwing> so it seems to me the 'contract hash' idea here is not relevant, what matters is just that Bob is using something similar to opentimestamps to store his key information on the blockchain.
12:34 < waxwing> istr andytoshi having ideas along these lines to improve wallets. it's vague in my mind though.
12:35 < arubi> yea I'm saying contract hash because alice comes up with a payment address for bob
12:36 < arubi> he just chooses to accept payment to this address, or not, but signing for a tx made to it.  right I remember andytoshi mentioning that
12:37 < arubi> er, s/but/by/
12:38 < arubi> but right you got the gist of it :)   /afk dinner
12:41 < waxwing> in other bitcoin nerd news, Zmn... wrote a post about swaps (htlcs actually) as call options, that's something i've thought about a fair bit in the past.
12:42 < waxwing> i've seen others talk about it too. for 2 different chains/assets, it is indeed basically an option contract.
12:47 < waxwing> any thoughts about optimal amount for Bob to contribute belcher ?
12:48 < waxwing> it's kind of a maths/arithmetic question i think.
12:49 < belcher> it might not even matter that much
12:49 < belcher> if the aim is to break the common-input-ownership heuristic then any other input will do that
12:50 < belcher> the only reason it might matter is because of what the change amount ends up being, and ideally dust wouldnt be created
12:50 < waxwing> yeah. there are always two solutions if 2 outputs, if interpreted as a payment from one party to another
12:51 < waxwing> but istr from london that you can come up with cases where one of the possibilities is illogical
12:51 < belcher> yes that sounds familiar
12:51 < belcher> maybe using the "unnecessary input heuristic" ?
12:51 < waxwing> yes     
12:53 < waxwing> A-in = 2, B-in = 20 A-out = 1.95, B-out = 20.05
12:53 < waxwing> illogical to be a payment of 1.95
12:53 < waxwing> not that that necessarily means it isn't of interest/value, but .. would tend to think it's better if both possibilities are plausible
12:54 < belcher> ah yes, thats the unnecessary input heuristic
12:54 < belcher> that happens if one output is smaller than any single input
12:55 < waxwing> right, got it - so that really impacts the wallet sector
12:55 < belcher> one way to fix is to add another input (if you have it) so that the change output amount stays large enough
12:56 < waxwing> i was wrongly thinking about bob's selection, but that doesn't matter - he always just bumps his output size, so it's more that the change has to be big, so alice has to bump her selection i guess.
12:57 < belcher> though in a payjoin which is the change output? the idea of a change output makes sense if both inputs are owned by the same person
12:57 < waxwing> i can just call select(2*payment) or something, with the obvious caveat that sometimes that won't be possible
12:57 < waxwing> i think the concept still applies (tho' of course the whole idea is that outside observers are confused)
12:58 < belcher> if you define "change output" as "the one which isnt the payment output" then alice and bob have different change outputs in the same transaction
12:58 < waxwing> ? bob doesn't have a change output
12:59 < belcher> he does in the sense that its an output going back to him.. but he doesnt in the sense that he isnt making a payment
12:59 < waxwing> heh     
13:00 < waxwing> anyway, your putting it as "unnecessary input heuristic" makes it very clear - we have to avoid this, otherwise it will flag.
13:00 < belcher> maybe our problem is we're stuck on the idea of a change output, we should check what information can be learned by an adversary regardless of which output gets the name change
13:00 < belcher> hmm, idk
13:01 < belcher> yes for stopping the unnecessary input heuristic, this condition must hold smallest_output > smallest_input
13:02 < waxwing> unless there's some sophisticated behaviour in e.g. core where they don't always avoid unnecessary input?
13:02 < belcher> that could happen if they want to consolidate coins if the wallet believes miner fees are low, i dont know if any wallet does this
13:04 < waxwing> yes, i wondered if core perhaps did, i know it became more sophisticated after murch's stuff
13:04 < waxwing> anyway select(2*payment) if possible seems the most logical thing to do for now, but it does show up quite a weakness in the idea.
13:04 < waxwing> (there are a pretty broad set of cases where that won't be possible)
13:04 < waxwing> oh, worse, that's not even at all enough, right, because if you select more than 1 it might fail
13:05 < waxwing> uhh .. no, scratch that last statement
13:05 < belcher> iv done some quick algebra on paper here
13:05 < belcher> to stop the UIH being useful, this condition must hold smallest_input < total_input_value - miner_fee - payment_amount
13:06 < belcher> so keep adding utxos (to make total_input_value go up) until its true
13:06 < belcher> of course miner fee goes up with number of utxos too
13:07 < belcher> also, if the UIH ends up being useful to an adversary its still not all bad, because the CIOH has still been broken
13:07 < belcher> so id say try to avoid UIH and if you fail then just do it anyway, because the CIOH is still broken and thats always valuable
13:07 < belcher> "do it" = create the coinjoin
13:08 < waxwing> right, that part isn't debatable to me, because you remove utxo fragmentation from the receiver also as well as the CIOH breakage
13:09 < waxwing> that was the particular drum i wanted to beat on in writing a blog post later :)
13:09 < waxwing> as has often been observed, fungibility improvements which also have economic benefits are the best type
13:09 < waxwing> but i'm a little disappointed that the range of cases where it's unobservable might be less than hoped.
13:10 < belcher> i think its always observable
13:10 < waxwing> of course only very vaguely observable given we don't know that other wallets aren't sometimes doing this.
13:10 < belcher> err, always unobservable i mean
13:10 < waxwing> but UIH?
13:10 < belcher> because even if UIH can be used then the adversary just has certainty at what the change address is, but they still dont know whether the tx is a regular payment or a coinjoin
13:11 < belcher> whether the tx is a coinjoin or not is always unobservable
13:11 < waxwing> well but other wallets don't use unnecessary utxos (this is not a fact, just conjecture from me)
13:11 < belcher> no they do, they sometimes make change address
13:11 < waxwing> don't get what you mean; we're talking about the inputs they select?
13:11 < belcher> if a wallet wants to pay 5 btc and has two utxos of 4btc and 2btc
13:12 < belcher> the tx will be: 4btc, 2btc ---> 5btc, 1btc
13:12 < belcher> UIH is strong evidence that the 1btc output is a change address.... but what may also have happened is that the above tx was a coinjoin
13:12 < waxwing> oh i think i see my confusion. it's only affecting *one* possible solution
13:13 < waxwing> i forgot that. yeah. so phew, that's much better :)
13:13 < waxwing> so rewinding up the stack, yes, always unobservable, even when not "ideal".
13:13 < belcher> yes     
13:14 < belcher> and even nonideal still has ok privacy because regular wallets make transactions like that all the time
13:14 < belcher> in fact... common usage of payjoin might improve their privacy, because previously the adversary could correctly assuming its a regular payment and that they knew the change address, but now they have to consider that it also might be a payjoin
13:15 < belcher> so usage of payjoin improves the privacy of wallets which dont even use it
13:15 < waxwing> yes this is the general pattern for the "deniable" approaches.
13:15 < belcher> yep     
13:15 < belcher> but not that if you always avoided the UIH problem then regular wallets which sometimes suffer from UIH wouldnt have their privacy improved
13:16 < belcher> but note*
13:16 < waxwing> while we're celebrating though, remember that i originally totally dismissed this idea because .. how many people will actually do it ...
13:17 < belcher> well if nothing else, joinmarket payjoin could give people good experience which could be useful when people come to add it to btcpay server and electrum
13:18 < belcher> also it gives us propaganda material useful when talking to the public about how chain analysis companies are all BS
13:40 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]     
13:44 < arubi> <belcher> the tx will be: 4btc, 2btc ---> 5btc, 1btc
13:44 < arubi> what is the actual payment amount in this p2ep example, and who's input's are who
13:45 < arubi> 's?     
13:45 < belcher> one interpretation is that the owner of 2btc is paying 1btc to the owner of the 4btc
13:46 < arubi> ah yes
13:46 < arubi> and the other is a just a simple payment of 5 and change of 1.  got it
13:46 < belcher> another is that the 4btc owner is paying 3btc to the owner of 2btc
13:47 < arubi> any interpretation where the '1' output is not the change?
13:48 < arubi> ah no, can't be because 5 is larger than both the 2 and 4
13:48 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket     
13:49 < belcher> so in that example, assuming UIH but not CIOH we can say that 1btc belongs either to 4btc, or 2btc, or both of them, and 5btc certainly does not belong to any of those
13:49 < belcher> wait not the last part, 5btc might belong to 4btc or 2btc but not both
13:50 < arubi> what is cioh?
13:50 < belcher> common-input-ownership heuristic
13:51 < arubi> ah cool
14:14 < waxwing> ok, back, so, belcher : i think we agree: step 1. Alice custom-select iteratively, checking if smallest input > implied change, keep adding until either true or fail, (2) if fail, fall back to a standard selection algo and accept non-ideal case, which is still perfectly good really (since alternate implied payment is still valid)
14:14 < waxwing> i guess that custom selection algo is still under-specified by that description
15:59 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
17:56 -!- AgoraRelay [~jmrelayfn@p5DE4AB5F.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
18:09 -!- AgoraRelay [~jmrelayfn@p5DE4AB64.dip0.t-ipconnect.de] has joined #joinmarket     
19:54 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]     
20:01 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket     
21:54 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has quit [Remote host closed the connection]     
21:55 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has joined #joinmarket     
21:56 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has quit [Max SendQ exceeded]     
21:56 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has joined #joinmarket