Getblock.io

GetBlock.io is Going Live! Fee-free Access to Full Blockchain Nodes

Hello!
At GetBlock we provide connection for the most popular cryptocurrencies nodes with JSON-RPC, REST and WebSockets. There is no need to deploy a node yourself, our service allows you to connect to the blockchain via a full node without having to pay a fee.
We are constantly developing and adding new nodes, on the contrary, the connection always stays put — fast and secure 24/7. At the moment, GetBlock offers nodes of more than 20 cryptos, including Bitcoin (BTC), Ethereum (ETH), Monero (XMR), and Litecoin (LTC).
The platform is quite suitable for young entrepreneurs and beginners, as well as for crypto developers and blockchain users, for all those who have neither time nor resources to run their own full node.
To start using the node, please get your personal and free API key. Tell us about your project or why you need access to blockchain data, and we will grant you a free API key.
If you do have any further questions or partnership offers, feel free to contact us via email: [[email protected]](mailto:[email protected])
submitted by getblockio to getblockio [link] [comments]

Nodes available at GetBlock

At the moment, there are 22 nodes supported by GetBlock. These nodes are Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), Bitcoin SV (BSV), Bitcoin Cash (BCH), Particl (PART), Lbry (LBC), DogeCoin (DOGE), ZCoin (ZXC), Verge (XVG), Groestlcoin (GRS), DigiByte (DGB), Dash (DASH), Reddcoin (RDD), Bitcoin Gold (BTG), Horizen (ZEN), Decred (DCR), Zcash (ZEC), Bytecoin (BCN), Loki Network (LOKI), Rsk (RSK), and Obyte (GBYTE).
New nodes are constantly being added to the service and monitored, the existing nodes are updated as needed. GetBlock is open for new partnerships and cooperation, if you can’t find the required node on the website, let us know, and we will add it as soon as possible.
The full list of nodes with their statistics is always available on the website, along with all of the appropriate documentation: https://getblock.io/#nodes
submitted by getblockio to getblockio [link] [comments]

GetBlock.io is Going Live! Fee-free Access to Full Blockchain Nodes

Hello!
At GetBlock we provide connection for the most popular cryptocurrencies nodes via an open API (JSON-RPC). There is no need to deploy a node yourself, our service allows you to connect to the blockchain via a full node without having to pay a fee.
We are constantly developing and adding new nodes, on the contrary, the connection always stays put — fast and secure 24/7. At the moment, GetBlock offers nodes of more than 20 cryptos, including Bitcoin (BTC), Ethereum (ETH), Monero (XMR), and Litecoin (LTC).
The platform is quite suitable for young entrepreneurs and beginners, as well as for crypto developers and blockchain users, for all those who have neither time nor resources to run their own full node.
To start using the node, please get your personal and free API key. Tell us about your project or why you need access to blockchain data, and we will grant you a free API key.
If you do have any further questions or partnership offers, feel free to contact us via email: [[email protected]](mailto:[email protected])
submitted by getblockio to u/getblockio [link] [comments]

...was I just shadow banned from /r/Bitcoin ?

