< luke-jr>
ah, with a function call to it from C++?
< luke-jr>
libsecpk251 is C89 IIRC
< cfields>
luke-jr: yea. That wasn't a real suggestion, though
< luke-jr>
oh, lol
< cfields>
randy-waterhouse: ^^. That doesn't change anything for libsecp256k1
< randy-waterhouse>
but the other dependencies now are all built using c++11
< cfields>
randy-waterhouse: the c++ ones are. The c deps don't change
< randy-waterhouse>
ah ok, lost sight of bigger picture
< sipa>
i wonder if compiling libsecp256k1 with c++11 would work (without any extern "C" { blocks, i mean)
< cfields>
sipa: yep
< cfields>
sipa: c++14, at least
< sipa>
ha
< cfields>
i played with it a while back to see what i could make constexpr
< cfields>
iirc there were 1 or 2 explicit casts needed, but nothing else
< sipa>
interesting
< * sipa>
used git rerere for the first time today
< cfields>
sipa: ah damn, i meant to remind you about that at last week's meeting
< cfields>
makes segwit rebasing a bit easier, i hope?
< sipa>
i'm not rebasing segwit
< sipa>
not until right before merge
< sipa>
plan is to just add fixup commits, and have a single merge with master commit at the end
< cfields>
oh, i figured you had a local branch that you were rebasing along the way
< cfields>
gotcha
< luke-jr>
sipa: I used to use git-rerere, but I found it too dangerous
< gmaxwell>
cfields: I don't think it's required, I think it's in an appendix.
< achow101>
would it be possible, for after segwit deployment, to have a command line option to have Bitcoin Core write blocks to the disk in the pre-fork block forkmat?
< gmaxwell>
achow101: it needs the data itself... the block files really aren't meant to be consumed by external software.
< achow101>
Yeah, I realize that and the situation is non-ideal. I just thought that it might be possible to prune the segwit data to maintain backwards compatibility with software like Armory
< wumpus>
jonasschnelli: FYI (reading your post in #7917) debug.logs compress *very* well
< jonasschnelli>
Right. Was to lazy.
< wumpus>
heh
< jonasschnelli>
At least i should enable mod_deflate
< jonasschnelli>
(for apache)
< wumpus>
right, that'd at least save bandwidth
< jonasschnelli>
Post #7165 means we can use C++11 features now? Right? Core will no longer compile on non C++11 compilers?
< gmaxwell>
I belive the goal was to avoid refactoring to use c++11 but to mostly use it in new code, so that things that we have to backport won't need to be rewritten, and so weren't not causing gratitious churn right now.
< sipa>
i wonder how much performance we gained :)
< jonasschnelli>
Hmm... is there no plan for removing the boost beast longterm?
< gmaxwell>
Absolutely, but not now.
< wumpus>
yes, we can use C++11 features now
< jonasschnelli>
So, new code will use c++11 foreachs old code still sticks with BOOST_FOREACH?
< wumpus>
and yes I'd suggest mostly doing so in the anicillary parts, not in main.cpp and other things that should be backported to 0.12 for segwit
< gmaxwell>
I think we shouldn't do any major refactors to use C++11 things until we're no longer supporting a non-C++11 release. (on top of the orindary desire to not have a lot of refactor disruption)
< wumpus>
using it in things that are new features in 0.13 anyhow is fine
< sipa>
i think converting sync.h to use std::thread would be fine, for example
< jonasschnelli>
gmaxwell: good point!
< sipa>
as it is very unlikely to conflict with anything
< sipa>
but yes, don't go all over the code to convert everything
< wumpus>
sipa: definitely, that is very unlikely to have to be changed for segwit, or anything backported
< gmaxwell>
self contained things... yep, new features. yep.
< wumpus>
so for the utilities and such: fine
< jonasschnelli>
Okay. Are there any c++11 features we should avoid? Like atomics?
< wumpus>
after segwit is merged to 0.12 I don't care anymore and IMO we can go full c++11 crazy
< wumpus>
(keeping in mind the risks that refactors always bring, of course)
< jonasschnelli>
Right. I agree with gmaxwell: As long as we support 0.12 (non C++11) we should not refactor to much
< wumpus>
I've arbitrarily set the minimum to gcc 4.7 and clang 3.3 in release-notes, don't know if they have atomics, it's open for discussion anyhow
< gmaxwell>
atomics aren't a replacement for proper locking... I don't know that we'd have that much use for atomics, but I am not aware of a reason to bar them right now.
< gmaxwell>
(like, for example, they might get used in the RNG.. but most places should just use conventional locking)
< wumpus>
right, definitely use convential locking unless there is a specific performance bottleneck where atomics wuld help a lot
< gmaxwell>
(because most of the time you need more complex data structures than atomics provide, and constructing safe data structures out of atomics is a bit rocket sciency for 99.999% of code)
< * sipa>
wants: auto, range for, rvalue references/moves, std::thread etc, nullptr, override, initializer lists
< wumpus>
code using atomics is usually even harder to review
< gmaxwell>
priorities should be changes that improve code safty, and changes that eliminate dependency on boost.
< gmaxwell>
once refactoring changes start.
< wumpus>
(unless it is for really trivial things like counters ...)
< gmaxwell>
wumpus: even with counters, you seldom have just one counter... :)
< wumpus>
right
< sipa>
for example for the debug=bench counters, atomics could be used i think?
< sipa>
all you need is += and get
< gmaxwell>
so long as you don't care if a print isn't mixing up data from seperate runs... for benchmarking its probably okay...
< sipa>
yeah
< sipa>
then again, they are currently just under cs_main and there is no reason to change that, as all the surrounding code also needs cs_main for now
< wumpus>
the debug=bench counters/accumulators are all used one at a time anyway afaik
< gmaxwell>
I've seen 'lock free' network stats code cause stupid failures in production systems, e.g. where there was a numerator and denominator, each updated atomically... and code that divided them and crashed with divide by zero because updating them indivigually atomically wasn't enough.
< gmaxwell>
sipa: also when performance matters, cacheline bouncing is _really_ expensive. atomics may not be a big performance win vs an ordinary lock... to get better performance: use per thread accumulators and infrequently merge them...
< wumpus>
jonasschnelli: it's a step forward - I do agree with marcofalke that what we really want here is a way to bring attention to the highest seq# transaction and 'grey out' the replaced ones. I'm not sure using the conflicts cross is the best way for that, it maybe looks to intimidating.
< wumpus>
(e.g. as if something is really wrong)
< wumpus>
but in any case your pull is a clear step forward
< sipa>
gmaxwell: aware (look at the crc code that you're running for me :p)
< wumpus>
better than showing both in the same way as waiting to be confirmed
< wumpus>
crc code?
< jonasschnelli>
wumpus: Right. I guess only RBF can result in a mempool conflict. So using a other icon should be fine.
< jonasschnelli>
Let me overhaul it.
< sipa>
wumpus: i'm benchmarking some crcs for a base32 address format :)
< wumpus>
sipa: have you seen https://github.com/laanwj/crcbench? (have been playing with crc instructions on aarch64 and sse42, and gmaxwell benchmarked on a few systems as well)
< JackH>
I know this is not the place for it, but could one of you help me out for a bitcoin-cli command I am struggling about? :)
< wumpus>
that's all for crc32c though as that's the one in leveldb
< jonasschnelli>
JackH: you are writing a new command (dev) or using a existing one (non-dev)?
< sipa>
wumpus: benchmarking how well they detect errors, not performance
< JackH>
what I want to do is to ./bitcoin-cli sendfrom but also include a fee. And I cant find any documentation on how to include both "sendfrom" and " settxfee ". The wiki doesnt explain it, and I am confused if I can type both commands on the same line?
< sipa>
JackH: settxfee modifies a global setting
< wumpus>
do the settxfee before the sendfrom
< sipa>
JackH: you need to run them separately
< sipa>
also, sendfrom will by default include a fee, based on estimations
< JackH>
ahh it modifies the global. So should I instead edit the .conf file and then do the sendfrom?
< sipa>
wumpus: latest development is a BCH code over GF(2^32) that guarantees detecting 4 errors with 6 base32 checksum
< sipa>
eh over GF(2^5)
< * jonasschnelli>
thinks we should probably add a optional feerate parameter to fundrawtransaction
< wumpus>
jonasschnelli: there isn't one yet?
< * jonasschnelli>
looking..
< wumpus>
I'm surprised, would be so much better than changing a global
< jonasschnelli>
no.. i don't think so. Maybe there is a PR.
< sipa>
there is a pr
< jonasschnelli>
Hard to keep track of everything. :)
< wumpus>
no, the PR does it wrong
< jonasschnelli>
It was an absolute fee IIRC
< jonasschnelli>
you pass in a feerate that one could determine with estimatefee
< wumpus>
... which everyone is trying to convince the author of that it's a bad idea, but he won't reconsider, probably going to close it soon
< jonasschnelli>
The ugly thing is, that CreateTransaction uses the static DEFAULT_TARGET
< wumpus>
passing in an optional feerate would be the obvious thing to do
< jonasschnelli>
So, this would require some refactoring.
< sipa>
just add a confirmation target to coincontrol
< jonasschnelli>
Yes. This sounds good.
< wumpus>
right, just slap it into coincontrol
< sipa>
wasn't there a PR that added a bunch of options to fundrawtransaction?
< sipa>
including that
< jonasschnelli>
Not the feerate.
< jonasschnelli>
But the rest is merged.
< jonasschnelli>
Which finally allows me to write my iOS Core Wallet client
< wumpus>
we have a bunch of options in fundrawtransactions, which is why I was confused
< wumpus>
yes that one was merged
< jonasschnelli>
(keep keys on smartphone, use watchonly core wallet, use fundrawtransactin, sign on the smartphone)
< wumpus>
jonasschnelli: nice
< wumpus>
sipa: how does that compare to standard CRC32?
< jonasschnelli>
It really made me thing that the wallet (in watchonly mode) is just a utility to keep track of user-(group-)relevant transactions.
< jonasschnelli>
like a selective tx-/address-index
< wumpus>
jonasschnelli: it is
< wumpus>
joinmarket uses it the same way
< sipa>
wumpus: a CRC32 isn't compatible with base32 (as it would produce 6.4 characters)
< sipa>
wumpus: i'm including a CRC30 though, and it seems to perform way better than the theory would predict
< wumpus>
sipa: ah right, get it now, output needs to be a multiple of 5 bits, not 32 bit
< sipa>
right, it's a checksum on base32 elements, so it takes a series of base32 tokens, and produces 6 extra ones
< wumpus>
instead of doing the checksum before the encoding, you do it afterward on the encoding itself
< wumpus>
I suppose that does make it easier to reason about the properties, yes
< wumpus>
and it's also slightly more convenient, no need to decode to check
< sipa>
indeed, though decoding base32 is sufficiently simple that it does not really matter
< GitHub185>
bitcoin/master 17a6a21 Wladimir J. van der Laan: qt: Make it possible to show details for multiple transactions...
< GitHub185>
bitcoin/master f135e3c Wladimir J. van der Laan: qt: Add transaction hash to details window title
< GitHub185>
bitcoin/master 574ddc6 Wladimir J. van der Laan: Merge #7939: qt: Make it possible to show details for multiple transactions...
< GitHub134>
[bitcoin] laanwj closed pull request #7939: qt: Make it possible to show details for multiple transactions (master...2016_04_qt_multiple_transaction_details) https://github.com/bitcoin/bitcoin/pull/7939
< Chris_Stewart_5>
"BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age,"
< Chris_Stewart_5>
Shouldn't 'input' be changed to 'output'?
< Chris_Stewart_5>
this is in BIP112
< kanzure>
for syncing an external application against bitcoind block history, i think getblock and _batch requests of getblockhash are the only options when receiving a blocknotify event, right?
< kanzure>
i was thinking about implementing a getallblockhashes rpc command. i'm hesitant though because i'm not sure why it doesn't already exist.
< kanzure>
the only other way to check if you are missing gaps of block history is by recursively calling getblockhash and getblock (starting from your last known best block) and ignoring the blocknotify parameter value. however, this is problematic for developers because they would have to also implement a "reverse" mode because if you run "getblock" from your last known block in some database then you will also have to go back in history in ...
< kanzure>
... the event of a recent reorg (e.g. maybe you had a stale block at your tip). this seems like more work than just working with a list of all blockhashes and comparing against your list of known blockhashes. right?
< kanzure>
alternatively: how much overhead is _batch rpc stuff in comparison to a single rpc call like a hypothetical "getallblockhashes"?
< wumpus>
pretty much the same
< wumpus>
the RPC batching functionality is severly underused, an example is contrib/linearize
< instagibbs>
wumpus, so, how do I use it
< wumpus>
it requests all the block hashes, though not in a way that copes with reorgs
< sipa>
that maintains a list of all blocks in a text file
< kanzure>
_batch 500,000 rpc requests for getblockhash is taking me like >10 seconds. wouldn't a hypothetical "getallblockhashes" take less than this? do we have an index in leveldb of all the blockhashes?
< sipa>
it also doesn't deal with reorgs, as it just puts all blocks there
< sipa>
kanzure: nope, in memory
< sipa>
:p
< kanzure>
in memory sounds good, that should be fast to dump over rpc
< kanzure>
yeah we should do this
< sipa>
sounds like something for the REST interface
< sipa>
actually, doesn't it already have that?
< sipa>
fetching a range of block headers
< kanzure>
range is incompatible with reorgs
< kanzure>
you can do range + confirmationwaitdepth i guess (where confirmationwaitdepth is your risk threshold for accepting deposits or payments or whatever)
< wumpus>
kanzure: until http streaming is implemented we don't really want anything that returns that much data
< kanzure>
wumpus: well, that makes sense, but in the mean time i'm not sure what applications are using...? calling getblock a few hundred thousand times is dumb.
< wumpus>
in the meantime just use batching
< kanzure>
but... it's slow.
< sipa>
kanzure: you only need to call it a few 100000 times at first startup
< wumpus>
REST is much faster than using getblock
< sipa>
kanzure: after that you just look at the tip, and go backwards to update your best known state
< wumpus>
saves the encoding overhead as first hex then JSON
< kanzure>
getblock isn't the problem, i'm using _batch with getblockhash only
< wumpus>
and you can pipeline requests on the same TCP connection
< wumpus>
also how many times do you expect to do this? is ten seconds really a problem?
< kanzure>
sipa: "go backwards" using getblock? i am "going backwards" using _batch getblockhash because i don't want to call "getblock" a few thousand times.
< kanzure>
wumpus: well i am getting socket timeouts... so yes. usually it does not take that long. but it varies. sometimes i am getting socket timeouts.
< sipa>
kanzure: i don't understand why you need to see all hashes
< wumpus>
increase your socket timeout
< wumpus>
it's the client that timeouts, never the server
< wumpus>
server won't timeout while it's working and not waiting for client input
< kanzure>
sipa: i don't need to see all the hashes, i agreed with you that a range is OK (like in the linearize script) plus/minus the number of confirmations that you feel safe waiting for, e.g. so that you can be reorg-compatible.
< sipa>
kanzure: no, that is not what i mean
< sipa>
kanzure: i mean you keep a list of hashes in your application; at block notify, you call getblockhash backward from the tip until you hit a hash you've already seen
< kanzure>
wumpus: correct. it's definitely the client that is timing out.
< wumpus>
kanzure: the default timeout is set to 30 seconds or so, that's not a lot, esp if you're batching
< wumpus>
instagibbs: linearize provides an example, I should also have a very simple proof of concept somewhere but can't find it right now
< kanzure>
sipa: i guess i could limit the getblockhash calls in my _batch request, to be (blockheight in database) minus (200 confirmations) or something.
< kanzure>
wumpus: is that server or client socket timeout default?
< sipa>
kanzure: i think using batching is overkill; just go one by one
< kanzure>
sipa: that takes a lot longer.
< sipa>
in almost all cases you just need 1 call!
< wumpus>
kanzure: I don't know, check for yourself
< wumpus>
(it depends on what client library you use)
< kanzure>
sipa: hmm okay. right.
< wumpus>
with python authserviceproxy you can simply specify it in the constructor
< GitHub114>
[bitcoin] laanwj opened pull request #7966: http: Do a pending c++11 simplification handling work items (master...2016_04_httpserver_c++11) https://github.com/bitcoin/bitcoin/pull/7966
< jonasschnelli>
why does CFeeRate has not setter?
< jonasschnelli>
Or am I missing something?
< wumpus>
it's just a value, if you need to assign a new value just assign a new CFeeRate(...) object
< wumpus>
no need to be able to change it partially
< jonasschnelli>
Right. But overloading = op. with a CAmount would be something. Not?
< wumpus>
I don't think that's necessary
< wumpus>
(sounds slightly confusing to me)
< jonasschnelli>
But right. feeRate = CFeeRate(new) is fine.
< wumpus>
better to be explicit
< gmaxwell>
Meeting time soon.
< jonasschnelli>
jtimon: meeting now.
< jtimon>
thanks
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Apr 28 19:00:11 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< kanzure>
i propose follow-up from last week re: segwit code review, and new/upcoming tasks on that front
< morcos>
i'm here for 10 mins
< kanzure>
gmaxwell: thanks for the ping
< jonasschnelli>
I have two very small topic proposals: wording for RBF, a request for creating/storing CI material
< gmaxwell>
morcos: anything you want to talk about in 10 minutes.
< cfields>
thanks, here
< morcos>
just to encourage anyone who is going to review segwit to get on it! :)
< wumpus>
action items of last time were a) more code review of segwit 2) kanzure: look at test coverage output 3) (Luke) update GBT segwit stuff 4) (jtimon) tutorial to enable travis on your own repo 5) (cfields) travis changes requiring some downtime 6) merge #7920 when cfields says so
< kanzure>
i have some segwit review notes but they are not precisely publicly consumable, can i get a volunteer to go through my notes? ideally not sipa :)
< gmaxwell>
What is the status of the segwit BIPs? are they all consistent with the implementation right now?
< kanzure>
wumpus: if i was supposed to look at test coverage output then i totally barfed on that, my bad-- i thought someone else took that.
< wumpus>
last two items are done at least, transition to trusty and c++11 was succesful
< gmaxwell>
\O/
< wumpus>
kanzure: yes the name is who suggested it, Idon't know the context
< sdaftuar>
kanzure: i'd be happy to review your notes
< kanzure>
sdaftuar: cool, i will spam you with them
< cfields>
jtimon: sorry, i got lost in the transition stuff
< wumpus>
jtimon: oh maybe he's going to, but he had a lot on his hands
< jtimon>
no hurry, just saying that I'm not working on that
< wumpus>
okay :)
< wumpus>
how is the review of segwit going?
< kanzure>
sdaftuar: you have been spammed, thanks.
< morcos>
wumpus: i'm feeling pretty good, but it's hard to tell who all has done deep commit by commit reviews
< kanzure>
topic suggestion-- how to convince sipa to give more context about testing status of segwit
< sdaftuar>
wumpus: i'm slowly making my way through
< wumpus>
morcos: good to hear that you're making your way through
< kanzure>
morcos: perhaps we should all post about our review status?
< cfields>
tangentially: I've finally started working with the mining pools (with Kang's help translating) to ensure that their real-world environments. Aim is to get at least one segnet block mined by each pool. Happy to report that last night, BTCC's patched pool mined a few blocks. I'll be working with the others in the coming days
< morcos>
cfields: oh thats great!
< cfields>
*segnet block with witness txs, ofc
< kanzure>
i have done a preliminary read of all the diffs for segwit but not commit-by-commit.... i have a number of places that i am considering investigating the test situation more closely but it's all probably dead-ends ( sdaftuar to advise ).
< morcos>
time for someone else to get some segnet coins, i have too many
< sipa>
i could list a few areas where i think mildly tricky things are done that warrant review
< kanzure>
yes please.
< wumpus>
#action (sipa) list a few areas where i think mildly tricky things are done that warrant review
< morcos>
sipa: in particular the areas that are new for me (such as the wallet/signing code) are harder to be confident about. i'd feel better knowing others are reviewing it as well
< sipa>
good to know
< kanzure>
signaturehash changes were specified by bip and one (trivial) review task is "confirm it follows the bip spec"
< morcos>
sipa: harder b/c of me, not b/c the code is tricky looking
< instagibbs>
morcos, maybe have people express review coverage with amount of certainty based on familiarity with the code
< sipa>
the wallet signing code adds a refactor to stop working directly on scriotsigs, but initially work on just the stacks being pushed, and only convert them at the last step
< instagibbs>
for me, review of wallet code was much easier than parsing the tree commitment stuff
< cfields>
kanzure: some input from other projects (NicolasDorier *poke*) may be helpful there.
< morcos>
instagibbs: i like that idea. not sure how easy it is to break up
< instagibbs>
that said, I read *every* commit, and attempted best-effort understanding
< sipa>
cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
< morcos>
ok got to run. overall, yay for c++11, yay for segwit!
< cfields>
sipa: ah, right. ack.
< gmaxwell>
I was talking to nickler about doing consensus harness tests for verifying consensus consistence, e.g. between 0.13 and 0.12.x or pre-segwit. Maybe there will be something to report there in a week or so.
< jtimon>
yeah, for example, I'm less familiar with the p2p and wallet parts, unfortunately I don't think I will be able to give a full utACK to #7910, but that of course shouldn't not stop it from being merged
< instagibbs>
jtimon, which brings me to my point, aside from sipa and a few others, I doubt anyone can full utACK #7910
< kanzure>
one of the things i'd like to investigate more closely is the set of tests that were written versus the expected set of tests... but hard to find all the corner cases.
< jtimon>
instagibbs: good point, the PR touches many parts. I think I will focus on the consensus and relay policy parts and only utACK that
< sipa>
also in general: what do people think of the strategy i've been following to not rebase/squash, but only add small patches and a changing merge commit at the end?
< kanzure>
sipa: i think that is a good idea. it gives us time to ACK various older commits.
< instagibbs>
jtimon, seems wise, people have to self-select what they feel competent to review
< sipa>
at some point i'll squash and rebase in such a way that the resulting tree id identical to the old broken down branch
< jtimon>
sipa: no strong opinion but it seems to partly defeat the point of having the commits separated in related sections (btw, I would separate p2p from consensus)
< kanzure>
tree id similarity is a nice approach....
< kanzure>
(git ls-tree and such)
< sipa>
jtimon: i'll keep the section
< sdaftuar>
sipa: some kind of warning before you squash/rebase would be helpful for me at least
< sdaftuar>
sipa: but i like how you've done it so far
< kanzure>
it would also be good if you could keep the original commits around on your git repo
< sipa>
kanzure: of course
< jtimon>
sipa: I see, so your question is more about squashing only once at the end, fine with me
< sipa>
it needs to be verifiable
< kanzure>
good, thanks.
< cfields>
sipa: you can just push to a spare branch before final squash, then we can diff the two
< jonasschnelli>
only add commits, once we have enough ACKS, hash the diff, rebase, check the hash of the diff and merge?
< sipa>
jonasschnelli: indeed
< wumpus>
ok next topic?
< wumpus>
#topic status of the segwit BIPs
< wumpus>
(gmaxwell)
< achow101>
bip 144 needs to include the service bit stuff
< wumpus>
everyone agree?
< sipa>
ugh, that was never uodated
< sipa>
yes, agree
< wumpus>
#action bip 144 needs to include the service bit stuff
< gmaxwell>
I suppose we should try to extract some feedback e.g. from roastbeef to reimplemented, who might be aware of other limitations in the spec.
< instagibbs>
roasbeef*
< petertodd>
just noticed someone has a python-bitcoinlib segwit branch too
< achow101>
armory does as well
< petertodd>
(sorry, just got in)
< wumpus>
petertodd: just in time for the python-bitcoinlib segwit branch!
< petertodd>
wumpus: ha yeah - no credit to me though :)
< wumpus>
#action (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
< sipa>
we have gotten some comments from a few people and making small clarifications frequently
< sipa>
including from tadge
< sipa>
i'm surprised nobody commented about the service bit
< achow101>
sipa: I think I brought it up a couple of weeks ago but didn't follow up on it
< sipa>
achow101: sorry then!
< instagibbs>
I can verify 141 and 143 match up
< wumpus>
great
< sipa>
small update: the reviewer that btcdrak contacted about ctaes wrote a report
< jonasschnelli>
sipa: the tor lead dev?
< sipa>
jonasschnelli: no, someone mathhew green recommemded
< sipa>
he formally proved that some parts were correct, and analyzed the condtant timeness
< jonasschnelli>
Okay. Good. What was the result?
< sipa>
i can share the reoort
< petertodd>
sipa: +1
< sipa>
a+ :)
< jonasschnelli>
sipa: Can you add it on your ctaes repository?
< wumpus>
awesome!
< cfields>
sipa: nice!
< sipa>
any more topics? i'll be off otherwise
< jonasschnelli>
RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
< petertodd>
jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
< jl2012>
bringing segwit testing to testnet?
< gmaxwell>
the former, I think. It's incorrect to say non-RBF is non-replacable; they're just somewhat less replacable.
< wumpus>
agree with gmaxwell
< jonasschnelli>
Okay. I agree as well. Will continue with this term.
< instagibbs>
'mempool-replaceable' ?
< petertodd>
doublespends happen all the time, and only a small subset of them are opt-in RBF txs
< wumpus>
but RBF transactions the user can easily replace themselves
< jl2012>
sipa: are we ready to define the testnet BIP9 parameter for segwit?
< wumpus>
that should be the focus imo
< wumpus>
what the user can do with it
< jonasschnelli>
instagibbs: I was also thinking about that. But does the normal bitcoin-qt user really knows what the mempool is?
< jtimon>
"standard-policy-0.12-replaceable"?
< jonasschnelli>
:}
< petertodd>
jtimon: all the user's node knowns is they think it's replacable, so the 0.12 is implicit :)
< wumpus>
yes the 0.12 is implicit, the BIP125 part makes sense
< jtimon>
yeah, 0.12 was kind of joking, the point is all tx are equally replaceable with a custom policy, the opt-in stuff is just about the standard policy
< petertodd>
don't we already have a bip125-replacable or similar name used in the RPC anyway?
< jtimon>
what was wrong about "Opted in to replacement" or something along those lines?
< wumpus>
any other topics?
< jtimon>
yeah, nv, "replacability signalled" does it
< jtimon>
s/nv/never mind
< jonasschnelli>
topic: another boring one, not sure if this is the right place: Someone contacted me that we should have a repository for Bitcoin Core logos and communication material.
< jonasschnelli>
Somehow that made me think that Bitcoin Core has no clear logo/visual identity. Its not define what to use when, the font, the colors. Not sure if anyone from us cares about that though.
< paveljanik>
press kit? ;-)
< petertodd>
paveljanik: +1
< jonasschnelli>
We probably don't care. But out userbase does a lot
< petertodd>
paveljanik: or maybe call it "media kit" to shift focus to all media in general
< jonasschnelli>
*our
< btcdrak>
jonasschnelli: a press kit would be a good idea
< wumpus>
we don't have that, but if anyone wants to make it and collect some things why not
< jonasschnelli>
It would imply that we first need to create a identity, proper logo, font, etc. I'm not interested ATM, but happy if someone know someone who is.
< btcdrak>
jonaschnelli: ideally we could store that in a "media kit" repository.
< jonasschnelli>
I think it should be a subarea of the website
< petertodd>
jonasschnelli: that makes sense
< wumpus>
yes I think the question is more *who* than if, I don't think press kits are very usual for open source projects, but if someone wants to work on that I don't want to discourage
< jonasschnelli>
Agree.
< sipa>
wumpus: they're very common among altcoins though :p
< cfields>
wumpus: for open-source, they almost always accompany a licensing policy
< cfields>
(lived through that hell for a while in a past life)
< wumpus>
cfields: yes, as for firefox
< cfields>
right
< cfields>
so for us, unless we wanted to police it, a press kit would be more of a collection of recommended images/text that we also use.
< cfields>
i suppose that was the idea, though
< wumpus>
right
< jonasschnelli>
Yes. There is even no clear logo that Bitcoin Core uses/represents.
< warren>
"\nExamples:\n"
< warren>
+ HelpExampleCli("getnewaddress", "")
< warren>
+ HelpExampleRpc("getnewaddress", "")
< warren>
Any idea why this has both, and they're identical?
< jonasschnelli>
warren: dumpprivatekey
< wumpus>
warren: we're in the middle of a meeting
< warren>
oops sorry!
< wumpus>
well, at the end
< wumpus>
I think we're done
< jonasschnelli>
\ö/
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Apr 28 19:55:37 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)