--- Day changed Wed Oct 24 2018
02:42 < waxwing> right, my 'mechanically complicated' wasn't quite to the point, it's better to say 'practicality'. if you wanted to fully leverage the effect you're focusing on then yeah it's going to require a lot of patience.
02:42 < waxwing> still it isn't that bad, e.g. doing tumbler
04:06 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 246 seconds]     
04:37 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket     
05:09 < Sentineo> gee git fsck ... oh my!
07:17 < belcher_> the PTG in CJXT must be all segwit transactions, i wonder if that could be a way to harm the privacy since if the adversary comes across a non-segwit tx in the transaction graph then they know its not part of the PTG
07:17 < belcher_> thats helped by segwit simply being adopted more i guess
07:38 < waxwing> belcher_, yeah that's a good point .. hmm, small detail though, perhaps you can use non-segwit promise utxos since tx will still be segwit as long as one input is?
07:38 < belcher_> i think that wont work, because the signature for the promise utxo can be malleated which will change the txid
07:40 < waxwing> belcher_, but like, Alice provides an already confirmed utxo that she owns as a promise
07:41 < belcher_> but spending that utxo in tx1 requires a signature, if that signature is non-segwit then malleating it will change the txid of tx1
07:42 < waxwing> the signature can be malleated without changing the txid of tx1 if tx1 has other, segwit, inputs
07:42 < belcher_> i didnt realize it worked that way
07:43 < belcher_> thats great then, so promise utxos can be non-segwit
07:44 < belcher_> that means even inside the PTG you can have non-segwit outputs as long as they are always spent along with at least one segwit utxo?
07:44 < waxwing> i should check, i always remember it in terms of bip143 that defines the serialization. afaik you have the txid and the wtxid, and only if there's no segwit inputs, then it reverts to the old serialization and sighashing algo
07:44 < waxwing> yeah i was thinking that too, but i want to recall the basic facts from the bips ...
07:44 < waxwing> oh bip144 and bip143, 143 is the sighashing
07:44 < waxwing> 144 is serializatoin
07:45 < belcher_> then that means the only kind of tx which are definitely not part of a PTG are ones which have only non-segwit inputs
07:49 < waxwing> yeah
08:00 < waxwing> hmm no now i think i must be wrong about my assertion that it's not malleable in that case. it's sha2d(version, ins, outs,..) and for the ins that are non-segwit the scriptSig still contains the signature.
08:00 < waxwing> just never thought about this mixed case before. glad you brought it up! :)
08:02 < belcher_> ok, to conclude a transaction spending a mix of segwit and nonsegwit UTXOs has a malleable txid until its confirmed?
08:03 < waxwing> that's what i think now; and i thought the opposite before. not sure if you should 'conclude' on that basis :)
08:03 < waxwing> it's reasonably clear though, see in bip144: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#hashes
08:05 < belcher_> it has to be that way otherwise segwit wouldnt be a soft fork
08:06 < belcher_> non-updated nodes expect that a nonsegwit UTXO will have a nonsegwit signature and that the txid is the hash of the entire tx
08:07 < waxwing> yes, i just forgot that (duh) the non-segwit input still has the same kind of scriptSig it had before. i agree it's clear.
08:07 < waxwing> so situation is not that rosy as we might have hoped.
08:08 < waxwing> but anyway we could never get to "complete coverage" as you said because in no case could completely non-segwit transactions be included in the "cover traffic"
08:08 < waxwing> and anyway SW usage is pretty high nowadays
08:09 < belcher_> approx 40% of txes are segwit txes looks like
08:10 < belcher_> lets say 50% rounding up... so knowing nothing else that means every other tx is segwit.. but if the PTG has something like 20 txes and none are segwit then that would stand out, because just by chance you'd expect around 10 of them (50%) would be nonsegwit
08:11 < belcher_> if so then it doesnt look very good :\
08:16 < Sentineo> what is PTG btw?
08:16 < belcher_> Sentineo proposed transaction graph, read this for the background https://joinmarket.me/blog/blog/coinjoinxt/
08:16 < Sentineo> I guess not Poor Turkish Government :) but something else!
08:17 < belcher_> btw do you think theres any chance of changing the name of CoinJoinXT waxwing ? to me it feels like the idea is very different from CoinJoin
08:17 < Sentineo> ah ok, is coinjoinXt like a new version, or new proposal?
08:17 < belcher_> Sentineo its a new proposed privacy tech
08:18 < belcher_> up there with coinjoin and coinswap
08:18 < belcher_> the crucial point is about locking up coins in a multisig address and then being able to make an arbitrary PTG
08:26 < waxwing> well yeah but i think the name has its point; you're extending the co-spending atomicity over multiple transactions.
08:26 < waxwing> in the case where you don't use promise you don't need backouts either, so there's no liveness requirement, so it's properly atomic like coinjoin there.
08:27 < belcher_> extending the co-spending atomicity over multiple txes; thats a good way of putting it
08:27 < waxwing> i think 'extended coinjoin' is a decent name for it really. but .. it's just a name
08:28 < belcher_> i think the bikeshed should be blue actually :P
08:29 < Sentineo> you will end up with ex-coinjoin :) 
08:29 < belcher_> XT sounds a bit like "extra" i guess is how the name was first made
08:29 < belcher_> from BitcoinXT, right?
08:29 < Sentineo> hm looking at https://www.walletexplorer.com/, does it try to fingerprint the services based on the wallet behaviors?
08:29 < waxwing> belcher_, 'extended'
08:30 < waxwing> yes, plus the joke :)
08:30 < belcher_> Sentineo it uses the common-input-ownership heuristic
08:30 < waxwing> Sentineo, i guess the proprietary ones do.
08:30 < waxwing> although i can only guess ofc
08:30 < belcher_> i.e. transactions which spend multiple inputs imply that those inputs were owned by the same entity
08:30 < belcher_> oh no i think it names the clusters by sending probes
08:31 < waxwing> oh, does it? interesting
08:31 < belcher_> more or less manually, i got the impression, like load up BitFinex and deposit 1mbtc to it, then see which wallet cluster its in
08:33 < Sentineo> ah my
08:33 < Sentineo> interesting!
08:33 < Sentineo> and evil :) 
08:35 < belcher_> one thing even with schnorr for privacy, after its softed forked in we still need to wait for it to become adopted to get any meaningful privacy
08:38 < Sentineo>  Note that the set doesn't have to be a chain (TX1->TX2->TX3...), it can be a tree - from the linked blogpost ... how would a tree look like, it would be like 2 inputs combined to 1 output, then that 1 output referenced elsewhere as an input and so on?
08:38 < belcher_> Sentineo also a big reason why walletexplorer works so well is because of address reuse
08:39 < belcher_> like this:
08:39 < belcher_> TX1 -> TX2 -> TX4
08:39 < belcher_>     -> TX3 -> TX5
08:39 < belcher_>            -> TX6
08:39 < belcher_> TX1 has outputs that get spent by TX2 and TX3
08:40 < Sentineo> ah ok
08:40 < Sentineo> ty     
08:41 < Sentineo> ok in this case tx1 must be 2of2 multisig? (just cause it is one tx and it is stated that all txes should have the sign of off both parties) - testing if I got it right
08:42 < Sentineo> lol I messed up the off and of :P 
08:43 < belcher_> yes, in the blog post thats called the funding transaction
08:47 < waxwing> yes the easiest way to understand it is if at least one of the 'connector' utxos between the txs is 2 of 2 between the 2 (or N) parties - which is another reason schnorr would really help here
08:48 < waxwing> technically you can do it without that for the ones after the funding though; the only thing that matters is that every step requires the signing of both (or all) parties
08:48 < waxwing> but that's a bit confusing so say each step has at least 1 2 of 2 input
08:48 < waxwing> without schnorr then we have all these 2 of 2 multisigs that are a pretty big watermark, realistically
08:50 < waxwing> the thing i really wanted to impress on people, and perhaps didn't, is that you can prepare all this in one step of negotiation. you wouldn't have to stay in communication with your counterparty(ies) even if you set it up to run for days.
08:51 < belcher_> yes that last point is big
08:52 < belcher_> the issue with schnorr is we still need to wait for a lot of adoption to get meaningful privacy, otherwise the schnorr signature stands out too
08:52 < belcher_> perhaps 2p-ecdsa might be more practical today, although it only works for 2of2 rather than NofN
08:52 < waxwing> right
08:53 < Sentineo> hm at Introducing Promises - looking at the ascii art graph, it says to Aliac: 1 BTC, to Bob 0.5 BTC, where does the 0.5 BTC in case utxo A1 is not spent, so no refund happens? 
08:53 < belcher_> but thats only a small issue, in the long term everyone moves over to schnorr anyway
08:53 < belcher_> but also in the long term bitcoin fungibility is dead so its best to not wait until then :p
08:54 < Sentineo> what I mean is 1+ 0.5 is not 2 BTC :) missing the 0.5 there
08:54 < waxwing> Sentineo, bob got paid out 0.5 in the previous tx
08:54 < waxwing> you're looking at the second ascii diagram right
08:54 < Sentineo> yep     
08:55 < waxwing> so if tx3 doesn't happen because alice double spent her input to it, the backout pays out what remains owed to each party
08:55 < waxwing> you could actually add punishment to that, to dissuade alice from doing that, but that didn't seem necessary in the description
08:56 < Sentineo> ok, so tx1 pays bob 0.5 btc (is one of its outputs), and tx2 is the second output. like that?
08:57 < waxwing> yes. the crucial point is that an *individual* transaction can be 'unbalanced' - paying more to one party than the other.
08:57 < waxwing> and the atomicity makes sure that the other party doesn't take a risk.
08:58 < belcher_> either the entire funding tx and PTG happens, or none of it happens
08:59 < waxwing> assuming that at least one of the 2 wants it to :)
09:00 < waxwing> they could get together and get cold feet after the funding and just do something else ofc
09:00 < belcher_> yes, though that would leave at least one of them losing money that they could easily get back
09:01 < waxwing> yes, once into an unbalanced condition, then there's no trustless way to agree an alternative. i think.
09:01 < waxwing> so once unbalanced, it is basically irreversible
09:02 < belcher_> also another thing with anonymity sets, CJXT would almost certainly use nLockTime, but only around 25% of all tx use that
09:03 < belcher_> so the anonymity set is the intersection of segwit and nlocktime using txes
09:03 < waxwing> belcher_, oh, right, i was told Core always uses it, so realistically Core is the anonymity set.
09:03 < waxwing> or like, the upper limit, more like.
09:03 < belcher_> electrum too
09:03 < belcher_> or it could not use nlocktime for some txes, then it has a risk of them being broadcast early, but that still might be worth it
09:03 < waxwing> ok. and that's only 25%? yeah i guess that makes sense.
09:04 < belcher_> it probably would be worth it thinking now, the risk outcome isnt that bad and you get a much large anonymity set in return
09:04 < waxwing> ah yes. i remember thinking that too. but you can't win really. if 50% of txs have nlocktime :)
09:05 < waxwing> i found myself thinking in the end that for coinjoinxt the comparison is mainly with joinmarket tumbler. better for non-interaction, worse/more difficult for the difficulties with N parties and/or using multisig, but overall to try to quantify the comparison .. blech, forget about it.
09:06 < belcher_> yes, and with a coinswap scheme
09:06 < waxwing> coinjoinxt is too large of a set of possible actions. overall it's probably a better model, but hard to code, hard to coordinate lots of parties.
09:06 < belcher_> but not with joinmarket sendpayment
09:28 < waxwing> belcher_, btw i just realised the other day, after being confused about it, ofc 45K txs is not correct, it's more like 10K i reckon (listtransactions lists the same tx multiple times .. twice? four times?)
09:28 < waxwing> you remember about us being suprised re: 45K listtxs output
09:28 < belcher_> i remember yes
09:28 < belcher_> yep the listing multiple times effect certainly contributes
09:29 < belcher_> i think its once per address, so if a tx sends from your addr and has an output going to a change address, that tx will appear twice
09:36 < Sentineo> in the details atrribute it has a categorie send, or receive iirc
09:46 -!- stoner19 [stoner19@gateway/vpn/privateinternetaccess/stoner19] has quit [Quit: Keep on keepin' on...]     
10:26 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
11:43 -!- berndj-blackout [~berndj@azna.co.za] has joined #joinmarket     
11:48 -!- Netsplit *.net <-> *.split quits: so, andytoshi, berndj
11:51 -!- Netsplit over, joins: so
11:52 -!- berndj-blackout is now known as berndj     
12:15 -!- reallll [~belcher@unaffiliated/belcher] has joined #joinmarket     
12:19 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Disconnected by services]     
12:19 -!- reallll is now known as belcher_     
12:24 < waxwing> belcher_, re: your earlier '50% of txs non sw' analysis, that's a very good point, *slightly* ameliorated i'd expect by segwit txs probably tend to cluster together a bit. but over a graph of 20, yeah. that is a bit of an issue ...
12:25 < waxwing> once we get into numbers like 20, (and i understand why - you want the combinatorics to kick in) it does start to get kinda costly.
12:26 < belcher_> its a shame since CJXT is better in many ways than coinswap
12:27 < belcher_> it breaks more heuristics
12:28 < belcher_> a concern with coinswap is an adversary can still build up wallet clusters with the common-input-ownership heuristic, but the thing which makes that really damaging is finding the change addresses
12:29 < belcher_> so if the coinswap software takes care to hide change addresses as best as possible then it would be ok in terms of privacy
12:29 < belcher_> also avoiding address reuse obviously, address reuse is another big reason why walletexplorer.com is so impressive
12:29 < belcher_> but with coinswap its seems so hard to code and has lots of DOS opportunities that seem hard to fix :\
12:33 < waxwing> yeah i see it less as a coding problem, more the 'XBI' problem (cross block interactivity)
12:33 < waxwing> that just makes it so icky .. you don't find out if it's actually worked for a while, you have to be aware of possible maliciousness for a long while (reorg risk as well, although that part is a bit 'how long is a piece of string')
12:34 < belcher_> yes, and someone needs to go first and take the risk of DOS and subsequent cost of miner fees
12:34 < waxwing> yes asymmetry is annoying with atomic swap, although it's even worse if you do it for trading rather than privacy
12:35 < belcher_> i had an idea which i didnt write down yet for antiDOS, which is that one party pays another via LN
12:35 < waxwing> it's probably quite fun to try to model a cross-blockchain swap as a european style option :)
12:35 < belcher_> and the amount they pay should cover the miner fees in case it turns out to be a DOS
12:36 < waxwing> yeah that could probably make sense, use the lightweight/smaller off-chain channel to support the onchain swap.
12:37 < belcher_> one thing that surprised me recently was that more than 10% of bitcoin transactions have just one output https://p2sh.info/dashboard/db/batching?orgId=1
12:41 < waxwing> wow.
12:41 < waxwing> oh you missed his talk right; it was pretty interesting
12:41 < belcher_> sadly i wasnt able to come, but i watched it on youtube
12:41 < waxwing> hmm. i'm wondering about that. last graph, right?
12:42 < waxwing> ah no it must be right. 2 = 60ish percent. yeah that is very interesting. he didn't cover this graph in that talk.
12:42 < belcher_> all the graphs on that page
12:43 < belcher_> the first one mostly, since it shows the proportion of transactions
12:43 < waxwing> but wait, why is it dominant at the start?
12:43 < waxwing> oh coinbase. hmm yeah.
12:43 < belcher_> ooh     
12:43 < waxwing> so i guess it must be services doing payouts without batching at all.
12:43 < belcher_> and without change addresses
12:44 < waxwing> oh derp, yeah, that's not an explanation.
12:44 < waxwing> oh: consolidation.
12:44 < belcher_> coinbase outputs are only 1 per block, and a block has ~2500 txes when full
12:44 < waxwing> yeah i meant coinbase in 2009-10, was wondering why it was dominant, that's why
12:44 < belcher_> but then in the second graph "volume" you see those 1-output txes dont create much volume
12:45 < belcher_> actually that would make sense too, because consolidations happen for small outputs i.e. small volumes
12:45 < belcher_> consolidations are used by casino sites or something, because they get incoming payments of small amounts
12:45 < belcher_> ok that seems to explain it
12:46 < waxwing> yeah consolidation/sweeping
13:59 -!- quitobro [d0b9b842@gateway/web/freenode/ip.208.185.184.66] has joined #joinmarket     
13:59 < quitobro> hey guys, is anyone else unable to connect to the IRC pit?
13:59 < quitobro> i can't get past `Listening on port 27183 connection was made, starting client`
14:08 < waxwing> quitobro, if it's on clearnet, i'm pretty sure agora is down
14:08 < waxwing> so you should either (a) connect over tor (best) or (b) edit the config and remove all the settings for the second server (agora)
14:08 < waxwing> if you choose the second, note you have to make each setting in that section have only one value
14:09 < waxwing> (section being 'MESSAGING')
14:15 < quitobro> waxwing: hmm i am connecting via tor actually
14:16 < quitobro> or at least i thought i was!
14:16 < quitobro> will look into this later on
14:16 < undeath> through tor = using the hidden service
14:20 -!- quitobro [d0b9b842@gateway/web/freenode/ip.208.185.184.66] has quit [Ping timeout: 256 seconds]     
14:21 -!- undeath [~undeath@hashcat/team/undeath] has quit [Read error: Connection reset by peer]     
14:22 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
14:22 < waxwing> yes sorry
14:58 -!- stoner19 [stoner19@gateway/vpn/privateinternetaccess/stoner19] has joined #joinmarket     
15:26 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.2]     
15:34 < Sentineo> who is peer, and why is he always resetting connections!? :)
16:08 -!- osiudnv [d598a268@gateway/web/freenode/ip.213.152.162.104] has quit [Ping timeout: 256 seconds]     
17:34 < technonerd> is agora tor hs down?
17:48 < qubenix> yeah, i had to comment it out for now
18:32 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
19:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
19:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
19:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
19:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
20:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
20:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
20:48 -!- mr_paz_ [~mr_paz@c-71-57-73-68.hsd1.il.comcast.net] has quit [Remote host closed the connection]     
22:52 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]