--- Log opened Sat Jun 19 00:00:43 2021
00:07 -!- LittleBoy [~LittleOne@89.46.102.116] has quit [Ping timeout: 268 seconds]
00:08 -!- LittleBoy [~LittleOne@89.46.102.116] has joined #joinmarket
00:09 < LittleBoy> I died. Did I miss anything?
00:49 < waxwing> LittleBoy, no nothing missed
00:49 < waxwing> figure out how to make the RPC connection work on the command line with bitcoin-cli first, is my suggestion
01:02 -!- belcher_ is now known as belcher
01:40 -!- undeath [~undeath@user/undeath] has joined #joinmarket
01:55 -!- SomeGuy [~SomeGuy@194.54.28.203] has joined #joinmarket
01:55 -!- SomeGuy is now known as SomeDude
02:25 < SomeDude> Sure are a lot of 'different' makers in the OB all of a sudden with 5-7 OrderIDs, a maxsize of ~0.5 for all of them, and exactly one OrderID from each nick being an absoffer. Cool new trend?
02:27 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] :'D
02:30 < LittleBoy> waxwing: Yeah, lol. I need to face reality and acknowledge that this archaic trash heater is not for this earth. Probably going to quit being a cheapskate and buy something modern to dedicate to my project.
02:37 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] J5wDwD3CRMNw9cTO == J5DQAhiL6YbiBhQh
02:42 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] I guess.
02:58 < waxwing> yes, can happen until we get 0.9.0 (shortly). (not that i have any idea, just talking about the general phenomenon)
03:31 < LittleBoy> Cool software.
03:50 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] SomeDude: J58VqRgRku3XLDs9 == J52KVF8DQks5HkJX
05:38 -!- LittleBoy [~LittleOne@89.46.102.116] has quit []
07:21 -!- technonerd [~techno@user/technonerd] has quit [Remote host closed the connection]
07:22 -!- technonerd [~techno@user/technonerd] has joined #joinmarket
07:47 < waxwing> am i wrong or isn't it the case that with a snicker-style transaction you could make something very similar to BIP47 without an extra notification transaction.
07:48 < belcher> that sounds about right
07:48 < waxwing> i.e. output address is just ECDH shared secret tweak on the given xpub by the donation recipient, where the payer's component of the ECDH key is just the key in the first input.
07:48 < waxwing> the tradeoff is that every payment is in an imported address/key.
07:48 < belcher> that is one of the ways of implementing ecdh addresses, though that method requires the receiver to scan all blocks
07:48 < waxwing> instead of in the tree.
07:48 < belcher> which is easy for a full node, but annoying for lightweight wallet
07:48 < waxwing> oh yes, and scan.
07:48 < waxwing> scan is the bigger one of the two drawbacks i guess.
07:49 < belcher> yeah
07:49 < belcher> the requirement to scan also means its hard to have many many of those ecdh addresses
07:49 < waxwing> how so?
07:50 < belcher> scanning means your full node has to do at least one ec calculation per transaction they see i think
07:50 < waxwing> true. i guess that's not too bad if in optimised code, though.
07:50 < belcher> yeah i suppose
07:51 < waxwing> but yeah .. how to do this without a lot of scanning is an interesting question.
07:51 < belcher> one nice thing about addresses today is if you avoid address reuse they can be quite censorship-resistant
07:51 < belcher> you may have noticed the addresses on the /joinmarket-donations page occasionally seem to come from exchanges, i always imagined coinbase or something
07:52 < belcher> someone can obtain a new unused address, put it into the coinbase interface and coinbase has no way of knowing who it belongs to
07:52 < belcher> with ecdh addresses if you dont solve the scanning issue then people will use far fewer addresses, and then to censor coinbase just has to block the ecdh pubkey
07:52 < belcher> i know in a perfect world coinbase wouldnt exist, but maybe its a bit natural that exchanges will centralize a little bit
07:53 < belcher> in either case, coinbase can easily censor today by not implementing sending to ecdh addresses
07:53 < waxwing> how so? how can they know an address is derived from ECDH?
07:54 < belcher> in a world where ecdh is widely adopted, the user would put the ecdh address into coinbase's interface
07:55 < waxwing> ok i see your logic (kinda?) that if scanning is too hard it ends up being single keys not new each time?
07:55 < belcher> yep
07:55 < belcher> someone told me a story of some coin-stealing malware that also stole monero which uses ecdh addresses, and if you took that ecdh address and put it into a search engine you found the thief used the same monero address to auth with gribble (oops :p)
07:56 < waxwing> lol
07:56 < belcher> "but how can this be?! stealth addresses are anonymous!" obviously privacy can have little pitfalls like that
07:57 < waxwing> i can see how they ended up with the BIP47 design. you want recipients to somehow be aware of a pubkey that senders have, in advance, and then iterate from there. cuts down on the workload.
07:57 < waxwing> but with an icky upfront tx requirement.
07:58 < waxwing> also it's per-send/receive pair which seems like it gets unmanageable quite quickly (quite a lot of scanning/checking anyway)
07:59 < waxwing> i'm wondering if we can't blind pre-agreed keys using adaptors. just a vague intuition right now.
08:00 < waxwing> if such a thing existed you might be able to have everyone have a known key but without revealing who-paid-who.
08:01 < undeath> is it just me or is something weird happening here? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/wallet_utils.py#L1254
08:01 < undeath> we take an already hex-encoded value and hex-encode it
08:02 < undeath> was that supposed to be an unhexlify?
08:02 < waxwing> undeath, i think this might be another case of something we saw recently: belcher was writing the FB wallet code at the same time i was doing the p-btx refactor, and we recently found a couple of bugs because of it.
08:03 < waxwing> because the code doesn't fit the new pbtx refactor, but since no one is using FB wallets yet, it might not have got picked up.
08:03 < waxwing> (but sorry that was just a guess :) )
08:03 < belcher> yeah thats weird
08:03 < belcher> the addtxoutproof part will probably never be used, because its used for the fidelity bonds created by burning coins which i think we'll never use
08:03 < undeath> i don't know what btc.txhash is or what kind of arguments it expects because it's not defined in jmbitcoin…
08:04 < belcher> it calculates the txid given the txhex
08:04 < undeath> what package does it belong to?
08:04 < belcher> pybitcointools probably :p
08:04 < waxwing> yeah that would relate to what i said above
08:04 < waxwing> it'll be out of date.
08:04 < waxwing> it did exist before, indeed.
08:04 < belcher> sorry gotta run, but id recommend just deleting all the fidelity bond burner outputs stuff
08:04 < undeath> one of the reasons i dislike the __init__.py files with all its exports :/
08:04 < undeath> lol
08:05 < belcher> using only time locked addresses to fidelity bonds is better, if you want to burn coins you can just lock them up for 99999 years
08:05 < undeath> yeah, i agree
08:05 < undeath> the "true" burner outputs only make things more complicated
08:06 < undeath> so basically we can nuke everything from jmclient that has "burner" in its function/method name?
08:22 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
08:22 < waxwing> I guess belcher should answer that one but I'm fine with it considering it can always be resurrected easily.
09:11 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] yes please, I fear my coins burned
09:20 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] feedbacks noreply: My one concern with JoinMarket is that the the key is in a hot wallet (Computer) rather than a cold wallet (Hardware wallet or Cold Storage). How can you ensure that your funds aren't stolen?
09:21 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] feedbacks noreply: Last time I checked the joinmarket was an user-unfriendly cli app
09:21 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] feedbacks noreply: Yeah I’m not the most technical person by any means but the directions were very confusing and lengthy to me
09:21 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] feedbacks noreply: Joinmarket is safe. Its a self custodial hot wallet.
10:48 < belcher> yes i agree we could delete everything dealing with burner outputs
10:49 < belcher> J546rNPdB25zwXD2 the hot wallet risk is just part of the risk of running
12:53 -!- SomeDude [~SomeGuy@194.54.28.203] has quit [Quit: Connection closed]
13:01 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] hey, can there be a race condition between (taker:!fill cjamount=>maker:!pubkey) ? The logs says, the mixdepth amount is just checked again at after receiving auth... shouldn't it check before answer with pubkey again? just in case
13:03 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] If I read logs correctly, it is now: 1.taker:!fill cjamount=>2.maker:!pubkey=>3.taker:!auth=>4.maker(maker who checks mixdepth amount):!ioauth
13:03 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] Before step 2. of maker, does it check, that it actually got enough to fill the fill order of taker?
13:04 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] I'm looking for reasons, why in issue #901 makers may not like to respond, while they got lucky enough to be choosen
13:06 <+JoinMarketRelay> [hackint/J546rNPdB25zwXD2] That's the issue link: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/901
17:07 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
17:11 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
17:33 -!- belcher_ is now known as belcher
17:34 -!- k3tan [~pi@user/k3tan] has quit [Ping timeout: 252 seconds]
17:36 -!- k3tan [~pi@user/k3tan] has joined #joinmarket
18:24 -!- k3tan [~pi@user/k3tan] has quit [Ping timeout: 252 seconds]
18:28 -!- k3tan [~pi@user/k3tan] has joined #joinmarket
18:48 -!- k3tan [~pi@user/k3tan] has quit [Ping timeout: 252 seconds]
18:51 -!- k3tan [~pi@user/k3tan] has joined #joinmarket
21:02 -!- k3tan [~pi@user/k3tan] has quit [Remote host closed the connection]
21:03 -!- k3tan [~pi@user/k3tan] has joined #joinmarket
23:19 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection]
23:20 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #joinmarket
23:25 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Client Quit]
23:25 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #joinmarket
23:36 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection]
--- Log closed Sun Jun 20 00:00:43 2021