< sipa>
meshcollider: address_type is also added to getnewaddress
< meshcollider>
sipa: but that RPC is deprecated now so should we even bother adding that?
< sipa>
what?
< meshcollider>
oh sorry I misread and thought you said addwitnessaddress
< sipa>
you're confusing getnewaddress with addwitnessaddress, i think?
< meshcollider>
yeah
< sipa>
also, with the inclusion of scripts in dump/import, i think those RPCs may just work fine
< meshcollider>
sipa: true, we should test it properly first before claiming though IMO?
< sipa>
meshcollider: yes, absolutely
< sipa>
but i think there's a good chance it just works now
< meshcollider>
Oh I'll just remove mention of those RPCs altogether for now rather than saying they are or are not supported
< sipa>
sign/verify and importmulti definitely don't support segwit addresses
< promag>
s/segwit/SegWit ?
< promag>
or who cares?
< promag>
#low-level-rpc-changes should mention fundrawtransaction change type and addmultisigaddress address type ?
< sipa>
meshcollider: validateaddress has had many changes
< meshcollider>
promag: you can change them all if you want :)
< sipa>
just mentioning it now in case someone wants to do a writeup
< sipa>
if not, i'll do so in a few days
< meshcollider>
promag: I added them to the segwit sections rather than the low level RPC changes, IMO no point duplicating the info as long as its in a logical place
< promag>
ok cool
< meshcollider>
sipa: what kind of changes, andrews PR hasnt been merged yet has it
< meshcollider>
I must have missed something
< sipa>
meshcollider: included in 11403
< sipa>
commit 3eaa003c8
< fanquake>
In the SHA256 ASM section. s/has/have s/this was/they were s/but is/but are and remove "is no" .
< fanquake>
Can we get conflicts when editing the wiki? I don't want to touch it in case I mess up your good work.
< sipa>
meshcollider: specifically, there are new "embedded" and "pubkeys" fields that apply to non-segwit as well
< meshcollider>
fanquake: I guess there might be conflicts if we edited the same part but I'm not currently editing so it should be ok
< meshcollider>
sipa: ooh ok I missed those, will add then
< sipa>
also, validateaddress has new functionality related to P2SH-P2WPKH, so that doesn't fit under BIP173 support
< promag>
do we have any idea what are the top 5 of most called RPC
< gmaxwell>
it's very different for different users.
< gmaxwell>
getblocktemplate and listtransactions are probably the most common rpcs (for miners, and people getting payments, respectively)
< gmaxwell>
and then other than a few status things, I'd expect everything else to be basically insubstantial compared to those.
< promag>
gmaxwell: listunspent?
< gmaxwell>
I wouldn't expect listunspent to be called more than sendrawtransaction, which would be rare since we know that network wide there is only a certian amount of that.
< gmaxwell>
I don't think so-- at least if I understand it correctly. listtransactions should be atomic with the blockchain. If the chain reorgs you shouldn't get mixed data on transactions. An example of how this could result in funds loss, say I pay you with a transaction then doublespend it to pay more fees with another txn also paying you. If you see a reorg that goes from one to the other during a lis
< gmaxwell>
ttransactions, they you might see both payments as confirmed and credit the user twice.
< promag>
gmaxwell: it's still atomic
< promag>
sorting the output is done without the locks
< gmaxwell>
hm? is it copying all the data then? otherwise confirm counts and whatnot would get updated, no?
< promag>
i think so, AcentryToJSON
< gmaxwell>
oh I see how I was misreading it.
< gmaxwell>
okay thats plausable
< promag>
I guess this is easy to bench
< bitcoin-git>
[bitcoin] promag opened pull request #12330: Reduce scope of cs_main and cs_wallet locks in listtransactions (master...2018-02-listtransactions) https://github.com/bitcoin/bitcoin/pull/12330
< Franklin_>
does anyone have examples of cross chain atomic swap script(s) for onchain swaps?
< dafuq>
could someone who knows unix/linux possibly chime in on PR #12322?
< gribble>
https://github.com/bitcoin/bitcoin/issues/12322 | Docs: Remove step making cloned repository world-writable for Windows build. by murrayn · Pull Request #12322 · bitcoin/bitcoin · GitHub
< gmaxwell>
wumpus: I think the FD issue is likely fixed. I ran RC1 in valgrind and after a few minutes of running had a branch on uninitilized in socket close.
< gmaxwell>
I pulled up to master, compiled, restarted, and now hours later no such error.
< gmaxwell>
As suspected, an uninitilied close was closing random FDs.
< meshcollider>
That's good \o/
< bitcoin-git>
[bitcoin] murrayn opened pull request #12331: Docs: Properly alphabetize output of CLI --help option. (master...help_changes) https://github.com/bitcoin/bitcoin/pull/12331
< bitcoin-git>
bitcoin/0.16 f17942a Wladimir J. van der Laan: qt: Pre-rc2 translations update...
< wumpus>
rc2 coming up, please interrupt me asap if I forgot something
< wumpus>
so we have: fix for the fd issue (cfields, confirmed by gmaxwell above), fix for eternal retry of onetries (cfields), and fix for coin-control-bechs32-change (promag) in. I've updated the translations from transifex. Should be good to go.
< meshcollider>
wumpus: has anyone addresses sipa's validateaddress changes earlier, I ran out of time
< meshcollider>
Addressed*
< wumpus>
the only mention of validateaddress is in BIP173 support
< provoostenator>
Re release notes: "When launched with -addresstype=legacy it is unchecked and disabled." -> it's actually hidden.
< meshcollider>
provoostenator: oh ok, I got that from the PR description ;)
< provoostenator>
I changed it based on feedback, but probably forgot to update that part of the descrioption.
< meshcollider>
wumpus: ok that's a to-do then, move it out of the BIP 173 section and write about all the other changes that happened to it
< meshcollider>
I'll do it tomorrow, more of a mental note unless someone else does
< meshcollider>
provoostenator: that's all good
< provoostenator>
The behavior around (change) address types is currently spread accross several parts of the release notes. Maybe better to just have one section Address Types and discuss the various defaults, launch flags and RPC params there.
< wumpus>
provoostenator: right; I've lazily grouped the address changes under wallet changes, because that's where people will be looking for them. I know some non-wallet utility functions are also affected.
< meshcollider>
Btw wumpus it'd be cool if we added sjors to the github org, I mentioned it a while back and it got lost :)
< wumpus>
but explaining the types of addresses in a separate section wouldn't hurt
< wumpus>
I'm done editing the wiki for now, so if anyone wants to have a go
< provoostenator>
Being part of the github org is what gets you the T-Shirt, right?
< gmaxwell>
do mention 'bc1' when talking about BIP173 addresses, since thats how users will identify them.
< wumpus>
provoostenator: I'm not sure; maybe someone still has a stack of bitcoin core t-shirts from one of the real life dev meetings
< wumpus>
I do have a lot of bitcoin core stickers
< provoostenator>
I was kidding, but good to know there actually _are_ T-Shirts.
< meshcollider>
provoostenator: there'll be t-shirts at coredev apparently :)
< meshcollider>
wumpus: you should bring some stickers too then hehe
< meshcollider>
provoostenator: I assume the t-shirts look like John's one on twitter
< wumpus>
invited provoostenator for bitcoin and bitcoin-core orgs
< wumpus>
meshcollider:sure!
< meshcollider>
wumpus: can I join bitcoin-core too
< wumpus>
meshcollider: there is a photo from coredev zurich somewhere where almost everyone is wearing one
< wumpus>
meshcollider: oh I forgot that?
< meshcollider>
Oh nice!
< meshcollider>
Yah haha
< meshcollider>
Thanks :)
< provoostenator>
wumpus: received invite, thanks
< provoostenator>
"Uses of "µBTC" in the GUI now use the more colloquial term "bits". -> clarify that this is _in addition to_ uBTC, otherwise people might go mad without actually checking the app.
< gmaxwell>
hah I was annoyed before I got to the end of provoostenator's message.
< sipa>
a 100 megabit/s network connection sounds very expensive now
< * sipa>
computes
< sipa>
crap.
< gmaxwell>
lol
< meshcollider>
provoostenator: is it *always* in addition to, or sometimes? Because the code had like a "short" and "long" version
< gmaxwell>
somewhere some french altcoiners people are cacking at bitcoiners trying get everyone to measure their bitcoin in millièmebite.
< provoostenator>
meshcollider: sometimes. See the screenshots in that link. Dropdown menus show both terms, which is where it matters the most I think. But there's some places where it just says "bits" now.
< wumpus>
sipa: so does it always cost 100 megabit/s or is that just the channel capacity and based on use? :)
< meshcollider>
provoostenator: ah yep I see, cool
< meshcollider>
A megabit is 1 bitcoin?
< wumpus>
meshcollider: yes :-)
< gmaxwell>
now I'll at least remember what unit 'bits' is.
< meshcollider>
At least I can still do basic math then :)
< wumpus>
even 80's mobile data must have been cheaper
< provoostenator>
Yeah, nobody liked my idea of redefining 1 satoshi as 10^-9 BTC :-)
< gmaxwell>
provoostenator: is 10 nanobitcoin so hard to use?
< provoostenator>
And then just use kilosat instead of uBTC or bits
< meshcollider>
A satoshi is just 10 microbits
< provoostenator>
Say "That'll be twenty three nanobitcoin and three hundred third five picobitcoin please" 20 times out loud and I'll consider it.
< meshcollider>
brb, changing my twitter name to something like [NO BIP176][MIKES]
< provoostenator>
NaN nans please
< aj>
sipa: because "mils" isn't already used for enough different measurements
< wumpus>
provoostenator: standardizing SI units in common language would be awesome, but not my fight
< * wumpus>
likes sipa's suggestions
< wumpus>
nan bread
< sipa>
aj: oh?
< promag>
who loves univalue raise hand
< provoostenator>
There's also no point in standardizing these things when prices can change by an order of magnitude every year. If and when it becomes a unit of account, people will come with words for it.
< aj>
sipa: oh, mostly just still bitter over discovering that when an american says "mils" that's not a nickname for millimetres
< wumpus>
univalue?
< gmaxwell>
provoostenator: well I suppose it's poor form to complain that people are coming up with words with the argument that they'll come up with words. :) (or perhaps I misunderstood)
< provoostenator>
aj: they do for guns though, right?
< wumpus>
promag: oh, I think we were still in the context of units
< promag>
sorry for the interrupt :P
< meshcollider>
milliunivalue
< provoostenator>
gmaxwell: I think it's fine that people come with words. I mean there's not much use in "centrally" dictating those words.
< wumpus>
deprecate SI units and unify all units to, univalue!
< wumpus>
that's 100 univalue please
< gmaxwell>
promag: it was an order of magnitude speedup from jsonspirit as we were using it before, and eliminated problems with number mangling.
< aj>
provoostenator: yeah, as i understand it, guns and drugs, at the forefront of bringing SI measurements to the US
< sipa>
wumpus: yes, i wish people would learn SI units for daily life usage... but indeed, not something i'm going to waste my time on
< meshcollider>
Well sipa has his own unit, we could call uBTC the laan
< wumpus>
for a mass of 123 univalue of 100 univalue capacitors
< sipa>
also, as the SI unit for weight is the kilogram, should it not be millikilogram instead of gram?
< wumpus>
promag: we're basically its maintainers, feel free to optimize it
< provoostenator>
The nice thing about computers is that they allow standards to just exist in the background. Precise time measurement is crucial, but most people don't need to think in UTC because their phone handles the conversion.
< meshcollider>
sipa: unfortunately so lol
< aj>
oh no, not time measurement
< * sipa>
tries to reintroduce the beat
< provoostenator>
In fact, we could just go back to each city having a time based on where the sun is. Though coordinating meetings would be a pain without good tools.
< gmaxwell>
provoostenator: irony... considering that we have to hold our meetings here in UTC times to avoid having people witness multiple DST changes per year
< aj>
sipa: that'll improve morale
< gmaxwell>
(and at random seeming different times than their local dst changes)
< provoostenator>
Right, that's because coordinating meeting times is still generally done with words.
< meshcollider>
I prefer to measure time in microfortnights
< wumpus>
my preference is kiloseconds, megaseconds, gigaseconds
< sipa>
gigaseconds are kinda bulky
< wumpus>
do away with planet or solar-system-specific time units
< sipa>
few people see more than 3 in their lifetime
< gmaxwell>
provoostenator: the time can't be set in any timezone with dst regardless of how you communicate about it, because if it is, people in other zones will witness their own time change as well as the other one.
< wumpus>
agreed, it's a big milestone
< provoostenator>
DST needs to die.
< sipa>
wumpus: a *kilometerstone*
< wumpus>
sipa: oooh yes, sorry
< gmaxwell>
(since north and souther hemispheres dst in opposing directions, and US and europe on different dates)
< sipa>
wumpus: i think we should do everything in planck units
< wumpus>
sipa: yes, planck units would be even better, at least then we could stop using floating point/decimal and account all physics in discrete units in 128 or 256 bit integers
< wumpus>
also it's based on a constant of nature instead of an arbitrary human measure
< wumpus>
we're going to need larger SI-prefixes though
< wumpus>
fanquake: also pushed my sigs, you were first though!
< esotericnonsense>
hm. how much space should test_runner.py require? seems it can't run in tmpfs on my laptop (only has 2GB /tmp, got to 1.9GB then started giving space errors)
< esotericnonsense>
found the --tmpdirprefix switch. :)
< AndyS2>
Newbie to C++ and bitcoin core here. I've been looking at EvalScript in interpreter.cpp, and from what I gathered it seems to push things onto 'stack' or return an error if something isn't kosher. But when/where is the stack actually 'executed'. EvalScript doesn't seem to evaluate the script anywhere I could see.
< AndyS2>
And functions calling EvalScript didn't seem to immediately get to work on that stack, either, but I might have missed something
< achow101>
AndyS2: the stack is not something where code is executed. It is just a place to store data temporarily
< achow101>
Opcodes execute things typically by popping things off of the stack
< achow101>
those opcodes do not actually get pushed to the stack
< bitcoin-git>
bitcoin/master 7444149 John Newbery: Document method for reviewers to verify chainTxData...
< bitcoin-git>
bitcoin/master 85123be Wladimir J. van der Laan: Merge #12317: Document method for reviewers to verify chainTxData...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12317: Document method for reviewers to verify chainTxData (master...verify_chainTxData) https://github.com/bitcoin/bitcoin/pull/12317
< AndyS2>
achow101: you are right, I don't know how I could mis-read all that code. Thanks for the correction. So EvalScript is actually where the script is evaluated, and the name fits :)
< AndyS2>
I'll look at p2sh specialities later, thanks for the hint.
< esotericnonsense>
never mind DST. the fact that timezones don't change with latitude is absurd
< sipa>
esotericnonsense: iceland has no dst for a reason :)
< esotericnonsense>
it's more that spain is utc+1 and the UK is utc which is just odd
< esotericnonsense>
there is probably some historical reason
< esotericnonsense>
apparently it was for political alignment with central europe, heh
< BlueMatt>
weird, that would imply Shutdown() wasnt called
< cfields>
hmm?
< BlueMatt>
Shutdown() waits for the threadGroup to exit fully, and a long time ago due to some other bug I made sure Shutdown() gets acalled always in bitcoind shutdown, and I thought i did for qt too
< BlueMatt>
but I dont have a good understanding of how that works
< BlueMatt>
I assume you did a pretty quick shutdown and not a full init, cfields?
< cfields>
yes, just long enough to display the version#
< cfields>
BlueMatt: there's a note somewhere in init.cpp about aborting halfway through. Not sure if it's stale or not.
< cfields>
nm, not relevant
< BlueMatt>
not if you finish AppInitMain
< BlueMatt>
does anyone actually understand qt init/shutdown?
< cfields>
BlueMatt: I managed to grab the log, AppInitMain indeed doesn't finish. It caught the shutdown check at init.cpp:1578
< BlueMatt>
cfields: in bitcoind (and I was very sure bitcoin-qt) if AppInitMain ever *enters* it should still call Shutdown()
< cfields>
BlueMatt: yes, I see that for bitcoind. Looking at qt with you.
< BlueMatt>
hmm, it looks like maybe qt doesnt call Shutdown there, fucking qt/bitcoind init differences :(
< BlueMatt>
i guess quit() doesnt call shutdown() when called from initializeResult
< BlueMatt>
I'll wait for jonasschnelli or someone who knows how the fuck qt works to figure out how to fix
< cfields>
BlueMatt: yes, though I'm a few min behind you
< cfields>
BlueMatt: hmm. As a hack, I wonder if we can just add a "StartShutdown();" before every "return false" in AppInitMain
< cfields>
blah, we'd still have to get qt to wait on that, which is basically the same problem. nm.
< BlueMatt>
cfields: no, but we could change AppInitMain to { bool ret = AppInitMainReal(); if (!ret) Shutdown(); return ret }
< cfields>
heh
< BlueMatt>
but we shouldnt do that, we should fucking fix qt to actually have the same goddamned init/shutdown process as bitcoind, otherwise we're just keep going with this constant stream of init/shutdown problems on one or the other cause the person writing the code was only considering one or the other and assumed the other did the same thing
< BlueMatt>
cause....duh
< cfields>
looking at all of the qt shutdown signals, I'm afraid that would screw something up
< BlueMatt>
i mean we can do a different fix on master vs qt
< BlueMatt>
but lets see what someone who knows the qt init/shutdown stuff says
< BlueMatt>
err, vs 16
< cfields>
yes, agreed on sharing behavior as much as possible. Some is beyond our control, though.
< achow101>
so 0.16 rc2 is DOA
< cfields>
nah, I think we should urge people to test it
< cfields>
rc1 had a bug that was so bad that _any_ bug report would've been unhelpful. For rc2, there's just a unlikely, known, startup issue
< mlz>
what's the difference between "origin/0.16" and "v0.16.0rc2" and which one should i test?
< cfields>
miz: former is branch, latter is tag. You probably want the tag.
< achow101>
cfields: does the assertion always happen or just sometimes?
< mlz>
cfields, ok, thank you
< cfields>
BlueMatt: for 0.16, can we not just start the scheduler thread until last thing in AppInitMain? Surely nothing depends on it running in there
< cfields>
grr.. or does reindexing and crap rely on the callbacks?
< cfields>
achow101: I only ran it once, but it only triggered because I shutdown immediately
< achow101>
ah, ok
< BlueMatt>
cfields: hmmm, I dont *think* anything depends on it, but i was trying to keep the diff when compared to previously where the scheduler is started early low
< BlueMatt>
and at least that change is harder to audit
< BlueMatt>
achow101: it should always crash if you quit bitcoin-qt while its loading
< BlueMatt>
if it finishes loading you should be fine
< achow101>
is the issue present on master?
< cfields>
yes
< cfields>
BlueMatt: actually, starting the thread last-thing sounds like a good idea anyway. Exactly to ensure that the scheduler isn't used at startup.
< achow101>
is it windows only? I can't seem to replicate on Ubuntu
< cfields>
i'll track down potential users
< cfields>
achow101: testing bitcoin-qt ?
< achow101>
yeah
< cfields>
I don't see anything that would make it win only...
< cfields>
you should be able to force it by throwing a "return false" into init
< BlueMatt>
cfields: hmmm...I mean maybe? I dont really want to go read through everything that AppInitMain calls recursively to ensure that is actually the case, but if we want to do that for 17 it seems reasonable
< cfields>
achow101: at init.cpp:1576, s/fRequestShutdown/true/
< achow101>
cfields: nope, didn't work
< cfields>
achow101: hmm, not sure why
< achow101>
I'm trying rc2 now, instead of master
< achow101>
nope, not even that had an error
< cfields>
BlueMatt: i think i might see the issue
< cfields>
BlueMatt: BitcoinApplication connects requestedShutdown to shutdown(), but SplashScreen connects it to close()
< cfields>
so it looks like we should re-route that after AppInitMain has started