< gmaxwell>
Do other people think that it would be reasonable if setting the upload limiter to a low value (e.g. below 500 MB/day) set the service flags towards non-whitelisted connections to be the pruned flags?
< gmaxwell>
e.g. have a -limitednode that defaults to false and gets softset to true if a low limiter is set.
< gmaxwell>
I didn't propose this previously because we didn't have NODE_LIMITED yet... but we do now, and its widely deployed.
< luke-jr>
gmaxwell: maybe a tri-state so users can disable sending any blocks at all?
< gmaxwell>
Is it really interesting to support that?
< gmaxwell>
luke-jr: that would be more a -clientmode than really a tristate on limited.
< dongcarl>
That is a shame, I'm also not sure if it should be discussed in this channel as this is not a dev topic
< gwillen>
is there a good way to ask the wallet to do coin selection including watch-only coins (for offline signing)?
< gwillen>
I tried just setting the fAllowWatchOnly flag on CCoinControl
< gwillen>
but various bits of machinery do not want to include watch-only coins even with that flag set
< gwillen>
in particular in CWallet::GetAvailableBalance we check COutput::fSpendable on the coins before we count them, even if the fAllowWatchOnly flag is set
< luke-jr>
gwillen: I thought fundrawtransaction could do it
< achow101>
gwillen: fundrawtransaction should be able to select watch only coins
< achow101>
gwillen: spendable in that case means solvable. the private key does not necessarily need to be in the wallet, but the pubkey and any related scripts do
< gwillen>
hmmmmmmmm
< gwillen>
I feel dumb asking this but why is solvability necessary
< jnewbery>
phantomcircuit: do you have a log from a failing rpc_zmq.py test for #14336? Or a link to travis for a failing build?
< gwillen>
it's enough to be able to find the utxos in order to build a transaction, right? as long as the offline signer can solve it?
< achow101>
gwillen: solvability is required for fee estimation
< gwillen>
ahhhhhhh hmmm
< gwillen>
ok, then I have another dumb question
< gwillen>
assuming that using importpubkey instead of importaddress will get me a solvable watch-only key, how do I _get_ a pubkey that I can import with importpubkey?
< gwillen>
validateaddress only gives the scriptpubkey
< gwillen>
(I mean, starting from a wallet that does know the privkey, how do I export the pubkey so I can then import it elsewhere)
< sipa>
use getaddressinfo
< sipa>
validateaddress is turning into a non-wallet RPC
< gwillen>
aha, thanks
< midnightmagic>
gwillen: consider writing up a howto after getting your offline signing going..?
< gwillen>
midnightmagic: the goal here is not merely to write a howto, it's to write a GUI :-)
< gwillen>
but a howto is not a bad idea as an intermediate step
< midnightmagic>
including the offline component?
< gwillen>
yeah
< midnightmagic>
oh, nice.
< midnightmagic>
nvm me then.
< gwillen>
I mean, a gui will take awhile to get in, a real offline signing howto isn't a bad idea at all, I keep referring to greg's version but it doesn't use the wallet for coin selection, it just does it by hand
< gwillen>
also it feels a little bad to me that there's no permutation of the stuff that comes out of getaddressinfo that can go into importmulti and work :-P
< sipa>
gwillen: yeah, importmulti and segwit is only accidental to the extent that it works
< achow101>
there was some method I found a while ago, but I can't remember it
< sipa>
we should have prioritized that for 0.17...
< sipa>
and we didn't improve upon it in 0.17 afaik
< gwillen>
does the crazy shit achow101 proposed above function as a workaround to get a segwit address imported, or does it just import it as a non-segwit address and happen to work?
< gmaxwell>
The wallet works much more like "bag of pubkeys which get interperted many ways" than we'd like, but changing it is slow going due to compatbility needs.
< gwillen>
will just doing importpubkey do the right thing, and interpret the pubkey many ways?
< gwillen>
I had thought I couldn't do that because of rescanning but achow pointed out that I can just rescan manually
< gwillen>
yesss okay that works
< thedrs>
hi, sorry to bug you guys, bitcoin 0.17 installer is identified as maleware by MBAM, is this known ?
< Lauda>
^false positive. #bitcoin
< thedrs>
yep though so
< thedrs>
but no google info about it. i reported it to MBAM
< luke-jr>
thedrs: check the PGP signatures
< jonasschnelli>
The wallets watch-only capabilities is a mess!
< jonasschnelli>
The only way how to import a watch only multisig is by importing the outer script, the readme-script and all it's pubkeys (via importpubkey)
< sipa>
you don't need the pubkeys for multisig
< sipa>
only for p2pkh
< jonasschnelli>
sipa:If you don't import the pubkey they are non-solvable and not useable in fundraw
< jonasschnelli>
So you need to import via importpubkey (and import all possible scripts!)
< sipa>
jonasschnelli: that makes no sense
< jonasschnelli>
GetScriptForRawPubKey will then lead to extract the pubKey and place them mapWatchKeys
< jonasschnelli>
Agree it makes no sense...
< sipa>
importing a pubkey is so that the signing code can find the pubkey based on the hash of the key
< sipa>
in a multisig there are no key hashes involved
< sipa>
just the redeemscript should be enough for multisig
< sipa>
plus importaddress of the toplevel thing
< jonasschnelli>
Yes. But following isSolvable, it will require to find the pubkey in oder to flag it solveable
< sipa>
it has the pubkey; it's in the redeemscript
< sipa>
i'm very skeptical :)
< jonasschnelli>
but it won't find it...
< sipa>
have you tried this?
< jonasschnelli>
Yes
< sipa>
i find this very hard to believe
< jonasschnelli>
mapWatchKeys gets only touched by AddWatchOnly
< jonasschnelli>
Try yourself... with the following steps:
< jonasschnelli>
1. createwallet "dummy" true
< sipa>
what do you need mapWatchKeys for in multisig?
< jonasschnelli>
sipa: pure watching no,.. but if you want to use them for watchOnly coinselection via fundraw, yes, you need it with the corrent code
< sipa>
that makes no sense :)
< sipa>
if you say so, i believe you
< sipa>
bit i don't know what that is the case
< jonasschnelli>
Try it youself. :)
< sipa>
i can't right now
< jonasschnelli>
Sure. No hurry...
< jonasschnelli>
the use case: decouple the keys from the wallet
< jonasschnelli>
(via importing scripts and using fundrawtransaction)
< sipa>
yes not claiming this isn't important!
< sipa>
i'm just not understanding why you need to import the pubkeys
< sipa>
they are in the redeemscript
< sipa>
the signing code doesn't need to look up any pubkeys
< jonasschnelli>
Because: fundraw takes only solvable imputs. isSolveable requires to find the pubKey in the keystore.
< jonasschnelli>
But it's fixable IMO
< sipa>
why?
< jonasschnelli>
isSolveable _currently_ requires to find the pubKey... its just coded that way...
< jonasschnelli>
You can bypass that problem by importpubkey all the multisigs pubkeys because it will generate a RawPubKeyScript where the pubkeys gets extracted and added to the keystore. :/
< jonasschnelli>
(with an overhead of a couple of unused scripts)
< sipa>
yeah
< sipa>
but that's pretty ridiculous
< jonasschnelli>
Which you have to do anyways for P2SH(P2WPKH) scripts to flag them solvable since importmulti can't handle it...
< jonasschnelli>
or for native P2WPKH
< jonasschnelli>
because importmulti compare the scriptPubKey with the P2PKH(pubkey) and refuse to insert the pubkey if no match. :/
< sipa>
jonasschnelli: fixing
< jonasschnelli>
sipa: \o/
< sipa>
jonasschnelli: i wonder if this was a regression in 0.17?
< jonasschnelli>
sipa: possible... I haven't checked that.
< thedrs>
ran it via virustotal, and strangley, MBAM passes it there. Although i 7/67 negativ results
< echeveria>
thedrs: virustotal tells you literally nothing about the safety of running a binary, sorry.
< gwillen>
jonasschnelli: sipa: so it seems kind of weird to me actually that you need keys to be solvable for fundraw and such to work
< gwillen>
achow101 said it was for fee estimation (I guess so you know the signature size), which makes sense, but ... the various signatures are not that different in size, you could easily make a conservative estimate without needing issolvable to be true
< gwillen>
you might overpay a little but in a lot of cases that's fine
< jonasschnelli>
gwillen: Yes. probably. for P2PKH, you could assume key is always compressed...
< jonasschnelli>
or overpay always by assuming its uncompressed
< jonasschnelli>
maybe make it even configurable
< gwillen>
*nods*
< gwillen>
better to overpay I think, if you're being sloppy
< gwillen>
although I guess with RBF it's not so bad anymore
< jonasschnelli>
yes. better overpay.
< jonasschnelli>
but who uses uncompressed keys anymore?!
< sipa>
jonasschnelli: gemini
< jonasschnelli>
I need to test later, but do we even require the pubkey for fee estimation with P2WPKH inputs?
< jonasschnelli>
I hope not but fear we do
< sipa>
yes i'm sure we do
< sipa>
solvability is defined as "can you sign, ignoring lack of private keys"
< sipa>
you can't sign for a P2WPKH without knowing the pubkey
< jonasschnelli>
shouldn't we split solvability from signability?
< sipa>
i don't think so
< sipa>
it's an interesting special case that indeed for P2WPKH you don't actually need to know the pubkey
< sipa>
but i think that the fact that you don't have it now is more a side effect of it being annoying to pass in, rather than not knowing it at all
< jonasschnelli>
but in order to run fundraw with watch-only, you only want to calculate the fee. If you use P2WPKS or P2SH(P2WPKH) or P2WSH(multisig)... you can calculate the fee when you have the scriptPubKey and optionally the redeem script.. right?
< jonasschnelli>
Maybe I get it wrong, but IMHO, the dummysigner is for fee calculation
< sipa>
jonasschnelli: yes, my point is that generally when you need to use fundraw, you know the redeemScript/pubkeys involved
< sipa>
and it's only because it's annoying to import them that we're talkijg about the few edge cases (like p2wpkh) where you can indeed estimate the fee correctly without knowing the pubkey
< phantomcircuit>
jnewbery, i do not
< jnewbery>
ok, if you see the failure again, please paste logs/link into the PR and I'll try to work out why it's failing
< jnewbery>
If it's rpc_zmq.py L31 then I suspect some race between the ZMQNotificationInterface initialization and the test framework sending the getzmqnotifications RPC. Logs would prove that
< jnewbery>
The ZMQ rpc test is pretty useless. I don't know why that rpc isn't just tested in the interface_zmq.py test
< phantomcircuit>
jnewbery, it's the getzmqnotifications call on line 30/31
< phantomcircuit>
im pretty sure it's just a race as you said