< gmaxwell>
aj: right, or get picked up as part of some other addition that needs an additional commitment.
< gmaxwell>
it can be done with 'external commitments' in the same manner as the proposed commited bloom filters... meaning that it's possible to implement the whole software stack, but not get a commitment from the blockchain for it (instead get it from semitrusted servers or what not).. probably a good way to go to work out the design.
< gmaxwell>
aj: why do you ask?
< aj>
gmaxwell: have been pondering a companion segwit-costs/risks page, and when reviewing the benefits page thought that one seemed mistaken now
< gmaxwell>
yea, it's out of date, when god knows who announced segwit would be done in design and implemenation complete in April it just didn't give any time to finalize a design... and better to have fewer commitments than commitments you regret. :)
< gmaxwell>
they same deployment approach could be used though, so basically a straightforward extension.
< aj>
yeah. i thought i remembered some other feature being mentioned that was implemented but wasn't in that list too. not coming to mind immediately though
< gmaxwell>
I don't think there was anything else.
< gmaxwell>
maybe the fact that pruned nodes could skip downloading stuff they wouldn't vakidate or keep? thats stull true though, commitment structure wise.
< gmaxwell>
maybe you were thinking of the n^2 sighash fix--- for a while that was implemented in the commitment structure but core wasn't making use of it to reduce the hashing, it does now.. however.
< aj>
gmaxwell: ah, my irc logs remind me that it was the fix for the "sighash single bug" -- but i'm not entirely sure what that bug is precisely
< gmaxwell>
oh? I don't really consider that much of a bug, it's just a surprising feature. It has some vaguely constructive uses, in theory.
< aj>
gmaxwell: i think it's that "if you use SIGHASH_SINGLE on an input with a higher index in a transaction than the number of outputs, then that signature can be used by anyone to spend any UTXO sent to that address", but post segwit it can only spend that particular coin?
< gmaxwell>
aj: thats not incorrect.
< aj>
haha, high praise
< gmaxwell>
for non SW txn an out of bound single causes to to sign the 32 byte value 1. For SW it just causes you to sign no particular outputs for that input.
< gmaxwell>
but you still sign the prevouts.
< Victorsueca>
gmaxwell: the how is it prevented that somebody changes the outputs?
< Victorsueca>
then*
< * Victorsueca>
wonders if he just asked the whole point of segwit and should read the docs instead
< gmaxwell>
Victorsueca: it's sighash single-- you're specifically flagging the signature so people can change outputs.
< Victorsueca>
OMG
< Victorsueca>
A wild bitcoin-qt.exe appeared
< Victorsueca>
it's finally compiled
< tulip>
neat, I now have 11 peers with NODE_WITNESS (but all inbound, less than ideal).
< gmaxwell>
4 on my bog standard host, all inbound.
< tulip>
that was on my bog standard host, too.
< luke-jr>
there's probably significantly fewer peers that they'll be willing to connect to
< tulip>
restarted the patched node and it managed 7/8 outbound peers as segwit, ha.
< luke-jr>
I thought it won't tolerate non-witness outbound peers at all?
< tulip>
in r1 you can end up with no NODE_WITNESS peers.
< tulip>
with #8949 you will continuously search until at least 4 as NODE_WITNESS.
< gmaxwell>
luke-jr: no, it makes 40 requests to addrman, and if it doesn't get any node_witness results, it gives up and uses a non-nodewitness one.
< luke-jr>
hm
< gmaxwell>
it turns out on mainnet there are so many non-nodewitness peers and such.. that it's pretty easy for it to get no node witness outbound peers at all, thus my PR.
< luke-jr>
what are things coming to, when we can't even find a witness peer anymore? :<
< luke-jr>
oh wait, that comment was meant for 2026, but this is 2016
< jl2012>
why 0.13.1rc1 binary is not yet released?
< jl2012>
aj: re SIGHASH_SINGLE: yes, BIP143 sort of fixed the bug
< jl2012>
or removed the unintentional "feature" of making a replay-able signature
< gmaxwell>
jl2012: in the past when we've encountered issues that would call for an RC2 before we shipped the RC1 binary we've sometimes just skipped it. I'm not sure if wumpus is planning on doing that.
< btcdrak>
jl2012: we are skippng RC1 because of the non version bump iirc
< jl2012>
btcdrak: it should be announced earlier so people won't waste time on building.....
< gmaxwell>
good practice? (sorry)
< wumpus>
it should be announced earlier so people won't waste time on building <- still makes sense to build to make sure that your gitian infrastructure is working an capable of building deterministic 0.13.1 executables
< wumpus>
also dependencies are cached by gitian so rc2 build will be faster
< wumpus>
and merging #8951 and tagging rc2 I guess
< wumpus>
anything else that needs to go into rc2 but doesn't have a 'Needs backport' tag?
< wumpus>
sipa: better question, do *you* sleep? You're still here afterall :)
< tulip>
wumpus: #8949 maybe? seems sort of critical.
< sipa>
8949?
< tulip>
"Be more agressive in getting connections to peers with relevant services."
< sipa>
wumpus: currently at the airport
< wumpus>
thanks added tag
< sipa>
wumpus: my comment is more aimed "8 hours ago you were merging/closing PRs, and now again" :)
< sipa>
i'm just hanging out on irc
< gmaxwell>
I expect 8949 to apply cleanly to 0.13 or nearly so, it's a trivial patch in any case.
< wumpus>
leave it up to rebroad to come up with lousy suggestions
< gmaxwell>
what PR?
< sipa>
8949
< gmaxwell>
lol
< Victorsueca>
morning
< wumpus>
I mean you're runnig a P2P network with decentralized propagation of node addresses, and what would you want to do, query centralized servers automatically periodically? :p
< wumpus>
morning Victorsueca
< gmaxwell>
better that he asked instead of submitting a patch "Improve DNSseeding."
< btcdrak>
yeah wumpus I replied to him
< wumpus>
true gmaxwell , very true
< gmaxwell>
had I added the skip I would have written a comment in the code that explained why it was there.
< gmaxwell>
perhaps I should have done so when editing that section.
< Victorsueca>
left 0.13.1rc1 running all night
< Victorsueca>
seems to work good
< wumpus>
gmaxwell: you could do it at the same time as the c++11 nit if you want, if not I'll just merge it as-is
< gmaxwell>
Victorsueca: do you have nodewitness peers?
< gmaxwell>
wumpus: Didn't know if we wanted the range based for. Okay, doing.
< wumpus>
13 witness peers on ereshkigal, two outgoing, rest incoming
< wumpus>
gmaxwell: yes,we do :)
< wumpus>
for new code, absolutely
< Victorsueca>
gmaxwell: have 4
< gmaxwell>
Victorsueca: inbound or outbound?
< Victorsueca>
3 outbound 1 inbound
< gmaxwell>
will push an update as soon as this compiles.
< wumpus>
going to kick my non-witness outbound peers until they're witness too :)
< Victorsueca>
wumpus: lol, you'll hardfork the network if everybody does that
< wumpus>
Victorsueca: I don't think so, I have plenty of non-witness inbound peers
< gmaxwell>
Victorsueca: nah, it won't partition due to inbounds-- SW is intended to be witness only on outbound.
< gmaxwell>
We don't want the topology to suddenly change when SW activates, if something goes wrong it's better if it goes wrong for people as they upgrade.
< gmaxwell>
and once SW is active we'll need to only fetch new blocks from SW peers.
< sipa>
Victorsueca: and if that actually happened, we could set up some proxy nodes to relay across (though that is an emergency only, obviously)
< wumpus>
Victorsueca: though, arguably if everyone did the same things as me it'd be a weird place
< gmaxwell>
yes, if there are any partioning problems as a result of some oversight there, the partition can be healed by even a single fixed node.
< wumpus>
it's somewhat working: gained one more outgoing witness peer
< gmaxwell>
I updated #8949 but did not rerun tests locally (laptop slow, took all that time to just compile it. :) )
< wumpus>
gmaxwell: luckily there's travis, and also if you just changes the loop type I'm not terribly afraid of that messing up :)
< gmaxwell>
just letting you know.
< sipa>
it's not like we're merging things and then immediately after marking it as release candidate
< sipa>
oh, wait
< btcdrak>
XD
< wumpus>
noo, we woudl never do something ill-advised like that
< Victorsueca>
lol
< gmaxwell>
maybe we should think about having a non-mandatory beta as part of the process. I noticed RC picked up a lot of testing pretty much instantly.. way more than what we had going on with 0.13 before it.
< wumpus>
non-mandatory beta?
< wumpus>
sounds intruiging, how do you suggest forcing people to install it :)
< gmaxwell>
hah I mean when we think were close to an rc, tagging something as 'beta' as inspiration to get people to switch their attention.
< wumpus>
oh, never mind, NON-mandatory. Boo.
< gmaxwell>
lol
< gmaxwell>
We only have mandatory fun.
< wumpus>
well the good news is that we can use the word 'beta' now in releases
< rebroad>
is testnet broken?
< Victorsueca>
if you think more testing is required then the beta release is pretty much mandatory
< wumpus>
as it's no longer a static part of the release naming, as it used to be
< gmaxwell>
rebroad: looks fine to me, can you be more specific?
< rebroad>
My node and my peers are al stuck on block 998938
< rebroad>
all
< rebroad>
have raised an issue for it
< gmaxwell>
rebroad: why are you saying they're stuck?
< rebroad>
based on their reported startheight and my last new best
< gmaxwell>
if your height is 998938 and all of their height is 998938 ... then perhaps you are all one big happy family.
< rebroad>
have been for over an hour now
< tulip>
receive version message: /Satoshi:0.11.0/: version 70002, blocks=1002280
< Victorsueca>
rebroad: have you considered the possibility that 998938 is the best block right now?
< gmaxwell>
it looks like the best block to me.
< tulip>
rebroad: that's pretty normal for testnet though, and even the main network, frequently there's no blocks for hours at a time.
< gmaxwell>
may just be no one is actively mining at the moment.
< rebroad>
I am seeing many headers for higher heights though
< Victorsueca>
maybe testnet is hard-forked
< gmaxwell>
Yes, and?
< Victorsueca>
that's why some nodes have a higher height
< Victorsueca>
there's nothing to do with that
< gmaxwell>
it has been for something like 6 months now, rogerver's "bitcoin.com" pool.
< rebroad>
why isn't my node sending getdata requests for headers that are new to the block index though?
< gmaxwell>
Not being sent by witness peers.
< tulip>
that's not really a good view to have as your first diagnosis. testnet is very frequently completely hosed, it's par for the course.
< rebroad>
unless proof of work is too low or something.. i guess more debug is needed
< rebroad>
AcceptBlockHeader returns true and AddToBlockIndex was called... but it needs more debug to debug
< Victorsueca>
"needs more debug to debug" -genius
< rebroad>
either it's broken or my understanding is wrong. probably the latter
< sipa>
rebroad: < gmaxwell> Not being sent by witness oeers.
< gmaxwell>
https://www.blocktrail.com/tBTC appears to be having fun, it's a non-SW testnet explorer and it seems to be jumping back in forth between different chains.
< wumpus>
we have a blocktrail contact
< gmaxwell>
pretty interesting to reload it and watch the block numbers constantly change but continue reading 1 hr 48m ago.
< gmaxwell>
may be nothing wrong there, I currently don't have any non-SW testnet nodes, but that chain may be flapping around in a reorg war.
< GitHub181>
bitcoin/master 9583477 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
< GitHub181>
bitcoin/master 4630479 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
< GitHub181>
bitcoin/master e44753c Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
< GitHub25>
[bitcoin] laanwj closed pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
< Victorsueca>
has somebody actually tried to fill a block over 1MB on testnet too see if the whole witness thing works and doesn't hard-fork the chain due to a invalid block size?
< rebroad>
MarcoFalke, how did you find that commit by jonasschnelli to fix #8970 so quickly?!
< wumpus>
search the current pulls / issues before opening a new one
< MarcoFalke>
out of memory :P
< MarcoFalke>
rebroad: I think it helps if "trivial" pull don't come in massive batches. If you see there is still a "trivial" pull open on your name, make sure to queue up additional ones locally.
< GitHub169>
bitcoin/master 59daa58 Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help
< GitHub169>
bitcoin/master b2df292 Wladimir J. van der Laan: Merge #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help...
< MarcoFalke>
You can submit a new one when the old one got merged.
< MarcoFalke>
or closed
< GitHub139>
[bitcoin] laanwj closed pull request #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help (master...gbt_help_update) https://github.com/bitcoin/bitcoin/pull/8951
< rebroad>
MarcoFalke, "locally"?
< MarcoFalke>
on your machine
< MarcoFalke>
in your .git folder
< wumpus>
MarcoFalke: interesting, why did the original change never get merged? it looks fine
< rebroad>
MarcoFalke, you mean some sort of "rate limiting"?
< MarcoFalke>
^
< MarcoFalke>
Jup, we have over 100 open pulls and there is lack of review.
< wumpus>
yes, rate limiting, to avoid DoSing other people
< rebroad>
MarcoFalke, to hold back branches on my end would create more rebase work for me. I tend to work in bursts, so the PRs get raised in bursts too.
< MarcoFalke>
Then wumpus has to go ahead and merge something and later on people complain that there are bugs in master.
< wumpus>
which is fine if the topics of the branches are wildly different
< btcdrak>
each comment, or action taken on the tracker mails 1230 people...
< MarcoFalke>
rebroad: But it seems you don't even compile the changes sometimes
< wumpus>
but if they are the same or simlar (e.g. change a log message) then group them or add them to an existing PR
< MarcoFalke>
Please make sure to put work in a pull before you send it to a thousand people
< MarcoFalke>
at least: compile, run tests, run python tests
< MarcoFalke>
Also, mention the motivation in the commit body or pull body
< MarcoFalke>
(I know I don't do it either, sometimes)
< MarcoFalke>
but it is good practice and helps review
< wumpus>
I don't think there's ever a good reason for one person to submit 8 pulls at once, I'm sure some are similar or part of similar intent
< wumpus>
working on 8 completely disparate things at the same time is beyond the scope of human memory :p
< rebroad>
MarcoFalke, I am sometimes guilty of not compiling after what looks like a very simple rebase... I do need to revise my workflow admittedly
< rebroad>
MarcoFalke, I am only just starting to familiarise myself with the tests.... do you mean "make check" or something else?
< MarcoFalke>
./qa/pull-tester/rpc-tests.py
< rebroad>
wumpus, "8 pulls at once"? why ever not?
< wumpus>
rebroad: so did #8972 solve your problem?
< MarcoFalke>
We need more people running the pull tester suite, anyway
< wumpus>
rebroad: because a) it comes over as horribly spammy, there are 120 pulls open by many different people, you're monoolizing the pull list with trivial stuff b) as I said above, if there's so many changes you must be able to combine a few as they will share a theme
< wumpus>
'shoot a buckshot at the codebase and see what sticks' is not a strategy for development
< wumpus>
at least not one that respects the time constraints and priorities of other people partaking in the project
< rebroad>
wumpus, how does it make any difference between raising 1 PR a day, and 7 only on Saturdays?
< wumpus>
please, dont' keep arguing this
< rebroad>
wumpus, you put forward an argument (based on false assumptions) and then complain when I correct those assumptions. I am not interested in hearing your rants.
< tulip>
for anyone following, there's progress on testnet now.
< wumpus>
ok, going to update the release notes lists and pulling in new translations and tagging rc2
< gmaxwell>
oops.
< gmaxwell>
backport is going to fail to compile.
< wumpus>
we'll hear from travis soon I guess
< gmaxwell>
net.cpp:1718:108: error: ‘nMaxOutbound’ was not declared in this scope if ((addr.nServices & nRelevantServices) != nRelevantServices && (nTries < 40 || nOutbound >= (nMaxOutbound >> 1)))
< Victorsueca>
RIP backport
< gmaxwell>
replace with MAX_OUTBOUND_CONNECTIONS
< rebroad>
Apologies for earlier. I need to learn to get less emotionally involved in my pull requests.
< wumpus>
we all do, np, it's kind of a stressful time and not a good time to pick fights now :)
< rebroad>
oh.. I didn't realise that? stress due to SegWit...? bitcoin related?
< btcdrak>
releases are always stressful. lots to get done.
< MarcoFalke>
rebroad: Also the pull request backlog
< rebroad>
ah ok. will bear that in mind. PRT (pre-release-tension)
< btcdrak>
ha!
< rebroad>
I am inclined to think of the backlog in the same way I think of my browser tabs. I have so many I struggle to keep track of them.. I do need to find a new system to organise them rather than a simple list as they currently are. Perhaps there might be a similar way to organise the issues - i.e. it's not the large number that's the issue but they way they are organised/sorted..?
< btcdrak>
rebroad: well the first thing we can do is be good citizens and consider the whole process - submitting a PR is just one part of the process. Think of reviewers and the effort they have to go through to verify and review. This is why grouping things is important. Etiquette starts from there.
< rebroad>
if there is anything I can do to help make the backlog seem less daunting, please do let me know
< btcdrak>
rebroad: review more PRs
< btcdrak>
review and _test_
< wumpus>
"error: use of undeclared identifier 'nMaxOutbound'; did you mean 'nOutbound'" eh, no thangs clang
< rebroad>
btcdrak, I certainly could do that, although it's hard to know which ones to review and test. is there an easy way to see which ones require greater attention or are the more useful/desired PRs?
< gmaxwell>
wumpus: yea, helpful compiler suggestions: Good news, your code compiles. You really didn't want that nice compiler static analysis to actually help you find bugs, right?
< btcdrak>
rebroad: right, so putting yourself in the POV of the reviewers is very good practice...
< MarcoFalke>
rebroad: Those tagged for 0.14, right now.
< rebroad>
MarcoFalke, ah... great starting point. thanks
< GitHub144>
bitcoin/0.13 53e6196 Wladimir J. van der Laan: qt: pre-rc2 translations update
< GitHub144>
bitcoin/0.13 0dbc48a Wladimir J. van der Laan: nMaxOutbound is MAX_OUTBOUND_CONNECTIONS on 0.13...
< rebroad>
has anyone else notices that the arrows point the wrong way in the peer table in the debug window? I've raised #8959 to fix this
< rebroad>
(the arrows to indicate sort direction)
< wumpus>
I haven't noticed, but don't think I've ever paid close attention to it so it's certainly possible
< Victorsueca>
you mean the ones on the table sort?
< rebroad>
Victorsueca, yes
< Victorsueca>
ahh yeah, I aalways felt weird when sorting that table, now I know why
< rebroad>
I wasn't sure if I fixed it in the best pace. the way I did it makes columns default to descending when you first click to sort them
< rebroad>
which is fine as descending is the more useful for most of the columns, IMHO
< rebroad>
an extra click to make it ascending, of course
< wumpus>
for things such as ping that makes sense, I guess, the only time descending is annoying is in text columns
< Victorsueca>
I think the arrow should be a bit darker to make it more visible, this is pure aesthetics tho
< wumpus>
that's up to your theme
< Victorsueca>
ahh windows theme
< Victorsueca>
but it seems to be rendered as text, why is it lighter than the rest of text?
< wumpus>
I don't know where qt takes the theme from on windows
< wumpus>
in any case it's not something that should be micro-managed, e.g. I have a theme that is pretty much black on black so marking the arrow *darker* would make it invisible :)
< Victorsueca>
that could be solved with a white outline
< Victorsueca>
but anyway, it's ok now, no reason to bother on that
< wumpus>
that's up to the theme, too
< wumpus>
some of the altcoins set up their own qt theme instead of using the system theme, but I think that's kind of pushy, no need to push your asthethic preferences to others
< Victorsueca>
yeah, dogecoin for example uses a funny typography
< tulip>
random would also have the weird effect of killing other daemons that try to bind to something after bitcoind
< gmaxwell>
wumpus: sounds great to me.
< Victorsueca>
what about random but exclude common ports?
< wumpus>
why would it kill other daemons?
< gmaxwell>
the special port would also allow more than labling, e.g. preferrential relay to HS peers.. which we can only do for outbound hs peers right now.
< tulip>
wumpus: say bitcoind came up, randomly chose 22, and then openssh tried to come up.
< wumpus>
I'm all for daemon-kiliing functionality in bitcoind, but arguably it should happen intentionally :p
< btcdrak>
is that everything now for rc2?
< gmaxwell>
tulip: it won't randomly choose 22. It will get some port over 32768.
< tulip>
gmaxwell: talking hypothetical, but ok.
< gmaxwell>
kernel reserves some range of ports for ephemeral use that is outside of the range normally used for services.
< wumpus>
I wonder if tor can create some kind of private, non-TCP socket
< wumpus>
anyhow that's not relevant to solving the issue, but for the far future would be nice list
< tulip>
gmaxwell: so there's privileged 1-1023, and >32768 for ephemeral. are there any other ranges?
< wumpus>
btcdrak: I think so!
< btcdrak>
wumpus: my gitian VM is ready!
< wumpus>
tulip: ranges are configurable and depend on the OS, although <1024 private is pretty ingrained (I think windows is an exception there?)
< gmaxwell>
tulip: not coming to mind. keep in mind these are local policy... there are sysctls to change them.
< gmaxwell>
yea, for a long time if you could get access to ports <1024 you could escilate to root access on other hosts that rhosts trusted your host.
< tulip>
I hate to think what caused that to be implemented.
< wumpus>
yeah rsh :-(
< wumpus>
* [new tag] v0.13.1rc2 -> v0.13.1rc2
< wumpus>
I guess that was a time in which the number of people having enough knowledge to circumvent that was so small that you could just trust them not to do it, sysadmin-inside-knowledge-based-access-control or so:p
< * Victorsueca>
starts compiling
< gmaxwell>
wumpus: yea, that time lasted about 10 minutes.
< * btcdrak>
starts gitian
< wumpus>
gmaxwell: yes I can't imagine it taking long. And after that the long period it was (mis)configured by default on some OSes
< btcdrak>
the node needs a witnesss protection program
< sipa>
bitcoind --aggressive=passive
< Victorsueca>
done building, now starting
< jonasschnelli>
[22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
< jonasschnelli>
Yes. Your probably right...
< jonasschnelli>
I don't have enough informations about the field-usage of IP transactions...
< jonasschnelli>
Better keep the code as it is
< arubi>
is it bad to symlink the database directory which is in datadir (contains log.0000000001 like files) to a tmpfs filesystem like /dev/shm ? It makes things like importing scripts and generating keys much quicker for me, e.g. initial keypool population takes 14418ms vs. 4236ms with the database dir in /dev/shm
< arubi>
I did (superficially with iotop) notice that a lot of writing is done to this log.0000.. file when I import many scripts, so this is why I ask.
< Victorsueca>
7 witness peers now, all outbound
< wumpus>
arubi: I don't know about berkeleydb specifics but having the wallet database crossing filesystem boundaries is reasonably dangerous
< achow101>
was rc1 DOA?
< wumpus>
arubi: also tmpfs is lost on reboot, which means you may lose data
< arubi>
wumpus, yea I'm aware about the second point. thought about copying it back to the hard drive periodically, but didn't take into account if bdb itself might not like it. I'll rtfm about bdb
< jonasschnelli>
BDB has some really strange way of storing data...
< wumpus>
jonasschnelli: yeah I wouldn't mind changing the 'transaction details' window if anyone has a good plan to do so, but this just seemed like ripping out a few things at semi-random, not sure either whether it would affect things such as watch-only or payment requests
< jonasschnelli>
wumpus: Yes. Indeed.
< wumpus>
with so many more urgent pulls open, it didn't seem worth the bother
< wumpus>
gah instead of building rc2 I re-built rc1
< wumpus>
achow101: yes
< wumpus>
it didn't have the version bumped and BlueMatt discovered a crash issue within a few minutes
< wumpus>
(probably in an RPC command that only he uses, but okay that's clearly a bug that shouldn't be in a release)
< wumpus>
fairly sure it was introduced in the refactoring
< jonasschnelli>
We should extend addnode's RPC tests
< wumpus>
yes
< jonasschnelli>
wumpus: The RPC command-structure refactoring (https://github.com/bitcoin/bitcoin/pull/8788) includes your JSONRPCRequestObj renaming now. Would be nice to get this in soon to escape the rebase-hamster-wheel
< luke-jr>
I still prefer 8775 :x
< luke-jr>
it's just ugly to have request.params everywhere
< wumpus>
I like request.params
< wumpus>
it's literally "request parameters", what naming could be better
< jonasschnelli>
I think request.param improves readability
< luke-jr>
params is clear and much shorter. but whatever
< jonasschnelli>
params is to generic and could be interpreted as local scope var
< luke-jr>
obviously when it comes to taste, majority rules, so if everyone else disagrees, just go ahead and do it
< wumpus>
yes it's a bit of a taste issue
< jonasschnelli>
Right. The important thing is, that we have a flexible container in the RPC command function structure.
< GitHub21>
bitcoin/master 23c32a9 Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
< GitHub21>
bitcoin/master 69d1c25 Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
< GitHub21>
bitcoin/master e7156ad Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
< GitHub131>
[bitcoin] laanwj closed pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
< BlueMatt>
tulip: yes, we havent addnode'd between the new fibre test network and your mining bitcoind :p
< wumpus>
jonasschnelli: darn now #7551 needs rebase again
< luke-jr>
:p
< wumpus>
I really think we should merge that one soon, it's been open for ages and he's been rebasing time after time and fixing load of nits after load of nits. And it has tests. I'm not convinced that it is bugless (it adds a lot of functionality) but it'd probably be better to merge it so it gets more testing.
< wumpus>
but it's very useful functionality that definitely needs to be in 0.14
< btcdrak>
BlueMatt: Lightsword, but he stopped mining yesterday to let cfields test out cgminer I believe.
< wumpus>
the branch prediction profiling makes local attacks (e.g. against the kernel) somewhat easier, ASLR is still a good measure against remote attacks
< wumpus>
also think function-level ASLR (selfrando) would make this harder to exploit, as you cannot just guess one offset and compute others from it
< wumpus>
haven't heard about using that at the kernel level though :)
< BlueMatt>
hey-o, fibre works on segwit
< BlueMatt>
look at that
< BlueMatt>
anyone need high-speed testnet blocks? :p
< wumpus>
awesome!
< BlueMatt>
even worked on the first try :)
< wumpus>
of course we need fast testnet blocks
< adiabat>
repost from wizards, but anyone know what's up with testnet3?
< adiabat>
seem to be 2 chains
< BlueMatt>
what about it?
< BlueMatt>
all my nodes ended up on the same chain when i synced them last night?
< BlueMatt>
adiabat: is classic forked off again?
< adiabat>
could be
< adiabat>
test.webbtc.com is where I can see another one, that's longer
< adiabat>
seems to diverge at 996198, but not sure why
< jonasschnelli>
wumpus: Yes. 7551 should go in soon. I gave it my tested ACK (tested pretty well), though, some comments where added/amend-changed afterwards.
< jonasschnelli>
sipa said he want to test it as well (before we merge)
< jonasschnelli>
I think we should merge it and fix (possible) issues later
< jonasschnelli>
but the rebase needs to be done
< jonasschnelli>
I guess 8788 will lead to plenty of rebases
< tulip>
adiabat: BlueMatt: 00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 is my chain and is valid with 0.13.1. I don't know why webbtc is showing a different one, I noticed that before.
< tulip>
I have >30 peers connected to that node, 11 of which are NODE_WITNESS. if there's a peering problem it's unlikely to be mine.
< GitHub135>
[bitcoin] jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
< GitHub183>
bitcoin/master 37aefff Matt Corallo: Fix init segfault where InitLoadWallet() calls ATMP before genesis
< GitHub183>
bitcoin/master c587577 Wladimir J. van der Laan: Merge #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis...
< GitHub121>
[bitcoin] laanwj closed pull request #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis (master...2016-10-fix-segfault) https://github.com/bitcoin/bitcoin/pull/8928
< goatpig>
is someone trolling the testnet?
< btcdrak>
goatpig: what do you mean?
< goatpig>
someone pointed me to a 4k long fork
< goatpig>
got me thinking
< rabidus_>
how did your software manage that? :P
< goatpig>
no idea, someone showed that to me
< goatpig>
so, say i create a SW anyone can spend output
< goatpig>
mine it
< goatpig>
spend it
< goatpig>
that would fork the chain for any 0.13 testnet node
< goatpig>
but 0.12 nodes would see it as valid
< goatpig>
say I throw in a couple asics and mine the hell out of that fork
< goatpig>
I could maintain a testnet fork for a wihle, right?
< arubi>
it really doesn't matter what you do. sure the partitioning of post fork and pre fork nodes is obvious, but that's any soft fork. you're really fighting hashpower, which is what pow is about
< goatpig>
im trying to figure out if someone could pull that out on the testnet
< goatpig>
im not concerned about the mainnet because, precisely because of the hashpower competition there
< arubi>
you could probably do that on testnet, sure