--- Log opened Thu Feb 18 00:00:35 2021 00:06 -!- jonatack_ [~jon@37.167.103.144] has quit [Quit: jonatack_] 00:07 -!- jonatack [~jon@37.167.103.144] has joined #joinmarket 03:04 -!- anon [5288693d@pub082136105061.dh-hfc.datazug.ch] has joined #joinmarket 03:04 -!- anon is now known as Guest69864 03:22 -!- Guest69864 [5288693d@pub082136105061.dh-hfc.datazug.ch] has quit [Quit: Connection closed] 03:39 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 03:40 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #joinmarket 03:52 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #joinmarket 03:54 -!- jonatack [~jon@37.167.103.144] has quit [Read error: Connection reset by peer] 03:55 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 268 seconds] 03:56 -!- Beau27Will [~Beau27Wil@static.57.1.216.95.clients.your-server.de] has joined #joinmarket 04:08 -!- Beau27Will [~Beau27Wil@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 05:02 -!- Mateo18Walter [~Mateo18Wa@static.57.1.216.95.clients.your-server.de] has joined #joinmarket 05:30 -!- Mateo18Walter [~Mateo18Wa@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection] 05:33 -!- Isom18Jacobs [~Isom18Jac@static.57.1.216.95.clients.your-server.de] has joined #joinmarket 06:11 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 06:27 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has quit [Remote host closed the connection] 06:27 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #joinmarket 07:08 < waxwing> re: #807 (and the wider topic in other Issues), how about a halfway house where we keep the IRC only for advertising (offers), but each bot has their onion attached to their offer and all the tx communication is p2p in that specific sense. 07:09 < waxwing> anyway i'll try to finally do #748 now based on the onion-in-daemon provided by #768 and in so doing it should naturally help the line of thought above, if indeed it is a viable thought. 07:19 -!- jonatack [~jon@37.169.13.22] has joined #joinmarket 07:33 -!- jonatack [~jon@37.169.13.22] has quit [Quit: jonatack] 08:02 < belcher_> waxwing that could work, the downsides are that if tor goes down then the system stops working 08:02 < belcher_> although if tor goes down today, even though the system works people still have to leak their IP address (or are vulnerable to something like a VPN) so tor going down today is a problem too 08:02 -!- belcher_ is now known as belcher 08:05 < waxwing> yeah 08:22 < belcher> another idea i was thinking of is some kind of central meeting point which is a http server with websockets 08:22 < belcher> so taker and makers connect to the same place and the http server relays messages between them 08:22 < belcher> and the taker and makers choose for themselves if they want to use tor or not 08:23 < belcher> that would be very similar in architecture to IRC, except maybe easier for people spin up these http servers in many different places... idk maybe its useful 09:11 < undeath> a mature irc network has probably more redundancy than such a centralised http network 09:14 < undeath> tor going down should not be any concern imo 09:15 < undeath> i can't recall a single incident in the past several years where that happened 09:18 < belcher> undeath it happened the other day for v3 onions 09:19 < belcher> https://matt.traudt.xyz/posts/tracking-tors-network-wide-v3-onion-service-outages/ 09:19 < undeath> thanks 09:20 < belcher> if the main problem with IRC is flooding/getting kicked because of flooding, it seems like the data transfer could be slowed down.. the coinjoin would take a bit longer to be created but so what 09:20 < belcher> also maybe its worth trying to reduce the size of data being transferred in the protocol somehow if possible 09:21 < undeath> isn't data sent in hex? if so you could save a bit by using base64/base85 09:22 < undeath> but not sure this would actually fix the flooding problem 09:25 < belcher> it was hex then encoded as base64 back when i last checked about 4 years ago :p 09:26 < belcher> TIL theres a base85 09:26 < undeath> the savings between b64/b85 are probably negligible for jm's purposes 09:27 < belcher> every little helps, maybe, especially in python you can probably do import base85 and switch over to it with zero effort 09:28 < undeath> it's part of the base64 module 09:29 < undeath> https://docs.python.org/3/library/base64.html?highlight=base64#base64.b85encode 09:35 < undeath> without requiring some proof-of-stake, is there a way to filter out dishonest makers? 09:36 < belcher> what do you mean exactly by dishonest 09:36 < undeath> spammers 09:36 < belcher> yes then some kind of sacrifice is required 09:36 < belcher> in the coinswap design i proposed using fidelity bonds which makers will have anyway 09:36 < undeath> that would like to make the infrastructure unusable by flooding/ddos 09:36 < belcher> although in joinmarket it will probably always be possible to run makers without fidelity bonds 09:38 < undeath> iirc that was the main discussion blocker in #415 09:40 < belcher> how about makers are required to have lightning wallets and pay a few satoshi when they want write access 09:40 < belcher> it makes makers a bit vulnerable in case LN has any privacy leaks though 09:40 < undeath> you mean towards directory servers? 09:40 < belcher> yes 09:41 < belcher> the LN wallets should be over tor and using UTXOs that were not related to the maker's identity 09:42 < belcher> yet another idea is to require makers to reveal one of their UTXOs to the directory server 09:42 < belcher> essentially the same as the fidelity bond idea but using a regular UTXO instead of a time-locked one 09:42 < belcher> a spammer would need to own many UTXOs 09:43 < undeath> or simply locking funds in a LN channel with the ds? 09:43 < belcher> however then the directory server links the UTXO with the maker's identity (but what identity? the maker presumably uses tor so no IP address) 09:43 < undeath> in case of a spam attack the ds can order makers by locked amount 09:44 < belcher> yes 09:44 < belcher> or in the UTXO-revealing solution, order by utxo value 09:44 < belcher> and evict lower valued ones that go above the disk space that the directory server allocated to this 09:45 < undeath> the utxo-revealer is without LN? 09:45 < undeath> i'd prefer non-LN because managing a LN node has its own set of troubles 09:45 < belcher> yeah 09:45 < belcher> agreed 09:46 < undeath> so a semi-private proof-of-stake towards the ds only 09:46 < belcher> right 09:46 < undeath> that would be relatively easy and prevents the bulk of low-effort spam attacks 09:46 < undeath> i like that 09:47 < belcher> one issue/attack 09:47 < belcher> the directory server will learn lots of UTXOs on the blockchain and know they belong to makers not takers... so in combination with looking at coinjoins on the blockchain that could help with unmixing them 09:48 < undeath> preferably the makers would use utxos not used for cjs 09:48 < belcher> also, if the maker reveals many utxos (e.g. they reveal a utxo, then spend it, then a day later reveal another utxo) that also reveals a lot of information which might help unmix coinjoins 09:48 < undeath> new utxo = new maker identity? 09:48 < belcher> yes 09:49 < belcher> for example have it that a maker can write to the directory server for 6 months with one UTXO 09:49 < belcher> revealing one utxo once every 6 months per maker should be private enough 09:49 < undeath> mhm 09:49 < belcher> and it doesnt matter if the utxo is later spent 09:49 < undeath> relying on bitcoin's high fees to prevent spammers 09:50 < belcher> also bitcoin ownership, in the case of spam if a spammer uses utxos worth 600 satoshi they will be the first to be deleted 09:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #joinmarket 09:50 < belcher> yet another possibility can be done after taproot becomes a bit more popular, which is to use a range proof to prove you own a coin without revealing which one 09:50 < undeath> i mean if you use a "timeout" like 6 months 09:50 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving] 09:51 < undeath> what would be needed to implement such a proof? 09:51 < belcher> everyone would need to know public keys of UTXOs not public key hashes 09:51 < belcher> taproot uses public keys which is why this is possible 09:52 < undeath> how is this ever going to happen? new address type? 09:53 < belcher> in theory you could encode the public key into the existing bech32 format, but that format was found to have a bug so taproot also includes a new address type 09:53 < belcher> but the blockchain and utxo set dont see addresses remember, they just see scriptPubKeys 09:53 < undeath> i see. not a short term option. 09:53 < belcher> the scriptpubkey would presumably be " OP_CHECKTAPROOT" 09:53 < belcher> yeah the taproot soft fork needs to happen first 09:54 < belcher> but after that and someone makes joinmarket use taproot it would be pretty possible after that 09:54 < undeath> on a site note, wouldn't that sacrifice a fair bit of quantum computer resistance? 09:54 < belcher> since the ring signature goes over all or most taproot UTXOs in the blockchain 09:55 < belcher> no because QC resistance is already broken :p someone found something like 40% of all coins have their public key known on the blockchain 09:55 < undeath> lol, alright 09:55 < belcher> plus many hardware wallets send the user's xpub to a server 09:55 < undeath> wtf 09:55 < undeath> great 09:55 < belcher> the "pubkey hash helps against QC" is a meme, invented by someone to try to get people to reuse addresses less (because saying "privacy" wasnt convincing enough) 09:56 < belcher> also, if the quantum computer is fast enough a miner could use it on an unconfirmed transaction and redirect the coins to himself 09:56 < undeath> oh, I hadn't considered dishonest miners. indeed. 09:57 < belcher> some people were talking about using ring signature proofs for LN 09:58 < belcher> because right now LN also involves revealing which UTXOs are actually lightning channels, but the only thing the proof requires is showing that the user controls X btc not which utxo it actually is, so ring signatures are fine 09:58 < belcher> then electrum's LN implementation doesnt even verify the UTXOs 09:58 -!- mcv [~McViLLaN@unaffiliated/mcvillan] has quit [Remote host closed the connection] 09:59 < undeath> the details of LN are beyond my current horizon :/ 10:00 < undeath> in the end you have a tx on the blockchain to open a channel. what do you need to verify about a utxo? 10:01 < undeath> but anyway, revealing utxos to a ds 10:02 < belcher> the verifying UTXOs is for the lightning channel graph out there, not the channels directly made by you 10:02 < belcher> its required for routing 10:02 < undeath> if done with an initial validity check only i'd choose a shorter interval than 6m. maybe 1m or less even. 10:02 < belcher> yeah 1 month is probably fine 10:02 < undeath> but I like the overall simplicity of the proof 10:03 < undeath> and the whole exchange in itself 10:03 -!- mcv [~McViLLaN@unaffiliated/mcvillan] has joined #joinmarket 10:04 < undeath> the maker would expect the ds to keep the proof secret, right? 10:05 < belcher> yeah 10:06 < belcher> but even if it was secret, the directory server still knows it 10:07 < undeath> yes, of course. added bonus if the proof could be tied to the ds somehow 10:07 < undeath> but that would require some non-trivial magic 10:07 < belcher> the ring signature hides the actual utxo so that would be even better 10:07 < belcher> then it doesnt matter if the ds publishes it, since theres no information in it 10:08 < undeath> but ring signatures are not a viable option right now, are they? 10:08 < belcher> sure, but i think they will be soon 10:08 < undeath> what's your eta for "soon"? 10:08 < belcher> a year or two 10:09 < belcher> people are talking about july 2021 as when the soft fork activation period starts 10:09 < undeath> ok, it would be nice to have something ready before that already :) 10:09 < belcher> well it could be implemented as just "reveal a utxo" and later its easy to change it to "reveal a ring signature" 10:09 < belcher> since everything else is the same 10:10 < belcher> there would still be directory servers, takers still download info from them 10:10 < undeath> yeah, absolutely. a simple protocol version bump 10:11 < undeath> ds would not communicate with each other, or at least not expected to 10:11 < undeath> or would they? 10:11 < belcher> they might do, they could pull proofs and messages from each other 10:11 < belcher> the proofs could be made transferable after all 10:11 < undeath> that would pretty much make the proof public 10:11 < belcher> ah yes, true 10:12 < belcher> maybe have each ds published an encryption key, and the maker encrypts his proof with each key 10:12 < belcher> that protection is not very strong admittedly 10:12 < undeath> if they communicate over tor e2ee is not an issue 10:12 < belcher> maybe not transferable proofs is better then 10:14 < undeath> they might want to include the ds's identity in the proof to discourage leaking the proofs 10:15 < undeath> how are ds chosen? 10:15 < belcher> same as the DNS seeds in bitcoin core, hard coded into the source code 10:15 < undeath> so we have a small set of "trusted" ds? 10:16 < belcher> they're only trusted for not revealing the proofs 10:16 < belcher> and once ring signatures get implemented they're not trusted for that either 10:16 < undeath> they are also expected to be (mostly; non-spam) non-censoring and available 10:17 < belcher> yes, good uptime mostly 10:17 < belcher> a lot like the IRC networks we use today 10:18 < undeath> you can earn a fair amount of ddos resistance by hiding behind an onion service 10:18 < belcher> yes 10:19 < undeath> so we would have a bunch of trusted people spin up some ds and hardcode their onion identities into jm? 10:20 < belcher> yeah pretty much 10:21 < undeath> not a huge fan of such a centralised design but better than nothing (and better than the iffy irc servers) 10:21 < belcher> its not centralized its federated 10:21 < belcher> note that every p2p network has something like it, they all need a starting point 10:21 < belcher> bittorrent has trackers, bitcoin has the DNS seeds 10:21 < undeath> doesn't federation include the possiblity to extend the network? 10:22 < belcher> okay so instead of hard coding into the source code, have them be in an external config file which users can add to 10:22 < belcher> in the same way bitcoin core users can use `addnode` or bittorrent users can add their own IP addresses or trackers 10:22 < undeath> yes, that would be my suggestion as well 10:23 < undeath> but it only slightly changes the fact that the set of ds cannot grow organically 10:24 < belcher> i was reading a little about botnets to try to figure out this topic, i came across a few that open a UDP port and then spam out UDP packets randomly to the entire internet until they find other peers 10:24 < undeath> heh 10:24 < undeath> i don't think we'll reach that scale 10:24 < belcher> why is it useful for the list of ds to grow organically? bitcoin core's DNS seeds dont 10:24 -!- Isom18Jacobs [~Isom18Jac@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 10:24 < belcher> if the existing ones ever go down someone could upload an extended config file list on reddit or github 10:24 < undeath> the seeds don't but they only refer to further nodes, not doing the main work 10:25 < belcher> ds dont do much work here either, i was imagining takers connect directly to makers on the maker's .onion addresses 10:25 < belcher> directory servers just have a list of those onions 10:25 < undeath> yes 10:26 < undeath> the ds need to be semi-trusted in this scenario because they are expected to be non-censoring 10:27 < belcher> In order to censor a maker, _all_ the directory servers would have to co-operate to censor him. If censorship is happening on a large scale (for example if the directory servers only display sybil makers run by themselves) then takers could also notice a drop in the total value of all fidelity bonds. 10:28 < belcher> this is similar to how bitcoin core gives a warning if the proof of work is very low when doing initial sync 10:28 < belcher> or not a warning, i think it just keeps searching for new peers 10:29 < undeath> would the ds host offers or really only makers' onion identities? 10:29 < belcher> only identities 10:29 < belcher> because offers change much more frequently, every time a coinjoin happens the max amount might go up or down 10:29 < undeath> so a taker has to (try to) contact every maker in the list 10:29 < belcher> yep 10:33 < undeath> the anonymity provided by the ring signatures would sure make this a lot nicer, allowing true federation. definitely should go on the todo list 10:34 < undeath> otherwise, this looks, well, good enough for now imo 10:36 < undeath> how would the maker's proof to the ds look like? pk + utxo + sign_pk(ds-id, maker-id, timestamp)? 10:36 < belcher> something like that yes 10:37 < belcher> the maker needs to prove that he really owns the utxo 10:37 < undeath> err, sign_pk is a bit misleading 10:37 < undeath> meant is sign_privkey(pk)(…) 10:38 < undeath> whatever can be validated using the pk linked to the utxo 10:41 < undeath> i'll put that into text and post in #415 10:41 < undeath> mind if i link our chat log as well? 10:47 < belcher> i already did 10:48 < undeath> thanks. I'll write a summary then 11:11 < waxwing> undeath, were you not aware of this proposal i made a long while ago about ring signature for fidelity bond stuff? https://gist.github.com/AdamISZ/52aa2e4e48240dfbadebb316507d0749 11:11 < waxwing> (sorry i've only read the first part of the above conversation so far) 11:15 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-ughbopzyobhstdxk] has quit [Remote host closed the connection] 11:16 < undeath> I believe what you wrote in your gist boils down to the problem belcher described: we don't have a list of suitable public keys 11:17 < waxwing> well sure, people always mention the problems (which are elucidated there, and not 100% insurmountable). but i think figuring out a design like that *might* be very important to make such designs work, since people don't like the privacy leak. 11:18 < waxwing> i suppose i am more focused on something that most people don't even think about, they just think 'ring signatures', but i looked into the concrete details of *what* ring signatures. 11:18 < undeath> belcher noted that as an upgrade to the protocol :) 11:18 < waxwing> well 'people' here is just belcher i guess lol, nobody else has any comments i've heard :) 11:19 < undeath> but for now we were just looking to find something that is better than irc and can be upgraded later on 11:19 < waxwing> for now i would be happy with literally anything that doesnt' block bursty traffic 11:19 -!- jungly [~jungly@host-80-181-72-112.pool80181.interbusiness.it] has quit [Ping timeout: 264 seconds] 11:19 < undeath> yep :) 11:20 < waxwing> ameliorating it with efficiences of transfer isn't very exciting and not worth a protocol upgrade. 11:20 < undeath> if you don't want to read the whole chat log wait until i've typed out the summary 11:28 < waxwing> re "okay so instead of hard coding into the source code, have them be in an external config file which users can add to", i mean we have that today with IRC. 11:28 < waxwing> i am fond of pointing out that people could be running Joinmarket pits that we simply don't know about, and they don't have to edit a line of code to do it. 11:29 < waxwing> unlikely i admit but not totally stupid :) 11:30 < undeath> yes, I imagine we'd have the list of DS in the joinmarket.cfg 11:30 < belcher> or a seperate file, so then that file can be passed around in whole without needing the rpcpasswords removed 11:31 < waxwing> ok. well i'll continue what i was working on before. the onion connecting and onion service is moving into jmbase, and the actual connections are instantiated in jmdaemon. 11:31 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving] 11:31 < waxwing> once we have it for payjoin that the receive function spins up ephemeral service, it'll be a long way towards supporting this model. 11:32 < waxwing> here 'before' is ... earlier today :) but laid a big chunk of groundwork in #768 11:33 < undeath> yes, absolutely! 11:34 < belcher> cool 11:35 < waxwing> sorry if i wasn't clear, the payjoin code already spins up ephemeral service i meant moving that code into daemon 11:35 < waxwing> qubenix pointed out that i violated the whole architecture thing by writing that in jmclient 11:36 < waxwing> was just a dumb error, but this means it's mostly refactoring more than new code 11:36 -!- asoltys [~root@s207-81-214-2.bc.hsia.telus.net] has quit [Remote host closed the connection] 11:40 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has quit [Remote host closed the connection] 11:40 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket 11:43 < waxwing> > or a seperate file, so then that file can be passed around in whole without needing the rpcpasswords removed <--- that's a good point, perhaps more widely applicable 11:43 < waxwing> don't think i'll spend any time on it, but it is a good thought 11:44 < undeath> belcher: posted the summary. can you check if I got anything wrong? 11:47 < waxwing> can we put 'run by volunteers' not 'run by various contributors to JM'? 11:47 < undeath> sure 11:47 < belcher> undeath seems fine to me 11:47 < waxwing> i've always been a bit leery about the idea of running any JM coordinating server myself, and in any case, writing it that way leaves other people to think 'good someone elsew ill do it' :) 11:47 < waxwing> which i don't want them to :) 11:48 < undeath> thanks for checking :) 11:48 < belcher> i agree waxwing, its a lot of centralization for just a few people 11:48 < belcher> these directory servers shouldnt be hard to run really, all kinds of people could run them 11:48 < undeath> yeah, the code should be very simple and so are the expected requirements 11:49 < belcher> undeath this phrase "This is neither truely decentralized nor perfectly trustless." seems to hold the idea to an impossibly high standard given that bitcoin core and bittorrent also fail this 11:49 < waxwing> i also tend to think 'proof of stake' is not a good term to use here, since it has a very widely used other meaning. Is it not exactly fidelity bond as previous discussions and as belcher 's code patch? 11:49 < waxwing> i mean you could argue it's literally correct, but i'm just trying to be practical 11:50 < undeath> i can change the wording 11:50 < belcher> maybe it doesnt matter 11:50 < undeath> "proof of stake" was my inital association 11:50 < belcher> waxwing yes its pretty close the using fidelity bonds except it allows UTXOs without any time locks 11:50 < belcher> so makers who dont have fidelity bonds can also use it 11:50 < waxwing> oh so it's timelock-less? 11:51 < undeath> yes 11:51 < belcher> yeah, makers without fidelity bonds would just use a UTXO from their wallet or something 11:51 < undeath> it's literally a proof of owning a utxo 11:51 < waxwing> oh i see. so you're going for a lighter model. 11:52 < belcher> allowing the option at least, as makers who do have fidelity bonds would presumably use those 11:52 < belcher> but if you allow the option it means a spammer could use it as well 11:52 < waxwing> if we don't use ring sigs, why not use PoDLE though? 11:52 < waxwing> no hang on that only makes sense with commit-reveal 11:53 < waxwing> yeah would be useless here 11:53 < belcher> hmm if fidelity bonds are allowed then the ring signature thing isnt really possible... because they are p2sh 11:53 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-rsryfracieltgoch] has joined #joinmarket 11:54 < waxwing> well sure. but it's back to what i said in the gist: people can post pubkeys to a list, because revealing the key is not the same thing as correlating it to your own usage. 11:54 < waxwing> but for sure keys-on-chain is by far the best model. 11:54 < waxwing> if we encourage people to reuse their fidelity bond address, lol 11:55 < belcher> thats not even possible, as reusing a fidelity bond address means reusing the locktime 11:55 < waxwing> (meanwhile people in #wizards were seriously discussing ways to make address reuse non-consensus) 11:55 < belcher> once the locktime is in the past it doesnt lock funds for any period 11:55 < waxwing> oh yeah i was thinking a repeating time, but derp 11:55 < waxwing> that's actually mildly annoying as a limitation, i agree. 11:55 < belcher> well then we could discard the fidelity bond thing and just have it accept single-sig UTXOs 11:59 < waxwing> belcher, just to be clear, you mean, as it currently says on that summary, you're just saying we might have to stick with that, only? 12:01 < belcher> yes 12:01 < belcher> actually hold on 12:02 < belcher> the point of ring signatures is to hide what the UTXO actually is 12:02 < belcher> but thats pointless with fidelity bonds, they are always revealed 12:02 < belcher> the takers eventually learn them 12:02 < belcher> so theres never a point doing ring signatures over fidelity bonds 12:02 < waxwing> hmm well ring sig + fidelity bond adds another dimension sure, but i'm not sure it's totally ruled out? 12:03 < waxwing> it would have to be fixed timelocks, that sounds kinda crappy 12:03 < waxwing> or wait, is that just totally not possible.. i'd have to think about it 12:04 < belcher> even if its possible, its pointless, because makers already have to reveal their fidelity bond UTXOs to takers so that takers can calculate the fidelty bond value 12:04 < belcher> so to get write access to directory servers, makers provide either a single-sig UTXO ring signature or a fidelity bond UTXO regular signature 12:04 < waxwing> so your point is that the taker has to verify it, and therefore has to see the timelock. 12:04 < belcher> yes 12:05 < waxwing> i had in my mind that the taker could also verify a ring sig, but the timelock being in an anon set too is borderline ridiculous. 12:05 < belcher> also note that the single-sig UTXO most likely comes from the maker's wallet, while fidelity bond UTXOs are not in the wallet 12:05 < belcher> the single-sig UTXOs actually get involved in coinjoins, so its more important to protect privacy-relevant information about them 12:06 < waxwing> yes 12:06 < waxwing> but they could again be from somewhere else, at least possibly. just that's a hassle. 12:06 < belcher> in practice though, where else will makers get utxos from? 12:07 < belcher> if they had any spare money lying around, why wouldnt they add it to their wallet 12:07 < waxwing> dammit why didn't someone already develop a self-contained chaumian cash server payable with btc or lightning for divisible tokens. 12:07 < belcher> it only has to be a small amount, even a few thousands sats is probably enough to buy write access 12:07 < waxwing> i mean, another wallet. i wasn't suggesting it, just pointing it out. 12:13 < belcher> im reading the recent mailing list posts about taproot activation, i take back my confidence that it will be quickly activated 12:13 < belcher> its possible it will never even be proposed as a soft fork because people cant agree on this lockontimeout parameter 12:15 < waxwing> nah i don't think i agree there. 12:15 < belcher> im about to write some text in ##taproot-activation 12:15 < belcher> right after i finish reading 12:15 * waxwing searches for my lot=false hat 12:16 < waxwing> (i mean i read that thread too..) 12:16 < belcher> hats are great but i think we need to convince the lot=true people that lot=false is better 12:17 < belcher> the hats were about overpowering people who disagree with you, which worked in the UASF because of intolerant minority effects, but wont work here and if try we'll just get ossification i think 12:17 < waxwing> well objectively i think lot=false has mostly won the argument, truth be told. not like it's a slam dunk either way, but there's too little support on the other side. 12:17 < waxwing> and i think michael correctly called that in his mail. 12:17 < belcher> i mentioned before that those hats were very similar to how flags are used in real-life politics 12:49 -!- ndo- [~ndo@unaffiliated/ndo-] has left #joinmarket ["Leaving"] 12:58 -!- jungly [~jungly@host-80-181-72-112.pool80181.interbusiness.it] has joined #joinmarket 12:59 -!- jungly [~jungly@host-80-181-72-112.pool80181.interbusiness.it] has quit [Read error: No route to host] 13:00 -!- jungly [~jungly@host-80-181-72-112.retail.telecomitalia.it] has joined #joinmarket 13:05 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-rsryfracieltgoch] has quit [Remote host closed the connection] 13:20 -!- MemeFarmer____ [sid414248@gateway/web/irccloud.com/x-hjawrzyihwjcyfex] has joined #joinmarket 13:28 -!- jungly [~jungly@host-80-181-72-112.retail.telecomitalia.it] has quit [Remote host closed the connection] 13:31 -!- jungly [~jungly@host-80-181-72-112.pool80181.interbusiness.it] has joined #joinmarket 13:44 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has quit [Ping timeout: 268 seconds] 13:58 -!- coconutanna- [~coconutan@gateway/tor-sasl/coconutanna] has joined #joinmarket 14:00 -!- jungly [~jungly@host-80-181-72-112.pool80181.interbusiness.it] has quit [Ping timeout: 264 seconds] 14:16 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket 14:18 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 14:20 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection] 14:22 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket 14:43 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has quit [Remote host closed the connection] 14:44 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has joined #joinmarket 15:32 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection] 15:33 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket 15:38 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Quit: k3tan] 16:11 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 3.0] 17:25 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket 17:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket 17:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 17:58 -!- DSRelBot [~DSRelBot@p5de4a984.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 17:58 -!- belcher_ is now known as belcher 17:59 -!- HackRelay [~jmrelayha@p5de4a984.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 18:08 -!- DSRelBot [~DSRelBot@p5de4aad0.dip0.t-ipconnect.de] has joined #joinmarket 18:09 -!- HackRelay [~jmrelayha@p5de4aad0.dip0.t-ipconnect.de] has joined #joinmarket 18:27 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #joinmarket 18:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 18:51 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 18:51 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #joinmarket 19:25 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has quit [Remote host closed the connection] 19:25 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #joinmarket 20:01 -!- rdymac [uid31665@gateway/web/irccloud.com/x-wdrcfkkgnifmvmby] has quit [Ping timeout: 265 seconds] 20:01 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-qoqrrlkcanackchf] has quit [Ping timeout: 272 seconds] 20:03 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ztsaembyqgmaqhzd] has joined #joinmarket 20:03 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-tnsqcyzevunwtvdv] has joined #joinmarket 21:02 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket 21:10 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 21:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 21:15 -!- lukedashjr is now known as luke-jr 21:37 -!- reallll [~belcher@unaffiliated/belcher] has joined #joinmarket 21:39 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 22:08 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Ping timeout: 268 seconds] 22:09 -!- dave_uy [~david@108.61.193.26] has quit [Quit: The Lounge - https://thelounge.chat] 22:09 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket 22:12 -!- dave_uy [~david@108.61.193.26] has joined #joinmarket 22:16 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has joined #joinmarket 22:26 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has quit [Remote host closed the connection] 22:27 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has joined #joinmarket 22:29 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Ping timeout: 268 seconds] 22:30 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #joinmarket 22:36 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket 22:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 22:39 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:40 -!- lukedashjr is now known as luke-jr 22:57 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 268 seconds] 23:02 -!- openoms_ [~quassel@91.132.136.76] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 23:02 -!- openoms [~quassel@91.132.136.76] has joined #joinmarket 23:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket 23:10 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has quit [Ping timeout: 256 seconds] 23:24 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has joined #joinmarket 23:38 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 23:44 -!- jungly [~jungly@host-79-49-186-155.retail.telecomitalia.it] has joined #joinmarket 23:50 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket 23:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] --- Log closed Fri Feb 19 00:00:36 2021