< meshcollider>
or was that just a reply to dcousens
< wumpus>
meshcollider: I'd prefer that - I think it'd make sense to restrict that PR what it says in the title; generally changing &vec[i] to vec.data() + i does nothing to avoid UB
< wumpus>
which was the idea behind &var[0] to var.data()
< sipa>
wumpus: &var[0] is inherently invalid for empty vectorz
< sipa>
while var.data() is allowed for empty vectors
< sipa>
you're still not allowed to dereference the result of var.data()
< sipa>
but with &var[0] it's already invalid, whether you use it not
< wumpus>
yes, I know that
< wumpus>
that was my point, &var[0] to .data() makes sense, but e.g. &var[42] to var.data()+42 does not
< wumpus>
which is what meshcollider has extended to scope to in some places in that PR
< sipa>
oh, i see
< meshcollider>
yeah I'll revert that
< sipa>
well, &var[42] is also invalid for a var of length 42 or less
< sipa>
while var.data() + 42 is always valid, as long as you don't use it
< wumpus>
still, it's getting used in all those cases
< sipa>
okay!
< wumpus>
which is UB in any case
< meshcollider>
yeah its usually used with memcpy()'s
< meshcollider>
fixed
< meshcollider>
poor Travis will be having a hard time with all these commits recently lol
< promag>
speaking of that, wumpus any idea when you'll check #11006?
< promag>
It can save some travis resources
< wumpus>
I'm really confused about that one
< wumpus>
can't reproduce any problems with it locally, but I'm afraid of bringing back random travis failures. I much prefer it taking somewhat longer to random failures that make people lose trust in the tests
< wumpus>
I'm not sure what the problem was back then and if you can remove that workaround now, what made it go away
< promag>
I would say merge as it get a couple more ACK, revert later if needed
< promag>
I can't figure out if you did that, pass nullptr to timeout
< wumpus>
no, I never did that, because it means that bitcoind will never terminate if there are open rpc connectinos
< wumpus>
AFAIK
< promag>
that is correct, but if the connections are closed then it quits immediately, if not then it will break as it is now
< wumpus>
so the timeout is there to force any existing RPC connections to terminate
< promag>
right, for instance, some dumb tests, whatever
< wumpus>
yes, could be for various reasons, our examples pretty much encourage keeping connections open between commands
< promag>
in the best scenario, there are no active events and the loop can exit right away
< wumpus>
(which is more efficient than opening a new connection for every commmand, but we don't want this to hold up the shutdown process, people will get confused)
< wumpus>
stop means that the process must exit, despite open connections
< wumpus>
yes, I agree ideally it should exit immediately if there are no active eventw
< wumpus>
and in say, 3 seconds if there are active events
< wumpus>
that's why the code is so complicated
< promag>
so, on my side I did test with different libevent versions, run test suite multiple times.. no issue so far
< wumpus>
yes, but did you try keeping connections open to the daemon after sending stop?
< meshcollider>
also wumpus, re #11237, do you want me to fix the weird commit split or leave it as-is
< esotericnonsense>
hm. promag: i'm looking at adding tests for the weight field in mempool now. can get it to work for txid2 and txid3 but not txid1. sdaftuar's 'add wtxid to mempool entry output'
< esotericnonsense>
also fails on txid1 if I reuse his test.
< bitcoin-git>
bitcoin/master ca67ddf esneider: Move the AreInputsStandard documentation next to its implementation
< bitcoin-git>
bitcoin/master 2a56baf MarcoFalke: Merge #10682: Trivial: Move the AreInputsStandard documentation next to its implementation...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10682: Trivial: Move the AreInputsStandard documentation next to its implementation (master...move-doc) https://github.com/bitcoin/bitcoin/pull/10682
< esotericnonsense>
i've amended the PR and pointed out the test that fails. my knowledge here is lacking unfortunately.
< meshcollider>
esotericnonsense: isn't it failing because txid1 has no witness
< meshcollider>
hmm idk
< esotericnonsense>
meshcollider: it might be that i'm getting lost in the python framework's definitions
< esotericnonsense>
from BIP141 i interpret 'base tx size' as tx.serialize() (because it is equivalent to tx.serialize_without_witness()), and tx.serialize_with_witness() as being total transaction size BIP141
< meshcollider>
yeah that sounds right
< esotericnonsense>
'size' in the mempool rpc is virtual tx size (weight/4)
< esotericnonsense>
argh. doh. this makes the entire thing pointless. brain fart.
< meshcollider>
hmm not quite, virtual size is rounded up to the nearest integer so they're not entirely the same
< esotericnonsense>
size == math.ceil(weight/4) checks out for all three tx in segwit.py. it's just this one for which tx.serialize()*3 + tx.serialize_with_witness() != weight.
< esotericnonsense>
hm.
< meshcollider>
sipa: where does the extra +3 come from?
< esotericnonsense>
meshcollider: it just accomplishes the ceiling function
< esotericnonsense>
e.g. (3*nowitness + size + 3)/4 == ceil((3*nowitness+size)/4)
< esotericnonsense>
(where the former uses integer division)
< sipa>
meshcollider: to round up
< sipa>
esotericnonsense: right
< meshcollider>
ok yeah so it relies on integer division, that's where I was confused
< meshcollider>
Was thinking there might be some reason it was always exactly an integer lol
< esotericnonsense>
the problem is that i misinterpreted the original rpc call, so knowing size and weight is not useful for my particular case, which means that my PR is probably pointless :)
< esotericnonsense>
(the intention was to know 'is this a segwit tx')
< meshcollider>
also kinda relevant is issue #11218, sipa suggested renaming size to vsize
< esotericnonsense>
the other PR accomplishes what I need, (just check wtxid against txid)
< esotericnonsense>
if it were base size and not vsize, then my check of bsize*4 != weight would work
< jtimon>
jnewbery: does BitcoinTestFramework.add_nodes() need to get num_nodes as param, isn't that internal now?
< meshcollider>
can only members with write access restart travis? Seems like that should be a weaker permission, but not really sure how githubs permission model works
< kallewoof>
meshcollider: restarted
< meshcollider>
thanks :)
< meshcollider>
So no IRC meeting this week right?
< meshcollider>
is this intended behavior? https://i.imgur.com/juKAf1O.png the credit shows the full 7 BTC which was received by the wallet, but it was received on 2 separate addresses in the same transaction (3 and 4 BTC respectively), because from looking at that transaction details window it looks like the full 7 BTC was received on just that one address
< meshcollider>
heh I forgot, everyones in SF so no one will be online at 4:30am sf time
< meshcollider>
but I have a feeling this might be what the change to transactiondesc.cpp in #7101 was trying to fix
< esotericnonsense>
meshcollider: this is feeling oddly familiar, i think i encountered this years ago when splitting coins
< esotericnonsense>
meshcollider: i just tried to test this but forgot that there's special behaviour if you send to your own wallet, doh
< meshcollider>
I just ran 2 regtest nodes on the same machine to do this
< meshcollider>
just run one with -port=whatever and then addnode=127.0.0.1:whatever in the other nodes config
< esotericnonsense>
crafted another one by using -wallet.
< esotericnonsense>
this tx, with 4 outputs, 3 to 'wallet2' and 1 to change in 'wallet1', is showing as three seperate entries/rows in the 'wallet2' node.
< meshcollider>
yep but if you go into the full details of each row, do they all just give the total, not the individual received by that address?
< esotericnonsense>
ah yes.
< esotericnonsense>
it's a bit odd in any case. on the 'sending wallet' it apportions the fee arbitrarily to one output.
< meshcollider>
indeed
< meshcollider>
seems like lots of little bugs are mixed up in this
< esotericnonsense>
it's difficult for me to reason about what you even want it to show really :P
< meshcollider>
Yeah I guess the fee being attributed to a random output kinda makes sense right, its gotta be shown somewhere and you wouldn't want to make another whole row for it in the table
< meshcollider>
its just the full details page, if you open it for any row from the same transaction it should show all inputs from that same transaction right, not just the one. Then it would make sense to have a total on there
< meshcollider>
in a similar way to how its shown on the sending node
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11264: [doc] Fix broken Markdown table in dependencies.md (master...dependencies-capitalization) https://github.com/bitcoin/bitcoin/pull/11264
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10731: Escape rather than remove any printable characters in UAs (master...log_more_uacomment) https://github.com/bitcoin/bitcoin/pull/10731
< bitcoin-git>
bitcoin/master 3b69a08 MeshCollider: Fix division by zero in time remaining
< bitcoin-git>
bitcoin/master c8d38ab MeshCollider: Refactor tipUpdate as per style guide
< bitcoin-git>
bitcoin/master e7f1255 Wladimir J. van der Laan: Merge #11237: qt: Fixing division by zero in time remaining...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11237: qt: Fixing division by zero in time remaining (master...201709_fix_estimated_time) https://github.com/bitcoin/bitcoin/pull/11237
< jtimon>
perhaps a short summary of how are things going in the phisical meeting instead of the IRC meeting?
< jtimon>
or kanzure's option sounds good too
< kanzure>
there's various text from last few days, although not as much as zurich
< wumpus>
mixed wallets are pretty much a neccesity
< gmaxwell>
we won't be supporting 'segwit only' in 0.15.1 at least just because it's a bigger change. (rather than the couple line core change needed to just auto-addwitness to everything)
< gmaxwell>
kanzure: that talk will have a video online in a bit.
< meshcollider>
addwitness newaddresses or existing addresses too?
< gmaxwell>
But perhaps in the future we will have wallets that are segwit only except for imported keys.
< gmaxwell>
meshcollider: all due to backup recovery.
< michagogo>
fakeping :-(
< gmaxwell>
if you only do 'new' then you need a way of storing where you started doing that.
< kanzure>
signature aggregation will land in libsecp256k1 at some point
< jtimon>
yeah, still too early to create a testnet, on the bright side I'm reading a lot of test code every time I rebase that...
< meshcollider>
I'll review that a bit later today jtimon, I like the sound of it
< meshcollider>
Any new bugs reported in rc3?
< jtimon>
meshcollider: awesome!
< meshcollider>
This segfault issue with Qt keeps coming up, #11262 yesterday is the third issue I've seen
< jonasschnelli>
Yes. The segfault things is ugly... it seems to happen for self-compiled Bitcoin-Qts only. So it could be a Qt5.5 bug. Couldn't track it down so far
< bitcoin-git>
bitcoin/master fa40b0e MarcoFalke: travis: Assert default datadir isn't created, Run scripted diff only once
< bitcoin-git>
bitcoin/master 52f8877 MarcoFalke: Merge #11260: travis: Assert default datadir isn't created, Run scripted diff only once...
< sipa>
i'd like to see #11174 addressed
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11260: travis: Assert default datadir isn't created, Run scripted diff only once (master...Mf1708-travisYaml) https://github.com/bitcoin/bitcoin/pull/11260
< meshcollider>
#11245 got tagged for 0.15.0 four hours ago, what's happening there
< meshcollider>
If the issue isnt present in rc3 then there isn't much point including the fix in 0.15.0 release notes, but we don't know if it really got fixed
< meshcollider>
What's needed for 11174 re: rescanning?
< meshcollider>
I can make a PR if no one else is going to
< kyzeeruz>
what is PR?
< meshcollider>
Pull request
< meshcollider>
But it sounded like gmaxwell was leaving a mental note for himself
< kyzeeruz>
Is there somebody can give me a free web link to learn bitcoin coding?
< meshcollider>
I think you're in the wrong channel, try #bitcoin :)
< bitcoin-git>
[bitcoin] rawodb closed pull request #11177: Support for SegWit Addresses in RPC calls and change addresses (master...pr/rpc_getsegwitaddresses) https://github.com/bitcoin/bitcoin/pull/11177
< kyzeeruz>
I want to create and build a bitcoin web game or either transforming an online game while playing earn a real bitcoin on it live online.
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11272: CKeystore/CCrypter: move relevant implementation out of the header (master...2017/09/wallet_refact) https://github.com/bitcoin/bitcoin/pull/11272
< kyzeeruz>
Is there any possible to use an old computer as a main miner to generate bitcoin?
< michagogo>
meshcollider: it didn't happen
< michagogo>
despite the ping
< jonasschnelli>
meshcollider: because most of the devs are working in the same physical location right now, the meeting was not really happening...
< michagogo>
kyzeeruz: short answer: no. Anyway, this is the wrong place
< jonasschnelli>
yeah.. next week it will be again in the normal fashion
< jonasschnelli>
sorry about that.
< kyzeeruz>
thanks michagogo
< meshcollider>
Ok sweet, just confused about the ping and thought it was started :)
< meshcollider>
Hope the last day of SF goes well then
< bitcoin-git>
[bitcoin] mess110 opened pull request #11274: [tests] Cleanup wildcard imports in functional tests (master...cleanup-wildcard-in-functional-tests) https://github.com/bitcoin/bitcoin/pull/11274
< kyzeeruz>
What repositories maen?
< sipa>
kyzeeruz: #bitcoin please
< esotericnonsense>
is it expected that pruning can become a limiting factor in IBD? testing now and by increasing my prune size (essentially, temporarily disabling it) it seems to have increased sync rate by approx 30%
< esotericnonsense>
the cache seems to flush on each pruning event
< esotericnonsense>
testing ramdisk with prune=5000 vs ssd with prune=50000 -> 30% faster off the ssd (and seemingly improving as dbcache increases)
< MarcoFalke>
wumpus: Pull list looks fine
< wumpus>
MarcoFalke: thanks for checking
< BlueMatt>
gah, mk229797 shows up on an issue and tells someone to download a datadir snapshot
< BlueMatt>
I assume its not a real person...wumpus wanna ban that account?
< BlueMatt>
hmm, maybe not?
< wumpus>
banned
< BlueMatt>
seems like a person, but thats a strange response
< BlueMatt>
eh, whatever
< BlueMatt>
they'll come here and complain if they're real
< wumpus>
right, it was definitely not ok
< wumpus>
hm, strange, I pushed the PR list in the release notes to the 0.15 branch and github's bot didnt trigger
< BlueMatt>
:O
< wumpus>
maybe it's overloaded
< BlueMatt>
github has had a lot of notification delays of late...there's been a few days where their email was super slow for a few hours
< wumpus>
I hope it's not our fault for merging so much :)
< BlueMatt>
heh, I hope it is :p
< BlueMatt>
(though other projects are larger...)
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11276: Update CONTRIBUTRING.md to reduce unnecesarry review workload (master...2017/09/cont) https://github.com/bitcoin/bitcoin/pull/11276
< wumpus>
the IRC bot is definitely backlogged
< bitcoin-git>
[bitcoin] laanwj closed pull request #11205: Make fixed CAmounts and related sanity function constexpr (master...refactor/constexpr-amount) https://github.com/bitcoin/bitcoin/pull/11205
< meshcollider>
yeah I'm working on it at the moment but I'm just trying to work out what gmaxwell's mental note meant ;)
< meshcollider>
< gmaxwell> mental note: we need release notes on the topup stuff and instructions for rescanning
< meshcollider>
Also should this be a new section in the release notes? 'Notes for 0.15.0' or something?
< wumpus>
maybe at the beginning, after the upgrade/compatibility instructions
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11280: [0.15] Final to-do's for 0.15.0 release notes (0.15...201709_release_note_015_todo) https://github.com/bitcoin/bitcoin/pull/11280
< bitcoin-git>
[bitcoin] laanwj closed pull request #10756: net processing: swap out signals for an interface class (master...no-net-signals2) https://github.com/bitcoin/bitcoin/pull/10756