< TGeek>
Hi all, I am having an issue in bitcoin core 0.17.0.1 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
< 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
< 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?
< 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>
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