I replied to theymos , regarding the bitcoin core client's RPC command: invalidateblock. I asked if this would have really allowed a node to manually fork if a block was discovered to be infected from the <0.16.3 vulnerability.
My question/reply revolved around whether or not that would do anything other than stall the node, since the getblocks message only returns a list of block hashes for the "best" chain, so the node wouldn't receive any blocks until a fork beat out the corrupted one.
It appears my comment does not show up in incognito. Curious if anyone else can see my comment or if I was shadow banned long ago...
If I was actually shadowbanned, then I'm a bit more than miffed. I'm genuinely asking about the behavior of the protocol to make sure my logic in Bitcoin Verde's implementation is correct. Cool.
EDIT: The comment chain I'm referring to: https://www.reddit.com/Bitcoin/comments/9hkoo6/new_info_escalates_importance_upgrading_to_0163/e6d4u9q/
EDIT 2: theymos : Thanks for the reply, and if I was shadow-banned, thanks for the unban. I wish you guys would reconsider your willy-nilly banning.
EDIT 3: ...okay. What is happening here? My first reply to theymos is showing up (presumably because he himself has replied), but now my 2nd reply isn't showing up? I'm either still shadowbanned and theymos is individually approving my posts, or any reply to a moderator must be approved first before being shown, or there's a massive delay between posting and being visible to others. I'd like to believe it's the lattermost scenario, but that feels naive given the subreddit's reputation.
EDIT 4: My most recent reply is now showing up. Great. I have no idea what is going on or if I'm actually shadowbanned. Regardless, I don't care anymore; I have more important things to do than investigate.
submitted by FerriestaPatronum to btc [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
 
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to btc [link] [comments]

sPRUNED Bitcoin Client - A new release is out [0.0.5]

sPRUNED Bitcoin Client - A new release is out [0.0.5]
Hello everyone.

I'd like to announce a new release of sPRUNED Bitcoin client.


spruned is a bitcoin client for lightweight systems.it doesn't need to store the blockchain on the disk, just the headers.128mb ram & 500mb hdd should be fairly enough to keep it up & running.
Supports both Bitcoin Mainnet and Testnet.
It doesn't rely on any central authority, use both the Electrum and the P2P Bitcoin Network in real-time to gather the data you need.
The new release (latest is v0.0.5.1) have:

  • lot of bugfixing all around
  • a robusts P2P connectionpool with a 100% getblock hitrate
  • an electrum servers quorum-based fee estimation
  • proxies and tor support
  • less memory usage for low end devices
  • RPC API improvements

The new release is cool enough to back BTC-RPC-Explorer with Tor Support:


https://preview.redd.it/zdgvz55lxbl21.jpg?width=1606&format=pjpg&auto=webp&s=44ac3b67cc49369b04f71dab691dabf772d959aa

And is able to keep Clightning in Sync on a low-end VPS (High bandwidth consumption, don't use metered connections).

https://preview.redd.it/hjs3blryybl21.png?width=1913&format=png&auto=webp&s=5ffa4bf8c7054bf6291b29d53dc71e715c7cf1ae
Give it a try!
$ pip install spruned*
$ spruned --daemon
$ bitcoin-cli getblockchaininfo

*dependencies required, check the README :)

https://github.com/gdassori/spruned/releases
https://pypi.org/project/spruned/
https://twitter.com/KHS9NE


submitted by case666 to Bitcoin [link] [comments]

BlockParser - A way to get the balance of all bitcoin addresses

For same time, I was searching for a way to get the balance of all bitcoin addresses in order to do statistical analysis of the wealthy distribution. If finally found a way to do it without using an external API such as blockchain.info. This method will allow you to create a list of all bitcoin addresses ordered by balance, excluding empty ones. This does not work properly for addresses involved in multisignature transactions.
Prerequisites:
Step 1 – Parse all blocks using this small program
#!/usbin/perl # File: blockParser.pl # Author: Saulo Fonseca # Licence: GNU GPLv3 use warnings; use strict; use JSON; # Get argument as block number my $blockNumber = $ARGV[0] + 0; # Convert to int # Get all transactions my $blockHash = `bitcoin-cli getblockhash $blockNumber`; chomp($blockHash); my $out = `bitcoin-cli getblock $blockHash`; my $json = decode_json($out); if (defined $json->{'tx'}) { my $txs = $json->{'tx'}; foreach my $txHash (@$txs) { $out = `bitcoin-cli getrawtransaction $txHash 1`; $json = decode_json($out); if (defined $json->{'vin'}) { # Get all input transactions my $vins = $json->{'vin'}; foreach my $vin (@$vins) { if (defined $vin->{'txid'}) { my $tx = $vin->{'txid'}; my $index = $vin->{'vout'}; printf("%s\t%d\tdel\n",$tx,$index); } } } if (defined $json->{'vout'}) { # Get all output addresses my $vouts = $json->{'vout'}; foreach my $vout (@$vouts) { if (defined $vout->{'scriptPubKey'}->{'addresses'}) { my $keys = $vout->{'scriptPubKey'}->{'addresses'}; my $value = $vout->{'value'}; my $index = $vout->{'n'}; foreach my $key (@$keys) { printf("%s\t%d\t%s\t%.8f\n",$txHash,$index,$key,$value); } } } } } } 
This program will get the height of the block as an argument and return a tab separated output with the following columns:
Here is an example of the output for the block 100000 (with cropped TXIDs in order to fit the reddit width):
8c14f0...d06d87 0 1HWqMzw1jfpXb3xyuUZ4uWXY4tqL2cW47J 50.00000000 87a157...382e03 0 del fff252...9702c4 0 1JqDybm2nWTENrHvMyafbSXXtTk5Uv5QAn 5.56000000 fff252...9702c4 1 1EYTGtG4LnFfiMvjJdsU7GMGCQvsRSjYhx 44.44000000 cf4e29...bf3ec3 1 del 6359f0...236ec4 0 1H8ANdafjpqYntniT3Ddxh4xPBMCSz33pj 0.01000000 6359f0...236ec4 1 1Am9UTGfdnxabvcywYG2hvzr6qK8T3oUZT 2.99000000 f4515f...72600b 0 del e9a668...b80c1d 0 16FuTPaeRSPVxxCnwQmdyx2PQWxX6HWzhQ 0.01000000 
You should process all blocks using this program and send the output to a text file. The command in bash that does it is:
seq -w 1 555000 | while read i; do (./blockParser.pl $i >> blocks.txt); done 
This will take a while depending on the performance of your system. However, it must be done only one time.
Step 2 – Export the list of all spent transactions
Use the following command to export all spent transactions on all processed blocks on step 1:
grep -h del blocks.txt | cut -f1,2 > spent.txt 
The lower cap letter L in “del” will not match any entry on a hex string nor on an address, as it is not allowed in base58.
Step 3 – Get the list of all UTXO
By removing all spent transactions, you have the list of all UTXO (unspent transactions output). Do it by running:
grep -v -f spent.txt blocks.txt > utxo.txt 
Step 4 – List all addresses balances
Using the UTXO list, you can get the balances of all addresses by running:
cat utxo.txt | cut -f3,4 | awk '{ seen[$1] += $2 } END { for (i in seen) printf "%.8f\t%s\n", seen[i], i }' | sort -n -r > anyBTC.txt 
Conclusion
You can import this last file on your favorite analysis program in order to have a better idea how the distribution of bitcoins over the addresses is.
PS: After the arrival of new blocks by the network, you only need to process the step 1 for the new blocks and repeat all the other steps in order to have an updated version of the files.
submitted by sauloqf to Bitcoin [link] [comments]

PSA: SegWit changes the format of data returned by JSON-RPC API, thus making it backward-incompatible

As far as I know, all soft-forks so far were backwards-compatible, i.e. a piece of software working with JSON-RPC API doesn't need to be upgraded when a soft-fork is activated. For example, OP_CHECKLOCKTIMEVERIFY will interpreted by old software as OP_NOP2, which is harmless.
But SegWit is different in this respect because it changes data formats.
For example, suppose you use getblock API to get raw block contents and parse it using bitcore-lib to extract some useful information of new blocks. If you happen to use Bitcoin Core 0.13.1, then after SegWit activation, getblock will return data in new format which bitcore-lib cannot understand, so your application will no longer work.
So if your application happens to use affected APIs (getblock is one of them, but I don't have a complete list), you choice is either to:
(I think Bitcoin Core could easily make all APIs backward compatible by transforming data into the old format for old calls and introducing new calls which return data in new format, e.g. getblocksw for segwit-comptable software. But it's too late for this...)
submitted by killerstorm to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to bitcoin_unlimited [link] [comments]

No SegWit2x Mining, But New "Clashic" Block #504039 Mined

It's unknown if there is no SegWit2x mining because no one has father to fix the purportedly borked code, but this morning I discovered this new "Clashic" block on my Bitcoin ABC 15.0.0 node (output shown is from a "getblock" command):
{ "hash": "0000000000000000000fdfc1041e943e6adfa28a12d97a6720aaa69f19c76435", "confirmations": 1, "size": 32862, "height": 504039, "version": 536870912, "versionHex": "20000000", "merkleroot": "df60ad7d2a7a86bbae97d01a57fd9779550674b1275a212503ceed62c30e1851", "tx": [ "d04e0a84ad71f9daa58539b68e29145bdfcbed1f3dad9cf2ee75f32e7e7b7a07", "8b8d717d41dc6a47b055fa4cf2edadc8afd0813ffc2fc9fe32b13dbfa507b92d", "76b9c4c2d360dd0fb17ed81a5e23560b0259e4695a3c93ec9d612600174cc69e", "76dc1ab2d578c7bd4cc0a5bd7e94a4d1a39bc53404828479506c39a895a2c55e", "772a00ea7346057845d606aa6646c4a54e6bfdbfbe5ebcf6a056726db2a6090f", "be3eb59982b81cdf20f8f554ed059930dd5aead215e8d76997e176ed91fa5e8d", "68963e656719281077e47cdc8597fd72e2e0eafb7b3bd42cf5a6f8c15b077ea7", "35d5b2d1995ce51b9c0ee0566d41ef1a5ee345ff56710a08db18cbc845dab1ad", "832ffcf1fd759eea5e8be4cd6d4e9ff110d6e41b14b537116ee1622a8037524f", "ac6a244c928f5373183fe09de5f6176c3f1bebb0601a5ab0bc93a902ac181d9c", "5159225217c036bbdf940f84eeb68e7159d4b96181557ae84b9693a8bd31fd14", "c8716c483cdd9e97039bb10f3270145fcce0628c21d0b0c9011fd61b64afbd62", "9f1cab7ecbd08d5e68509cef791f5590765c5d25b29570b3d2fd63655550eacb", "8e7c390208ca29eca9d1e852c049ae0649577aadce6a035cb4227ee8d2bc79b7", "67a7814cfa551d5f671417957daa43a85ababe179aafd01a472db5e81cfee0a9", "af2a944cfb428467002029ddb71348a6d4f676d4c883afd9833b96b2e0163778", "54c9bf80f3178860e8561eed8735f81366fa7aa1167418ae864c5eaffe1e3171", "7d71b929f5942fc5f6456f6312b40bd797a53ab90ec09b75a5470ebe4f908730", "e0861a01dc01933d895950588abe1325207b3ed147359c9e6f642ccd24569079", "adc35f6692b05e55a133a11668f1bdb504983e957384537cd14c43e53d02e79a", "cc8583daa110b4ff8af7c0e474e374d669862b0c8280ed837b687062b7009807", "1ce59a31682c33f7725e92909d21c5203200e5274f73a66a185ca10346cf3e60", "92ad14671662523ed09222ea1e7a065c981d4ae547e5897da9f016a3abfd45c7", "bf618000115f09ebef29c3d67f2fcbf7da983aa57c72fb9cca60c8d426132eba", "0de408c0f8620be7ea787b2221a189c95becca7465372f5598660367795d8c57", "05845896a02f96e25ac7535a0d9660d3d15e552670b0d38b451c83f5b3590395", "d55f4d32114d94f00aa5540c4c91a9173774807f664de3fdb58c31f5288292fe", "83df5aaebb4f2718cc3466a00db2ff9975613e8bfba21f000ad381a9dc53d4ef", "e3e9cfe8fee9bb2f6c4bd104da5c33b5dd05e382add2abd8ca706379539124fd", "2a5cd1c9b0590ea310dcd363cc80b7b71f4c94135f52ce05a1a245c2df2b6f3c", "d58d23c4bee43b3816d66def6b783d8525bedbe5a53e849857c2bffe5e35872a", "11f5eb1134d53c468d4aeac02aac2629693641af1a9a85a80c64f7c774808c0e", "e2dd305837478d4cd8129c9eb018e85d2776adab7c41c478c4a1f36a33a3406f", "a505ea0a6723c074747e9202f872aa8ba64aa4d5fd692ebfd6592f581eee9391", "149a42c19244fbbb6004a67672b671dee430521a37776feb2f22aef38e5af6bc", "62bc476c2e254eb1a6b293cfae567b157e51267b34f34ee352984392e3ef0f3f", "8cfe5c06a1880b348ee7758cfaa78da6654c6c62a2556c780bff34783bebf5c2", "f8e50ef95d0a096c43459fccf3ad44f27238420333f02d86e0337d1ba58361a6", "400fc7be490b11ebe2baf34961d435a52d3e14e27d69a76ceae716ed0c97b73a", "cd41a77de8149b7feb019b0e9bcf6113a8ad1f98b1cd1b1e24774247c546de7e", "73eec7d88cd2910c80d7747031ca3ec66dabed9ca372097b31079ac2cbecd65e", "d4513f5e80b1d1e8357dd9d956e0fb77720d53d771cf05a725e787fbed9a4765", "a4eafc3ea854cf39aa69da95a47d7d34e8d6eb4c936bc747cfab1f9b7ffceda4", "e5e24a2f3377d27dff287d08f689145f1de2222526ecc1e3b976d90678dcce55", "a24a9f739e696ff22bf3ac975dd37b9524d16136d024218ca73e2785c1b8ebb2", "ba6bc6d3c3fda070e5eaaa9256b43de390cd22691056b87abcf294383c4b2c48", "d342caa553133eb6e5d92ca8307200202b4e93feea4c41b66c6313604f63dce9", "9ce3a864d94ad274a7030d56bf471e9729d4ca60528ca51c1afb45c50f05b1cd", "8420c8d16bf8fdb9c0072d600770800fbce0ca5edf9dcbb60392c7696b374ea9", "07b514f47a805ca76d461ced9f1ed303af757a326b28c2ab66c3429b1ddb118b", "caa97ac4d21d439d9c464621ff267d5ae96cff88797d67492a641a4535a61618", "4b205add554d62b33cf99206e9d22d30838c455ae699b9d15f57bbbae8d45341", "40264894b3cf0475f961863bc8243598e3df787f70744afe3ef51d0cf78bce13", "1310a1b4592afa101cd0a250c8f6eb57f847442f3ace6ebad923c9d0ca8e2082", "b75c07b0bc9846c89e8181dd02539ff936615bf332d2f3b17851f7bb1009cb3b", "db9565c25b5a4f0819b20b9d75fc18de0aa3b6098d696e08dd24dc86f4916a70", "4f4cac78ee917047426dade6c585bf3a90e435ddca657b2cc5c4f7d7e000bf46", "989a94491bc22e34e89d10159653fcb298e578a00fe8a4f40f7b886d5c3e56f1", "13540550d8c382d177c5c26a278028a7105b238c581d9eabe26dceabe3f6de9a", "345d0c8c2a4139b0dbdcb36bd20d067dbb37ebb1b164a4cc36decf4038d7a0e6", "eaca78839daf5a51b03b341de72c45aad036b17313007a25cabb0466e938cac0", "ece6d98b3c9f0599fd0035df8a333fe73b58c8b8dce1b00d94bd74431aecd6cb", "4515c64c6b43b0e62076d0b6da3ecd3ab8ef0d37baca5f9fcc292ae666d9938f", "db9ac3391fc83cb77bc8aacba72c973e242a544fe8f3589b787008998653174b", "ce1fc9ccf4ec230c212d8b264c3ae0f3714fd74088cc8229a4ec2c61d7c01d09", "ceaf13ee16380f76b39c9668a8b917832befd84513fca6e23c10171c2be5fa8b", "f62d11631a1b1aa4f0f7ad05194fe1235754e4ddb7ac3328894cee02de586fe4", "344de7e964d3d3fc8050e38bb340e57866717b4667126b95b56e99e9a5121caa", "a2efc748eceebdc849cab697bcd0f29c8d291f6fdd6cedbd38ad7506c94fff62", "752bd6e4a45f2976fd741bab0ac69c5a30913697190b504342562176ffc0b3f8", "0ecf83573b6cccbb23e5f6cbfa2024d2078305eb87ad81068effb2ec4a94f089", "f8f543272f8c64ce42b3ec58a1417cd28a1086e08af4f5065508e0a956b67c9d", "f95d3809b1da007551d229c92897b7f42eeba4e2a20bdaf73ef2960ea54d615d", "15b4892e4ba194fd0d0eb8bfb5d297e150340f211e448e958a4df6d9f2496b98", "b790263bbde819192a94cc7c353ce9aa6c61b4a2984c6ed3fdea06a5dfe7007b", "c14c3023ddc3f33df7a328c6eab969753bbb3eae8281d8444b2f02bb691716e3", "8735ab937a1549b22327958a729934ef8b93fb96e71774d745eef7e3fefef4c1", "0fc8e59c96e166a4c42a339665496f594a9a3cf72a7ddc77e4a599ee13a85393", "27c0c14c2f92c0576bcf2c0479743b9339859690a003fa38f78f39bef2c89d46", "3cd7e5d27cd9b476ab8bbae9eeed68412de11f88e69a408a7a73bfb025ebc07d", "8ab042f5440ce60e0f89208e88d7b78d86d2a89ece869c1786771f08c7b4ccc2", "dff05a03b814e3de43863c164a05497ffc0d1713ad13ea581055fe1557ba477d", "efbf9a53dd45823d8e1f36e31ca275bc996a911c968aa149d149a202cb14164d", "8f27f5ba3350b8f5efaba28c5694eea31bca0f7296bb9c0797a2275f18b90269", "a81cd0bc50c18e5ba157ac682f774aa960bd11b7ea1389000996f25c45b86752", "8dfaeebd9a7b8c46bcd7e059f98fd1b98977b2a95ccb7ad3f0387459733971e8", "f0ee1b12b1f9a4e6178c44827ce6059420c486b67d7ca3366140bafc22c80598", "470f43cff2e3aad5603513b625eac0063cf420e1bc6cdf0aa3c1c4fb71736f58", "9be0f2c74de525c3b7d38d030e5b843bb77c79e1a9f924dd79c73da0215f56a3", "2f2a0288d1efe709835f5da8ab0b1303f49a69abdf1222694e13d7d5912e7c6f", "9a5d2ce78d908010ccc9955be7aea9947899eeafc71733102022759e8609e435", "70b51d5c1ae6280451005568313f31b330924aac0d94c562874b7dc53a47abf1", "2ab69bed37f821680bd7d73be104188d6fc207a58496c3431d4124bab595476c", "74b9afc8a3552fda94edf6b99aa7b82da0cca731414048058b6885ab872bbab1", "7f71c6d315aaa1ea7f30c8986d2d8bdb49d540de173dd958775d8c80131d8df2", "4db37453796cd3acf5489e80f491b9191c3a8abbddb5c7450f25be50d6e47af3" ], "time": 1511007107, "mediantime": 1510806460, "nonce": 1427084338, "bits": "180349c7", "difficulty": 334376642271.5151, "chainwork": "0000000000000000000000000000000000000000007cb2b96442a3194e68d5ab", "previousblockhash": "000000000000000000e56c9596b72a1afdecd29762ca0e75ea567696a79aebe9" } 
submitted by AcerbLogic to btc [link] [comments]

I'm out of this insanity, goodbye bitcoin

I was in the process of writing a websocket relay outside of bitcoin but it appears bitcoin has become paranoid and insane and sees conspiracy everywhere (when someone asks a legitimate question they call them a troll or a noob bullshit, and if this was any another potential user they would never use bitcoin)
hope this code is useful for someone
"use strict"; const util = require('util'); const Transform = require('stream').Transform; const fs = require('fs'); const path = require('path'); const net = require('net'); const async = require('async'); const ref = require('ref'); var clients = {}; var bitcoinServer = '????'; var magic = new Buffer('f9beb4d9','hex') function handleMessage(msg){ switch (msg.cmd){ case 'version': process.stdout.write("\n"); process.stdout.write(msg.dat.toString().replace(/\0/g, '')); break; case 'verack': break; case 'addr': break; case 'inv': break; case 'getdata': break; case 'notfound': break; case 'getblocks': break; case 'getheaders': break; case 'tx': break; case 'block': break; case 'headers': break; case 'getaddr': break; case 'mempool': break; case 'checkorder': break; case 'submitorder': break; case 'reply': break; case 'ping': process.stdout.write(" - "+ref.readInt64LE(msg.dat)); break; case 'pong': process.stdout.write(" - "+ref.readInt64LE(msg.dat)); break; case 'reject': break; case 'filterload': case 'filteradd': case 'filterclear': case 'merkleblock': break; case 'alert': break; case 'sendheaders': break; } } function streamHandler(tag) { if (!(this instanceof streamHandler)) return new streamHandler(tag); Transform.call(this); this._tag = tag; this._count = 0; this._lastChunk = null; this._currentMsg = null; } streamHandler.prototype._transform = function(chunk, encoding, done) { if (this._lastChunk){ chunk = Buffer.concat([this._lastChunk,chunk]); this._lastChunk = null; } if (chunk.length < 24){ // not long enough? console.log("short",chunk); this._lastChunk = chunk; this.push(chunk); return done(); } var startIdx = chunk.indexOf(magic); if (startIdx > -1){ while (startIdx > -1){ try{ if ((startIdx + 24) > chunk.length){ // not long enough? console.log("short!",chunk.slice(startIdx)); this._lastChunk = chunk.slice(startIdx); break; } this._currentMsg = { cmd: chunk.slice(startIdx+4, startIdx+16).toString().replace(/\0/g, ''), len: chunk.slice(startIdx+16, startIdx+20).readUInt32LE(), chk: chunk.slice(startIdx+20, startIdx+24).readUInt32LE(), dat: null } if (this._currentMsg.len){ this._currentMsg.dat = chunk.slice(startIdx+24, startIdx+this._currentMsg.len) } process.stdout.write("\n" + this._tag + this._currentMsg.cmd + ' ' + this._currentMsg.len + ' ' + this._currentMsg.dat.length); handleMessage(this._currentMsg); }catch(e){ console.trace(e); } startIdx = chunk.indexOf(magic, startIdx+24); } this.push(chunk); done(); }else{ if (++this._count>=10){ this._count=0; process.stdout.write("."); } this.push(chunk); done(); } } util.inherits(streamHandler, Transform); var clientQueue = async.queue(function (task, callback) { callback(); }, 1); var serverQueue = async.queue(function (task, callback) { callback(); }, 1); var server = net.createServer((socket) => { socket.key = socket.remoteAddress + ":" + socket.remotePort; clients[socket.key] = socket; socket.on('close', (err) => { console.log('socket.on.close',err); try{ client.destroy(); socket.destroy(); }catch(e){ console.log('socket.on.close',e); } delete clients[socket.key]; }); console.log('socket'); var client = net.connect({host: bitcoinServer, port: 8333}, () => { }); var packetBuf = null; var count = 0; var lastDataClient = null; var lastDataSocket = null; var clientParser = new streamHandler('-> '); var socketParser = new streamHandler('<- '); clientParser.pipe(socket); client.pipe(clientParser); socketParser.pipe(client); socket.pipe(socketParser); client.on('end', () => { console.log('disconnected from server'); }); client.on('error', (err) => { console.log('client error',err); }); socket.on('error', (err) => { try{ client.destroy(); socket.destroy(); }catch(e){ console.log('client.close',e); } }); }).on('error', (err) => { console.log('server error',err); }); server.listen({ host: 'localhost', port: 8334, exclusive: true }); 
What is bitcoin going to do when all of the people that really understand it go elsewhere?
Best of luck to everyone, guess my cashing out after 5 years of support was the right move
submitted by DaSpawn to btc [link] [comments]

Segregated Witness JSON-RPC API changes

Hi, I wonder what are the total changes we should expect to see in the JSON responses from the bitcoin JSON-RPC server as it will support Segregated Witness? As I see it we should have: 1. For each transaction input, a new field 'witness' which should contain what originally was the scriptSig or the redeem script in the p2wsh case. 2. Fore each transaction, its wtxid - the outcome of the hash of the serialization which includes the transaction witnesses. 3. For the coinbase transaction, an extra field in its input which is the merkle-root of all the witnesses serialization (will it override current 'coinbase' field, or will it be an extra field and if so how will it be called?) Questions: - did I get it right? - Will all the witnesses be part of the block-data (i.e. returned with getblock JSON-API response)? If so, would their length be as the sum of the number of all inputs, or as the number of the block trasnactions (and then each witness will be a concatenation of the transaction's inputs witnesses)? I'm asking because I'm building a block explorer which heavily relies on bitcoind JSON-RPC response calls.
submitted by oleiba to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
 
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to Bitcoincash [link] [comments]

Bitcoin Core 0.11.0 released | Wladimir J. van der Laan | Jul 12 2015

Wladimir J. van der Laan on Jul 12 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.11.0 is now available from:
<https://bitcoin.org/bin/bitcoin-core-0.11.0/>
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
<https://github.com/bitcoin/bitcoin/issues>
The entire distribution is also available as torrent:
magnet:?xt=urn:btih:82f0d2fa100d6db8a8c1338768dcb9e4e524da13&dn;=bitcoin-core-0.11.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F 
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrade warning
Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.
Important information

Transaction flooding
At the time of this release, the P2P network is being flooded with low-fee
transactions. This causes a ballooning of the mempool size.
If this growth of the mempool causes problematic memory use on your node, it is
possible to change a few configuration options to work around this. The growth
of the mempool can be monitored with the RPC command getmempoolinfo.
One is to increase the minimum transaction relay fee minrelaytxfee, which
defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be
rejected, and thus fewer transactions entering the mempool.
The other is to restrict the relaying of free transactions with
limitfreerelay. This option sets the number of kB/minute at which
free transactions (with enough priority) will be accepted. It defaults to 15.
Reducing this number reduces the speed at which the mempool can grow due
to free transactions.
For example, add the following to bitcoin.conf:
minrelaytxfee=0.00005 limitfreerelay=5 
More robust solutions are being worked on for a follow-up release.
Notable changes

Block file pruning
This release supports running a fully validating node without maintaining a copy
of the raw block and undo data on disk. To recap, there are four types of data
related to the blockchain in the bitcoin system: the raw blocks as received over
the network (blk???.dat), the undo data (rev???.dat), the block index and the
UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once
it's been validated and used to build the databases. At that point, the raw data
is used only to relay blocks to other nodes, to handle reorganizations, to look
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
for rescanning the wallet. The block index continues to hold the metadata about
all blocks in the blockchain.
The user specifies how much space to allot for block & undo files. The minimum
allowed is 550MB. Note that this is in addition to whatever is required for the
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
minutes per block). In rare instances it is possible that the amount of space
used will exceed the pruning target in order to keep the required last 288
blocks on disk.
Block pruning works during initial sync in the same way as during steady state,
by deleting block files "as you go" whenever disk space is allocated. Thus, if
the user specifies 550MB, once that level is reached the program will begin
deleting the oldest block and undo files, while continuing to download the
blockchain.
For now, block pruning disables block relay. In the future, nodes with block
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
active chain.
Block pruning is currently incompatible with running a wallet due to the fact
that block data is used for rescanning the wallet and importing keys or
addresses (which require a rescan.) However, running the wallet with block
pruning will be supported in the near future, subject to those limitations.
Block pruning is also incompatible with -txindex and will automatically disable
it.
Once you have pruned blocks, going back to unpruned state requires
re-downloading the entire blockchain. To do this, re-start the node with
  • -reindex. Note also that any problem that would cause a user to reindex (e.g.,
disk corruption) will cause a pruned node to redownload the entire blockchain.
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
and rev???.dat files in the data directory prior to restarting the download.
To enable block pruning on the command line:
  • - -prune=N: where N is the number of MB to allot for raw block & undo data.
Modified RPC calls:
    • getblockchaininfo now includes whether we are in pruned mode or not.
    • getblock will check if the block's data has been pruned and if so, return an
error.
  • - getrawtransaction will no longer be able to locate a transaction that has a
UTXO but where its block file has been pruned.
Pruning is disabled by default.
Big endian support
Experimental support for big-endian CPU architectures was added in this
release. All little-endian specific code was replaced with endian-neutral
constructs. This has been tested on at least MIPS and PPC hosts. The build
system will automatically detect the endianness of the target.
Memory usage optimization
There have been many changes in this release to reduce the default memory usage
of a node, among which:
    • Accurate UTXO cache size accounting (#6102); this makes the option -dbcache
    precise where this grossly underestimated memory usage before
    • Reduce size of per-peer data structure (#6064 and others); this increases the
    number of connections that can be supported with the same amount of memory
    • Reduce the number of threads (#5964, #5679); lowers the amount of (esp.
    virtual) memory needed
Fee estimation changes
This release improves the algorithm used for fee estimation. Previously, -1
was returned when there was insufficient data to give an estimate. Now, -1
will also be returned when there is no fee or priority high enough for the
desired confirmation target. In those cases, it can help to ask for an estimate
for a higher target number of blocks. It is not uncommon for there to be no
fee or priority high enough to be reliably (85%) included in the next block and
for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.
Privacy: Disable wallet transaction broadcast
This release adds an option -walletbroadcast=0 to prevent automatic
transaction broadcast and rebroadcast (#5951). This option allows separating
transaction submission from the node functionality.
Making use of this, third-party scripts can be written to take care of
transaction (re)broadcast:
    • Send the transaction as normal, either through RPC or the GUI
    • Retrieve the transaction data through RPC using gettransaction (NOT
    getrawtransaction). The hex field of the result will contain the raw
    hexadecimal representation of the transaction
    • The transaction can then be broadcasted through arbitrary mechanisms
    supported by the script
One such application is selective Tor usage, where the node runs on the normal
internet but transactions are broadcasted over Tor.
For an example script see [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx).
Privacy: Stream isolation for Tor
This release adds functionality to create a new circuit for every peer
connection, when the software is used with Tor. The new option,
-proxyrandomize, is on by default.
...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009400.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

[Informational] [CC0] Plug In To The Bitcoin Network

Bitcoin Peer to Peer Network Protocol

The Bitcoin network is designed to operate in a peer to peer configuration, in a reflection of the overall decentralized design of the system. The network goal is to sync the Blockchain, the transaction record and payment settlement system through which Bitcoins are minted and exchanged with Bitcoin users. A high level view of the network is that of a wide array of individual peers, each helping to broadcast updated Blockchain information across the entire group.
The broadcast sync of the Blockchain and the network setup and operational action are accomplished through a narrow network protocol, consisting of a small set of messages. Most messages are designed with pushing data in mind, to continue to propagate waves of updated Blockchain and peer data to local peers and across the greater network.

Connecting

All Bitcoin network communication occurs using TCP, the standard Internet protocol for reliable networking. Bitcoin has supported the IPv6 standard since September of 2012, and can be used over a user selected port, with the default being 8333.
When a Bitcoin node is instantiated for the first time, it needs to find a way to connect to the greater network. At the start of the project, new nodes would automatically connect to a hard-coded IRC server, with IRC channels being used to publish and discover IP addresses of network nodes. This bootstrapping process was created in 2011, complementing the IRC system it would ultimately wholly replace. In this system hard-coded DNS address based seeds are resolved to the IP addresses of seed nodes to direct a new node onto the network. Since 2012 Bitcoin Core developers Luke-Jr and Pieter Wuille have operated seed nodes, along with various others over the years.
When connecting to a node IP, a Bitcoin node will send its version as the initial message, in a handshaking process where information about its makeup including its current clock value is published to the remote node. The specific messages used are version, which sends the node information, and verack, which acknowledges the receipt of the version information. This handshake helps a node define a normalized network clock value: time calculations a node makes are based not off of its own clock, but rather the median time from all successfully connected peers.
After the initial bootstrapped connection onto the network, previously connected-to peers as well as relayed known local active peer information is cached. Nodes are designed to recall other nodes in an archival list. This list of node IPs is cached in order to bypass the node seed stage on subsequent starts. On each network join, a node will consult its cache of nodes, semi-randomly selecting nodes to attempt to connect to, with a prioritization of most recently active.

Syncing

Once nodes have successfully joined the network, they are then faced with their primary task of syncing the Blockchain. The workhorse message that helps a node accomplish this task is the inventory or more precisely inv message, which a node uses to push listings of blocks and transactions to connected peers. Inventory messages are simply concise high level identification information, they do not carry any information beyond a listing of blocks and transactions. These messages are published constantly, as novel blocks and transactions are validated and then pushed to other peers to relay the new information.
Specific inventory messages may be requested directly from a connected peer using the getblocks message that queries about a specific set of blocks. This message is used to sync nodes that are out of date, such as nodes that are new to the network and must sync the entire blockchain through a long series of getblocks requests.
When an inventory message is received, listed inventory of blocks and transactions may be requested through the getdata request. This is generally performed when a node receives an inventory message containing novel block or transaction information. In response to the getdata response the node returns with a block or tx message, sending blocks and transactions respectively.

Syncing to Light Clients

Full nodes may also service the syncing needs of light clients, which some call SPV clients after a general proposal made by Satoshi in the original Bitcoin whitepaper. These clients avoid validating the blockchain to provide a more practical user experience at the cost of incurring counter-party risk of an abusive miner or set of miners.
Filter message features so that full node could service requests for light clients were added through BIP 37. Light clients uses the getheaders message to request that full nodes return Blockchain headers information which are sent using the headers message. The chain of Blockchain headers are used to piece together the chain with the greatest proof of work. This is used to verify transactions as being on the longest chain of blocks, with the important caveat that it may be an invalid chain.
Light clients also use bloom messages to request transactions that they care about, they do not ask directly for transactions in an effort to add some slight privacy to the client's financial status, however these efforts have only a small impact and are not comprehensive.

Peer Announcements

In addition to syncing the Blockchain, the Bitcoin network syncs information about the IP addresses that comprise the network, to provide for sustainable connectivity. Nodes publish to other nodes the set of active peers they know about using the addr message, which can contain a list of up to a thousand known active nodes. Nodes can also ask other nodes for an addr message using a getaddr message. Every twenty four hours every node will broadcast a heartbeat addr message, which is passed along to two connected nodes.
General network connectivity may also be tested by a node using the ping message, which does nothing other than attempt a connection to verify connectivity.

Obsolete Messages

In the original Bitcoin protocol, support was present for an IP based sending system. The concept allowed connecting to a node directly to make a transaction. To accomplish that task nodes used messages that were later deprecated and removed. IP based sending was eliminated very early on due to security, privacy, and practicality issues.
Although the Bitcoin network was designed as a group of headless automatons, early in its life various critical defects were found that required aggressive central action to remedy. As a practical solution to facilitate the rapid deployment of requisite fixes, Satoshi Nakamoto devised an alerting system for sending version update messages across the node network.
This system used a protocol message called alert to directly broadcast a signed message from Satoshi, to be shown to users to inform them of critical information. To avoid a singular dependency Satoshi shared the signing key with others, which over time became an unnecessary risk to the network. In April of 2016 the release of Bitcoin Core version 0.12.1 eliminated the alert system.
submitted by pb1x to writingforbitcoin [link] [comments]

Facilitating Discussion of 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT)

To facilitate a detailed discussion of some of the finer points of this update, I added numbering to each bullet in release notes, and also posted it to RapGenius, where people can annotate it if they'd like.
I'm not a programmer, but I'm curious to hear what programmers and other people smarter than me have to say about all the new changes.
http://rapgenius.com/The-bitcoin-dev-team-bitcoin-090-final-lyrics
EDIT1 : Doh! Reddit detroyed all the formatting and now i'm on baby duty so can't fix it. EDIT 2: Nap time! Just fixed the formatting :)
---- 0.9.0 RELEASE NOTES ----
Part 1. RPC:
1.1 - New notion of 'conflicted' transactions, reported as confirmations: -1
1.2 - 'listreceivedbyaddress' now provides tx ids
1.3 - Add raw transaction hex to 'gettransaction' output
1.4 - Updated help and tests for 'getreceivedby(account|address)'
1.5 - In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility
1.6 - Add 'verifychain', to verify chain database at runtime
1.7 - Add 'dumpwallet' and 'importwallet' RPCs
1.8 - 'keypoolrefill' gains optional size parameter
1.9 - Add 'getbestblockhash', to return tip of best chain
1.10 - Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output
1.11 - Make RPC password resistant to timing attacks
1.12 - Clarify help messages and add examples
1.13 - Add 'getrawchangeaddress' call for raw transaction change destinations
1.14 - Reject insanely high fees by default in 'sendrawtransaction'
1.15 - Add RPC call 'decodescript' to decode a hex-encoded transaction script
1.16 - Make 'validateaddress' provide redeemScript
1.17 - Add 'getnetworkhashps' to get the calculated network hashrate
1.18 - New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output
1.19 - Adding new 'addrlocal' field to 'getpeerinfo' output
1.20 - Add verbose boolean to 'getrawmempool'
1.21 - Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
1.22 - Explicitly ensure that wallet is unlocked in importprivkey
1.23 - Add check for valid keys in importprivkey
Part 2. Command-line options:
2.1 - New option: -nospendzeroconfchange to never spend unconfirmed change outputs
2.2 - New option: -zapwallettxes to rebuild the wallet's transaction information
2.3 - Rename option '-tor' to '-onion' to better reflect what it does
2.4 - Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet)
2.5 - Update default '-rpcsslciphers' to include TLSv1.2
2.6 - make '-logtimestamps' default on and rework help-message
2.7 - RPC client option: '-rpcwait', to wait for server start
2.8 - Remove '-logtodebugger'
2.9 - Allow -noserver with bitcoind
Part 3. Block-chain handling and storage:
3.1 - Update leveldb to 1.15
3.2 - Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded)
3.3 - Allow txindex to be removed and add a reindex dialog
3.4 - Log aborted block database rebuilds
3.5 - Store orphan blocks in serialized form, to save memory
3.6 - Limit the number of orphan blocks in memory to 750
3.7 - Fix non-standard disconnected transactions causing mempool orphans
3.8 - Add a new checkpoint at block 279,000
Part 4. Wallet:
4.1 - Bug fixes and new regression tests to correctly compute the balance of wallets containing double-spent (or mutated) transactions
4.2 - Store key creation time. Calculate whole-wallet birthday
4.3 - Optimize rescan to skip blocks prior to birthday
4.4 - Let user select wallet file with -wallet=foo.dat
4.5 - Consider generated coins mature at 101 instead of 120 blocks
4.6 - Improve wallet load time
4.7 - Don't count txins for priority to encourage sweeping
4.8 - Don't create empty transactions when reading a corrupted wallet
4.9 - Fix rescan to start from beginning after importprivkey
4.10 - Only create signatures with low S values
Part 5. Mining:
5.1 - Increase default -blockmaxsize/prioritysize to 750K/50K
5.2 - 'getblocktemplate' does not require a key to create a block template
5.3 - Mining code fee policy now matches relay fee policy
Part 6. Protocol and network:
6.1 - Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
6.2 - Send tx relay flag with version
6.3 - New 'reject' P2P message (BIP 0061, see https://gist.github.com/gavinandresen/7079034 for draft)
6.4 - Dump addresses every 15 minutes instead of 10 seconds
6.5 - Relay OP_RETURN data TxOut as standard transaction type
6.6 - Remove CENT-output free transaction rule when relaying
6.7 - Lower maximum size for free transaction creation
6.8 - Send multiple inv messages if mempool.size > MAX_INV_SZ
6.9 - Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and MIN_PEER_PROTO_VERSION
6.10 - Do not treat fFromMe transaction differently when broadcasting
6.11 - Process received messages one at a time without sleeping between messages
6.12 - Improve logging of failed connections
6.13 - Bump protocol version to 70002
6.14 - Add some additional logging to give extra network insight
6.15 - Added new DNS seed from bitcoinstats.com
Part 7. Validation:
7.1 - Log reason for non-standard transaction rejection
7.2 - Prune provably-unspendable outputs, and adapt consistency check for it
7.3 - Detect any sufficiently long fork and add a warning
7.4 - Call the -alertnotify script when we see a long or invalid fork
7.5 - Fix multi-block reorg transaction resurrection
7.6 - Reject non-canonically-encoded serialization sizes
7.7 - Reject dust amounts during validation
7.8 - Accept nLockTime transactions that finalize in the next block
Part 8. Build system:
8.1 - Switch to autotools-based build system
8.2 - Build without wallet by passing --disable-wallet to configure, this removes the BerkeleyDB dependency
8.3 - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more recent versions
8.4 - Windows 64-bit build support
8.5 - Solaris compatibility fixes
8.6 - Check integrity of gitian input source tarballs
8.7 - Enable full GCC Stack-smashing protection for all OSes
Part 9. GUI:
9.1 - Switch to Qt 5.2.0 for Windows build
9.2 - Add payment request (BIP 0070) support
9.3 - Improve options dialog
9.4 - Show transaction fee in new send confirmation dialog
9.5 - Add total balance in overview page
9.6 - Allow user to choose data directory on first start, when data directory ismissing, or when the -choosedatadir option is passed
9.7 - Save and restore window positions
9.8 - Add vout index to transaction id in transactions details dialog
9.9 - Add network traffic graph in debug window
9.10 - Add open URI dialog
9.11 - Add Coin Control Features
9.12 - Improve receive coins workflow: make the 'Receive' tab into a form to request payments, and move historical address list functionality to File menu
9.13 - Rebrand to Bitcoin Core
9.14 - Move initialization/shutdown to a thread. This prevents "Not responding" messages during startup. Also show a window during shutdown
9.15 - Don't regenerate autostart link on every client startup
9.16 - Show and store message of normal bitcoin:URI
9.17 - Fix richtext detection hang issue on very old Qt versions
9.18 - OS X: Make use of the 10.8+ user notification center to display Growl-like notifications
9.19 - OS X: Added NSHighResolutionCapable flag to Info.plist for better font rendering on Retina displays
9.20 - OS X: Fix bitcoin-qt startup crash when clicking dock icon
9.21 - Linux: Fix Gnome bitcoin: URI handler
Part 10. Miscellaneous:
10.1 - Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
10.2 - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC
10.3 - Add 'linearize.py' script to contrib, for creating bootstrap.dat
10.4 - Add separate bitcoin-cli client
submitted by WhiteyFisk to Bitcoin [link] [comments]

Bitcoin-QT 0.9 disponível para download

The Core Developers of Bitcoin released the 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT).
DOWNLOAD:
This is a Final Version, but its the same as 0.9.0rc3
Sources: https://github.com/bitcoin/bitcoin/releases http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.9.0/ https://bitcoin.org/bin/0.9.0/README.txt
Bitcoin Core version 0.9.0 is now available from:
https://bitcoin.org/bin/0.9.0/
This is a release candidate for a new major version. A major version brings both new features and bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).
If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine.
On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version.

Windows 64-bit installer

New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it.
NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP and the SHA256SUMS.asc file to make sure your binaries are correct. In the final 0.9.0 release, Windows setup.exe binaries will be code-signed.

OSX 10.5 / 32-bit no longer supported

0.9.0 drops support for older Macs. The minimum requirements are now: * A 64-bit-capable CPU (see http://support.apple.com/kb/ht3696); * Mac OS 10.6 or later (see https://support.apple.com/kb/ht1633).

Downgrading warnings

The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9 and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs).
Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem.
Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine).

Rebranding to Bitcoin Core

To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core.

Autotools build system

For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles.
Using the standard "./autogen.sh; ./configure; make" to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project.
Be sure to check doc/build-*.md for your platform before building from source.

Bitcoin-cli

Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality ("tell the running bitcoin daemon to do THIS") was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.

walletpassphrase RPC

The behavior of the walletpassphrase RPC when the wallet is already unlocked has changed between 0.8 and 0.9.
The 0.8 behavior of walletpassphrase is to fail when the wallet is already unlocked:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays) 
The new behavior of walletpassphrase is to set a new unlock time overriding the old one:
> walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time) 

