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
yes, sorry, shorthand for "try to send some bitcoin"
uh, yeah, not bitcoin transaction. isolation as in the I from ACID.
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' ?
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
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)
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.
sipa: protocol changes need consensus. we can't force them on people. but it only takes good willed miners to use pro-Bitcoin policys.
yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
dermoth, rabidus: also, please take this to #bitcoin
you would kill the "store of value" property of bitcoin
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.
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
-rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log
also, IIRC bitcoin.org and the bitcoin foundation are no longer related
shinyg: blockstream does not fund Bitcoin Core development at all. There are developers who work on Bitcoin Core who also have jobs at Blockstream. The people who actually partially fund development are the MIT DCI who actually pay some people to work on Core (wladimir, cory)
I have recently expanded the Wikipedia article for Bitcoin Core by a factor of 10. Could someone spend just a few minutes to see if there are any major ommission or errors?
Hi people, I was after a little assistance from those who know more about Bitcoin Core and those who support Wikipedia.
okay, bitcoin's sha256 is 237.1 million bytes per second, openssl is 320.7 million bytes per second.. and the chacha is 358.6 million bytes per second. (openssl at slight disadvantage due to 8k vs 1m size, but it doesn't matter much)
gmaxwell: no no, we're not allowed to sign that, because it's Roger Ver's attempt to snub Bitcoin Core. Looks like a more watered down version of the first leak http://pastebin.com/cgkqcWBS.