12019-03-25T00:05:12  *** justanotheruser has joined #bitcoin-core-dev
  22019-03-25T00:21:53  *** fanquake_ has quit IRC
  32019-03-25T00:25:03  *** Guest80974 has quit IRC
  42019-03-25T00:29:54  *** Zenton has quit IRC
  52019-03-25T00:45:04  *** belcher has quit IRC
  62019-03-25T00:52:19  *** EagleTM has joined #bitcoin-core-dev
  72019-03-25T00:52:59  *** Aaronvan_ has joined #bitcoin-core-dev
  82019-03-25T00:56:28  *** AaronvanW has quit IRC
  92019-03-25T00:58:13  *** jonatack has quit IRC
 102019-03-25T01:05:06  *** _Sam-- is now known as tonto27
 112019-03-25T01:11:00  *** tonto27 is now known as _Sam--
 122019-03-25T01:18:31  *** zhangzf has joined #bitcoin-core-dev
 132019-03-25T01:24:08  *** belcher has joined #bitcoin-core-dev
 142019-03-25T01:31:26  *** fanquake has joined #bitcoin-core-dev
 152019-03-25T01:43:07  *** _Sam-- has quit IRC
 162019-03-25T01:55:35  *** Aaronvan_ is now known as AaronvanW
 172019-03-25T02:12:52  *** EagleTM has quit IRC
 182019-03-25T02:12:52  *** BGL has quit IRC
 192019-03-25T02:38:40  *** ccdle12 has joined #bitcoin-core-dev
 202019-03-25T02:40:56  *** dviola has joined #bitcoin-core-dev
 212019-03-25T02:50:48  *** spinza has quit IRC
 222019-03-25T02:52:59  *** kj_ has joined #bitcoin-core-dev
 232019-03-25T02:56:50  *** fanquake has quit IRC
 242019-03-25T02:57:44  *** fanquake has joined #bitcoin-core-dev
 252019-03-25T03:12:43  *** BGL has joined #bitcoin-core-dev
 262019-03-25T03:15:58  *** fanquake has quit IRC
 272019-03-25T03:20:18  *** spinza has joined #bitcoin-core-dev
 282019-03-25T03:22:18  *** promag has joined #bitcoin-core-dev
 292019-03-25T03:25:08  *** kj_ has quit IRC
 302019-03-25T03:26:24  *** promag has quit IRC
 312019-03-25T03:48:38  *** fanquake has joined #bitcoin-core-dev
 322019-03-25T03:54:58  *** fanquake has quit IRC
 332019-03-25T04:07:48  *** fanquake has joined #bitcoin-core-dev
 342019-03-25T04:16:02  *** ccdle12 has quit IRC
 352019-03-25T04:34:35  *** dviola has quit IRC
 362019-03-25T04:35:05  *** diego1 has joined #bitcoin-core-dev
 372019-03-25T04:35:31  *** diego1 has left #bitcoin-core-dev
 382019-03-25T04:44:06  *** dviola has joined #bitcoin-core-dev
 392019-03-25T05:14:41  *** fanquake has quit IRC
 402019-03-25T05:16:31  *** fanquake has joined #bitcoin-core-dev
 412019-03-25T05:18:46  *** fanquake has quit IRC
 422019-03-25T05:24:15  *** fanquake has joined #bitcoin-core-dev
 432019-03-25T05:31:58  <fanquake> dongcarl Sorry for the delay, getting to Guix capabilities today. Was sidetracked with other depends stuff.
 442019-03-25T05:56:58  *** ccdle12 has joined #bitcoin-core-dev
 452019-03-25T06:06:43  *** dviola has quit IRC
 462019-03-25T06:21:12  *** pinheadmz has quit IRC
 472019-03-25T06:36:23  *** fanquake has quit IRC
 482019-03-25T06:59:08  *** lnostdal has quit IRC
 492019-03-25T07:03:45  *** lnostdal has joined #bitcoin-core-dev
 502019-03-25T07:04:50  *** fanquake has joined #bitcoin-core-dev
 512019-03-25T07:22:18  *** promag has joined #bitcoin-core-dev
 522019-03-25T07:26:42  *** promag has quit IRC
 532019-03-25T07:52:34  *** promag has joined #bitcoin-core-dev
 542019-03-25T07:54:48  *** promag has quit IRC
 552019-03-25T07:55:36  *** ccdle12 has quit IRC
 562019-03-25T07:59:58  *** ccdle12 has joined #bitcoin-core-dev
 572019-03-25T08:41:20  *** promag has joined #bitcoin-core-dev
 582019-03-25T08:45:46  *** promag has quit IRC
 592019-03-25T08:50:49  *** ccdle12 has quit IRC
 602019-03-25T09:31:34  *** e4xit has joined #bitcoin-core-dev
 612019-03-25T09:34:50  *** Zenton has joined #bitcoin-core-dev
 622019-03-25T09:35:05  *** setpill has joined #bitcoin-core-dev
 632019-03-25T09:45:42  *** timothy has joined #bitcoin-core-dev
 642019-03-25T09:50:58  <jonasschnelli> I was waiting for Voskuils mailing list reply... *sigh*
 652019-03-25T09:56:01  *** oneark has joined #bitcoin-core-dev
 662019-03-25T10:09:36  <nothingmuch> while his points are valid, i never quite understood the actual objection is
 672019-03-25T10:26:13  *** Guyver2 has joined #bitcoin-core-dev
 682019-03-25T10:28:36  <jonasschnelli> his points are valid... but he fails to see the current state as well as the potential of v2 for its future
 692019-03-25T10:29:27  *** spinza has quit IRC
 702019-03-25T10:33:43  <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
 712019-03-25T10:46:07  *** spinza has joined #bitcoin-core-dev
 722019-03-25T10:47:11  *** zhangzf has quit IRC
 732019-03-25T11:01:13  <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.
 742019-03-25T11:02:20  <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
 752019-03-25T11:02:54  <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
 762019-03-25T11:05:53  <echeveria> you're not wrong.
 772019-03-25T11:07:25  <echeveria> in a lot of situations they could just connect back to you on 8333 if they wanted to though.
 782019-03-25T11:11:20  <nothingmuch> unauthenticated opportunistic encryption i think can also be argued for empirically, e.g. bittorrent throttling in the past
 792019-03-25T11:13:32  <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
 802019-03-25T11:16:02  <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
 812019-03-25T11:16:18  <echeveria> I couldn't work that out. its pretty clear what is running bitcoin, from the traffic or the port number.
 822019-03-25T12:04:12  <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
 832019-03-25T12:04:12  <harding> otherwise multihomed, the ISP can determine what txes you originated.
 842019-03-25T12:05:41  *** oneark has quit IRC
 852019-03-25T12:08:44  *** zhangzf has joined #bitcoin-core-dev
 862019-03-25T12:09:37  *** elichai2 has joined #bitcoin-core-dev
 872019-03-25T12:10:31  <echeveria> harding: so, they just connect to you directly if you're listening.
 882019-03-25T12:12:49  <echeveria> all of this is really difficult to reason about. encryption in networks with anonymous peers.
 892019-03-25T12:15:02  <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
 902019-03-25T12:15:02  <harding> peer before the spy node hears about thet transaction from your peer.
 912019-03-25T12:25:20  *** jonatack has joined #bitcoin-core-dev
 922019-03-25T12:26:52  *** AaronvanW has joined #bitcoin-core-dev
 932019-03-25T12:49:11  *** Aaronvan_ has joined #bitcoin-core-dev
 942019-03-25T12:52:15  *** AaronvanW has quit IRC
 952019-03-25T12:58:32  *** Aaronvan_ is now known as AaronvanW
 962019-03-25T13:12:47  *** aitorjs has joined #bitcoin-core-dev
 972019-03-25T13:15:00  *** zhangzf has quit IRC
 982019-03-25T13:15:39  *** zhangzf has joined #bitcoin-core-dev
 992019-03-25T13:21:49  *** justanotheruser has quit IRC
