--- Day changed Thu Jan 17 2019
00:54 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
03:46 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
04:13 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
05:53 < qubenix> d3spwn: no, just joinmarketd
05:58 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
06:33 < waxwing> belcher, looks interesting, thanks. giving it a read now.
06:48 < waxwing> first thoughts: i like the intro, it specifies the key problem succinctly.
06:49 < waxwing> second: is there some shenanigans we can do to remove or reduce financial trust in a server.
06:49 < belcher> federate them, have more than one server
06:49 < waxwing> i know we can make the payments either quasi- or totally unlinkable, but .. trust in server(s) is a big friction
06:49 < waxwing> yeah but i think this is what stopped such systems getting off the ground in the first place
06:50 < waxwing> i mean if like OT had taken off, you would barely need to make much of a proposal, you could probably use that infrastructure
06:51 < belcher> it does need the contract where the money only goes to makers if txid gets confirmed, so its not just a regular ecash server (though i dont know maybe OT can do that)
06:51 < waxwing> yes. i admit i wasn't totally clear on that part of the proposal.
06:52 < waxwing> if the ecash is under the control of the server, does an atomic contract help that much? i guess it gives proof of fraud, that type of thing.
06:52 < waxwing> like the whole ricardian contract idea
06:52 < belcher> it means takers and makers cant cheat each other
06:52 < waxwing> yeah, understood
06:53 < waxwing> these models always felt dodgy over the years when people proposed them (including me!). collusion etc etc
06:53 < waxwing> "cryptography not game theory" as Szabo put it.
06:54 < belcher> joinmarket already depends on that sadly, its defence against sybil attacks is game theory/economics
06:54 < belcher> but yes it wouldnt be nice to add even more
06:54 < belcher> once ecash servers build up a reputation they have an incentive to convert that reputation to money by doing an exit scam (unless there exists a mechanism for them to sell reputation)
06:55 < waxwing> i guess "sell reputation" kind of exists in markets naturally through profits, no?
06:56 < belcher> depends, sometimes
06:56 < waxwing> what screws it up in DNMs is the large asymmetrical downside risk of LE
06:56 < waxwing> so you can't just sum over the future time series of profits, in the way you would with a legal business. (waving hands here..)
06:57 < belcher> sounds like the capital asset pricing model
06:57 < belcher> which i guess is a fine way of figuring out the value of a reputation
07:00 < belcher> waxwing what about a server which uses multisig
07:01 < belcher> 7-of-15 or something, and they all run full nodes so can check whether the txid got confirmed
07:01 < belcher> that doesnt solve the exit scam reputation thing, since 15 parties still build up a reputation
07:02 < waxwing> yeah i remember going down this line of thinking before. it's why i was investigating N of M maximum multisig when we first chatted on bitcointalk :)
07:03 < waxwing> i liked the idea of some randomness combined with that. but i think ultimately people just kind of won't do it. i coudl of course be entirely wrong.
07:42 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
07:45 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Client Quit]     
07:46 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
07:50 < nothingmuch> for the problem as it's stated i still don't understand why an off chain protocol is required
07:51 < waxwing> nothingmuch, it really kinda does
07:52 < waxwing> because any delta between (ins+change) subsets indicated who the payer is in the current joinmarket model
07:52 < waxwing> remember, one reason for wanting privacy is to not want the receiver to know your utxos. say you're a millionaire or whatever.
07:53 < nothingmuch> if i have two non linked UTXOs, a and b, and i want to send an amount a < x << b. i could create a mix as a taker with 3 outputs - x to payee, and change outputs b + fee - x, and a - (m + 1) * fees, where m is the number of makers. my mixed input is indistinguishable from the makers', and the lower bound on my wealth is the smallest maker input.
07:54 < nothingmuch> (ignoring makers' mixed & change outputs)
07:55 < nothingmuch> (those would be x and m_i + fee - x, like b)
07:55 < waxwing> so not current Joinmarket model :) interesting, so you're simulating one more maker, is that it?
07:56 < nothingmuch> yep, and yeah i understand that requires some changes, but it seems much simpler than an additional protocol which would also require changes
07:56 < waxwing> so it requires at least two inputs, also it requires more space usage. but it's an interesting angle. using more outputs is always a way of creating more obfuscation.
07:56 < waxwing> nothingmuch, not really disagreeing. i also kinda like the simplest solution of all: if some makers feel inclined they just set their fees zero and takers can choose them :)
07:57 < waxwing> i suggested this a little while back, you could imagine for small amounts it might work, and leave the paid version for larger amounts. but the incentive will figure out whether that's valuable i guess.
07:57 < waxwing> negative fees are ofc also possible.
07:57 < waxwing> this can be done today, and perhaps is (haven't checked).
07:58 < waxwing> still, don't mean to dismiss that specific construction you suggest. it's interesting at least in that it's a minimal change.
08:02 < nothingmuch> feel free to dismiss, it's not like it's without drawbacks =)
08:03 < waxwing> well i dismiss implementing it in the next month, there, that much is concrete :)
08:04 < waxwing> i've always been 'meh' about people suggesting splitting up into more complex structures, but i know both you and nopara have taken a seriously look at that. it makes my head hurt tbh (trying to figure out what's "optimal")
08:05 < nothingmuch> heh, i'm a month into that rabbit hole, studying up on Dempster-Shafer theory now to try and work out a convincing model
08:06 < nothingmuch> basically i think laurnetmt's link probability matrix idea can be generalized into a whole blockchain thing, similar to k-anonymity, with belief functions... that's not computationally viable but from there i hope to work back down to special cases
08:19 < belcher> waxwing i wonder if LN combined with the ecash server could be good, because each maker could withdraw their coins out almost immediately
08:20 < belcher> then the ecash server's main job will be the contract which trades money for a txid getting confirmed, and it will store very little money itself and so wont have a valuable reputation
08:20 < waxwing> yeah the extremely small amount of money involved has to be considered
08:21 < belcher> the maker fee would include part of the miner fee too, in early-2018 that reached $20 or so, so its not always extremely small
08:21 < waxwing> but i remember thinking about the LN approach to solving this problem that it wouldn't likely work because it's too much extra complexity in workflow for users, for a small difference. but, don't really know.
08:22 < belcher> the UX is a bit less good i guess
08:38 < nothingmuch> fwiw, electrum's LN impl seems to be coming along, code looks fairly reusable, for taker unidirectional (send only) channel might make sense, w/ reasonable UX
08:39 < nothingmuch> seems like a lot of work to integrate, and i've no idea how close it is to ready, this is the first i've looked
08:40 < belcher> we still need the contract of trading money for a tx confirmation
08:40 < belcher> im not sure LN can do that
08:43 < nothingmuch> i'm pretty sure that requires chaumian servers. but at least paying such servers could be simple for takers, requiring just a single wallets (not for makers though)
12:17 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Ping timeout: 256 seconds]     
12:45 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-kwdkgdsfuwizoile] has quit [Quit: Connection closed for inactivity]     
12:45 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
14:54 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
17:17 -!- AgoraRelay [~jmrelayfn@p5DE4AE81.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]     
17:31 -!- AgoraRelay [~jmrelayfn@p5DE4AE6F.dip0.t-ipconnect.de] has joined #joinmarket     
17:53 -!- StopAndDecrypt_ [~StopAndDe@pool-141-155-179-159.nycmny.fios.verizon.net] has joined #joinmarket     
17:55 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #joinmarket     
17:58 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Disconnected by services]     
17:58 -!- achow101_ is now known as achow101     
17:59 -!- Pasha [~Cory@unaffiliated/cory] has joined #joinmarket     
18:00 -!- Netsplit *.net <-> *.split quits: Cory, belcher_, d3spwn, StopAndDecrypt, AgoraRelay
18:02 -!- Pasha is now known as Cory     
18:03 -!- Netsplit over, joins: d3spwn
18:07 -!- Netsplit over, joins: belcher_
18:26 -!- AgoraRelay [~jmrelayfn@p5DE4AE6F.dip0.t-ipconnect.de] has joined #joinmarket