< gmaxwell>
lol I see other people complaining on the PR.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13454: Add linter: Make sure LC_ALL=C is set when using grep range expressions (master...avoid-locale-dependent-range-expressions) https://github.com/bitcoin/bitcoin/pull/13454
< fanquake>
wumpus I can create that backport if you aren't already doing it
< wumpus>
sure! thanks, though no real hurry, I've tegged it 0.16.2, don't think it should hold up 0.16.1
< fanquake>
np, I'll do that and the other outstanding backport. Hadn't noticed the Windows one until now..
< fanquake>
Any further thought on #13091? Agree that it's only useful if you branch has already been found. Maybe we need to put a notice in the master readme.md?
< fanquake>
If we don't want to do that I'll close the PR and the 0.15.2 milestone.
< wumpus>
fanquake: yes, as I commented there, I don't think it's very useful in current form, most people are bound to look at README.md in master, but it probably also needs opinions by other people
< fanquake>
wumpus meh, I think I'll close for now, and might do something against master
< jonasschnelli>
sipa: thanks for the new BCH code...
< jonasschnelli>
You set "randomly" picked... out of what set?
< jonasschnelli>
wumpus: for your scantxoutset issue, the problem is, that P2PK and P2PKH leads to the same address, and decoding the script from that address always decodes in a P2PKH script
< jonasschnelli>
wumpus: scanning for the P2PK script equivalent by "hashing" the script in the txoutset (form a P2PK script) would probably be a large overhead
< jonasschnelli>
I don't know how to best deal with that... if a warning the P2PK scripts are not covered by providing addresses is enought
< marcoagner>
hi! is the process of documenting changes in behavior (including adding release notes) documented anywhere? thanks
< marcoagner>
I'd like to know if I introduce a small behavior change, should I just write a release-notes-prXXX.md or is there anywhere else to document? asking here so I don't clutter the PR with notifications for simple q's :)
< fanquake>
marcoagner: The main place changes in behaviour are documented is in release notes. With some changes having a deprecation period for a release or two. i.e RPC changes.
< fanquake>
A release-notes.md PR sounds ok.
< wumpus>
if it's a significant behavior change, it needs to be mentioned explicitly in the release notes, it's preferable to add a .md for your PR because it has the least chance of conflict (these will be assembled into one text before the release)
< wumpus>
jonasschnelli: I understand. Maybe it's not a problem at all.
< wumpus>
jonasschnelli: depending on the use-case
< wumpus>
agree it would add overhead to scan for those as well
< wumpus>
on the other hand, if people rely on this to output the spendable outputs to an address, this needs to work
< provoostenator>
What's a simple way to generate a reasonably random UInt256 for in src/benchmark?
< jonasschnelli>
provoostenator: what do you want to benchmark?
< provoostenator>
CCoinsView(Cache) writes / reads with and without disk access.
< provoostenator>
So I need unique tx hashes, but they can be garbage.
< jonasschnelli>
provoostenator: use FastRandomContext() and eventually make sure you pre-generate random hashes before entering the benchmark timecycle?
< provoostenator>
Thanks. Yes, I'm making sure to keep that sort of stuff away from the benchmark itself.
< provoostenator>
There's already sa FastRandom_32bit helper function in the becnh dir I just notice, so can just reuse that pattern.
< provoostenator>
(no actually that's different, but I'll figure it out)
< bitcoin-git>
bitcoin/master 51cd508 Ben Woosley: When build fails due to lib missing, indicate which one...
< bitcoin-git>
bitcoin/master cf7ca60 Wladimir J. van der Laan: Merge #13435: When build fails due to lib missing, indicate which one...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13435: When build fails due to lib missing, indicate which one (master...lib-missing) https://github.com/bitcoin/bitcoin/pull/13435
< sipa>
jonasschnelli: support for xpub derivation etc
< jonasschnelli>
It's supported in the current PR
< sipa>
i know
< promag>
> gui: Drop qt5 support < uff
< jonasschnelli>
sipa: Just not with a text base script type descriptor as we once discussed
< sipa>
jonasschnelli: okay
< jonasschnelli>
sipa: But I changed the API to have n elements of various types
< jonasschnelli>
(as you suggested)
< wumpus>
promag: lol...
< sipa>
wumpus: straight to qt6?
< fanquake>
sipa bundle that with c++17
< sipa>
fanquake: that seems weird; c++17 actually exists :)
< sipa>
go for c++20 at least
< wumpus>
sipa: we're migrating to electron *runs very fast*
< sipa>
haha
< fanquake>
heh
< jonasschnelli>
sipa: any preferences for a name for the Base32 based 27 checksum BCH code? BechSeven32? Bech32Priv? Priv32?
< jonasschnelli>
And I guess I can use the HRP checksum integration 1:1 from Bech32?
< sipa>
yeah
< sipa>
Bech32X
< sipa>
:)
< jonasschnelli>
Okay. Bech32X shall it be
< fanquake>
jonasschnelli: I'm just retesting, but be good to get your ack/nack on #12783. Not sure if you wanted to test a 10.8 VM, but I think we'll be moving to 10.10+ "soonish".
< bitcoin-git>
bitcoin/master c2dfbb4 Andrew Chow: Add unavailable options to hidden options category...
< bitcoin-git>
bitcoin/master 4a7e64f MarcoFalke: Merge #13441: Prevent shared conf files from failing with different available options in different binaries...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13441: Prevent shared conf files from failing with different available options in different binaries (master...gargs-disabled-options) https://github.com/bitcoin/bitcoin/pull/13441
< Chris_Stewart_5>
I have a question about using `addmultisigaddress` in conjunction with decodescript. I am not getting the same address field output
< satwo>
Hello all. Been thinking about a couple of features I'd like to see in Bitcoin Core and am curious what others think and whether these features already been discussed (or even implemented somewhere). a) Exposing SigOps count in getrawtransaction and getblock
< satwo>
b) a multi-file solution for bitcoind's debug logging to allow for truncating and archiving debug.log
< satwo>
b) a multi-file solution for bitcoind's debug logging to allow for truncating and archiving debug.log
< sipa>
nkohen: use addresstype=legacy if you want p2sh-multisig
< Chris_Stewart_5>
sipa: Is this an issue that there isn't consistentcy in the address being returned by these? I.e. one of thos rpcs isn't reading what your configuration is?
< Chris_Stewart_5>
if we submitted a PR to do this would that be accepted?
< jonasschnelli>
Why is "include_watchonly" in getbalance depracated?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13460: doc: Remove note to install all boost dev packages (master...Mf1806-docBuildUbuntu) https://github.com/bitcoin/bitcoin/pull/13460
< sipa>
Chris_Stewart_5: what would you change?
< sipa>
all the returned information is correct
< sipa>
Chris_Stewart_5: decodescript is not a wallet RPC
< sipa>
it just decodes the script
< sipa>
validateaddress/getaddressinfo will return the wallet related information
< sipa>
i guess decodescript could get an extra "p2sh-p2wsh" field
< sipa>
which gives the p2sh-p2wsh address for that script
< sipa>
actually, no
< sipa>
if it's already a witness program it can't do that, etc
< gmaxwell>
satwo: you can handle the logs like standard unix daemon logs. Mv the file, then HUP the process and it'll make a new file and stop writing to the old one.
< satwo>
gmaxwell: Wouldn't there be data loss (albeit small) with that approach?
< satwo>
Or does bitcoind immediately make a new debug.log if it doesn't see one where it's expecting to?
< Chris_Stewart_5>
sipa: If you provide a 'raw' (non witness) redeem script it would make sense to have multiple address encodings no?
< sipa>
Chris_Stewart_5: iguess
< sipa>
but generally decodescript doesn't know
< sipa>
though things that look like witness programs aren't useful as scripts directly
< Chris_Stewart_5>
Yeah I understand, I didn't realize it was an rpc that doesn't have any context into your wallet. Not even configuration settings
< sipa>
oh it does have configuration info
< sipa>
but the field is called "p2sh", not "address", so i guess it's expected to produce a p2sh address
< sipa>
still, i think it wouldn't make sense to make its output depend on what type of addresses you have configured
< sipa>
it's an rpc designed to examine things, not to construct addresses
< Chris_Stewart_5>
really? I would disagree. But to each and his own. Thanks you for the help
< sipa>
but adding other fields for p2wsh addresses there sounds oretty useful to me
< sipa>
Chris_Stewart_5: generally nobody but the receiver wallet should be constructing addresses (as only he and his software can determine exactly which outputs tjey will consider valid payments)
< sipa>
so i think it doesn't make sense to have an RPC that is designed to analyse other's addresses be dependent on your own settings for what addresses to genrrate
< sipa>
i've seen some confusion from people who want to "convert" an existing p2pkh address into segwit versions, which you should never do, as you don't know the receiver wallet will support it
< cfields>
sipa: it occurs to me that for for SHA256D64, duplicated leaves have some redundant sigma0 calculations during message expansion.
< cfields>
not enough redundancy to be useful, just thought it was interesting
< luke-jr>
IIRC, the new code is doing 8-way if there's >=8 things left, and 4-way if 4-7 things left.. is there a reason not to do 8-way for >4 things? wouldn't that be faster than doing 4-way + 2-way + 1-way ?
< luke-jr>
sipa: ^
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #13461: Wallet: correctly deprecate accounts in getbalance, re-add minconf / include-watch-only (master...2018/06/watch_only_balance) https://github.com/bitcoin/bitcoin/pull/13461
< sipa>
luke-jr: yes, i've thought about that- but it also doesn't matter all that much
< sipa>
it affects at most 3 entries per level
< bitcoin-git>
[bitcoin] Empact opened pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH (master...serialize-hash-type) https://github.com/bitcoin/bitcoin/pull/13462
< christos88>
hi, my bit core client says since a few hours ago as i started it that its "checking again the blocks..." "Blöcke werden nochmal neu verarbeitet...", its says 0%, the client is working but i dont know what its doing, i want to complete the download of the blockchain, its possible that the program wasnt shut down properly but how long can the work process take?
< sipa>
christos88: yes, unclean shutdown
< sipa>
it can take a long time; it needs to go through all blocks since the last succesful flush
< sipa>
with large dbcache that can be a lot
< bitcoin-git>
[bitcoin] spyder46n2 opened pull request #13463: Merge change from BitCoin #11013 - Fix automake warnings when running autogen.sh (Ubuntu and others) (master...develop) https://github.com/bitcoin/bitcoin/pull/13463
< christos88>
@sipa thank you, i had already over 80%, it took me a few weeks, do i have to wait again that long?
< sipa>
christos88: weeks?!
< sipa>
what hardware?
< midnightmagic>
gah, what's up with ken's signature
< achow101>
what's wrong with it?
< christos88>
sipa: its old hardware, intel dual core, 4gb ram, geforce 9400
< achow101>
midnightmagic: he uses ECDSA instead of RSA, perhaps that's the problem?
< midnightmagic>
hrm
< midnightmagic>
he must be using gpg2 as gpg
< booyah>
christos88: it shouldn't take so long. is computer running almost 24/2?
< booyah>
christos88: it shouldn't take so long. is computer running almost 24/24?
< achow101>
midnightmagic: probably. in some systems, gpg2 is the default gpg
< midnightmagic>
rad
< christos88>
booyah: yes, right now 24 hours, percentage per hour was o,XX, depended on how much i was using browsers to surf, right now bitcore is checking at 0% since 4 hours
< bitcoin-git>
[bitcoin] spyder46n2 closed pull request #13463: Merge change from BitCoin #11013 - Fix automake warnings when running autogen.sh (Ubuntu and others) (master...develop) https://github.com/bitcoin/bitcoin/pull/13463
< bitcoin-git>
[bitcoin] kristapsk opened pull request #13464: RPC: Allow to specify rescan start timestamp for importaddress, importprivkey and importpubkey (master...rescan-from) https://github.com/bitcoin/bitcoin/pull/13464