Transaction malleability-related fixes

This release contains a few fixes for transaction ID (TXID) malleability issues:

Transaction Fees

This release drops the default fee required to relay transactions across the network and for miners to consider the transaction in their blocks to 0.01mBTC per kilobyte.
Note that getting a transaction relayed across the network does NOT guarantee that the transaction will be accepted by a miner; by default, miners fill their blocks with 50 kilobytes of high-priority transactions, and then with 700 kilobytes of the highest-fee-per-kilobyte transactions.
The minimum relay/mining fee-per-kilobyte may be changed with the minrelaytxfee option. Note that previous releases incorrectly used the mintxfee setting to determine which low-priority transactions should be considered for inclusion in blocks.
The wallet code still uses a default fee for low-priority transactions of 0.1mBTC per kilobyte. During periods of heavy transaction volume, even this fee may not be enough to get transactions confirmed quickly; the mintxfee option may be used to override the default.

0.9.0 Release notes

RPC:
Command-line options:
Block-chain handling and storage:
Wallet:
Mining:
Protocol and network:
Validation:
Build system:
GUI:
submitted by allex2501 to BrasilBitcoin [link] [comments]

You are being LIED TO about BITCOIN 🚨DON'T BE FOOLED ... How To Get FREE Bitcoin Fast!  Free BTC in 2019/2020 ... Visualizing Bitcoin Blockchain Block Hashes What is Bitcoin? Bitcoin Explained Simply for Dummies ... Bitcoin Q&A: Block height, syncing, and validation

