--- Log opened Mon Mar 25 00:00:25 2019
00:03 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
00:04 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
00:22 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
00:26 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 245 seconds]
00:52 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
00:54 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
00:55 -!- ccdle12 [~ccdle12@116.92.188.38] has quit [Remote host closed the connection]
00:59 -!- ccdle12 [~ccdle12@116.92.188.38] has joined #bitcoin-core-dev
01:41 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
01:45 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
01:50 -!- ccdle12 [~ccdle12@116.92.188.38] has quit [Remote host closed the connection]
02:31 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
02:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
02:35 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
02:45 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:50 < jonasschnelli> I was waiting for Voskuils mailing list reply... *sigh*
02:56 -!- oneark [uid254801@gateway/web/irccloud.com/x-iiqmeklnlucgbfmi] has joined #bitcoin-core-dev
03:09 < nothingmuch> while his points are valid, i never quite understood the actual objection is
03:26 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:28 < jonasschnelli> his points are valid... but he fails to see the current state as well as the potential of v2 for its future
03:29 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:33 < nothingmuch> i'm not sure if that's a charitable interpretation, i just think he interprets the current situation & potential differently, if i'm not mistaken his main objections are to the accompanying peer authentication? maybe more precisely, i don't understand why he predicts censorship as the most likely outcome
03:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:47 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
04:01 < jonasschnelli> peer authentication is happening and going to happen in future. We currently authenticate with the IP (-connect=IP)... there are many users doing this.
04:02 < jonasschnelli> Also, the opportunistic encryption sets a much higher burden for a MITM... a) active interception rather then just manipulating/listening packages, b) risk of being detected
04:02 < jonasschnelli> Right now, an ISP can spy on your and even tamper and you would have almost zero chance to detect this. The possibility of detection alone is a feature
04:05 < echeveria> you're not wrong.
04:07 < echeveria> in a lot of situations they could just connect back to you on 8333 if they wanted to though. 
04:11 < nothingmuch> unauthenticated opportunistic encryption i think can also be argued for empirically, e.g. bittorrent throttling in the past
04:13 < nothingmuch> i guess what i'd better like to understand is why he thinks censorship is any more likely with these features than without, the way i see it there is about as much potential right now
04:16 < nothingmuch> the way i see it, if anything, improving privacy at the p2p level would make censorship harder, but at any rate it's not a 1 dimensional spectrum
04:16 < echeveria> I couldn't work that out. its pretty clear what is running bitcoin, from the traffic or the port number.
05:04 < harding> echeveria: encryption by itself, if we assume no mitm and no eclipse, improves own-transaction relay privacy in combination with Bitcoin Core's existing tx trickling code.  Right now when you send your own transaction, spy nodes can't be sure whether you originated a transaction or just relayed it.  However, your ISP can see that you never received the tx over clearnet before sending it, so unless your node is also on Tor or 
05:04 < harding> otherwise multihomed, the ISP can determine what txes you originated.
05:05 -!- oneark [uid254801@gateway/web/irccloud.com/x-iiqmeklnlucgbfmi] has quit [Quit: Connection closed for inactivity]
05:08 -!- zhangzf [~zhangzf@120.244.121.61] has joined #bitcoin-core-dev
05:09 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-zchkcmvmyfhzqhdp] has joined #bitcoin-core-dev
05:10 < echeveria> harding: so, they just connect to you directly if you're listening. 
05:12 < echeveria> all of this is really difficult to reason about. encryption in networks with anonymous peers. 
05:15 < harding> echeveria: yes, but (as I mentioned) Bitcoin Core trickles txes.  That is, it doesn't send to each of its peers immediately but separates all of its peers into buckets of peers and maintains a queue of transactions for each bucket, sending to all the peers in the bucket on some schedule.  This means a transaction may be propagated to a non-spy node, relayed through the network, and then heard about by the spy node from some other 
05:15 < harding> peer before the spy node hears about thet transaction from your peer.
05:25 -!- jonatack [d598a165@gateway/web/freenode/ip.213.152.161.101] has joined #bitcoin-core-dev
05:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:49 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
05:58 -!- Aaronvan_ is now known as AaronvanW
06:12 -!- aitorjs [~aibanez@161.187.16.95.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:15 -!- zhangzf [~zhangzf@120.244.121.61] has quit [Ping timeout: 250 seconds]
06:15 -!- zhangzf [~zhangzf@223.72.70.128] has joined #bitcoin-core-dev
06:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
06:22 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Remote host closed the connection]
06:22 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev
06:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
06:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
06:28 < emilr> any reason against using ssl Electrum style? Each peer has its own self generated certificate, download the cerfiticate at first connect and then use that certificate to authenticate the peer
06:28 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #bitcoin-core-dev
06:28 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection]
06:30 -!- lc2g [~lc2g@static.177.220.213.82.ibercom.com] has joined #bitcoin-core-dev
06:32 < nothingmuch> emilr: from a trust/security POV, that's essentially what the proposal enables, but with lower complexity than TLS (no crypto agility, no PKI, ...)
06:32 < wumpus> main reason for not using ssl is that it adds too much attack surface, and its complexity makes it hard to be confident in its security
06:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
06:41 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
06:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.2]
06:46 -!- mildly_risky [~~mildly_r@n11211889041.netvigator.com] has joined #bitcoin-core-dev
06:46 -!- mildly_risky [~~mildly_r@n11211889041.netvigator.com] has quit [Client Quit]
06:48 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
06:51 -!- mildly_risky [~~mildly_r@n11211889041.netvigator.com] has joined #bitcoin-core-dev
06:55 -!- mildly_risky [~~mildly_r@n11211889041.netvigator.com] has quit [Client Quit]
06:56 -!- spaced0ut_ [~spaced0ut@198.211.112.88] has joined #bitcoin-core-dev
06:56 -!- spaced0ut_ [~spaced0ut@198.211.112.88] has quit [Client Quit]
06:58 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 250 seconds]
07:00 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
07:12 -!- asdasdasd [2d4cef8f@gateway/web/freenode/ip.45.76.239.143] has joined #bitcoin-core-dev
07:13 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 272 seconds]
07:13 -!- asdasdasd [2d4cef8f@gateway/web/freenode/ip.45.76.239.143] has quit [Client Quit]
07:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:14 < bitcoin-git> [bitcoin] practicalswift opened pull request #15663: Remove unused AES-128 code (master...aes-128) https://github.com/bitcoin/bitcoin/pull/15663
07:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:19 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
07:20 -!- aitorjs [~aibanez@161.187.16.95.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
07:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:30 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
07:34 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
07:43 -!- aitorjs [~aibanez@14.85-86-116.dynamic.clientes.euskaltel.es] has joined #bitcoin-core-dev
07:49 -!- jonatack [d598a165@gateway/web/freenode/ip.213.152.161.101] has quit []
08:15 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 250 seconds]
08:21 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
08:36 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
08:45 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
08:47 -!- morcos_ [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
08:50 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 256 seconds]
08:50 -!- morcos_ is now known as morcos
08:52 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 272 seconds]
09:07 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
09:16 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
09:17 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
09:17 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
09:18 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
09:25 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has quit [Quit: pinheadmz]
09:27 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 245 seconds]
09:28 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
09:33 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
09:42 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
09:44 -!- zhangzf [~zhangzf@223.72.70.128] has quit [Remote host closed the connection]
09:45 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
09:47 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 250 seconds]
09:48 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:50 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Read error: Connection reset by peer]
10:10 -!- aitorjs [~aibanez@14.85-86-116.dynamic.clientes.euskaltel.es] has quit [Remote host closed the connection]
10:11 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has quit [Quit: pinheadmz]
10:11 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
10:15 -!- wzhroho [~robino@195.91.48.152] has joined #bitcoin-core-dev
10:33 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
10:35 -!- wzhroho [~robino@195.91.48.152] has quit [Remote host closed the connection]
10:39 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
11:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-zchkcmvmyfhzqhdp] has quit [Quit: Connection closed for inactivity]
11:11 -!- kmels [~carlos@2803:7000:6000:1cd6:1cac:2754:b362:eb8a] has joined #bitcoin-core-dev
11:14 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
11:14 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
11:15 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
11:16 -!- hebasto [~hebasto@95.164.65.194] has quit [Client Quit]
11:16 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
11:22 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
11:25 -!- promag [~promag@83.223.233.118] has joined #bitcoin-core-dev
11:58 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 250 seconds]
12:04 < achow101> sipa: any ideas on how addmultisig and multisig in general will work with thew plan for the new ismine logic? I've started working on replacing the ismine logic but I ran into some problems with multisig and the current ismine weirdness surrounding that.
12:06 < sipa> achow101: so i think you'd have the "old world state" and "new world state", which are independent, and if either of them says an output is yours, it's yours
12:06 < achow101> my plan was to make it so that what is currently considered ismine wouldn't actually change, but that seems to not be possible
12:06 < sipa> and addmultisig would keep interacting with just the old state
12:06 < achow101> bleh
12:06 < sipa> i don't think there is any other way
12:06 < sipa> in the old mechanism, things interact in stupid and unpredictable ways
12:07 < sipa> that just don't fit in the descriptor based view
12:07 < sipa> at some point it may be useful to try to convert the old state into a new state, and then disable RPCs that interact with the old state
12:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:08 < sipa> but i think that's better done as a separate thing from actually supporting both
12:08 < achow101> what about getting rid of addmultisig and just make people use createmultisig and importmulti if they want that script and watch it?
12:08 < achow101> the import stuff actually makes sense under the new ismine
12:09 < sipa> in a descriptor based wallet you have no need for either RPC
12:09 < sipa> you can just import a descriptor with the multisig key in it directly
12:10 < sipa> maybe a utility function that has input compatible with createmultisig that spits out a descriptor is useful
12:10 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
12:10 < achow101> i wanted to avoid having two separate ismine logics
12:11 < sipa> i fear that's going to be very hard
12:11 < gmaxwell> I wonder if anyone is actually using addmultisig.
12:12 < sipa> achow101: to be clear, i think it's just hard for compatibility reasons - if you don't, you need to do something like convert an old wallet to the new design on first use with new code... and that will inevitably change the semantics of some existing RPCs
12:13 < sipa> plus that conversion is nontrivial
12:13 < sipa> and presumably that conversion will effectively need a copy of the old ismine logic anyway
12:14 < achow101> From what i've done so far, converting a wallet that doesn't have multisig is pretty straightforward
12:14 < achow101> and afaict it doesn't require the old ismine logic
12:15 < sipa> possibly
12:15 < sipa> though there are weird edge cases around single-key things as well (like requiring a p2sh version imported before native segwit outputs are treated as ismine)
12:16 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
12:17 < gmaxwell> Keeping around the old thing and bolting something new on the side is a fairly simple thing that has some pretty good guarentees for compatibility.
12:17 < gmaxwell> Anything else will take more work and not guarentee compatibility as strongly.
12:18 < sipa> newly created wallets can lack the old state altogether, and just not support addmultisig (and possibly other RPCs)
12:19 < gmaxwell> We could also depricate addmultisig, so you have to set a config option to get access to it, in order to stop people from using it.
12:19 < gmaxwell> (... if any are...)
12:19 < achow101> gmaxwell: I'm tempted to do that
12:19 < gmaxwell> I earnestly doubt anyone is using.
12:19 < sipa> that seems reasonable now we have a more usable importmulti and descriptors... but it doesn't solve the problem of what to do with wallets that have it
12:20 < sipa> i certainly have used it!
12:21 < sipa> https://bitcoin.stackexchange.com/questions/83102/how-to-import-p2wsh-in-p2sh-multisig-as-watch-only
12:22 < gmaxwell> sipa: yes, you and I have but we don't count.
12:22 < gmaxwell> (as you and I would just use importmulti...)
12:22 < sipa> importmulti has the same problem
12:23 < achow101> does it?
12:23 < sipa> you can emulate whatever addmultisig does using importmulti
12:24 < gwillen> can someone help me remember / grok the difference between addmultisig and createmultisig+import
12:25 < sipa> gwillen: createmultisig just computed the address/redeemscript you'd import if you would have used addmultisigaddress
12:25 < sipa> but it's a utility rpc instead of a wallet rpc
12:26 < gwillen> interesting
12:27 < sipa> achow101: so there is an open question around importmulti in the new state, i think
12:27 < sipa> importmulti lets you specify exactly which outputs you're talking about... but then effectively imports things in a way that quite possibly affect other outputs as well
12:27 < achow101> sipa: importmulti will explicitly add the script as watchonly if you don't have the keys. I don't think addmultisig does that so spends to the multisig wouldn't be considered ismine or watchonly
12:28 < sipa> achow101: good point; you need addmultisig+importaddress to emulate importmulti
12:28 < sipa> the question is whether in a post-native-descriptor design, importmulti can have its semantics changed to only affect the outputs you're actually talking about
12:29 < sipa> (because i've seen people talk about calling importmulti multiple times taking advantage of the interaction to accomplish missing things... )
12:30 < achow101> imo with the native descriptor design, all existing import rpcs should just not work on those wallets
12:30 < sipa> agree
12:30 < sipa> there should just be importdescriptor or importrecord or something
12:31 < sipa> but then i do think the cleanest design is to just keep the old state around, and as long as you have old state... the old RPC work on that
12:31 < sipa> and new RPCs work on the new state
12:31 < sipa> as otherwise you'd force people to adopt a new set of RPCs whenever their wallet gets upgraded
12:32 < gwillen> let me bang the drum as usual for doing the split at the wallet level
12:32 < achow101> .. right. I see how that is the safest and most compatible way to go about this
12:32 < gwillen> your old wallet has old RPCs, your new wallet has new descriptor-native RPCs
12:32 < gwillen> the two never to mix
12:33 < sipa> gwillen: i think that's fair from a user perspective... but it doesn't really simplify the code (beyond have a restriction that you can't have both states at the same time)
12:33 < achow101> well somethings of the old design might leak into the new design due to use in a lot of places. e.g. isminetypes
12:34 < sipa> those are fine
12:37 < gmaxwell> creating a sharp line between old wallets and new wallets sticks users with old functionality until they create a new wallet (and probably make a privacy destroying sweep-- since we can't spend across wallets).. it also splits up the user/testing base.
12:38 < gmaxwell> it might be justifyable if the new thing were just done, but its constantly advancing, we can't really use 'make a new wallet' as the general upgrade mechenism for each new version.
12:39 < achow101> gmaxwell: there should be someway to upgrade from old to new with some caveats regarding ismine
12:39 < sipa> achow101: i think we want to generalize what "watchonly" means, so it becomes independent from the question whether you happen to have the private key exactly in your wallet.dat file (so for example a HW wallet doesn't need to be marked as watchonly...), 
12:39 < achow101> sipa: in my current design, i have watchonly be defined as existing in setWatchonly and mine as existing in a newly introduced setScriptPubKeys
12:39 < sipa> gmaxwell, achow101: i think a correct conversion from old to new is possible, but it will (a) involve the old IsMine logic and (b) preferably something that isn't forced upon you when you upgrade software
12:40 < sipa> achow101: have you read https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2 ?
12:40 < achow101> yeah
12:41 < sipa> i really think watchonly should just be a boolean in the descriptor record
12:41 < sipa> saying "do i want to treat things that match this as really mine, or just something i'm watching"
12:41 < gmaxwell> Why shouldn't the concept of watch only be eliminated and replaced with signing sources, with null a potential signing source.
12:42 < gmaxwell> ?
12:42 < achow101> the way I imagined it was that descriptors would be expanded to sets of scriptPubKeys and, depending on that bool, the scriptPubkeys would go into the appropriate set
12:42 < gmaxwell> sipa: that boolean split alone isn't the most useful... esp because it is just a single category.
12:42 < sipa> gmaxwell: for example a multisig you're participanting is may be something you want to watch, but not count as your balance
12:43 < sipa> i expect gwillen to now say "just use a separate wallet for that", and he's probably right
12:43 < gmaxwell> sipa: make a seperate wallet?
12:43 < gmaxwell> The fact that watching has only a single category "watching" makes it much less useful...
12:43 < sipa> true
12:43 < achow101> gmaxwell: that would be ideal, but breaks upgrading I think
12:44  * sipa lunch
12:44 < gmaxwell> well let me revise, there is a seperate "non-balance" functionality that is useful: collecting txouts for filling a PSBT.
12:44 < gmaxwell> I agree _that_ kind of watching actually is useful, doesn't need special categories, doesn't interact with balances, etc.
12:45 < midnightmagic> +1 filling txouts for PSBT
12:45 < gmaxwell> achow101: breaking upgrading for more obscure features isn't something we should reject out of hand.
12:45 < gmaxwell> achow101: we could allow an upgrade that stripped out all watching (or converted it into something else)
12:46 < achow101> well I suppose an upgrade could just make two wallets
12:46 < gmaxwell> right.
12:47 < gwillen> yeah, I do maintain "keep separate wallets for separate sorts of funds" is the right call
12:48 < gmaxwell> gwillen: I agree, but I expect that virutally no watchonly use is 'seperate funds' (esp because the user interface for watching is mostly unusable), it does however get used to provide inputs e.g. for multisigs.
12:49 < gwillen> well my thinking is like, if you have your own funds in a wallet, and you also have keys that represent part of a multisig that holds funds
12:49 < gwillen> it's better for those to be two separate wallets
12:49 < gwillen> rather than try to puzzle how how we should define 'watchonly' and 'ismine' to make that scenario work smoothly
12:49 < gmaxwell> another way of looking at this is that provide general random access indexes scriptpubkeys isn't particularly viable, we don't do it, and don't plan to do it...  our answer to needing to find inputs for random scriptpubkeys is "add them to a wallet before use so the wallet will track them"
12:50 < gwillen> e.g. you will probably not want to spend "some funds from my wallet and also some funds from the multisig" in the same tx
12:50 < gwillen> although I guess if you did ever want that, it's an argument against separate wallets
12:50 < gmaxwell> I think you're talking past me.
12:50 < gwillen> probably
12:52 < gmaxwell> "some funds from my wallet and also some funds from the multisig" isn't something that is usable with watchonly now.
12:52 < gwillen> mmm, heh, that's a good point
12:53 < gmaxwell> It is one of the problems with the "use lots of wallets for all the things" line of thinking however, but I think that isn't a concern in this discussion.
12:53 < gmaxwell> I think right now the thing watchonly actually gets used for is simply telling the wallet to collect data for providing inputs to transactions, without getting in the way of normal wallet use.
12:54 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
12:54 < midnightmagic> +1 that use; also informational tracking of known addresses.
12:54 < gmaxwell> now, this could be done by just making another wallet, throwing everything you want to collect data on in it and then ignoring it otherwise.
12:55 < gmaxwell> midnightmagic: I don't believe it's used like that right now, there isn't for example, a usable way to get balances, and presumably you want to watch more than one such thing.
12:56 < gmaxwell> It gets used by things like custom wallet software to make bitcoin core track data needed for spending. I assume electrum personal server uses it. Joinmarket uses it.
12:56 < achow101> gmaxwell: instead of a watchonly wallet, use scantxout set :p
12:56 < midnightmagic> gmaxwell: I'm currently using: b -rpcwallet=weirdwallet.dat listunspent|grep -A 2 -i weird|grep amount|awk '{ print $2 }'|sed -e 's/,//g' | paste -sd+ | bc -l
12:57 < gmaxwell> achow101: doesn't work if you need to see past spends, and alsoscantxoutset is pretty slow!
12:58 < gmaxwell> but perhaps the concept should be dropped and replaced with something that better fits how its mostly being used.
12:58 < achow101> if you're just filling psbts, you don't need past spends
12:58 < gmaxwell> midnightmagic: okay, well if you actually want to follow some other wallet I think thats a case where running a seperate wallet file makes sense to me.
12:59 < midnightmagic> Just a hackish informational thing that means I don't have to use bitcoin-iterate 
12:59 < midnightmagic> +1 laziness
12:59 < gmaxwell> achow101: yes, but examples I listed do more than just fill out psbts. 
13:00 < gmaxwell> But they don't need balances, coinselections, etc.
13:08 -!- promag [~promag@83.223.233.118] has quit [Remote host closed the connection]
13:21 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 250 seconds]
14:06 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
14:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:14 < bitcoin-git> [bitcoin] instagibbs opened pull request #15664: change default Python block serialization to witness, test round-trip (master...default_wit_block) https://github.com/bitcoin/bitcoin/pull/15664
14:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:15 -!- promag [~promag@83.223.232.11] has joined #bitcoin-core-dev
14:20 -!- promag [~promag@83.223.232.11] has quit [Ping timeout: 250 seconds]
14:25 -!- omonk [~omonk@unaffiliated/omonk] has joined #bitcoin-core-dev
14:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
14:46 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
14:50 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 255 seconds]
14:55 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
14:57 -!- BostX [4db9aff2@gateway/web/freenode/ip.77.185.175.242] has joined #bitcoin-core-dev
14:59 < BostX> Hi, do you know why signrawtransactionwithwallet returns the same hex as entered?
15:00 < sipa> presumably because it couldn't sign anything
15:01 < BostX> sipa: but it was completed with "true"
15:01 < sipa> then it's already fully signed!
15:01 < BostX> sipa: that's impossible
15:01 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
15:03 < sipa> BostX: what's the input?
15:03 < sipa> (you can pm me)
15:03 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 250 seconds]
15:06 < BostX> sipa: I created: bitcoin-cli createrawtransaction '[]' '{"unused-new-address": <number>}'
15:06 < BostX> sipa: then I was returned the hex
15:06 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:06 < sipa> BostX: you have no inputs, so all inputs are by definition signed
15:07 < sipa> you probably want to call fundrawtransaction first to add inputs and change
15:10 < BostX> sipa: aaaah... that's possible. BTW I was following the https://stackoverflow.com/a/46637033
15:11 < BostX> sipa: I thought the createrawtransaction '[]' knows automatically how to add an input.
15:11 < BostX> sipa: what is a `change`?
15:11 < sipa> BostX: perhaps you should head to bitcoin.stackexchange.com
15:11 < sipa> you shouldn't be using these RPC functions if you don't know what change outputs are
15:15 < BostX> sipa: Uhm... I'd like to sign my TX on an offline computer where I don't want to install anything other than bitcoin-core.
15:15 < sipa> BostX: yes, this is the wrong place to ask such questions
15:17 < BostX> sipa: not really - I wasn't asking "how" I was asking "why it doesn't work", since I got no(!) errors. I consider this to be a legitimate question for this place.
15:18 < sipa> BostX: well, the answer is that your transaction has no inputs, so signrawtransactions responds by saying all your inputs are signed
15:18 < BostX> sipa: yes yes I was also asking "what is a change" but I'm able to figure it now by myself... don't worry.
15:18 < sipa> which is expected
15:19 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
15:20 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:22 < BostX> sipa: maybe some warnings would be helpful. Like "You're signing a TX w/ no inputs". Or maybe a better message in the `bitcoin-cli help signrawtransactionwithwallet`
15:23 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
15:24 < achow101> BostX: If you are planning on using an offline computer, I recommend using the psbt RPCs
15:25 < achow101> https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md has some info on how to use them
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:28 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7b13c6464579...8a8b03ecd221
15:28 < bitcoin-git> bitcoin/master 5801dd6 gwillen: docs: Add more tips to productivity.md
15:28 < bitcoin-git> bitcoin/master 8a8b03e MarcoFalke: Merge #15603: docs: Add more tips to productivity.md
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:29 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15603: docs: Add more tips to productivity.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15603
15:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:30 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:30 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:32 -!- Cory [Cory@unaffiliated/cory] has quit [Ping timeout: 255 seconds]
15:35 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
15:35 < gwillen> BostX: I'm going to send you a PM
15:38 -!- Cory [Cory@unaffiliated/cory] has joined #bitcoin-core-dev
15:51 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
16:01 -!- omonk [~omonk@unaffiliated/omonk] has quit [Quit: omonk]
16:01 -!- omonk [~omonk@unaffiliated/omonk] has joined #bitcoin-core-dev
16:03 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 245 seconds]
16:03 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
16:22 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
16:24 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
16:26 -!- jarthur [~jarthur@207.114.244.5] has quit []
16:29 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
16:29 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
16:35 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 246 seconds]
16:35 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitcoin-core-dev
16:35 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
16:35 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
16:45 -!- shesek [~shesek@185.3.144.77] has joined #bitcoin-core-dev
16:46 -!- shesek [~shesek@185.3.144.77] has quit [Changing host]
16:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:46 -!- pinheadmz [~matthewzi@96-82-67-198-static.hfc.comcastbusiness.net] has quit [Quit: pinheadmz]
16:50 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 255 seconds]
16:50 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitcoin-core-dev
16:50 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
16:50 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
16:51 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev
16:54 -!- trillhc [~trillhc@192.252.222.35] has joined #bitcoin-core-dev
17:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
17:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:10 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 250 seconds]
17:17 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
17:28 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:28 -!- benthecarman [~benthecar@ics133-248.icsincorporated.com] has joined #bitcoin-core-dev
17:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 255 seconds]
17:32 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
17:35 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
17:37 -!- trillhc3 [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
17:41 -!- trillhc [~trillhc@192.252.222.35] has quit [Ping timeout: 246 seconds]
17:56 -!- Bullitje [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev
17:57 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitcoin-core-dev
17:57 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
17:57 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
17:58 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
17:58 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Ping timeout: 255 seconds]
18:02 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 245 seconds]
18:04 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
18:12 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
18:18 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 245 seconds]
18:19 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
18:25 -!- BostX [4db9aff2@gateway/web/freenode/ip.77.185.175.242] has quit [Quit: Page closed]
18:25 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
18:25 -!- trillhc3 [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer]
18:31 -!- lc2g [~lc2g@static.177.220.213.82.ibercom.com] has quit [Quit: Leaving]
18:31 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
18:34 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Remote host closed the connection]
18:34 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
18:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 245 seconds]
18:36 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
18:44 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection]
18:48 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
18:55 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:02 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
19:02 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
19:10 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
19:14 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 250 seconds]
19:14 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 245 seconds]
19:17 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
19:25 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
19:29 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 255 seconds]
19:34 -!- Pink_ [ac38106b@gateway/web/freenode/ip.172.56.16.107] has joined #bitcoin-core-dev
19:35 < Pink_> Adminastrator developer
19:37 < Pink_> Bitcoin miner mining
19:43 < Pink_> Mine calico mines place claim with official legal waiver use bullet point 1. Exact location 2. Fees. 3. Degree. 5. License per-tax,.
19:44 < Pink_> Compliance
19:45 < Pink_> With the act of 1933
19:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
19:51 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
19:51 < Pink_> Use bitcoin wallet JEFFREY HENRY BANKS
19:52 < Pink_> YES
19:53 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
19:53 -!- mode/#bitcoin-core-dev [+b *!*ac38106b@*.172.56.16.107] by sipa
19:53 -!- Pink_ was kicked from #bitcoin-core-dev by sipa [Pink_]
19:54 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
19:57 -!- mildly_risky [~~mildly_r@14-0-175-098.static.pccw-hkt.com] has joined #bitcoin-core-dev
20:00 -!- mildly_risky [~~mildly_r@14-0-175-098.static.pccw-hkt.com] has quit [Client Quit]
20:01 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
20:02 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
20:20 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
20:36 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
20:40 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
20:47 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
20:48 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
20:51 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Ping timeout: 256 seconds]
20:58 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
21:02 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev
21:34 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
21:35 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
21:38 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
21:49 -!- jhfrontz1 [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.]
22:06 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
22:35 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
22:37 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
22:39 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 272 seconds]
22:42 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
22:57 -!- omonk [~omonk@unaffiliated/omonk] has quit [Read error: Connection reset by peer]
23:02 -!- omonk [~omonk@unaffiliated/omonk] has joined #bitcoin-core-dev
23:07 -!- DougieBot5000_ is now known as DougieBot5000
23:09 -!- harrymm [~harrymm@43.249.37.7] has quit [Ping timeout: 272 seconds]
23:22 -!- harrymm [~harrymm@mx-ll-223.204.125-126.dynamic.3bb.co.th] has joined #bitcoin-core-dev
23:22 -!- harrymm [~harrymm@mx-ll-223.204.125-126.dynamic.3bb.co.th] has quit [Client Quit]
23:46 -!- robo_ [7ca0d676@gateway/web/freenode/ip.124.160.214.118] has joined #bitcoin-core-dev
23:50 -!- robo_ [7ca0d676@gateway/web/freenode/ip.124.160.214.118] has quit [Ping timeout: 256 seconds]
--- Log closed Tue Mar 26 00:00:26 2019