--- Day changed Thu Mar 21 2019
01:54 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
01:55 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
07:58 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
08:50 < waxwing> nice unexpected side effect of the way i've got it working on Qt is, you can watch the coins moving from one mixdepth to the other in real time during a tumbler run. it's on a separate tab 'Coins'.
08:51 < waxwing> still need to fiddle with it a bit more.
09:54 < undeath> waxwing: you don't mind me slightly refactoring your pr code, do you?
09:55 < waxwing> no. to specify, the bugfix needed is get_balance_by_mixdepth needs to be able to optionally ignore disabled utxos (for offers from makers).
09:55 < waxwing> but other than that i think it works from my tests. and, yeah, go for it. maybe tell me what you'll do though?
09:56 < undeath> remove the code duplication in wallet_disableutxo
09:56 < undeath> err     
09:56 < undeath> in display_utxos_for_disable_choice_default
09:56 < waxwing> ah, k, istr something like that sure.
09:56 < waxwing> wait, why do you think self._utxo_meta is never None?
09:57 < waxwing> i think load_storage just skips it if it's not there right?
09:57 < waxwing> oh it's defaultdict, sorry
09:57 < undeath> yep     
09:57 < waxwing> right the next line covers it anyway, i see.
12:39 -!- Comstock_ is now known as Comstock     
13:37 < belcher> iv written up an idea for lightweight wallets that resist miner attacks, called DSPV (or developer SPV) https://gist.github.com/chris-belcher/60d58f51657e73b02a9cc04b6e363f89
13:41 < belcher> maybe obvious to some but im interested in whether users/enthusiasts would be comfortable with the tradeoffs
13:42 < gmaxwell> belcher: one concern that you're not addressing is that it makes developers a more attractive target for compromise or coercion-- doubly so because keys would have to be online, or a related that it may be harder to shed legal liability for their signing than it is for their software.
13:42 < gmaxwell> I think that I wouldn't be willing to run such a thing myself (even assuming I fully bought your arguments that it was a good thing!) unless I was paid pretty handsomly for the additional exposure.
13:43 < belcher> yes thats a good point
13:43 < belcher> i suppose devs are already targets (ghost43 from electrum says he regularly gets emails offering to buy the domains hardcoded into electrum) but this scheme would make the budget for attacks go up
13:44 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.4]     
13:44 < belcher> developers could nominate someone else by coding in their public key instead... but who would volunteer for that job
13:44 < gmaxwell> Right. this was a reason, for example, that I wanted to get the alert key published.
13:45 < gmaxwell> because I didn't want to have possession of any key material that anyone had reason to believe 'controlled bitcoin' or should be used to control bitcoin.  
13:45 < belcher> the alert key could probably be used for phishing too
13:45 < belcher> i suppose that kills the idea
13:47 < gmaxwell> I think your proposal would be better if it limited its scome to validity. E.g. are the developers doing something 'wrong' if they sign the 'wrong' side of a reorg attack
13:47 < gmaxwell> since you just say '51% attack' someone could read this as being intended to prevent reorgs, which I think isn't actually a realistic guarentee you could make. (e.g. the signer may only see the 'wrong' side of a reorg)
13:48 < belcher> yes i only intended for Bitcoin Classic style attacks, not rewriting the history
13:48 < nothingmuch> signing party could be anyone the user trusts, e.g. a friend, or a reputable company or individual, but then delivering sigs from an unbounded set of signers gets tricky, and requires config
13:48 < belcher> im not sure how to code a requirement for validity, since lightweight wallets cant check the validity
13:49 < gmaxwell> belcher: I mean in terms of what it says the signatures are supposted to do... right now it seems to say 'protect from 51% attacks'
13:49 < belcher> ill edit that, since in other parts it only talks about bitcoin classic style attacks
13:49 < gmaxwell> it should be clarified, I think, that it can't protected from 51% attacks in general, but it can at least protect from accepting blocks different than a full node.
13:50 < belcher> yes thats my only intention, good catch ty
13:50 < gmaxwell> the signatures could even signal which full node software they're checking against.
13:50 < nothingmuch> fwiw the way i read it is only as indicating that the developers' full node accepted some block, not re 51%
13:51 < belcher> changed to "The 6 block timeout means that any miner attack on SPV wallets which mines invalid blocks will stop working against Electrum wallets after 6 blocks. Presumably this should provide enough disincentive for 51% of miners to never attempt it. "
13:51 < gmaxwell> (I'm kinda dubious of the idea, but I think that at least you should have the best version of it. :P )
13:53 < gmaxwell> I wish I could see a way to tie this only to validity and not be able to use it to force winners in reorgs or whatnot.
13:53 < harding> The better idea IMO is to get BIP150/151-like things working so that you can query the nodes belonging to your trusted friends.
13:53 < gmaxwell> yea, if you have authenticated peerings then rules like "tx isn't confirmed unless at least two authenticated peers are on that chain"
13:53 < gmaxwell> are possible.
13:54 < belcher> isnt using trusted friends just transferring the problem somewhere else? those trusted friends still need a run a full node and they'd also find it expensive
13:55 < harding> belcher: transfering it to devs is arguably the same thing too.  :-)
13:55 < harding> belcher: I think it's pretty normal for people to have friends who are more willing to go the extra mile on one thing that you yourself might not be so interested in.
13:56 < belcher> my feelings are devs would be enthusiasts would run nodes anyway
13:56 < harding> I mean, doesn't everyone in this chatroom get the requests from family and friends to fix their computers?
13:56 < gmaxwell> FWIW, see the threat on reject messages on the bitcoin-dev list, which could also be titled: "Lite wallet authors don't want the resource usage of running a full node so they can test" :P
13:56 < belcher> but yes i see what you mean, its a good option at least
13:56 < gmaxwell> s/threat/thread/
13:56 < harding> gmaxwell: aiiie, that's insanity.
13:57 < gmaxwell> it's not new though. there are a number of people who work on -core who at varrious times have tried contributing without a working node on mainnet.
13:57 < gmaxwell> a lot of people's only computer is an OSX laptop...
13:57 < gmaxwell> and if it has a 256GB SSD .... well, you're not running without pruning now. :)
13:58 < gmaxwell> I'm even guilty to a slight extent: I don't have testnet running anywhere anymore....
13:58 < belcher> what else makes you feel dubious about the idea gmaxwell apart from my now-fixed bad writing and increased targeting of the devs
14:01 < gmaxwell> belcher: same general problem I have with signy things, basically market forces end up creating a power law distribution so this sort of thing would confer a lot more power in fewer hands.  Yes, developers already have some power but at least absent push software updates it's gated by users upgrading.
14:01 < belcher> thanks for explaining
14:02 < gmaxwell> hm. I guess this, imagine things worked like this before in 2015 but even MORE users used SPV clients than did then (because like... they were more secure!) .... and the keys were held by hearn (anything bitcoinj based) and kyupichan (electrum).
14:02 < gmaxwell> E.g. if you want to know how dangerous a policy is, imagine your enemies control it.
14:03 < belcher> yep i see what you mean
14:03 < belcher> and people who work on lightweight wallets tend to be supportive of their security model
14:03 < gmaxwell> the fact that I don't see a way to limit it to validity also means unfortunately that there is no way to prevent it from providing "sham reorg protection", so you could easily see people concluding it was "more safe" than fullnodes.
14:03 < gmaxwell> "Look, I don't need to be able to handle reorgs, I just wait for Hearn to sign my blocks!" :P
14:04 < belcher> yes yes i see
14:05 < belcher> ah well, dead idea, luckily i didnt spend too much time on it.. maybe in future someone will come up with something else
14:05 < belcher> you need to find some other entity to trust to verify on your behalf
14:06 < gmaxwell> pft. don't let me kill ideas like that.
14:06 < gmaxwell> I mean, I don't love it but TBH its better than a lot of crap I see lite wallets do.
14:06 < gmaxwell> "I'll just grab neutrino filters from multiple peers and if they match I'll trust they are fine!" 
14:07 < belcher> dont feel bad hah, bad ideas have to die
14:07 < belcher> i was thinking of implementing neutrino in joinmarket for a lightweight wallet mode but didnt like the idea of fully trusting the miners
14:07 < gmaxwell> Like I'd rather see wallets doing developer signed nutrino filters than crazy "please sybil attack the network" peer comparison stuff.
14:08 < belcher> i guess the "trusted friend" idea is better than i originally thought, since they wont be as centralized
14:08 < belcher> i could imagine bitcoin meetup groups and merchants advertising that you can connect to their node for extra security
14:08 < belcher> (but then the merchant might be bitpay, so who knows)
14:08 < gmaxwell> well in practice everyone's trusted friend would be coinbase. :P
14:09 < gmaxwell> or blockchain.info or whatever.
14:14 < belcher> here's an idea... in the future we'd expect payjoin to be used a lot, and payjoin involves an interaction between sender and receiver (say customer and merchant)
14:14 < belcher> so why not have that the communication also involves sending a best block hash, with the reasoning being that merchants might run full nodes more
14:15 < belcher> the same could be done for joinmarket, have market makers (who all run full nodes) send a block hash during their communication with takers (who often might run lightweight wallets)
14:15 < harding> belcher: might be nicer to get a protocol improvement that allows transactions to commit to the current best block hash.
14:16 < harding> (Or the hash of whatever block their nLockTime points to by height.)
14:16 < belcher> does that solve the problem? since lightweight wallets can obtain a value for "best block hash" by downloading all the headers
14:18 < nothingmuch> isn't the sending party the one with the most incentive to lie about chain tip?
14:19 < nothingmuch> and as a sender, you wouldn't really care, it's the receiver that is interested in confirmation
14:20 < harding> belcher: having both parties send what they think is their best tip could help communicate that something might be wrong.  Committing to it in the transaction could help make the transaction invalid in case of accidental forks.
14:20 < belcher> so that would be like, having the address commit to the block hash
14:21 < belcher> ok i see what you mean, the idea is the "trusted friend" one except that friend is the merchant you're paying
14:21 < harding> Well, the proposals I've heard are just having the signature commit to the block hash of a block at a height indicated somewhere else in thetransaction.
14:22 < harding> belcher: in that case, nothingmuch is correct that the spender probably doesn't care much about chain validity at the point they're spending.  They only care when they're receiving.
14:23 < harding> (And if the spender is attempting to spend a coin they never actually received because it came from an invalid chain, the payjoin is going to fail anyway.)
15:03 -!- Comstock_ [Comstock@gateway/vpn/privateinternetaccess/comstock] has joined #joinmarket     
15:06 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has quit [Ping timeout: 255 seconds]     
18:50 -!- AgoraRelay [~jmrelayfn@p5DE4AA8D.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
19:05 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
19:06 -!- AgoraRelay [~jmrelayfn@p5DE4A927.dip0.t-ipconnect.de] has joined #joinmarket     
20:33 -!- Comstock- [~Comstock@unaffiliated/comstock] has joined #joinmarket     
20:36 -!- Comstock_ [Comstock@gateway/vpn/privateinternetaccess/comstock] has quit [Ping timeout: 244 seconds]     
20:59 -!- technonerd [~techno@unaffiliated/technonerd] has quit [Read error: Connection reset by peer]     
21:32 -!- takinbo [uid19838@gateway/web/irccloud.com/x-qerinmpzwzsmzeoc] has quit [Ping timeout: 268 seconds]     
21:34 -!- takinbo [sid19838@gateway/web/irccloud.com/x-oihfqbquzgdviglw] has joined #joinmarket     
21:38 -!- Comstock- [~Comstock@unaffiliated/comstock] has quit [Quit: Leaving]     
21:49 -!- Comstock [Comstock@gateway/vpn/privateinternetaccess/comstock] has joined #joinmarket     
22:10 -!- technonerd [~techno@unaffiliated/technonerd] has joined #joinmarket     
22:58 -!- prasad [af656a87@gateway/web/freenode/ip.175.101.106.135] has joined #joinmarket     
22:58 < prasad> hi     
23:02 -!- prasad [af656a87@gateway/web/freenode/ip.175.101.106.135] has quit [Ping timeout: 256 seconds]