Bitcoin broke new heights to touch February 2020 highs but swiftly came down to yesterday’s levels closer to USD 9,500 Libra-like digital money competitors will be coming in the near future, says a16z Coin Metrics data suggests Bitcoin’s exponential volume growth will place it on par with other assets Bitcoin made the news today when it broke above USD 10,000 … Bitcoin News is the world's premier 24/7 news feed covering everything bitcoin-related, including world economy, exchange rates and money politics. Bitcoin (BTC) News, Guides And Information Bitcoin (BTC) price, information, updates, and more. BTC is a cryptocurrency which was invented by Satoshi Nakamoto in 2009. What is Bitcoin? >At the time, Bitcoin price was far under $1 US. Bitcoin (BTC) News. One of the fastest growing cryptocurrencies in the world, Bitcoin (BTC) has turned out to be a game changer in the world of digital currency. One of the best things about Bitcoin (BTC) is that it can be sent from any one user to another or from one peer network to another without the need for any kind of intermediary. The transactions that are done through this form of ... GetBlock is a provider of blockchain nodes. Connect to Bitcoin, Ethereum, Monero and other nodes with JSON-RPC, REST, and WebSockets. All nodes have an open API and available for connection. Get a free API key right now!

[index] [40688] [19475] [15870] [11915] [36817] [15656] [48825] [48659] [9648] [37501]

You are being LIED TO about BITCOIN 🚨DON'T BE FOOLED ...

In this video, I show you How To Get FREE Bitcoin Fast! This is NOT anything related to Bitcoin Faucets. If you are looking for those look elsewhere. This is... Follow these steps to instantly buy Bitcoin with your Blockchain wallet. You can start by visiting blockchain.com and setting up your free wallet. 🔥 TOP Crypto TIPS In My Newsletter 👉 https://signup.coinbureau.com/newsletter 💰 Get A Ruby Card Or Better & Get $50 FREE Here 👉 https://www.coinbureau.com ... Subscribe to the channel to learn more about Bitcoin & open blockchains; click on the red bell to enable notifications about new videos! MASTERING BITCOIN, 2nd Edition: https://amzn.to/2xcdsY9 Follow Altcoin Daily: https://www.youtube.com/channel/UCbLhGKVY-bJPcawebgtNfbw/videos Protect your crypto with a Ledger - the world’s best hardware wallet: h...

#