1002019-03-25T13:22:23  *** ExtraCrispy has quit IRC
1012019-03-25T13:22:50  *** ExtraCrispy has joined #bitcoin-core-dev
1022019-03-25T13:26:12  *** Aaronvan_ has joined #bitcoin-core-dev
1032019-03-25T13:27:27  *** AaronvanW has quit IRC
1042019-03-25T13:28:09  <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
1052019-03-25T13:28:48  *** cubancorona has joined #bitcoin-core-dev
1062019-03-25T13:30:47  *** lc2g has joined #bitcoin-core-dev
1072019-03-25T13:32:07  <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, ...)
1082019-03-25T13:32:10  <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
1092019-03-25T13:38:17  *** justanotheruser has joined #bitcoin-core-dev
1102019-03-25T13:41:42  *** spaced0ut has joined #bitcoin-core-dev
1112019-03-25T13:42:24  *** justanotheruser has quit IRC
1122019-03-25T13:46:56  *** mildly_risky has joined #bitcoin-core-dev
1132019-03-25T13:48:00  *** promag has joined #bitcoin-core-dev
1142019-03-25T13:51:56  *** mildly_risky has joined #bitcoin-core-dev
1152019-03-25T13:55:04  *** mildly_risky has quit IRC
1162019-03-25T13:56:22  *** spaced0ut_ has joined #bitcoin-core-dev
1172019-03-25T13:58:46  *** spaced0ut has quit IRC
1182019-03-25T14:00:26  *** spaced0ut has joined #bitcoin-core-dev
1192019-03-25T14:12:17  *** asdasdasd has joined #bitcoin-core-dev
1202019-03-25T14:13:06  *** spaced0ut has quit IRC
1212019-03-25T14:13:23  *** asdasdasd has quit IRC
1222019-03-25T14:14:41  *** bitcoin-git has joined #bitcoin-core-dev
1232019-03-25T14:14:41  <bitcoin-git> [bitcoin] practicalswift opened pull request #15663: Remove unused AES-128 code (master...aes-128) https://github.com/bitcoin/bitcoin/pull/15663
1242019-03-25T14:14:53  *** bitcoin-git has left #bitcoin-core-dev
1252019-03-25T14:19:52  *** spaced0ut has joined #bitcoin-core-dev
1262019-03-25T14:20:27  *** aitorjs has quit IRC
1272019-03-25T14:28:47  *** AaronvanW has joined #bitcoin-core-dev
1282019-03-25T14:30:46  *** Aaronvan_ has quit IRC
1292019-03-25T14:34:11  *** jarthur has joined #bitcoin-core-dev
1302019-03-25T14:43:10  *** aitorjs has joined #bitcoin-core-dev
1312019-03-25T14:49:36  *** jonatack has quit IRC
1322019-03-25T15:15:46  *** spaced0ut has quit IRC
1332019-03-25T15:21:11  *** hebasto has joined #bitcoin-core-dev
1342019-03-25T15:36:41  *** pinheadmz has joined #bitcoin-core-dev
1352019-03-25T15:45:17  *** dviola has joined #bitcoin-core-dev
1362019-03-25T15:47:36  *** morcos_ has joined #bitcoin-core-dev
1372019-03-25T15:50:13  *** morcos has quit IRC
1382019-03-25T15:50:14  *** morcos_ is now known as morcos
1392019-03-25T15:52:32  *** esotericnonsense has quit IRC
1402019-03-25T16:07:15  *** promag has quit IRC
1412019-03-25T16:16:43  *** hebasto has quit IRC
1422019-03-25T16:17:15  *** hebasto has joined #bitcoin-core-dev
1432019-03-25T16:18:39  *** hebasto has joined #bitcoin-core-dev
1442019-03-25T16:25:26  *** pinheadmz has quit IRC
1452019-03-25T16:27:07  *** davec has quit IRC
1462019-03-25T16:28:32  *** pinheadmz has joined #bitcoin-core-dev
1472019-03-25T16:33:32  *** davec has joined #bitcoin-core-dev
1482019-03-25T16:42:10  *** dviola has quit IRC
1492019-03-25T16:44:53  *** zhangzf has quit IRC
1502019-03-25T16:45:15  *** esotericnonsense has joined #bitcoin-core-dev
1512019-03-25T16:47:20  *** Emcy has quit IRC
1522019-03-25T16:48:34  *** Emcy has joined #bitcoin-core-dev
1532019-03-25T16:50:14  *** esotericnonsense has quit IRC
1542019-03-25T17:10:07  *** aitorjs has quit IRC
1552019-03-25T17:11:11  *** pinheadmz has quit IRC
1562019-03-25T17:11:57  *** pinheadmz has joined #bitcoin-core-dev
1572019-03-25T17:15:36  *** wzhroho has joined #bitcoin-core-dev
1582019-03-25T17:33:43  *** esotericnonsense has joined #bitcoin-core-dev
1592019-03-25T17:35:17  *** wzhroho has quit IRC
1602019-03-25T17:39:08  *** setpill has quit IRC
1612019-03-25T18:08:24  *** elichai2 has quit IRC
1622019-03-25T18:11:19  *** kmels has joined #bitcoin-core-dev
1632019-03-25T18:14:24  *** hebasto has quit IRC
1642019-03-25T18:14:44  *** spinza has quit IRC
1652019-03-25T18:15:34  *** hebasto has joined #bitcoin-core-dev
1662019-03-25T18:16:36  *** hebasto has quit IRC
1672019-03-25T18:16:54  *** hebasto has joined #bitcoin-core-dev
1682019-03-25T18:22:48  *** spinza has joined #bitcoin-core-dev
1692019-03-25T18:25:16  *** promag has joined #bitcoin-core-dev
1702019-03-25T18:58:12  *** Zenton has quit IRC
1712019-03-25T19:04:59  <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.
1722019-03-25T19:06:07  <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
1732019-03-25T19:06:12  <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
1742019-03-25T19:06:15  <sipa> and addmultisig would keep interacting with just the old state
1752019-03-25T19:06:29  <achow101> bleh
1762019-03-25T19:06:47  <sipa> i don't think there is any other way
1772019-03-25T19:07:00  <sipa> in the old mechanism, things interact in stupid and unpredictable ways
1782019-03-25T19:07:14  <sipa> that just don't fit in the descriptor based view
1792019-03-25T19:07:48  <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
1802019-03-25T19:07:59  *** DeanGuss has quit IRC
1812019-03-25T19:08:08  <sipa> but i think that's better done as a separate thing from actually supporting both
1822019-03-25T19:08:38  <achow101> what about getting rid of addmultisig and just make people use createmultisig and importmulti if they want that script and watch it?
1832019-03-25T19:08:55  <achow101> the import stuff actually makes sense under the new ismine
1842019-03-25T19:09:36  <sipa> in a descriptor based wallet you have no need for either RPC
1852019-03-25T19:09:45  <sipa> you can just import a descriptor with the multisig key in it directly
1862019-03-25T19:10:06  <sipa> maybe a utility function that has input compatible with createmultisig that spits out a descriptor is useful
1872019-03-25T19:10:15  *** StopAndDecrypt has joined #bitcoin-core-dev
1882019-03-25T19:10:45  <achow101> i wanted to avoid having two separate ismine logics
1892019-03-25T19:11:01  <sipa> i fear that's going to be very hard
1902019-03-25T19:11:37  <gmaxwell> I wonder if anyone is actually using addmultisig.
1912019-03-25T19:12:53  <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
1922019-03-25T19:13:05  <sipa> plus that conversion is nontrivial
1932019-03-25T19:13:25  <sipa> and presumably that conversion will effectively need a copy of the old ismine logic anyway
1942019-03-25T19:14:07  <achow101> From what i've done so far, converting a wallet that doesn't have multisig is pretty straightforward
1952019-03-25T19:14:21  <achow101> and afaict it doesn't require the old ismine logic
1962019-03-25T19:15:07  <sipa> possibly
1972019-03-25T19:15:51  <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)
1982019-03-25T19:16:14  *** hebasto has quit IRC
1992019-03-25T19:17:41  <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.
2002019-03-25T19:17:55  <gmaxwell> Anything else will take more work and not guarentee compatibility as strongly.
2012019-03-25T19:18:30  <sipa> newly created wallets can lack the old state altogether, and just not support addmultisig (and possibly other RPCs)
2022019-03-25T19:19:11  <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.
2032019-03-25T19:19:17  <gmaxwell> (... if any are...)
2042019-03-25T19:19:27  <achow101> gmaxwell: I'm tempted to do that
2052019-03-25T19:19:48  <gmaxwell> I earnestly doubt anyone is using.
2062019-03-25T19:19:55  <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
2072019-03-25T19:20:02  <sipa> i certainly have used it!
2082019-03-25T19:21:13  <sipa> https://bitcoin.stackexchange.com/questions/83102/how-to-import-p2wsh-in-p2sh-multisig-as-watch-only
2092019-03-25T19:22:01  <gmaxwell> sipa: yes, you and I have but we don't count.
2102019-03-25T19:22:21  <gmaxwell> (as you and I would just use importmulti...)
2112019-03-25T19:22:33  <sipa> importmulti has the same problem
2122019-03-25T19:23:09  <achow101> does it?
2132019-03-25T19:23:21  <sipa> you can emulate whatever addmultisig does using importmulti
2142019-03-25T19:24:17  <gwillen> can someone help me remember / grok the difference between addmultisig and createmultisig+import
2152019-03-25T19:25:13  <sipa> gwillen: createmultisig just computed the address/redeemscript you'd import if you would have used addmultisigaddress
2162019-03-25T19:25:23  <sipa> but it's a utility rpc instead of a wallet rpc
2172019-03-25T19:26:34  <gwillen> interesting
2182019-03-25T19:27:08  <sipa> achow101: so there is an open question around importmulti in the new state, i think
2192019-03-25T19:27:37  <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
2202019-03-25T19:27:44  <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
2212019-03-25T19:28:12  <sipa> achow101: good point; you need addmultisig+importaddress to emulate importmulti
2222019-03-25T19:28:46  <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
2232019-03-25T19:29:46  <sipa> (because i've seen people talk about calling importmulti multiple times taking advantage of the interaction to accomplish missing things... )
2242019-03-25T19:30:27  <achow101> imo with the native descriptor design, all existing import rpcs should just not work on those wallets
2252019-03-25T19:30:33  <sipa> agree
2262019-03-25T19:30:43  <sipa> there should just be importdescriptor or importrecord or something
2272019-03-25T19:31:08  <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
2282019-03-25T19:31:12  <sipa> and new RPCs work on the new state
2292019-03-25T19:31:59  <sipa> as otherwise you'd force people to adopt a new set of RPCs whenever their wallet gets upgraded
2302019-03-25T19:32:06  <gwillen> let me bang the drum as usual for doing the split at the wallet level
2312019-03-25T19:32:16  <achow101> .. right. I see how that is the safest and most compatible way to go about this
2322019-03-25T19:32:27  <gwillen> your old wallet has old RPCs, your new wallet has new descriptor-native RPCs
2332019-03-25T19:32:30  <gwillen> the two never to mix
2342019-03-25T19:33:12  <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)
2352019-03-25T19:33:19  <achow101> well somethings of the old design might leak into the new design due to use in a lot of places. e.g. isminetypes
2362019-03-25T19:34:10  <sipa> those are fine
2372019-03-25T19:37:51  <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.
2382019-03-25T19:38:46  <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.
2392019-03-25T19:39:01  <achow101> gmaxwell: there should be someway to upgrade from old to new with some caveats regarding ismine
2402019-03-25T19:39:16  <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...),
2412019-03-25T19:39:57  <achow101> sipa: in my current design, i have watchonly be defined as existing in setWatchonly and mine as existing in a newly introduced setScriptPubKeys
2422019-03-25T19:39:58  <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
2432019-03-25T19:40:52  <sipa> achow101: have you read https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2 ?
2442019-03-25T19:40:55  <achow101> yeah
2452019-03-25T19:41:13  <sipa> i really think watchonly should just be a boolean in the descriptor record
2462019-03-25T19:41:32  <sipa> saying "do i want to treat things that match this as really mine, or just something i'm watching"
2472019-03-25T19:41:50  <gmaxwell> Why shouldn't the concept of watch only be eliminated and replaced with signing sources, with null a potential signing source.
2482019-03-25T19:42:03  <gmaxwell> ?
2492019-03-25T19:42:12  <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
2502019-03-25T19:42:28  <gmaxwell> sipa: that boolean split alone isn't the most useful... esp because it is just a single category.
2512019-03-25T19:42:43  <sipa> gmaxwell: for example a multisig you're participanting is may be something you want to watch, but not count as your balance
2522019-03-25T19:43:02  <sipa> i expect gwillen to now say "just use a separate wallet for that", and he's probably right
2532019-03-25T19:43:03  <gmaxwell> sipa: make a seperate wallet?
2542019-03-25T19:43:25  <gmaxwell> The fact that watching has only a single category "watching" makes it much less useful...
2552019-03-25T19:43:48  <sipa> true
2562019-03-25T19:43:55  <achow101> gmaxwell: that would be ideal, but breaks upgrading I think
2572019-03-25T19:44:06  * sipa lunch
2582019-03-25T19:44:11  <gmaxwell> well let me revise, there is a seperate "non-balance" functionality that is useful: collecting txouts for filling a PSBT.
2592019-03-25T19:44:34  <gmaxwell> I agree _that_ kind of watching actually is useful, doesn't need special categories, doesn't interact with balances, etc.
2602019-03-25T19:45:02  <midnightmagic> +1 filling txouts for PSBT
2612019-03-25T19:45:19  <gmaxwell> achow101: breaking upgrading for more obscure features isn't something we should reject out of hand.
2622019-03-25T19:45:54  <gmaxwell> achow101: we could allow an upgrade that stripped out all watching (or converted it into something else)
2632019-03-25T19:46:07  <achow101> well I suppose an upgrade could just make two wallets
2642019-03-25T19:46:28  <gmaxwell> right.
2652019-03-25T19:47:51  <gwillen> yeah, I do maintain "keep separate wallets for separate sorts of funds" is the right call
2662019-03-25T19:48:52  <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.
2672019-03-25T19:49:30  <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
2682019-03-25T19:49:36  <gwillen> it's better for those to be two separate wallets
2692019-03-25T19:49:49  <gwillen> rather than try to puzzle how how we should define 'watchonly' and 'ismine' to make that scenario work smoothly
2702019-03-25T19:49:56  <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"
2712019-03-25T19:50:15  <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
2722019-03-25T19:50:25  <gwillen> although I guess if you did ever want that, it's an argument against separate wallets
2732019-03-25T19:50:30  <gmaxwell> I think you're talking past me.
2742019-03-25T19:50:36  <gwillen> probably
2752019-03-25T19:52:18  <gmaxwell> "some funds from my wallet and also some funds from the multisig" isn't something that is usable with watchonly now.
2762019-03-25T19:52:27  <gwillen> mmm, heh, that's a good point
2772019-03-25T19:53:03  <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.
2782019-03-25T19:53:59  <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.
2792019-03-25T19:54:07  *** dviola has joined #bitcoin-core-dev
2802019-03-25T19:54:41  <midnightmagic> +1 that use; also informational tracking of known addresses.
2812019-03-25T19:54:55  <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.
2822019-03-25T19:55:38  <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.
2832019-03-25T19:56:37  <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.
2842019-03-25T19:56:41  <achow101> gmaxwell: instead of a watchonly wallet, use scantxout set :p
2852019-03-25T19:56:44  <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
2862019-03-25T19:57:04  <gmaxwell> achow101: doesn't work if you need to see past spends, and alsoscantxoutset is pretty slow!
2872019-03-25T19:58:06  <gmaxwell> but perhaps the concept should be dropped and replaced with something that better fits how its mostly being used.
2882019-03-25T19:58:26  <achow101> if you're just filling psbts, you don't need past spends
2892019-03-25T19:58:29  <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.
2902019-03-25T19:59:09  <midnightmagic> Just a hackish informational thing that means I don't have to use bitcoin-iterate
2912019-03-25T19:59:12  <midnightmagic> +1 laziness
2922019-03-25T19:59:46  <gmaxwell> achow101: yes, but examples I listed do more than just fill out psbts.
2932019-03-25T20:00:06  <gmaxwell> But they don't need balances, coinselections, etc.
2942019-03-25T20:08:15  *** promag has quit IRC
2952019-03-25T20:21:42  *** timothy has quit IRC
2962019-03-25T21:06:12  *** Zenton has joined #bitcoin-core-dev
2972019-03-25T21:14:22  *** bitcoin-git has joined #bitcoin-core-dev
2982019-03-25T21:14:22  <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
2992019-03-25T21:14:23  *** bitcoin-git has left #bitcoin-core-dev
3002019-03-25T21:15:51  *** promag has joined #bitcoin-core-dev
3012019-03-25T21:20:20  *** promag has quit IRC
3022019-03-25T21:25:03  *** omonk has joined #bitcoin-core-dev
3032019-03-25T21:28:25  *** justanotheruser has joined #bitcoin-core-dev
3042019-03-25T21:46:38  *** promag has joined #bitcoin-core-dev
3052019-03-25T21:50:52  *** promag has quit IRC
3062019-03-25T21:55:50  *** dviola has quit IRC
3072019-03-25T21:57:27  *** BostX has joined #bitcoin-core-dev
3082019-03-25T21:59:18  <BostX> Hi, do you know why signrawtransactionwithwallet returns the same hex as entered?
3092019-03-25T22:00:12  <sipa> presumably because it couldn't sign anything
3102019-03-25T22:01:16  <BostX> sipa: but it was completed with "true"
3112019-03-25T22:01:33  <sipa> then it's already fully signed!
3122019-03-25T22:01:51  <BostX> sipa: that's impossible
3132019-03-25T22:01:59  *** dviola has joined #bitcoin-core-dev
3142019-03-25T22:03:36  <sipa> BostX: what's the input?
3152019-03-25T22:03:40  <sipa> (you can pm me)
3162019-03-25T22:03:58  *** esotericnonsense has quit IRC
3172019-03-25T22:06:28  <BostX> sipa: I created: bitcoin-cli createrawtransaction '[]' '{"unused-new-address": <number>}'
3182019-03-25T22:06:48  <BostX> sipa: then I was returned the hex
3192019-03-25T22:06:55  *** Guyver2 has quit IRC
3202019-03-25T22:06:59  <sipa> BostX: you have no inputs, so all inputs are by definition signed
3212019-03-25T22:07:18  <sipa> you probably want to call fundrawtransaction first to add inputs and change
3222019-03-25T22:10:12  <BostX> sipa: aaaah... that's possible. BTW I was following the https://stackoverflow.com/a/46637033
3232019-03-25T22:11:17  <BostX> sipa: I thought the createrawtransaction '[]' knows automatically how to add an input.
3242019-03-25T22:11:31  <BostX> sipa: what is a `change`?
3252019-03-25T22:11:42  <sipa> BostX: perhaps you should head to bitcoin.stackexchange.com
3262019-03-25T22:11:56  <sipa> you shouldn't be using these RPC functions if you don't know what change outputs are
3272019-03-25T22:15:13  <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.
3282019-03-25T22:15:36  <sipa> BostX: yes, this is the wrong place to ask such questions
3292019-03-25T22:17:27  <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.
3302019-03-25T22:18:54  <sipa> BostX: well, the answer is that your transaction has no inputs, so signrawtransactions responds by saying all your inputs are signed
3312019-03-25T22:18:58  <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.
3322019-03-25T22:18:59  <sipa> which is expected
3332019-03-25T22:19:24  *** cryptapus has quit IRC
3342019-03-25T22:20:20  *** spinza has quit IRC
3352019-03-25T22:22:45  <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`
3362019-03-25T22:23:07  *** dviola has quit IRC
3372019-03-25T22:24:14  <achow101> BostX: If you are planning on using an offline computer, I recommend using the psbt RPCs
3382019-03-25T22:25:00  <achow101> https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md has some info on how to use them
3392019-03-25T22:28:38  *** bitcoin-git has joined #bitcoin-core-dev
3402019-03-25T22:28:39  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7b13c6464579...8a8b03ecd221
3412019-03-25T22:28:40  <bitcoin-git> bitcoin/master 5801dd6 gwillen: docs: Add more tips to productivity.md
3422019-03-25T22:28:41  <bitcoin-git> bitcoin/master 8a8b03e MarcoFalke: Merge #15603: docs: Add more tips to productivity.md
3432019-03-25T22:28:50  *** bitcoin-git has left #bitcoin-core-dev
3442019-03-25T22:29:29  *** bitcoin-git has joined #bitcoin-core-dev
3452019-03-25T22:29: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
3462019-03-25T22:29:35  *** bitcoin-git has left #bitcoin-core-dev
3472019-03-25T22:30:16  *** cryptapus has joined #bitcoin-core-dev
3482019-03-25T22:30:21  *** spinza has joined #bitcoin-core-dev
3492019-03-25T22:32:16  *** Cory has quit IRC
3502019-03-25T22:35:06  *** promag has joined #bitcoin-core-dev
3512019-03-25T22:35:16  <gwillen> BostX: I'm going to send you a PM
3522019-03-25T22:38:36  *** Cory has joined #bitcoin-core-dev
3532019-03-25T22:51:37  *** EagleTM has joined #bitcoin-core-dev
3542019-03-25T23:01:24  *** omonk has quit IRC
3552019-03-25T23:01:55  *** omonk has joined #bitcoin-core-dev
3562019-03-25T23:03:47  *** IGHOR has quit IRC
3572019-03-25T23:03:56  *** IGHOR has joined #bitcoin-core-dev
3582019-03-25T23:22:56  *** gribble has quit IRC
3592019-03-25T23:24:02  *** dqx_ has joined #bitcoin-core-dev
3602019-03-25T23:26:53  *** jarthur has quit IRC
3612019-03-25T23:29:06  *** fanquake has quit IRC
3622019-03-25T23:29:22  *** gribble has joined #bitcoin-core-dev
3632019-03-25T23:35:33  *** andytoshi has quit IRC
3642019-03-25T23:35:43  *** andytoshi has joined #bitcoin-core-dev
3652019-03-25T23:35:43  *** andytoshi has joined #bitcoin-core-dev
3662019-03-25T23:45:57  *** shesek has joined #bitcoin-core-dev
3672019-03-25T23:46:05  *** shesek has quit IRC
3682019-03-25T23:46:05  *** shesek has joined #bitcoin-core-dev
3692019-03-25T23:46:38  *** pinheadmz has quit IRC
3702019-03-25T23:50:07  *** andytoshi has quit IRC
3712019-03-25T23:50:15  *** andytoshi has joined #bitcoin-core-dev
3722019-03-25T23:51:53  *** Skirmant has joined #bitcoin-core-dev
3732019-03-25T23:54:48  *** trillhc has joined #bitcoin-core-dev