< TGeek> Hi all, I am having an issue in bitcoin core with the bumpfee rpc call.. It keeps throwing an error "(-4) Transaction does not have a change output". Which is strange because the output for the tx has two outputs, one for the to address and one for change. I have been troubleshooting this issue for 2 days now and cannot seem to find anything related in searches.. Any help would be greatly appreciated.
< sipa> how was the transaction created?
< TGeek> via createrawtransaction and set as replaceable
< sipa> how did you create the change?
< sipa> *the change address
< TGeek> tried both getnewaddress and getrawchangeaddress.. both do not work
< sipa> i think you should open an issue
< gmaxwell> does the fee bumper give correct errors on all the other cases it can't handle?
< TGeek> also tried using a specific static address with a UTXO's
< sipa> i would expect getrawchangeaddress to work
< sipa> but maybe the change information is held as metadata in the wallet, which means it won't work with anything but sendtoaddress/sendmany
< TGeek> hmm.. but getrawchangeaddress says in the docs that it is only for using with RAW transactions "NOT normal use"
< sipa> TGeek: yes, i mean that it's possible that bumpfee only works on transaction created through sendtoaddress/sendmany, and not through any of the rawtransaction RPCs
< sipa> in any case, if so, that should be improved upon
< sipa> so perhaps best to open an issue so more people can chime in
< TGeek> ok, will do.. thanks for your time, have a good one
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14772: refactor: Convert comments to thread safety annotations (master...Mf1802-csCommentsLock) https://github.com/bitcoin/bitcoin/pull/14772
< bitcoin-git> [bitcoin] kallewoof opened pull request #14774: interface/wallet: get rid of missing initializer warnings (master...suppwarn-empty-constructor) https://github.com/bitcoin/bitcoin/pull/14774
< bitcoin-git> [bitcoin] dooglus opened pull request #14775: 'break' should be 'continue' here? (master...patch-6) https://github.com/bitcoin/bitcoin/pull/14775
< bitcoin-git> [bitcoin] jameshilliard opened pull request #14776: Add process based prctl spectre mitigation controls. (master...spectre-prctl) https://github.com/bitcoin/bitcoin/pull/14776
< wumpus> what's up with appveyor? looks like it's failing on every PR
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6b90a2a0e065...267793af8b03
< bitcoin-git> bitcoin/master 6be7d14 Carl Dong: Properly generate salt in rpcauth.py, update tests...
< bitcoin-git> bitcoin/master 267793a Wladimir J. van der Laan: Merge #14742: Properly generate salt in rpcauth.py...
< bitcoin-git> [bitcoin] laanwj closed pull request #14742: Properly generate salt in rpcauth.py (master...2018-11-fix-rpcauth-salt) https://github.com/bitcoin/bitcoin/pull/14742
< promag> wumpus: test added to #14670
< gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] domob1812 opened pull request #14777: tests: Add regtest for JSON-RPC batch calls (master...batch-rpc) https://github.com/bitcoin/bitcoin/pull/14777
< promag> no travis job for #14777? :/
< gribble> https://github.com/bitcoin/bitcoin/issues/14777 | tests: Add regtest for JSON-RPC batch calls by domob1812 · Pull Request #14777 · bitcoin/bitcoin · GitHub
< dawud> Hello anybody around?
< dawud> I have a question about generating keys. I've used bitaddress.org to generate a key pair. It works pretty simply, so I'm pretty confused what could have gone wrong.
< wumpus> ask general question in #bitcoin please
< dawud> This is about R values and the algorithm used to generate private keys.
< dawud> When I generated the key, I took photos and wrote down the 'brain wallet passphrase'. So, I know the phrase is "correct". However, now, when I type the same passphrase, it generates a DIFFERENT private key.
< dawud> So, I'm wondering, in core, when generating keys, is there a way that somehow a different R value or something like that could happen, if it was done, say, in an old version of core?
< phantomcircuit> dawud, still this channel is about bitcoin core development
< phantomcircuit> which this is definitely not
< dawud> I asked there.
< wumpus> please, don't insist. you could also try the bitcoin stack exchange (https://bitcoin.stackexchange.com/) if #bitcoin yields nothing
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/267793af8b03...16498860546e
< bitcoin-git> bitcoin/master fa7da06 MarcoFalke: qa: Check specific reject reasons in feature_block
< bitcoin-git> bitcoin/master 1649886 Wladimir J. van der Laan: Merge #14719: qa: Check specific reject reasons in feature_block...
< bitcoin-git> [bitcoin] laanwj closed pull request #14719: qa: Check specific reject reasons in feature_block (master...Mf1811-qaRejectBlock) https://github.com/bitcoin/bitcoin/pull/14719
< stevenroose> Does bitcoind remove the cookie file when closing?
< stevenroose> Hmm seems so, didn't know.
< stevenroose> Is core supposed to make the .cookie file in datadir/.cookie or datadit/chain/.cookie?
< stevenroose> With chain = chainname
< stevenroose> But I seem to find the cookie file in the main datadir.
< sipa> stevenroose: inside the chain specific datadir
< sipa> if you configure the datadir yourself, that's the one that will be used
< sipa> otherwise a default is used that depends on the chain
< stevenroose> sipa: oh wait, so if you set -datadir yourself, it should be top-level?
< stevenroose> but then that like in test_framework doesn't make sense, right? test_framework always sets the -datadir and still it points at datadir/regtest/.cookie?
< stevenroose> s/that like/that line/
< stevenroose> sipa: it seems to always add the network-specific part, no?
< stevenroose> ah, networkspecific part for mainnet is "" :|
< stevenroose> k thanks
< wumpus> even if you configure datadir yourself, it should use the network-specific subdir
< wumpus> for mainnet that's top-level
< wumpus> test chains (testnet3, regtest) have subdirectories
< dgpv> script output descriptors multi() expression supports only fixed order of keys, in the order they listed
< dgpv> but some wallets (copay, for example) uses an approach where pubkeys are sorted by their hex values for each address
< dgpv> to create an address at index 123, you get all pubkeys for index 123, sort the pubkeys, and then make a multisig address with them
< gmaxwell> ugh, that prevents you from putting the most likely to sign first, so they take longer to validate.
< dgpv> this way there's no need to know the order of the keys in a keyring
< gmaxwell> dgpv: they could have as well defined it by sorting the master keys.
< dgpv> you only need to know the xpubs of participants, but not the order of how they joined the multisig scheme
< dgpv> they could not, because they do not know the order beforehand
< dgpv> some user creates multisig wallets and sends invitations to others
< dgpv> they may join in arbitrary order
< dgpv> *creates multisig wallet*, not wallets
< dgpv> they also do not know who will likely to sign more often
< gmaxwell> dgpv: I am not following your statement. If the keys on an output come from xpubs a, b, c then they could be put in xpub sorted order.
< gmaxwell> dgpv: the user almost certantly does, even if the application doesn't provide a way for the user to tell them. :)
< sipa> dgpv: i don't think it's unreasonable to extend descriptors with a sorted-multi construction
< dgpv> my point is that this scheme exists, and is used for a long time by at least one wallet
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/16498860546e...d7b0258ff037
< bitcoin-git> bitcoin/master 3fb09b9 Akio Nakamura: Warn unrecognized sections in the config file...
< bitcoin-git> bitcoin/master d7b0258 Wladimir J. van der Laan: Merge #14708: Warn unrecognised sections in the config file...
< dgpv> we also do not use this scheme as a default, but support it as an artifact of previous integration with copay/bws
< bitcoin-git> [bitcoin] laanwj closed pull request #14708: Warn unrecognised sections in the config file (master...warn_unrecognized_section) https://github.com/bitcoin/bitcoin/pull/14708
< sipa> dgpv: so far, the bitcoin core wallet also hasn't really supported HD chains created by other software as import
< sipa> and it still doesn't, but with descriptors that'll hopefully become easier
< dgpv> one of the use for descriptors is interoperability, as I understand
< sipa> not really
< sipa> it's more about flexibility
< sipa> interoperability may be a nice side effect
< sipa> but i don't expect other wallets to support descriptors too, or at least not in a guaranteed to be compatible way
< sipa> they're just a generic way for representing something more flexible and readable than what we had before in core
< dgpv> it would be useful way to create interoperable backups
< sipa> meh :)
< sipa> different software hardly agrees on what a wallet is
< gmaxwell> Generally interoperablity between wallets in a broad sense is misguided... the interoperability depends critically on the functionality, and we can't expect all wallets to have the same functionality.
< dgpv> we support a lot address configurations, and could create script descriptors that can be imported into core, or import descriptors from core
< sipa> sure, but will you keep up?
< sipa> i don't intend to make descriptors a "standard" - more something that we can easily extend
< sipa> i think it's important to provide flexibility, so that power users can build interesting constructions on top - which may include interoperability between wallets
< luke-jr> dgpv: last year, quite a few wallet software teams met to discuss issues like interoperability, but concluded it wasn't practical
< sipa> but interoperability as a supported feature is very hard, as it essentially requires the developer teams to coordinate rollouts of new features etc
< gmaxwell> luke-jr: They're interoperable in the sense that you can send funds from one wallet to another. :P
< luke-jr> gmaxwell: well, yeah, but .. context :P
< sipa> in any case, i have no objection to extending descriptors with a sorted-pubkey-multisig construction if that's useful, but it's not personally a priority to me
< luke-jr> I guess note that for literal export/import, one could treat any wallet as JBOK
< promag> should we allow reindex=1 in conf file?
< gmaxwell> it's almost always a mistake, but I thought we discussed doing something about that before...
< promag> or maybe warn?
< luke-jr> promag: I don't think it would be reasonable to forbid it
< gmaxwell> I guess one downside of refusing it, is that if someone has a startup script where the only way to pass options to the process is the config file...
< promag> is there a use case for that? I can't see one
< dgpv> only popular wallet with exotic scripts that I know is greenaddress, others use standard scripts and maybe different derivation paths..
< sipa> promag: there are people for whom editing the config file is easier than passing a cmdline argument, i think
< luke-jr> conf file shouldn't deviate from command line parsing too much
< luke-jr> being stricter with unknown command line options makes sense, but anything more seems like a bad idea
< sipa> agree
< gmaxwell> dgpv: use of the particular script is only 1% of what it takes to make things compatible.
< dgpv> what else? derivation paths ?
< promag> so not even warn?
< rafalcpp> maybe warn, or someone will be stuck always reindexing?
< luke-jr> rafalcpp: I think anyone would notice fairly quickly
< dgpv> if you allow to specify arbitrary derivation paths with templates, you can support any scheme
< gmaxwell> dgpv: Seriously, the bitcoin project has been held back for years by misguided efforts towards interoperability with a largely indifferent industry. It's a bit irritating that you're advocating us burning more time here on this particular point of it, because it would be useful in your product.
< rafalcpp> luke-jr: if some RPC for getting general "state" of node could include misc warninings, it could remind there
< sipa> gmaxwell: no need for that
< sipa> i'm sure dgpv is just earnestly trying to understand the issue
< luke-jr> rafalcpp: "hmm, every time i restart my node it takes days to work again" is a stronger warning than anything we can do
< dgpv> actually this is new info for me, about the fact that interoperability is not important
< sipa> dgpv: of course interoperability is important, but it comes at a high cost
< sipa> and i think the space, and the concept of what wallets are and try to be is just evolving too fast to focus on it
< promag> luke-jr: +1
< promag> thanks for the feedback
< sipa> dgpv: for example, how to deal with change, or backups, or multiple wallets, or hardware devices, ...
< sipa> are all ways in which wallets can differ in ways that make them hard to interoperate
< luke-jr> coming soon: or Lightning channels
< sipa> some software insists that 'the blockchain is your wallet' and everything except a seed can be recovered from the chain
< luke-jr> x.x
< sipa> luke-jr: exactly
< rafalcpp> luke-jr: what about a server, it will just have 80% of uptime for bitcoind unstead of 99% for unclear reason. Wouldnt't RPC getblockchaininfo -> "warnings" field make sense? Maybe not, but we could make it a place admins know to look at first when troubleshooting. "doing-reindex". Maybe later also "no-peers", and some other. Just idea
< sipa> dgpv: when you include multiparty or multidevice things, you complicate things further, even beyond just the script involved (for example, how do the different parties interact to construct a transaction)
< dgpv> sipa: but IMO the most important part is how to specify where to find your UTXO - how to generate the addresses
< sipa> dgpv: even that differs between wallets
< dgpv> sipa: the most important for interoperability - you can have your money even if you have a backup from now-unsupported wallet
< sipa> dgpv: emergency recovery is a whole lot easier to support than full interoperability though
< dgpv> sipa: but what differs is scripts, derivation paths, and maybe pubkey order
< sipa> i'm not sure what you're arguing for now
< sipa> all i'm saying is that i don't think it makes sense to commit to "bitcoin core aims to be interoperable with software X"
< sipa> if descriptors are flexible enough to support emergency recovery from wallets created by software X, great, use it
< dgpv> sipa: actually my initial question was should I submit a PR with change for sortedmulti() or just create an issue on bitcoin core github
< dgpv> sipa: got a suggestion to ask here first
< sipa> up to you
< dgpv> sipa: I got my answer, so thank you for the time you expended answering me
< luke-jr> dgpv: I think the existing sorted multi PR should get merged first
< dgpv> it is there ?
< luke-jr> not for HD, just in general
< sipa> there's also a bip for it i think
< luke-jr> #8751
< gribble> https://github.com/bitcoin/bitcoin/issues/8751 | RPC: Add parameter to addmultisigaddress / createmultisig to sort public keys by afk11 · Pull Request #8751 · bitcoin/bitcoin · GitHub
< luke-jr> looks like it needs someone to rebase it
< luke-jr> actually, I probably already did
< luke-jr> dgpv: here, you can submit this if you want: https://github.com/luke-jr/bitcoin/pull/new/sort-multisigs-0.17
< luke-jr> although I don't know if it needs *more* rebasing..
< luke-jr> probably
< dgpv> luke-jr: that PR is about adding a single multisig address, and that can be sorted on client, so I don't think it would be useful
< dgpv> luke-jr: sorting is useful if you are creating many addresses from xpubs
< dgpv> luke-jr: ah, sorry, i'm mistaken
< sipa> dgpv: well is all of this useful at all before we even support importing descriptors?
< sipa> right now, for multisig, the only thing we can do is import individual things
< luke-jr> dgpv: what you're talking about is just a repeated form of that
< dgpv> actually, I'm not mistaken - createmultisig takes only pubkeys, not xpubs
< dgpv> sipa: I see. so maybe sometime in the future, if core supports importing xpubs to create a sequence of multisig addresses from it
< dgpv> sipa: then sortetmulti may become relevant
< dgpv> sipa: until then, no need.
< bitcoin-git> [bitcoin] jnewbery opened pull request #14778: A few minor formatting fixes and clarifications to descriptors.md (master...descriptors_doc_update) https://github.com/bitcoin/bitcoin/pull/14778