< wumpus>
cfields: no particular reason, that was just the simplest to do, and every proxy seems to support it
< wumpus>
cfields: really don't want DNS leakage so we don't aim to support proxies that cannot support connecting by name
< wumpus>
of course if you already have a ipv4/ipv6 address (say, from the P2P network) you could pass that directly instead of converting it to a name, I considered that at some point but gave up, not enough reason, some chance it may break things with some proxies, etc. There's .onion to contend with for example which we rolled into IPv6 but really need to pass as name to the proxy.
< wumpus>
converting it to a string*
< wumpus>
tl;dr. it was done because it fitted most easily into the current code, feel free to do it differently in a re-implementation, but don't do any host-side DNS queries when a proxy is set,ever
< jonasschnelli>
sipa: gmaxwell: p2p encryption: you said the ECDH secret should go into a PRNG. Wouldn't this require a custom PRNG implementation (something like the fortuna PR) to get the same result on both sides?
< jonasschnelli>
What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
< jonasschnelli>
SHA512_hmac from both pubkeys (or the requesting pubkey), use the ecdh as SHA512 mac
< jonasschnelli>
wumpus: how do i pass a -g into the gitian build? Just a -g for the ./gbuild command?
< jonasschnelli>
or do i need to change the descriptor?
< sipa>
jonasschnelli: sha512 and ecdh are not macs
< sipa>
jonasschnelli: yes, you need a fixed PRNG... i shouldn't have used the name PRNG though - just something to derive keys in a deterministic manner... i would suggest encryption_key = HMAC(key=ecdh_output,msg="encryption key"), session_id = HMAC-SHA256(key=ecdh_output,message="session id"), ...
< sipa>
jonasschnelli: i've been playing with chacha20-poly1305, and it's so fast... ~5 cycles per byte or so
< sipa>
i don't think i can get aes128-gcm below 80 cycles per byte without using assembly
< sipa>
in theory, aes128-gcm, on very modern hardware should be doable in ~1 cycle per byte, with aes-ni and carryless multiplication instructions
< sipa>
jonasschnelli: if we just copy chacha20-poly1305 from openssh (it's very simple code, and fast), it needs 2 256-bit keys (one for encrypting the sizes, one for encrypting and authenticating the data)
< jonasschnelli>
sipa: Thanks. Your HMAC make sense and is already possible with our codebase.
< jonasschnelli>
sipa: I think I drop the AES-GCM cipersuite in the BIP any only cover chacha20-poly1305
< jonasschnelli>
(still allows AES256-GCM in a later BIP update or another BIP)
< sipa>
our current sha256 implementation is around 16 c/b, so using chacha20-poly1305 would actually be faster than our current checksumming
< wumpus>
jonasschnelli: just change the descriptor
< sipa>
jonasschnelli: or HMAC-SHA512, which we already have, and can provide larger keys at once
< wumpus>
jonasschnelli: I'm not exactly sure how I did it last time, wouldb e nice if we had a more structured way of doing this, or even better, have the build produce external symbol files for gdb by defalt
< wumpus>
I think I just added CPPFLAGS="-g" to CONFIGFLAGS
< wumpus>
(which is a hack, but CPPFLAGS are passed to both g++ and gcc, without overriding the current C*FLAGS optimizations etc)
< wumpus>
jonasschnelli: oh I remember! no i didn't even do that last time - i just replaced install_strip with install. This won't give full line number information, but at least basic symbols, which could be enough (and is guaranteed not to change the binary otherwise)
< jonasschnelli>
wumpus: thanks. Will try. What speaks again releasing with symbols as long as we are bellow <v1.0?
< wumpus>
jonasschnelli: it'd waste a lot of space - remember we're static linking every executable, and have quite a lot of executables
< wumpus>
(and static linking gives lots of symbols, for every executable you have all the dependency symbols as well - and c++ symbols like from boost are huuuge)
< jonasschnelli>
Right. 7770 makes sense!
< wumpus>
talking about executables, it doesn't make a lot of sense to package bench_bitcoin and test_bitcoin-qt, but that's a whole other issue :)
< wumpus>
packaging the main test_bitcoin makes sense to check the tests on the specific OS/platform combination, but those two don't add much
< jonasschnelli>
Indeed. Lets remove those.
< wumpus>
CodeShark: I remember you were planning to use bitcoin core's rpc system in another project - you may like https://github.com/bitcoin/bitcoin/pull/7766, it removes further bitcoin-specific logic from rpc/server.cpp
< wumpus>
jonasschnelli: not sure what the best way would be - either deleting them in the gitian descriptor before packaging, or changing the build system to not install them in the first place
< wumpus>
probably the first is best, other distributions may want to make their own decision about what to ship
< wumpus>
OTOH they don't need to get built either
< jonasschnelli>
wumpus: Yes. We might need to set two different test level, so we could distinct over ./configure which test should be built and installed.
< CodeShark>
wumpus: yeah, that's a good idea
< CodeShark>
is it pretty safe to say CSV will be merged in the next couple weeks?
< btcdrak>
sipa: some of us can't survive with vim :-p
< wumpus>
it's free for open source projects so why not
< wumpus>
I'm happy with vim myself
< sipa>
ah, i see
< sipa>
it would license anyone to use it for the purpose of developing bitcoin core?
< wumpus>
I think we get a limited number of licenses, to be distributed over people developing bitcoin core
< wumpus>
the license allows using it for developing any open source software
< btcdrak>
sipa: yes. Personally, I love the IDE and debugger features.
< btcdrak>
API autocomplete in itself is gold for me.
< sipa>
btcdrak: i've used Eclipse a long time ago (including CDT), but had no problem going back to a text editor for other projects
< btcdrak>
sipa: I was an Eclipse fan until I discovered JetBrains. They are remarkably good.
< wumpus>
I tried to like eclipse very hard, i really did, but it never stuck with me. All the features are awesome, but it feels too slow and heavy.
< kinlo>
vim ftw :p
< sipa>
mcedit!
< wumpus>
it's like an OS in itself. I'm old-fashioned and just like opening the editor on separate files
< * sipa>
hides
< kinlo>
sipa: heh, I actually use that aswell, you're an mc user?
< sipa>
yeah
< kinlo>
sipa: there aren't enough mc users in this world :)
< wumpus>
I used 'joe' editor a long time
< sipa>
i like bluescreens
< sipa>
;)
< kinlo>
haha :)
< wumpus>
but it's no longer maintained, and at some point someone convinced me to use vim, which has a lot more plugins and syntax highlighting etc available. And I'm kind of happy with it. Though most of the true hard-core vim-golf tricks elude me.
< btcdrak>
Sublime is fun.
< jl2012>
if i want to return the size and hash of every txs in the blockchain to log during block validation, where should i do it? main.cpp?
< wumpus>
yes, sublime is nice too, I used sublime 2 at a job for a while. At least it's simply an editor and not en IDE monster :)
< wumpus>
jl2012: why would you want to do that during validation, and not do a after-pass using getblockhash and getblock verbose=true to get all the txids??
< wumpus>
in any case if you want such logging, ConnectBlock is probably the best place, where it checks the transactions in the block for consensus
< jl2012>
wumpus: just for studying purpose. Logging of fee of each tx, for example, could also be done in ConnectBlock?
< jl2012>
I'm self-learning C++
< wumpus>
yes, I think so, it should have all the information available there
< jl2012>
thanks
< wumpus>
the fee/block reward computation should also be somewhere areound those parts
< sipa>
so the naive uint32-based chacha20-poly1305 implementation from OpenSSH, compiled at -O2, needs 8.6 c/b for chacha20, and 2.8 c/b for poly1305... that's faster than sha256 or naive variable-time AES
< wumpus>
wow
< wumpus>
obviously that's not fast enough and we should do an asm implementation *ducks*
< sipa>
AES-NI + CLMUL based implementations can do AES-GCM in 1 c/b; without those, 22 c/b, without SIMD, 35 c/b
< sipa>
wumpus: i just realized! we only compute the p2p message checksum before sending it, or after receiving it entirely; for a 1 MB block message, that means an unnecessary 5ms delay on both sides!
< sipa>
on the sending side, that's inevitable, as the checksum goes before the actual data
< sipa>
but on the receiver side we could in theory compute it while receiving the data, in the network thread
< wumpus>
sipa: right, for receiving we could certainly use a CHashWriter there
< sipa>
not that it matters much for 1 MB messages, but it does indicate that there is a downside to having large p2p messages
< wumpus>
for sending all the data is processed at once anyway
< sipa>
if the checksum was at the end, it could in theory be computed by the networking thread during sending, which is usually not loaded
< wumpus>
well the networking thread receives messages entirely right? so it could still do the computation there
< sipa>
no the networking thread receives whatever recv() returns
< sipa>
the message handler receives entire messages
< wumpus>
just leave it blank initially then fill it in before sending it to the wire
< wumpus>
no, I'm talking about sending
< wumpus>
messages could be queued up without checksum, then the network thread fills in the checksum before actually dispatching them on the wire
< sipa>
that doesn't change the latency, but it can take some load of the message handler thread, indeed
< sipa>
*off
< wumpus>
well, sure, there's a good point for adding the checksum at the end
< sipa>
jonasschnelli: ^
< wumpus>
and using a cheaper to compute one in the first place
< sipa>
jonasschnelli: in the encrypted p2p protocol, the authentication tag (produced by poly1305) goes at the end :)
< wumpus>
also I agree that there is a downside to having very large messages, it may make sense to divide up realy big data into multiple messages at some point and stream them
< wumpus>
(also because of memory usage and buffers)
< sipa>
indeed
< * jonasschnelli>
is back at keyboard and reads backlog
< sipa>
jonasschnelli: yup, after the crypted message, so that the sender can compute it while sending, instead of computing it before any send can occur
< jonasschnelli>
sipa: so using poly1305 as mac (hash replacement) would make the transmission process faster because chacha20+poly1305 requires less cycles then sha256?
< sipa>
jonasschnelli: yup
< jonasschnelli>
That is an argument.
< sipa>
or rather: naive implementation of chacha20+poly1305 is faster than naive implementation of sha256
< sipa>
both can be made a small multiple faster with SIMD code etc
< * jonasschnelli>
is looking over to wumpus asm skills...
< sipa>
i'm not saying we should do that
< sipa>
but it's not fair to say "algorithm X is faster than algorithm Y" without qualifying what kind of implementation you're talking about
< jonasschnelli>
SIMD?
< jonasschnelli>
Yes.
< jonasschnelli>
sipa: you said: "it needs 2 256-bit keys (one for encrypting the sizes, one for encrypting and authenticating the data)" Whats the purpose to encrypt the "sizes"?
< sipa>
jonasschnelli: because the sizes leak privacy
< sipa>
if you observe an ingoing message of a certain unusual size, followed by output messages of the same size to several peers, you may be able to distinguish transactions and trace them
< jonasschnelli>
sipa: but by analyzing the stream you could still get the encrypted chunk/message sizes,... or would it then allow padding of random data while knowing the size only when you can decrypt?
< sipa>
jonasschnelli: sure, stream analysis may still leak information, but leaking sizes is just giving away potentially private information without reason
< sipa>
jonasschnelli: read the link to openssh's document about it
< jonasschnelli>
sipa: thanks. Will check it. I guess you pass in a int32 into chacha20 and get a "encrypted" int32 back while providing a sizes key?
< jonasschnelli>
howevery,... i need to check the openssl docs first.
< sipa>
OpenSSH, not OpenSSL
< jonasschnelli>
arg. right.
< sipa>
jonasschnelli: yes, chacha20 is a stream cipher, so it can encrypt things of any byte size
< sipa>
without expanding them
< sipa>
it's essentially just xoring the data with the output of a deterministic PRNG
< sipa>
which is seeded by the key
< jonasschnelli>
sipa: what do you think about an approach where each message could contain arbitrary pseudo-random data padded?
< sipa>
sure
< sipa>
that's orthogonal, i think
< jonasschnelli>
Yes. I just wondered if it would make sense to mention in the BIP. But agree,... has nothing to do with the encrypted sized.
< wumpus>
instagibbs: you can even do --run-test=suite_name/test_name
< sipa>
ha!
< sipa>
i had tried various separators, but not /
< wumpus>
stumbled on it by accident too
< instagibbs>
heh, I should probably write this up as PR for the testing doc
< wumpus>
just grepped it, we somehow already documented this in test/README.md
< wumpus>
never know
< wumpus>
knew*
< instagibbs>
wah, I just read the document, didn't see it?
< instagibbs>
maybe an old version
< wumpus>
so many things I forget most of it
< instagibbs>
oh i see, doc/unit-tests.md doesn't mention this
< instagibbs>
that's what I found and read
< wumpus>
may make sense to combine them
< paveljanik>
jonasschnelli, in the GUI, after using the autocomplete in the console tab, what do you have in the entry line?
< jonasschnelli>
paveljanik: what do you mean with "after"?
< paveljanik>
get cursor down, Enter
< paveljanik>
type get, ...
< jonasschnelli>
Yes. It keeps the command...
< jonasschnelli>
hmm...
< jonasschnelli>
until i send it again,... than its gone.
< jonasschnelli>
Needs fixing...
< paveljanik>
yup
< paveljanik>
I'll have a look once I finish the rest.
< jonasschnelli>
Why I did not recognized that in the first place...
< jonasschnelli>
paveljanik: super. Thanks. Should be easy to implement.
< paveljanik>
How can I create immediatelly abandonable transaction so I can test #7707 now?
< jonasschnelli>
paveljanik: set -walletboardcast=0, create a transaction, restart
< jonasschnelli>
then you can abandone
< jonasschnelli>
*abandon
< paveljanik>
jonasschnelli, restart with -walletboardcast=0 again? Probably yes. Still grayed Abandon transaction in the UI
< paveljanik>
ah, boardcast :-)
< instagibbs>
btcdrak, once csv cherry-picks are validated, what's the speed at which a release comes?
< instagibbs>
s/speed/process
< btcdrak>
instagibbs: I am not the release manager, but my understanding is that once #7648 is merged, we can merge #7543 (the 0.12 backport). And #7543 is the only PR pending for 0.12.1 release cycle that I am aware of.
< instagibbs>
I suppose since it's directly off of 0.12, it doesn't require a long freeze period, etc
< instagibbs>
enough time for RCs
< btcdrak>
instagibbs: we discussed the contents of 0.12.1 a few meetings back, so basically we're good to go once #7543 is merged.
< GitHub114>
bitcoin/master 478fba6 BtcDrak: Soft fork logic for BIP113
< GitHub114>
bitcoin/master 02c2435 BtcDrak: Soft fork logic for BIP68
< GitHub193>
[bitcoin] laanwj closed pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (master...vb_68_112_113_1) https://github.com/bitcoin/bitcoin/pull/7648
< btcdrak>
omg boat party!
< Ylbam>
\o/
< wumpus>
o/ \o
< gmaxwell>
Is there a reason we can't get all these IsSuperMajority checks? they're kinda slow. There are 6 of them used in accepting a header right now.
< wumpus>
there have been pulls in the past replacing at least one of them with a fixed height. No idea what happened to it, or why it isn't merged.
< sipa>
it was merged for BIP34
< sipa>
not for later ones
< wumpus>
ok
< wumpus>
in any case there is no pressing reason why they couldn't go
< ZerownZ>
hahaha
< cfields>
wumpus: thanks for the explanation, that was very helpful
< GitHub76>
bitcoin/0.12 ba80cee Wladimir J. van der Laan: bump version to 0.12.1
< morcos>
btcdrak: sipa: yeah the remaining thing we were hoping to get in 0.12.1 is #7568... unfortunately that still doesn't have much review... i suppose we could get that backported in time for 0.12.2, but it would be nice to expedite. sorry for not reviewing myself
< btcdrak>
morcos: actually, since these are master, it seems unlikely these could be reviewed and backported in time for 0.12.1
< morcos>
btcdrak: we don't want 7707
< morcos>
we already got the commit we wanted, jonas broke it out separately
< btcdrak>
morcos: ah
< btcdrak>
oh right I cant read "#7707 RPC-only (commit 42e945d79fd54ab11ad48978910b42d10c1c7cf8), which is 1 line of code."
< btcdrak>
yeah, so #7568 wont happen in time. We should consider disabling the warnings instead.
< morcos>
7568 would have been very nice, but we all dropped the ball on that. the existing false positives on alerts are terrible, especially with the upcoming slew of soft and hard forks, having a more functional alert system is important
< btcdrak>
as it stands, with so many false positives, the longer they are giving false positives, the more they will get ignored into the future.
< morcos>
i'd be more in favor of properly reviewing 7568 than trying to rush in some other half ass solution such as disabling them
< btcdrak>
morcos: not on our timeline.
< btcdrak>
that's a basically unreviewed PR in master. It would need to get review, merge and backport. We have to start a 0.12.1 release cycle soon. since the QA process is laborious as it is for release, we just dont have time unless we let it slip. The 0.12.1 is suppose to be released well in advance of the May 1st start date for counting CSV signalling.
< morcos>
i know!
< morcos>
honestly its a bit tricky to think about and review for correctness, but its not much in the way of code changes, and it seems highly likely to not be WORSE than what we have now.
< morcos>
i'd vote that sipa reviews it for 10 mins and decides that its got a very high liklihood of being an improvement and we just merge and call it a day. :)
< morcos>
i will try to look at it in the next 24 hours... but i do agree that we can't hold up 0.12.1
< morcos>
we suck though if we can't do something about these wonky alerts.. this is exactly what we need to be building into the installed base to make things safer in the future
< wumpus>
<morcos> i'd vote that sipa reviews it for 10 mins and decides that its got a very high liklihood of being an improvement and we just merge and call it a day. :) <- for master that'd be totally ok, for a backport I do think the bar should be higher
< wumpus>
but sure, even if sipa were to look at it for 10 minutes that's better than nothing :D
< GitHub0>
[bitcoin] paveljanik opened pull request #7772: Clear the input line after activating autocomplete (master...20160330_completer_clean_input_line) https://github.com/bitcoin/bitcoin/pull/7772
< morcos>
wumpus: yes i agree in principle, its just that the current situation is bad.. and i'm pretty optimistic that 0.12.1 will be upgraded too widely.. but its not 100% clear what happens after that, so would be nice to have alerts working as well as reasonably possible in short notice.
< wumpus>
yes you could say that the current handling is so bad that everything is an improvement :)
< morcos>
right, all we have to do is be confident it will alert LESS often, and its an improvement
< wumpus>
and at least if we can rule out that it causes crashes or reversions outside the immediate area of chain-alerts
< morcos>
terrible way to code a project though... incremental improvements without caring that they are right... :) its like monkeys typing shakespeare
< wumpus>
yes, to be honest I'd rather disable the code until we get it right
< btcdrak>
wumpus: +1
< wumpus>
at least on major releases, in master we still have quite some time until a release
< btcdrak>
disable for 0.12.1, then if we fix it properly in master, we can backport it to 0.12.2
< wumpus>
that sounds like the responsible thing to do
< morcos>
well lets give it 24 hours, til the meeting, if it gets reviews, then we can merge, if not we can decide what to do
< morcos>
disabling sounds like its also bad to me, thats still a code change to be merged
< btcdrak>
disabling is easy code though.
< wumpus>
it is a very predictable and safe change
< wumpus>
in any case let's say that if we can unequivocably decide that 7568 is an improvement that makes it worth keeping the system in the next 24 hours then we'll merge and backport that, otherwise we'll disable it in 0.12 for now
< morcos>
roger. paging sipa. :) ok got to run
< wumpus>
yes, gtg in a bit too. later!
< sipa>
wumpus, morcos: i think it's an improvement and technically correct, but the logic is a bit hard to read, and meni brings up good points
< gmaxwell>
Meni's point is really good.
< gmaxwell>
I think we _must_ reduce the false positives ASAP, even if it means turning off the functionality.
< gmaxwell>
We're destroying the future utility by producing false positives now.
< sipa>
i think i can implement meni's proposal easily though
< gmaxwell>
we also need the too few blocks warning to go away immediately, not after 4 hours.
< gmaxwell>
or it produces another kind of false positive.
< sipa>
though, to be correct, it would actually need to check every 4 hours
< sipa>
not just every 24 blocks
< sipa>
i guess it can just happen based on clock/adjusted timr
< gmaxwell>
yes.
< Luke-Jr>
hmm, so trying to update BIP 145, but VB doesn't have GBT support yet..
< gmaxwell>
VB?
< Luke-Jr>
versionbits
< Luke-Jr>
are we still numbering bits 24..31, 16..23, 8..15, 0..7? not entirely clear from BIP 9 :x
< sipa>
nVersion is interpreted as an integer; bits in that integer are being set
< sipa>
how those map to byte position is a block serialization issue, which is unchanged
< Luke-Jr>
so yes
< sipa>
i have no idea what you mean
< sipa>
nVersion is a little-endian 32-bit signed integer
< sipa>
in the block header serialization
< sipa>
so the lowest 8 bits map to the first byte
< Lightsword>
Luke-Jr, is your issue with it just the format?
< Luke-Jr>
Lightsword: ? just clarifying
< Luke-Jr>
"The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number." sounds correct?
< sipa>
sounds correct to me!
< sipa>
indeed, i notice that there is no 2^N anymore in the text
< Luke-Jr>
would 2^N be a better way to phrase that?
< sipa>
i don't care :)
< Luke-Jr>
curiously, I observe that << is more universal than ^ in syntax
< sipa>
actually, the code snippet inside bip9 does define the behaviour fully
< gmaxwell>
Luke-Jr: the stream operator?
< sipa>
though clarifying in the text makes sense..
< Luke-Jr>
gmaxwell: nevermind :P
< gmaxwell>
(screw you C++)
< Luke-Jr>
so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
< Luke-Jr>
simple*
< Luke-Jr>
bip-number:bit-number
< Luke-Jr>
where bit-number is true when ACTIVE
< Luke-Jr>
… {} instead of [] in JSON
< Lightsword>
can’t the stratum server/miner just decode that itself from the version number?
< sipa>
Luke-Jr: VB does not identify deployments by bip number
< Luke-Jr>
sipa: does it identify them at all?
< Luke-Jr>
Lightsword: not without teaching every client about the VB options..
< sipa>
Luke-Jr: they get a name in getblockchaininfo
< Luke-Jr>
Lightsword: and median time past etc
< Luke-Jr>
sipa: that name isn't in the BIP afaict
< Luke-Jr>
sipa: shall I add it?
< Luke-Jr>
(considering that GBT will need to keep it in the list basically forever, smaller might be best?)
< Lightsword>
Luke-Jr, can’t the miner/stratum server just issue a getblockchaininfo rpc call if it actually needs fork status info?
< Luke-Jr>
Lightsword: no such RPC exists in GBT spec
< Lightsword>
why does it have to be in GBT?
< Luke-Jr>
Lightsword: how else will the client and server negotiate rules?
< sipa>
i still think that trying to replicate the consensus rules in the mining client is folly
< Lightsword>
it can issue other RPC calls
< sipa>
if you want to be able to modify the transaction, run a bitcoind yourself
< Lightsword>
IMO best not to try and stuff too much into GBT
< Luke-Jr>
sipa: still need to figure out the union of what the local bitcoind and remote are
< sipa>
but i don't oppose adding some string list of extra rules that are active to GBT
< sipa>
Luke-Jr: no, you tell the bitcoind "this is the coinbase txn i want, give me a block"
< sipa>
no merging
< Luke-Jr>
that may be a better approach, but it's not how GBT works
< sipa>
does anyone in the world actually have code that can even do txn merging over GBT?
< Luke-Jr>
there is a fork of libblkmaker that can
< Luke-Jr>
in any case, for BIP 145, it needs to know whether BIP 141 is being used or not, to figure out what the sigop definition is
< Lightsword>
can’t it infer that?
< Luke-Jr>
which is needed even without merging, for eg truncation
< Luke-Jr>
Lightsword: infer it how?
< Lightsword>
if there’s both a hash and txid and a defaultwitnesscommitment available?
< Luke-Jr>
defaultwitnesscommitment is not even part of GBT spec
< sipa>
txid/hash are
< Luke-Jr>
anyway, inferring it can't reliably be expected to work for other softforks
< Lightsword>
Luke-Jr, is defaultwitnesscommitment going to be in the final version of GBT?
< Luke-Jr>
Lightsword: no (but maybe in bitcoind's implementation)
< sipa>
i'm not opposed to adding some list to the GBT output that lists the active consensus rules
< sipa>
maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
< Luke-Jr>
sipa: so should VB add a name, or does BIP number work?
< sipa>
the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
< Luke-Jr>
oh
< Luke-Jr>
right
< sipa>
and they are intentionally being rolled out at once, as the alternative would mean testing way more combinations of their interactions
< Lightsword>
Luke-Jr, GBT needs to be overhauled/replaced at some point anyways, not sure if it’s worth putting fork status info in it
< Luke-Jr>
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. <-- ACK?
< GitHub77>
[bitcoin] mruddy opened pull request #7774: RPC: BIP9 version bits related, format version as hex in getblock and getblockheader (master...hexver) https://github.com/bitcoin/bitcoin/pull/7774
< dgenr8>
morcos: in 7568 I had to change the test to generate blocks faster than before, to get it to trigger. so yes, harder to trigger.