< Tatty>
I think I found an outdated version User Agent on Bitcoin Core 64 bit for Windows v0.15.0.1. I enabled 2 tor proxies, both making bidirectional connections. It happened one of the proxies contacted the other, and that's when I saw a wrong version: User Agent /Satoshi:0.14.0/
< sipa>
why is that wrong?
< Tatty>
I am sure because I recognize the Hidden Service, of the income connection, it is mine
< gmaxwell>
Tatty: what reason do you have to believe it wasn't some other node connecting to you.
< sipa>
you can't know where an hidden service connection is coming from
< gmaxwell>
0.15.0.1 gives a correct useragent, so either that connection wasn't from you or you're not running what you think you are. :)
< Tatty>
it says on top via and then my hidden service
< Tatty>
is it possible the user agent is only wrong one one of them when using 2 tor proxies?
< Tatty>
and I am sorry for insisting
< sipa>
what do you mean by 2 tor proxies?
< sipa>
you can only configure oe
< sipa>
one
< Tatty>
I run 2 different ptor proxies as allowed by Bitcoin Core 0.15.0.1
< sipa>
what's your configuration like?
< Tatty>
no, I have 2 configured, running and one connecting to the other as I can only set 1 externalip=
< Tatty>
and you see a incoming connection via that hidden service
< sipa>
what do you mean by tor proxy 2
< Tatty>
ok, someone might be having some fun announcing my hidden service as being theirs, but the simplest solution is that tor proxy 1 contacted tor proxy 2
< sipa>
what do you mean by tor proxy 1 and tor proxy 2
< Tatty>
check the second picture, the one set for port 9150 instead of 9050
< sipa>
are those screenshots from the same client?
< kallewoof>
I don't even see the error in that log.
< meshcollider>
kallewoof its something to do with that table diff, it runs scripts/buildtable.pl before and after your commit and then runs `if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1;`
< meshcollider>
Should you add an entry to README.mediawiki?
< kallewoof>
Ohh, that is probably it yeah. Thanks!
< eck>
if any of you use fedora, I just set up a bitcoin rpm repo based mostly on the existing spec file in the contrib/ directory, feel free to help me test it or give me feedback: https://copr.fedorainfracloud.org/coprs/eklitzke/bitcoin/
< kallewoof>
Man, running a full node with datadir on an external USB drive is really slow. Like, handshakes are timing out kind of slow.
< jonasschnelli>
kallewoof: you could do a PR that would allow to keep the block files on a different "datadir"...
< jonasschnelli>
That would be handy IMO
< jonasschnelli>
Maybe only blocks older then 144+...
< kallewoof>
Can't you just ln -s the blocks folder? I was thinking of doing that
< jonasschnelli>
You want the UTXO/chainstate internal and the blocks external
< jonasschnelli>
kallewoof: you can...
< jonasschnelli>
but meh
< kallewoof>
I actually think this might be a problem on my end, but not sure. It's way too slow to be normal behavior. I can't even addnode another full node on the same network. It times out.
< kallewoof>
After running for awhile, things got faster. I don't know what was going on but it seems to have been temporary.
< jonasschnelli>
kallewoof: anyways,.. that datadir split PR is still welcome. :)
< bitcoin-git>
[bitcoin] eklitzke opened pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (master...desktop-file) https://github.com/bitcoin/bitcoin/pull/11690
< kallewoof>
OK! I'll see what I can do. :) Related: I wanted to make a PR that lets you have a readonly "cache" of the blockchain in a separate folder. You can spin up more than one node very easily without having to copy entire chain if you have access to the filesystem of the first one. Would be helpful for testing things I think.
< meshcollider>
You can already move conf file with -conf and #11466 splits walletdir out so soon there'll be nothing left in the datadir itself ;)
< kallewoof>
WOuld this benefit from having only blocks on external drive? I am not sure what part of the fs is used for the tx connect stuff. *checking*
< wumpus>
where you put chainstate is going to have the most influence there
< jonasschnelli>
Yeah.. I guess the lag comes from leveldb internals
< wumpus>
the blocks directory has the block data and block index, which are relatively rarely accessed (unless -txindex)
< kallewoof>
Okay, testing ln -s solution to see if it helps.
< wumpus>
(and unless you're reindexing, at which point it has to go through all blocks twice, but stilll chainstate drive will be much, much more busy)
< promag>
I'm not familiar with the dumpwallet test
< promag>
let me read it
< meshcollider>
The dumpwallet test basically counts the number of keys present in the file and makes sure that is the number that were generated in the wallet
< meshcollider>
For the scripts part which I added, it relies on the comment to find which scripts correspond to which P2SH address we generated
< meshcollider>
and then reimports to make sure the script was valid
< meshcollider>
I'm looking into the GetAllReserveKeys() comment you wrote now, I'm unsure on that as I didn't change that part of it
< promag>
+1 on the test
< promag>
dunno why there is no lock in the RPC
< meshcollider>
there is a lock on cs_wallet
< meshcollider>
I commented on the PR, its on line 630
< kgc>
Hi! I have a question, sorry for interrupting, is it planned in the foreseeable future to change signrawtransaction rpc method to successfully sign an output that was sent to a P2SH-P2WSH address? I tried doing so resulted in failure.
< wumpus>
kgc: hrm, I think that should just work?
< meshcollider>
kgc wumpus: yep should just work, tested on 0.15.0.1
< wumpus>
thanks for testing meshcollider
< wumpus>
kgc: so you need to be a bit more specific about the steps you followed and the result you get
< kgc>
ok, I'll give you a json request I made, give me a sec
< kgc>
are there some undocumented parameters I should be passing in?
< wumpus>
no, there are no further parameters. Sounds like the transaction is missing the witness somehow?
< meshcollider>
oh hrm
< kgc>
well, it's slightly weird because if I create corresponding deposit address and import it inside bitcoin core wallet, I can send to and spend funds without anyproblems
< meshcollider>
Yeah that's what I thought you were asking about initially
< wumpus>
it looks like the witness was stripped from the transaction
< meshcollider>
Does signtrawtransaction need a witness transaction with empty witness?
< meshcollider>
Or will it add the witness itself
< kgc>
Hmm, are you suggesting that createrawtransaction method somehow cut out the witness part?
< meshcollider>
createrawtransaction would not create a witness transaction because it would not know it was a P2WSH address would it
< kgc>
yeah, sounds legit, are there any workarounds for this except for realizing serialization myself (which I would much rather avoid)
< meshcollider>
Well it shouldn't be hard to make it into a witness transaction right
< meshcollider>
just added marker, flag and empty witness
< wumpus>
it's strange if that is needed though
< meshcollider>
indeed
< wumpus>
so I think we're missing something
< meshcollider>
Ideally signrawtransaction should just convert the raw transaction to a witness transaction itself if the input is a witness input right
< meshcollider>
I looked into that, but there are no tests for P2SH-P2WSH it seems
< meshcollider>
using signrawtransaction
< meshcollider>
because L251-L264 notice that encode_p2sh is False
< meshcollider>
Hmm actually how does it know what the redeemscript is for the P2WSH part
< meshcollider>
you only pass in the P2SH redeemscript aye
< kgc>
these are the parameters I've available: https://pastebin.com/TE1LrR44 should I be passing in as a redeem script something other than: 002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac
< meshcollider>
Yeah see you give it `002016a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` which is the redeemScript for the P2SH wrapper, but then it must not know what the redeemscript for the internal `16a91e58e02069f95ea6defba7436199658573c34d384c69779779f4500d7cac` is
< meshcollider>
which is what hex=...
< meshcollider>
but I don't know how to pass that in, no :/
< kgc>
I'm confused, then what is it expecting as the redeem script parameter
< meshcollider>
I would think what you did was correct, maybe it really isn't supported without importing the script into the wallet... I would wait for someone more experienced than me to say for sure though
< kgc>
well the very least I got the address generation part right :D hopefully someone can shed some light on it, because implementing tx serialization/deserialization/signing and maintaining it would be painful for me
< kgc>
then I might as well start contributing to bitcoinj project on my spare time (which I don't have)
< aj>
MarcoFalke: #11646 was merged, so it shouldn't be labelled up for grabs, should it?
< bitcoin-git>
bitcoin/master 63c2d83 practicalswift: Explicitly state assumption that state.m_chain_sync.m_work_header != nullptr in ConsiderEviction...
< bitcoin-git>
bitcoin/master aca77a4 Wladimir J. van der Laan: Merge #11655: net: Assert state.m_chain_sync.m_work_header in ConsiderEviction...
< JackH>
how can I dump privkey on segwit addresses? I get an error when doing dumpprivkey
< JackH>
from the one topic I read, since it is a p2sh script, there is no address, thus I cannot dump privkey? but how can I otherwise get the privkey for the inputs?
< wumpus>
you probably added the witness address using addwitnessaddress?
< wumpus>
that won't add a private key
< JackH>
so how do I get access to the inputs? basically I am looking to do a child pays for parent for some stuck txs
< JackH>
and I wanted to import the privkey into electrum
< JackH>
or is there a better way?
< wumpus>
I think you need the address you called addwitnessaddress with, and use dumpprivkey with that
< wumpus>
that would give you a private key, though importing it in other software is not going to be easy I expect, e.g. just importing the key isn't going to make it recognize the transaction
< was>
hello
< was>
is someone can help me ?
< wumpus>
just ask your question in the channel and if someone can help you they'll answer (or tell you where it's better to ask it)
< was>
i have a wallet btc core
< was>
i save wallet.dat
< was>
for change another pc
< was>
now how can getback ?
< was>
i have wallet.dat and my password
< was>
you know ?
< sipa>
try #bitcoin
< promag>
Are CBlockTreeDB/CDBWrapper member functions thread safe?
< wumpus>
no
< wumpus>
though leveldb itself is thread safe
< wumpus>
we make use of that only in one place, for the Cursor in GetUTXOStats, to iterate over a snapshot of the database while the rest of the process continues
< wumpus>
but none of the caching and buffering we do on top of leveldb is thread-safe
< bitcoin-git>
[bitcoin] practicalswift closed pull request #11691: rpc: Add missing lock in getblocktemplate(...). Work around Clang thread safety analysis quirks. (master...rpc-locking) https://github.com/bitcoin/bitcoin/pull/11691
< promag>
wumpus: ty
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11694: rpc: Add missing cs_main lock in getblocktemplate(...) (master...missing-lock-in-getblocktemplate) https://github.com/bitcoin/bitcoin/pull/11694
< gustav>
i have one app where users are given 1 bitcoin address A, they deposit btc on A and later on they withdraw on their address B. I'd like to use segwit addresses to cut down expenses on network fees (if im getting this right). now i use getnewaddress, sendmany and rawtransactions functions. would it be possible to use $addr = getnewaddress(); $segwit
< gustav>
addr = addwitnessaddress($addr); to "move into segwit addresses usage"? if so would users be able to send to my app segwit address, and will my existing code be able to send payments to user addresses (non segwit and segwit)? thank you very much for all the work. now fees are insane this is why im asking. if wrong irc please tell me where to ask.
< gustav>
reading online on stackoverflow and similar leads me to believe it can be done but im not sure about compatibility (user sends from non-segwit to segwit, needs to receive from segwit to non-segwit) and if addwitnessaddress is all i need. again thanks and sorry for wall of texts
< gustav>
oopsie, using bitcoin-core latest version on linux (rpc, with php)
< sturles>
Yes, this will make an address into a segwit address (P2SH-P2WPKH). There are multiple kinds of segwit addresses. To get the highest nenefit, you can make a P2PKWH address like this: addwitnessaddress($addr,true)
< sturles>
The P2PKWH address will begin with bc1... (Bech32 format), and the sending wallet must be segwit aware to use it.
< sturles>
You can only convert your own addresses. Do not attempt to convert addresses you get from other people.
< BlueMatt>
note to anyone with open wallet-rpc PRs: ##10286 will likely cause a silent conflict - you will need to add calls to BlockUntilSyncedToCurrentChain!
< luke-jr>
BlueMatt: I wonder if there's a good way to make builds fail if they're incompatible
< luke-jr>
though I can't think of anything obvious
< BlueMatt>
I mean its kinda a manual thing to figure out if a given RPC needs the block
< luke-jr>
BlueMatt: right, but we could fail everything until some change is made to indicate one way or the other
< BlueMatt>
that seems like overkill? I mean as long as people pay attention when merging wallet rpc changes in the same way that we will need to in the future
< luke-jr>
dunno
< luke-jr>
incompatible changes breaking stuff is generally a good idea to avoid bug
< BlueMatt>
I mean if you want to write one I'd be happy to see it, but I dont think its a huge risk
< jonasschnelli>
Do you recommend to keep MayHaveUsefulAddressDB() as it is and add the HasAllDesirableServiceFlags() at another place?
< jonasschnelli>
IMO NODE_NETWORK_LIMITED should conform to MayHaveUsefulAddressDB()... or why not?
< BlueMatt>
hmm?
< BlueMatt>
yes, no, I was not objecting to the code changes there
< BlueMatt>
at all
< BlueMatt>
my complaint was about the commit message and the confusion it implies
< BlueMatt>
an easy fix for which would be to change net_processing's addr handling
< BlueMatt>
to check MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)
< BlueMatt>
as the condition for getting an address into *our* addr db
< BlueMatt>
(which, as indicated in the comment, would also not be a change in behavior, but it'd make things much clearer)
< jonasschnelli>
I see..
< jonasschnelli>
BlueMatt: but we should also do feeler to NODE_NETWORK_LIMITED, right?
< jonasschnelli>
That's why I have changed MayHaveUsefulAddressDB()
< BlueMatt>
correct
< BlueMatt>
again, I think the *code* in that commit is right, the changes I was talking about would change no behavior against what you already have
< jonasschnelli>
Okay with just rewording the commit message to mention the feeler thing?
< BlueMatt>
wait, huh?
< BlueMatt>
ohoh, yes
< BlueMatt>
so the function is named MayHaveUsefulAddressDB because its primary use is "should i do a feeler to this connection"
< jonasschnelli>
Or do you think adding "HasAllDesirableServiceFlags(services)" in net_processing would make the code more readable (not an acctual change)
< BlueMatt>
the fact that acceptance into our addr db relies on that function is purely because its a superset of HasAllDesirableServiceFlags
< BlueMatt>
my request was that you do both
< jonasschnelli>
okay... got it
< jonasschnelli>
BlueMatt: wait,... but HasAllDesirableServiceFlags() changes over time. Should we not add NODE_NETWORK_LIMITED to our addr man even during IBD?
< jonasschnelli>
A check in net_processing (MayHaveUsefulAddressDB(services) || HasAllDesirableServiceFlags(services)) would lead to not adding NODE_NETWORK_LIMITED during IBD, right? Is that desirable?
< BlueMatt>
jonasschnelli: I mean MayHaveUsefulAddressDB will always return true for either NODE_NETWORK{,_LIMITED}
< bitcoin-git>
bitcoin/master b077fe9 Evan Klitzke: fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it
< bitcoin-git>
bitcoin/master f0c1f8a MarcoFalke: Merge #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11690: [trivial] Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (master...desktop-file) https://github.com/bitcoin/bitcoin/pull/11690
< go1111111>
I'm experiencing a fairly painful UX issue with Core. I'm probably "using it wrong", but I wanted to describe my problem in case it influences development, and also see if there's a workaround:
< go1111111>
I have several different wallet files, with different passwords. I rename them 'wallet.dat' as needed. I also recently started pruning my node. These two things don't work together well, as whenever the node is given a wallet with new addresses and it thinks it might be missing info, it wants to re-download the entire blockchain
< go1111111>
so, i essentially have to redownload and revalidate the entire blockchain for every wallet (it is possible to be smarter about this by taking snapshots, but it's cumbersome). Is there a workaround to that?
< sipa>
are you using multiwallet? you can load all wallets at once
< go1111111>
Oh, wasn't aware of that. I'll look into it -- thanks! My other problem: I'm about 40% of the way through validating the blockchain, but all the inputs I want to spend have already been seen by the node, so I'd like to be able to broadcast a tx even though the node itself doesn't know that inputs are unspent. Is there a better way to do this other than using createrawtransaction?
< go1111111>
I'd like to take advantage of the transaction construction of the UI to avoid errors, but also don't want to wait another 6 hours..
< sipa>
you can construct a transaction as soon as your node knows about the outputs
< sipa>
however, if you would construct a transaction that spends inputs which happen to be already spent in the chain, the result will be invalid (and you'll need to use abandontransaction to fix things)
< go1111111>
interesting. that's how I wanted it to work, but when I construct my tx in the UI and click 'send', the UI doesn't respond at all. I expect to be prompted for my pw. Now that I know this is unexpected i'll try some variations to see if I can get it to work. thanks
< sipa>
i'm unfamiliar with the GUI, but that does sound like a bug
< sipa>
or at least something that requires more accurate information
< go1111111>
it seems to relate to coin-control. I get the expected behavior when I don't manually select the inputs
< go1111111>
wait no, that's wrong.. I'll be back when/if I have a proper bug report. thanks for the help.