< Lauda>
The balance is there, looks spendable. Received from in Transactions shows an empty label
< Lauda>
Coin control shows nothing though.
< Randolf>
With the help of folks in the NetBSD community, I can now compile bitcoind (and friends) in NetBSD 7.0 after making a few minor changes to 2 files. I also added one "doc" file which provides build instructions. Since I'm new to GitHub and this is my first contribution to bitcoin, I want to make
< Randolf>
sure that I don't proceed incorrectly. Do I just create a new Pull Request so that peer-review can commence, or does peer-review come first? (2 files have minor changes, and 1 new file containing instructions was added for NetBSD users.) Thanks in advance.
< sipa>
Randolf: unless you're very unsure about the approach, i suggest you just open a PR
< Randolf>
sipa: Okay, I assume PR is short of Pull Request, and not Problem Report?
< kexkey>
Hi! listunspent returns a list of UTXOs and some of them have an amount of 0. Weird. I thought I could use coin control to get rid of those UTXOs but looks like the feature uses UTXOs with amount > 0. How can I clean those UTXOs? Thanks!
< bitcoin-git>
[bitcoin] jtimon opened pull request #12128: Refactor: One CBaseChainParams should be enough (master...b16-baseparams-nohierarchy) https://github.com/bitcoin/bitcoin/pull/12128
< meshcollider>
keykey: the fifth parameter to listunspent is "query_options" which allows you to specify minimumAmount, is that what you are looking for?
< meshcollider>
kexkey*
< meshcollider>
kexkey: the fact that is shows 0 value UTXOs was exlicitly added in #6036 though, its not weird :)
< kexkey>
meshcollider, I should have said "surprising" instead of weird. :) Well, displaying 0 value UTXOs is expected, but creating them is surprising, I wonder what's the point of having 0 value UTXOs. Now is it possible to used them as inputs? I'll try that tomorrow. :) Thanks!
< kexkey>
meshcollider, oh and thanks for the PR number, I'll have a look at it. :)
< meshcollider>
kexkey: yeah I think the PR describes why better than i can
< Lauda>
promag: Nope. It seemed like he abandoned/was too busy for it and it's been needing a rebase since October I think.
< promag>
jl2012: ping?
< kallewoof>
Needing a rebase doesn't really mean anything. If there are unanswered questions or change requests that may be a different story though.
< kallewoof>
I tend to only rebase if a PR gets attention (I'm the quiet type -- my PRs generally take 6-12 months to be merged, since I never bug anyone about them).
< promag>
there is jnewbery comments in the old one
< promag>
I would wait for jl2012 feedback at least
< kallewoof>
Ahh, yeah. That kind of does look abandoned. Agree on waiting for jl2012 feedback.
< Lauda>
Well, it's part of the Segwit project and seemed abandoned; that's why, but sure!
< kallewoof>
Lauda: I sometimes have people randomly pick up my PR:s and remaking them, thinking they're abandoned even though I'm simply waiting for people to get around to reviewing. :)
< Lauda>
hehe, that's unfortunate.
< promag>
kallewoof: little noise from time to time doesn't hurt
< provoostenator>
I'm trying to sync a v0.15.1 node with a master branch node on regtest, but they seem to reject each-others blocks with: Reject block code 16: bad-witness-nonce-size
< provoostenator>
(the functional test framework lets you point to alternative binaries, which might be useful for testing compatibility between versions)
< BlueMatt>
the default parameters changed on master - segwit is always (?) active now, or something like that, iirc
< provoostenator>
Ah yes, I remember that too. Should I patch the old version(s) or is there a file I can copy over?
< BlueMatt>
you can change the bip9 activation parameters option thinggy so they match
< provoostenator>
#11389
< gribble>
https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest (sipa, ajtowns, jnewbery) by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #12133: [qa] Fix rare failure in p2p-segwit.py (master...2018-01-fix-p2p-segwit) https://github.com/bitcoin/bitcoin/pull/12133
< luke-jr>
should probably get #10595 merged too (trivial fix, sortof blocking further cleanup)
< gribble>
https://github.com/bitcoin/bitcoin/issues/10595 | Bugfix: RPC/Mining: Use pre-segwit sigops and limits, when working with non-segwit GBT clients by luke-jr · Pull Request #10595 · bitcoin/bitcoin · GitHub
< hghghg>
...
< bitcoin-git>
[bitcoin] Sjors opened pull request #12134: [WIP] Build previous releases and run functional tests (master...previous-release) https://github.com/bitcoin/bitcoin/pull/12134
< echeveria>
huh, there's no way of finding out if you're on testnet via RPC now?
< echeveria>
it used to be in getinfo['testnet']
< cncr04s>
validateaddress m..... vs 1......
< echeveria>
that's dirty.
< cncr04s>
i'll add getinfo back into the code when I need to
< echeveria>
it was removed for a reason
< cncr04s>
which is?
< echeveria>
it did dumbass shit like touched the wallet keypool every time you called it.
< echeveria>
it would reserve, then unreserve a key.
< cncr04s>
then just make it not do that
< echeveria>
the RPC is gone, it's not really up for debate or re-inclusion.
< cncr04s>
I can edit my own source as I please=D
< echeveria>
ok, but in the context of using a piece of software I'm not talking about your insanity fork that grasps onto RPCs deprecated a long time ago.
< cncr04s>
well then i guess you'll need to use validateaddress
< instagibbs>
echeveria, getnetworkinfo["chain"] I think
< jonasschnelli>
echeveria: getblockchaininfo and look for "chain"
< echeveria>
I expected it to be 'network info', as in information about the network, not information about *your* network :)
< instagibbs>
heh, true
< cfields>
BlueMatt: whoops, missed your ping yesterday. Yes, I need to do my next round of rebasing/PR for the libevent stuff.
< cfields>
sipa: out of curiosity... It looks like dns servers pretty much ignore the port provided in the query, but are free to filter based on it. What was the reasoning for using subdomains rather than plugging it in there?
< cfields>
mm, I suppose that would break caching/ttl