< bryyan> if Bitcoin core is written in C++, why not support any kind of native interface directly (numbers as represented in memory going over tcp sockets as an RPC opposed to the serialised JSON RPC) ?
< gmaxwell> because either it exposes internal datastructures which are unstable and change from version to version to outside applications; or it has to specify yet another encoding.
< gmaxwell> and we do already have a binary encoding for most thigns: use the p2p protocol.
< bryyan> I mean't like json but in a C struct
< bryyan> and not a char* but between applications you would include a .h file containing the structs
< sipa> structs don't have a well-defined serialization to bytes
< bryyan> on the same architecture they do
< sipa> different architectures store them differently in memory
< sipa> just a different compilation option may change them
< bryyan> yes, but why write bitcoin core in c++, a platform dependent language under many circumstances?
< bryyan> additionally its often feasible to have multiple AMD64 machines which use the same format for C variables
< sipa> efficiency, tight control over resource usage, high-level
< bryyan> JSON is kind of cpu intensive to cast back and forth between native types you know
< bryyan> directly copying 4 bytes of memory is far cheaper
< sipa> you can use REST
< bryyan> what is REST?
< sipa> for some data with well-defined serialization, Bitcoin Core has a REST interface
< sipa> you can fetch full blocks and transactions directly in binary network format over it
< bryyan> without having to send a bunch of ascii json around?
< sipa> to avoid the JSON encoding/decoding overhead
< sipa> yes
< sipa> but you still need a serialization/deserialization layer... it's not just a struct that gets sent over the network
< bryyan> yes, but I'm looking for just that
< bryyan> I assume I have 2 machines of identical architecture and the fastest means of transfering data is in native format
< sipa> there is no 'native' format
< bryyan> a C int type is native by my definition
< bryyan> will look identical on 2 AMD64 machines
< sipa> what's the native representation for a transaction?
< sipa> it has a number of nested data structure of variable size
< gmaxwell> none of the interesting data in bitcoin is just an int or a simple arrays of them.
< gmaxwell> and as I said above, we do have a binary seralization of data: the p2p format.
< bryyan> if you query for your balance, a float or double could work as a returned native type
< gmaxwell> all ready for anyone to use.
< gmaxwell> oh jesus bitcoin amounts aren't natively floating point.
< gmaxwell> one should generally not use floating point when dealing with money.
< sipa> bryyan: the cost of computing the balance is orders of magnitude larger than running a json deserializers
< bryyan> you know, floating point has a certain number of digits of accuracy, just don't go too far
< bryyan> I don't think we're talking about the same thing
< sipa> fine
< bryyan> in a native binary (such as bitcoind) certain instructions are applied to do math with integers and floating point types, the format of those values in memory are the native types
< bryyan> pretty printed json is like 64 bytes to represent a 4-byte int
< bryyan> very slow
< bryyan> additional information is transfered over the network when keeping a header file with bitcoind and with the RPC client containing C macros which resolve to short 2-byte sequences for calls, and structs for reciving will take up far less thoroughput
< bryyan> and after the word network there should be a comma I meant to put
< bryyan> if you've written programs in C you would know what I'm talking about
< praxeology> bryyan: how about create software and find the RPC api as a bottleneck before you look to optimize it
< bryyan> for one thing, C doesn't handle JSON very well
< bryyan> although thats more of a side problem
< phantomcircuit> bryyan, the question you want to be asking yourself right now is
< phantomcircuit> BUT WHY
< bryyan> largely because I plan to make an operating system, and JSON puts in wayyy to much computational overhead compared to even a native-type conversion service
< bryyan> you can convert endianness, format, and signing polarity far quicker then serialising and de-serialising some json
< gmaxwell> Go away earlygrey.
< bryyan> you could probably process 10s of requests in native format by the time a single JSON request completes
< bryyan> maybe even 100s with a well-optimized binary
< luke-jr> bryyan: jansson handles JSON good enough
< praxeology> luke-jr: did you see he is making an operating system?
< bitcoin-git> [bitcoin] sipa opened pull request #10958: Update to latest Bitcoin patches for LevelDB (master...20170731_leveldb) https://github.com/bitcoin/bitcoin/pull/10958
< MarcoFalke> jnewbery: The issue is that the last commit of #10853 conflicts with other pulls tagged for 0.15
< gribble> https://github.com/bitcoin/bitcoin/issues/10853 | [tests] Fix RPC failure testing (again) by jnewbery · Pull Request #10853 · bitcoin/bitcoin · GitHub
< MarcoFalke> At this point I'd prefer if we didn't force a rebase on tagged pulls
< jnewbery> MarcoFalke: I'm happy for 10853 to wait until after rc1
< jnewbery> Unless you want it before, in which case I'll split it
< MarcoFalke> Fine, let's defer it for now.
< Oscillate> Hi,
< Oscillate> New to bitcoin here, can somebody tell me if the split is neccecary fot bitcoin hardfork ??
< sipa> Oscillate: #bitcoin
< Oscillate> for*
< Oscillate> thank you sipa
< luke-jr> wumpus: can I get access to bitcoin-devwiki? seems github is picky about pushing changes via git/ssh :/
< luke-jr> copypa;ted for no,
< jnewbery> (I have my own logs, but it's useful to be able to send a URL)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70888a39c43a...2a50b11586a2
< bitcoin-git> bitcoin/master 9a8b054 Gregory Maxwell: Update defaultAssumeValid according to release-process.md....
< bitcoin-git> bitcoin/master 2a50b11 Wladimir J. van der Laan: Merge #10945: Update defaultAssumeValid according to release-process.md....
< bitcoin-git> [bitcoin] laanwj closed pull request #10945: Update defaultAssumeValid according to release-process.md. (master...201707-update-assumevalid) https://github.com/bitcoin/bitcoin/pull/10945
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a50b11586a2...df3a6f4ee4e2
< bitcoin-git> bitcoin/master f0acedd Wladimir J. van der Laan: p2p: Hardcoded seeds update pre-0.15 branch
< bitcoin-git> bitcoin/master df3a6f4 Wladimir J. van der Laan: Merge #10948: p2p: Hardcoded seeds update pre-0.15 branch...
< bitcoin-git> [bitcoin] laanwj closed pull request #10948: p2p: Hardcoded seeds update pre-0.15 branch (master...2017_07_seeds_update) https://github.com/bitcoin/bitcoin/pull/10948
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/df3a6f4ee4e2...af563971fcbe
< bitcoin-git> bitcoin/master bdd5543 Alex Morcos: Clarify help message for -discardfee
< bitcoin-git> bitcoin/master af56397 Wladimir J. van der Laan: Merge #10949: Clarify help message for -discardfee...
< bitcoin-git> [bitcoin] laanwj closed pull request #10949: Clarify help message for -discardfee (master...betterhelp) https://github.com/bitcoin/bitcoin/pull/10949
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/42307c4bf363d695c68a65ba7cbf8d6790079abf
< bitcoin-git> bitcoin/master 42307c4 Wladimir J. van der Laan: qt: Periodic translations update...
< bitcoin-git> [bitcoin] practicalswift opened pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
< bitcoin-git> [bitcoin] practicalswift opened pull request #10963: [bench] Restore format state of cout after printing with std::fixed/setprecision (master...restore-format-state-of-cout) https://github.com/bitcoin/bitcoin/pull/10963
< bitcoin-git> [bitcoin] practicalswift opened pull request #10964: Pass SendCoinsRecipient (208 bytes) and CConnman::Options (168 bytes) by reference (master...pass-big-parameters-by-reference) https://github.com/bitcoin/bitcoin/pull/10964
< BlueMatt> #8330 could get a merge, tbh, its a free few-10s-of-k memory win
< gribble> https://github.com/bitcoin/bitcoin/issues/8330 | Structure Packing Optimizations in C{,Mutable}Transaction by JeremyRubin · Pull Request #8330 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] practicalswift opened pull request #10965: Use the noexcept specifier (C++11) instead of deprecated throw() (master...noexcept) https://github.com/bitcoin/bitcoin/pull/10965
< achow101> whoever runs the doxygen site at dev.visucore.com needs to update their ssl cert. it expired this morning and I can't access it
< MarcoFalke> wumpus: ^
< MarcoFalke> It is issued by let's encrypt... I thought the point of that CA was that such updates are automatically done
< sipa> MarcoFalke: they have automated the procedure for renewal to almost nothing, but there is stipl some script you need to run (potentially in a cronjob)
< sipa> wumpus: ^
< bitcoin-git> [bitcoin] promag opened pull request #10966: Add walletnotify functional test (master...2017-07-walletnotify-functional-test) https://github.com/bitcoin/bitcoin/pull/10966