< bitcoin-git>
[bitcoin] fanquake closed pull request #8983: WIP: Log block height and size when received (master...ShowBlockHeightAndSizeWhenReceived) https://github.com/bitcoin/bitcoin/pull/8983
< bitcoin-git>
[bitcoin] laanwj opened pull request #9219: doc: Improve windows build instructions using Linux subsystem (master...2016_11_windows_build_update) https://github.com/bitcoin/bitcoin/pull/9219
< bitcoin-git>
[bitcoin] laanwj closed pull request #9189: Always add default_witness_commitment with GBT client support (master...alwayscommit) https://github.com/bitcoin/bitcoin/pull/9189
< bitcoin-git>
bitcoin/master d932159 Wladimir J. van der Laan: Merge #9189: Always add default_witness_commitment with GBT client support...
< bitcoin-git>
bitcoin/master 95f4a03 Suhas Daftuar: [qa] Test getblocktemplate default_witness_commitment
< bitcoin-git>
bitcoin/master ad04d1c Pieter Wuille: Always add default_witness_commitment with GBT client support
< gmaxwell>
bitcoin358: add more fees later in the chain and enjoy giving them to miners running Bitcoin Core, since it will happily notice those fees later in the chain.
< rusty>
gmaxwell: it's your fault I now have 'while sleep 10; do bitcoin-cli getblocktemplate | awk '/"fee"/ { FEES += $2 } /"height"/ { HEIGHT = $2 } END { print HEIGHT,FEES }'; done' running in a terminal here, BTW.
< bitcoin-git>
[bitcoin] sipa closed pull request #9199: Always drop the least preferred HB peer when adding a new one. (master...remove_high_bandwidth_zombies) https://github.com/bitcoin/bitcoin/pull/9199
< bitcoin-git>
bitcoin/master 407d923 Pieter Wuille: Merge #9199: Always drop the least preferred HB peer when adding a new one....
< bitcoin-git>
bitcoin/master ca8549d Gregory Maxwell: Always drop the least preferred HB peer when adding a new one....
< cfields>
BlueMatt: i suppose we're looking at this from different sides. I originally rewrote the net layer and tried to plug it into bitcoin. I didn't like the result. I started instead trying to rip bitcoin out of our net layer, and that's where we are now. The next step would be to split the resulting CConnman into high and low levels. That's next.
< BlueMatt>
cfields: bitcoin-specific hacks like what?
< cfields>
BlueMatt: for context, I first wrote a completely low-level, no-bitcoin network layer. Plugging that into bitcoin proved to require a bunch of bitcoin-specific hacks. In the end, I didn't think it was an improvement over what we had.
< BlueMatt>
cfields: well I dont think you mean that tighter-integration is needed between bitcoin logic and libevent/async
< sipa>
CConnman is exactly the bitcoin specific thing
< BlueMatt>
sipa: CConnman should be a networking library, not a bitcoin networking library
< BlueMatt>
sipa: the way i see it: processing of messages and the peer handling is already well-separated, or at least somewhat separated...we currently have bitcoin-specific and general-networking code intermixed in a bunch of places, and that also needs to be separated
< brhood9_>
Is there any way that you all could help me figure out what is going on with my bitcoin transaction? I have asked and looked and read everywhere. The transaction that you need to look at is this one.
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9139: Change sync_blocks to pick smarter maxheight (on top of #9196) (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
< bitcoin-git>
bitcoin/master 0de7fd3 MarcoFalke: Merge #9139: Change sync_blocks to pick smarter maxheight (on top of #9196)...
< bitcoin-git>
bitcoin/master 1126c85 Russell Yanofsky: [qa] Change sync_blocks to pick smarter maxheight...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9139: Change sync_blocks to pick smarter maxheight (on top of #9196) (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
< BlueMatt>
so I could PR relay-compact-block-before-full-validation (https://github.com/TheBlueMatt/bitcoin/commits/2016-11-compact-fast-relay) but now I'm kinda thinking I dont want to do that prior to there being multithreaded ProcessMessages with some smarts to respond to getblocktxn without a lock for the latest block...thoughts?
< bitcoin-git>
bitcoin/master 5e8631b Wladimir J. van der Laan: Merge #9205: Minor change to comment for consistency....
< bitcoin-git>
bitcoin/master f004e67 Greg Walker: Minor change to comment above new NODE_WITNESS service flag to keep it consitent with existing comment structure. Helps with readability.
< gribble>
https://github.com/bitcoin/bitcoin/issues/9073 | Trivial: Add common failure cases for rpc server connection failure by instagibbs · Pull Request #9073 · bitcoin/bitcoin · GitHub
< wumpus>
instagibbs: eh in #9073 you changed the bitcoin-cli message but it's confusing now: error: couldn't connect to server (make sure server is running and you are connecting to the correct RPC port: -1 unknown)
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #9130: Mention the new network toggle functionality in the tooltip. (master...20161111_disable_network_tooltip) https://github.com/bitcoin/bitcoin/pull/9130
< bitcoin-git>
bitcoin/master ac489b2 Jonas Schnelli: Merge #9130: Mention the new network toggle functionality in the tooltip....
< bitcoin-git>
bitcoin/master 1260c11 Pavel Janík: Mention the new network toggle functionality in the tooltip.
< bitcoin-git>
[bitcoin] jnewbery closed pull request #9203: [trivial] Fixes the RPC help text for waitforblockheight (master...waitforblockheightcomment) https://github.com/bitcoin/bitcoin/pull/9203
< bitcoin-git>
[bitcoin] jnewbery opened pull request #9203: [trivial] Fixes the RPC help text for waitforblockheight (master...waitforblockheightcomment) https://github.com/bitcoin/bitcoin/pull/9203
< wumpus>
this is not related to bitcoin core development, can you move this to #bitcoin?
< bitcoin-git>
[bitcoin] laanwj opened pull request #9202: bench: Add support for measuring CPU cycles (master...2016_11_bench_cpu_cycles) https://github.com/bitcoin/bitcoin/pull/9202
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #9199: Always drop the least preferred HB peer when adding a new one. (master...remove_high_bandwidth_zombies) https://github.com/bitcoin/bitcoin/pull/9199
2016-11-21
< skyraider>
it might help to put on a client's shoes here. context was https://github.com/petertodd/python-bitcoinlib/pull/128 in which a blind retry python decorator was considered. turns out this can a) result in actually sending bitcoin multiple times, b) result in decisions made on stale read data (balance was just an example - really any bitcoind state subject to
< skyraider>
yes, sorry, shorthand for "try to send some bitcoin"
< skyraider>
uh, yeah, not bitcoin transaction. isolation as in the I from ACID.
< skyraider>
so 'read before you try to send lots of bitcoin' - alright. but if another RPC connection writes in the meantime, won't my read be stale, or is there transaction isolation somehow? is the recommended policy therefore 'only ever use a single RPC writer' ?
< instagibbs>
wumpus, I'm not an old timer, which is why I'm asking more basic account questions. It's always been deprecated in my Bitcoin lifetime :P
< bitcoin-git>
[bitcoin] laanwj closed pull request #9117: net: don't send feefilter messages before the version handshake is complete (master...feefilter-assert) https://github.com/bitcoin/bitcoin/pull/9117
< bitcoin-git>
bitcoin/master c390640 Wladimir J. van der Laan: Merge #9117: net: don't send feefilter messages before the version handshake is complete...
< bitcoin-git>
bitcoin/master 4662553 Cory Fields: net: don't send feefilter messages before the version handshake is complete
< bitcoin-git>
[bitcoin] laanwj closed pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (master...sharedblock) https://github.com/bitcoin/bitcoin/pull/9125
< bitcoin-git>
bitcoin/master 1662b43 Pieter Wuille: Make CBlock::vtx a vector of shared_ptr<CTransaction>
< bitcoin-git>
bitcoin/master da60506 Pieter Wuille: Add deserializing constructors to CTransaction and CMutableTransaction
< bitcoin-git>
bitcoin/master 0e85204 Pieter Wuille: Add serialization for unique_ptr and shared_ptr
< bitcoin-git>
[bitcoin] instagibbs opened pull request #9194: Add flags to getrawtransaction and getblock to return non-segwit seri… (master...nonswserialrpc) https://github.com/bitcoin/bitcoin/pull/9194
< sipa>
it's probably a relatively good way to understand the design of bitcoin, but it's not that helpful to learn how the code works now
< luke-jr>
but in case he reads the log: I don't recommend reading the earliest code as a way to learn about Bitcoin. It was a mess, and included a lot of features later discarded (eg, built-in marketplace)
< meownow>
im currently reading through the first commit of the bitcoin source code onto github. seems a good way to familiarize myself with the core of the code base and what it does.
< luke-jr>
sipa: protocol changes need consensus. we can't force them on people. but it only takes good willed miners to use pro-Bitcoin policys.
< dermoth>
yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
< sipa>
dermoth, rabidus: also, please take this to #bitcoin
< rabidus>
you would kill the "store of value" property of bitcoin
< dermoth>
I think after a certain number of bitcoin cycles (210k blocks) we could scavenge all unspent coins from the oldest 210k block, put them in a pool and let miners siphon 1/210000th of that pool every block. At that point the older part of the chain could be completely dropped as it would no longer have any use, and pooling the fund would ensure miners get a predictable reward.
< gribble>
https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
< wumpus>
many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
< wumpus>
we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
< gmaxwell>
Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye.
< gmaxwell>
jonasschnelli: political discussion to ##bitcoin.
< shangzhou>
gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is
< BlueMatt>
-rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log