--- Day changed Thu Dec 12 2019 00:36 -!- MaxSan [~four@37.120.210.211] has joined #joinmarket 01:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] --- Log closed Thu Dec 12 01:11:45 2019 --- Log opened Thu Dec 12 01:12:19 2019 01:12 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #joinmarket 01:12 -!- Irssi: #joinmarket: Total of 57 nicks [1 ops, 0 halfops, 0 voices, 56 normal] 01:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 01:22 -!- Irssi: Join to #joinmarket was synced in 600 secs 01:42 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 03:04 -!- Donavon55Ullrich [~Donavon55@ns334669.ip-5-196-64.eu] has joined #joinmarket 03:20 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #joinmarket 03:48 < waxwing> belcher, ping 03:52 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 03:57 < belcher> pong 03:57 < belcher> waxwing 04:15 < waxwing> ah sorry my IRC doesn't have good notifs right now belcher :) 04:15 < waxwing> yeah so the question i was going to ask, i've figured out; the 'network' setting thing in BCI constructor. 04:16 < waxwing> i wrote a comment and closed that one because i figured it out, but it's kind of silly how complicated that is. 04:17 < belcher> yeah 04:17 < waxwing> will think a bit about this post_sync_wallet_callback thing now 04:17 < belcher> ok 04:18 < belcher> ill fix this last thing you commented on, about using elif with else being the error 04:24 < waxwing> i think the reason this case is tricky/weird, even though simple, is because 'NoHistory' is not really just a blockchain interface, it's a mode of operation of the wallet. 04:25 -!- openoms [~quassel@195.140.215.182] has quit [Remote host closed the connection] 04:25 < belcher> yeah, in fact i was thinking theres an argument to make bitcoin-rpc --recoversync and bitcoin-rpc default (formally known as --fast) be their own blockchain interfaces 04:26 < waxwing> oh? but that seems like going in the opposite direction 04:26 < belcher> they are also modes of operation 04:26 < belcher> on the other hand theres also an argument to make no-history a command line argument like --recoversync 04:26 -!- openoms [~quassel@195.140.215.182] has joined #joinmarket 04:26 < waxwing> i was more saying that bci was more conceived to be a pure access of blockchain, and the modes of access / control of the wallet should not be their concern. 04:27 < waxwing> yeah on the 'command line arg like recoversync' that sounds, at least as gut reaction, as like maybe right. 04:27 < waxwing> but i could think about it a bit more. 04:27 < belcher> imagine if you set bci = electrum and then ran with --recoversync, im not sure that even makes sense 04:28 < waxwing> well that's all disabled. we should complete the deletion of it. 04:28 < waxwing> but that brings up another point, i was planning to add a dummy bci for rare cases where it's actually needed to start up and run a script without Core. 04:28 < waxwing> i know we have noscan methods but they still need a bci to run today which is kinda dumb. 04:29 < waxwing> there's like a getblockchaininfo() and/or some other reasons why nothing actually runs without Core. 04:29 < belcher> that makes sense, for things like recovering a wallet from seed then extracting the privkeys individually 04:29 < waxwing> sorry bit of a side story. 04:29 < waxwing> yeah. 04:29 < belcher> the side thing is fine, all this is related really :) 04:29 < belcher> also, the argument "X was conceived as Y" doesnt make sense, its like "satoshi vision" 04:29 < waxwing> ok, but to me it *is* conceived as Y. 04:29 < waxwing> and more to the point i was trying to make that more solid with the recent refactoring. 04:30 < waxwing> there was an unholy mess of cross referencing between wallet and bci before, made it very hard to know what was going on sometimes. 04:31 < belcher> ok, so to you what does it mean for someone to run with --recoversync if they've set `bci = electrum` or `bci = client-side-block-filtering`, since i dont think those methods have a distrinction between --fast and --recoversync 04:31 < waxwing> i mean it still is hard, and i increasingly realise that our basic architecture causes it (not software style architecture, but actual technical architecture): blockchain, then Core wallet, then imports then JM wallet. state spread between them. 04:32 < belcher> yeah agreed on that 04:32 < waxwing> yeah seems like a sound point re: recoversync but i mean, it's not illegal to just make some arguments only operable for certain setups. 04:37 < belcher> right, but its related to the question of what to do with post_sync_wallet_callback(), since one option is to add another CLI option like --no-history, or to separate --fast and --recoversync into their own blockchaininterfaces, or maybe a third way 05:39 -!- Donavon55Ullrich [~Donavon55@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds] 06:19 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 06:51 < waxwing> belcher_, yes i can certainly see that there is an argument for doing this differently, and in particular i see: there's no perfect way to create clean architectural boundaries here, precisely because the underlying tech doesn't have clean boundaries. 06:52 < waxwing> like, the difficulty in making our software have a good modular arch with separation of responsibilities is exactly that the state is "smeared over" the Core wallet, the blockchain itself, and the JM wallet. 06:53 < waxwing> probably things would only ever get really clean if we just ditched a reliance on watch-only from Core and just read the blockchain itself. possible but a real can of worms. 06:54 < belcher_> what do you think of the idea to remove the post_wallet_sync_callback() because it will likely never be used anywhere else, and somewhere in wallet_service have `if bci == BitcoinCoreNoHistory: disable_address_generation_in_wallet()` 06:55 < waxwing> one possibility: sync_wallet is a callback and default_sync_wallet does what it does now. a config variable for say NoHistory could be used to inject a callback which is really just a wrapper for the default, but adds those final changes to the wallet. 06:55 < waxwing> yeah what you suggest seems fine with me, i mean, we're clearly opening a big can of worms here and we just have one simple thing we want to achieve. 06:55 < waxwing> my reason for raising it is i just don't want to go back to having to worry about wallet state being updated outside like it was before, so trying to stick to a rule. 06:56 < belcher_> i think that solution follows the principle of the waller_service arch, specifically it doesnt update the wallet state outside 06:56 < waxwing> yes 06:57 < belcher_> ill do that 06:57 < belcher_> also for a reason i didnt understand the automated tests failed, it just says that install.sh failed 06:58 < waxwing> i've been seeing some problems recently. we'll have to look into it. 06:59 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 276 seconds] 07:00 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 07:03 < waxwing> i mean run the tests locally ofc 08:35 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket 09:47 -!- MaxSan [~four@37.120.210.211] has quit [Ping timeout: 265 seconds] 10:57 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 250 seconds] 11:03 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket 12:14 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #joinmarket 12:38 -!- quitobro [448156e2@pool-68-129-86-226.nycmny.fios.verizon.net] has joined #joinmarket 12:38 < quitobro> hi guys - question, is it no longer possible to run joinmarket using a remote bitcoin core node backend? 12:38 < quitobro> say one of the public nodes provided by ... anyone really 12:40 < waxwing> quitobro, it can be remote, but you have to have rpc access to import watchonly addresses into that Core instance 12:40 < quitobro> ah okay 12:41 < quitobro> since those watchonly addresses are maintained in the node's wallet right 12:41 < waxwing> yeah. you can also use the multiwallet feature of Core and have the JM wallet in one separate wallet.dat 13:59 -!- quitobro [448156e2@pool-68-129-86-226.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 15:07 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 15:07 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #joinmarket 15:09 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #joinmarket 15:10 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Read error: Connection reset by peer] 17:54 -!- AgoraRelay [~jmrelayfn@p5DE4A68C.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 17:56 -!- CgRelayBot [~CgRelayBo@p5DE4A68C.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 18:06 -!- AgoraRelay [~jmrelayfn@p5DE4A382.dip0.t-ipconnect.de] has joined #joinmarket 18:07 -!- CgRelayBot [~CgRelayBo@p5DE4A382.dip0.t-ipconnect.de] has joined #joinmarket 18:31 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket 20:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 20:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket 22:08 < zfk> has tx_broadcast been added/fixed or does it still only work with "self" ? 22:11 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket 22:12 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]