Mining — Bitcoin

Observe for yourself: Segwit allows 2 MB blocks in the typical scenario

Basic English explanation of the process

To demonstrate this, I take each block, figure out the average transaction size and weight, calculate how many of these segwit would allow in a block, and then measure the total sizes of them.
Because the generation transaction is inherently unusual, and few transactions make too small a sample size to be meaningful, I exclude blocks with fewer than 16 transactions (ie, empty blocks).
Finally, I take the average of these segwit block sizes.

The result

25th pct: 1807737 Average: 1890429.153079902 90th pct: 2062659 Largest: 2816041 
Yes, 1.890429 MB is close enough that I'm going to round it up to 1.9 MB or even 2 MB considering the Notes below.

How to reproduce this

Note I do all this stuff on Linux. If you don't know how to use Linux yet, get a Raspberry Pi and learn. ;)
1. Build custom bitcoind to calculate max segwit block sizes.
Apply this patch to your bitcoin code and recompile:
curl | patch -p1 make 
2. Generate table of max segwit block sizes.
[Re]start your custom bitcoind, and for each block, print its height, block hash, max segwit block size, and transaction count.
first_block=412404 last_block=465000 while [ $first_block -le $last_block ]; do blkhash=$(bitcoin-cli getblockhash $first_block); echo "$first_block $blkhash $(bitcoin-cli getblock $blkhash | python -c 'import json, sys; j = json.load(sys.stdin); print("%d %d" % (j["segwit_equiv_hack"], len(j["tx"])))')"; let first_block=first_block+1; done > data 
This is looking at the last 1 year of blocks.
3. Calculate average (and other stats) of statistically-useful max segwit block sizes.
Save this Python script to a file, then run it: python < data


  1. These statistics are assuming every single block is full, and with the same ratio of spam/non-spam as presently. In a less extreme scenario, if a block maxed out at 1.8 MB, the 200k of transactions left would simply get mined in a 2.2+ MB block instead since the average block size wouldn't be the average filled block size.
  2. The network currently does not have any Lightning or sidechain usage yet. It is likely these will weigh heavier on witness data, and thereby expand the block sizes further, possibly even hitting 3 MB.
submitted by luke-jr to Bitcoin [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]

Testnet is currently on non-BIP101 (legacy) chains. More fork tests will follow.

We turned off the hashpower on the BIP101 fork at the end of our testing today. After I went to sleep, it seems someone started hashing on the legacy fork, and the work on that chain overtook the BIP101 fork. These are from an XT node that I know was following the big-block fork, and has several 9 MB blocks in its database:
./bitcoin-cli getblock 000000003199e2651d08bb2282d0896128d04ac3bf82f344d3ab92bf0061c80b | grep height "height" : 585471 ./bitcoin-cli getblockhash 585471 0000000000324544abe2531548faec6525a856999f3b46ecf9128a3f5b273d24 
Those are not the same hash. Not the same block. The first block was orphaned at height 585471, but the second block is currently confirmed. Here's another interesting block for the records:
./bitcoin-cli getblock 0000000015cbe557995bf95861d66231d01513ba99f06d23854522272c9049c3 | less "hash" : "0000000015cbe557995bf95861d66231d01513ba99f06d23854522272c9049c3", "confirmations" : -1, "size" : 9115445, "height" : 586921, "version" : 536870919, "merkleroot" : "6fcc61f29be259c74bc95e8f57c249678572b82b343b6b2bb62897ce1cfd7283", tx: [ .... (9.1 MB of tx go here) ... ] "time" : 1447195582, "nonce" : 3149336320, "bits" : "1c276440", "difficulty" : 6.49874805, "chainwork" : "0000000000000000000000000000000000000000000000067d572257e0d8ef4b", "previousblockhash" : "0000000020e32b6f8f80950b3bb888294a8ece8e61b6ee4b0fed6800d0a44209" } 
That's from a sequence of (IIRC) about five 9.1 MB blocks that we mined over the course of 7 minutes. It's since been reorged out by an empty Legacy block:
./bitcoin-cli getblock `./bitcoin-cli getblockhash 586921` { "hash" : "00000000004572422af0fd54ac158ff430bf60003c54db27eb2e953d4ae2aa4c", "confirmations" : 14985, "size" : 262, "height" : 586921, "version" : 4, "merkleroot" : "857b0723d7999341cd0b9ff9fa0e112dbbb19535dc32c7f06d3721a528c0021a", "tx" : [ "857b0723d7999341cd0b9ff9fa0e112dbbb19535dc32c7f06d3721a528c0021a" ], "time" : 1447140611, "nonce" : 2663112535, "bits" : "1c24a880", "difficulty" : 6.98332357, "chainwork" : "00000000000000000000000000000000000000000000000677759d3b1ee4737d", "previousblockhash" : "00000000007947bac4fb9dbc759704958bc38c2050f7cd236c2a7e0b8c859958", "nextblockhash" : "000000000048c36f0ed2bb68145ea4376ed4facfbbc020726204162f95692387" } 
The second block was mined 54971 seconds or 15.27 hours later.
So far, the testnet chain has forked twice when it should have, and it has reorged twice when it should have. The first reorg was caused by us switching to Core to overtake the BIP101 branch. The second reorg was caused by us switching off our hashpower, and someone else overtaking the BIP101 branch. So far I have not found any behavior that is incorrect.
Edit Nov 12th: We're currently focusing on developing tools to collect data from subsequent tests right now. We should be able to fork pretty much whenever we want as long as we leave the hashrate off when we're not using it. If we leave the hashrate on, it's (a) expensive, and (b) harder to test the forking behavior since we'd have to hash on Core to get it to catch up first.
submitted by jtoomim to bitcoinxt [link] [comments]

PSA: If you want to run a "full" node but don't have much disk space

...simply delete the old blk0***.dat files from your blocks directory after bitcoin-qt is done indexing them.
(or rename them if you want to test without having to redownload the blockchain)
This will work perfectly fine if you are not doing anything obscure. If a peer tries to load a block from you which you deleted your node will simply ignore the request. (see this private testnet test)
However, it will crash if you open the development console and use the getblock command to retrieve a deleted block, so don't do that.
Cases I have not tested yet:
For technical reasons I can't try a -rescan now, can anyone check what happens in such a case so we can fix any bugs that might have been overseen?
worst case scenario: it will crash and you'll have to restore the deleted/renamed blocks.
Edit: not sure if this works for p2pool mining as without the blocks and without full txindex you can't verify the transaction chains. is this necessary or does this only matter to p2pool operators, not miners?
Edit2: miners don't need the blockchain, deleting (or renaming..) blocks will work fine :) (just remember to let it finish indexing a blk file before you delete it)
Edit3: I think the confusion stems from the fact that 387943 thought the merkle tree was stored in the blk*.dat files :D
duh, i knew nobody could be seriously this retarded.
btw, BTCisGod is a real bitcoiner, he was just asking legit questions so don't hate him. he's not connected to the insane number.
submitted by iuoiuo to Bitcoin [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.
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 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.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
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/ to limit outgoing bandwidth
10.2 - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC
10.3 - Add '' script to contrib, for creating bootstrap.dat
10.4 - Add separate bitcoin-cli client
submitted by WhiteyFisk to Bitcoin [link] [comments]


I'm working on enabling merge mining for the Prohashing mining pool. I've spent 45 hours trying to get the dogecoin daemon to accept a merge mined block, with no success. I'm posting my progress in this post, in the hopes that someone who has experience in merge mining can figure out what is wrong. I'll tip the first person $50 in DOGE (about 180,000 DOGE at current rates) who can tell me what is wrong with what I'm doing. If there are multiple issues, then I'll split the reward amongst all the helpers.
I simplified the procedure by removing the parts of the algorithm that are irrelevant.
Here is the procedure I used:
  1. Get the latest block from the litecoin testnet and store its data in memory.
  2. Call getauxblock against the dogecoin testnet. Since this example is only going to merge mine dogecoins, we ignore "chainid" and store only "hash" in memory. "Target" is obtained by calling getblocktemplate, because we need difficulty and other things from the full template for calculating payouts. "Target" in getauxblock and in getblocktemplate are reversed, so the appropriate conversion is made.
  3. When a block is found for the litecoin testnet, check to see whether the target is less than the dogecoin testnet's target. If so, we call getauxblock again, passing the "hash" exactly as provided in step 2, without any modification, and the serialized block data as the second parameter. The help for the command states that the parameters are "getauxblock [hash] [auxpow]."
The result is that the litecoin blocks are always accepted, and the dogecoin blocks are always rejected with the following errors:
2014-10-09 02:37:45 ERROR: Aux POW merkle root incorrect 2014-10-09 02:37:45 ERROR: AUX POW is not valid 
Here is an example "auxpow" serialized block that is submitted to the dogecoin damon. I annotated it as I think is correct, but keep in mind that the annotations could be incorrect and you shouldn't assume that I have identified the correct things to insert or the correct order. In the real submission, there are no spaces or characters between the separated sections.
Litecoin coinbase transaction:
Double-SHA-256 hash of the litecoin block header:
The length of the merkle branch from the litecoin block, which is the same as the branch sent out in the stratum protocol. Because this litecoin block has no transactions, the length of the merkle branch is zero:
The litecoin merkle branch, if there were one, would go here in a series of hashes. Since there are no transactions in the block other than the coinbase transaction, we append nothing here.
[There is nothing here] 
The "branch side mask" of the coinbase transaction, which is always zeroes:
The auxiliary branch count, which is zero because we are only mining dogecoins in this example:
The auxiliary branch index, which is also zero because we are only mining dogecoins:
The block header of the litecoin block, in full:
I'll also break down my understanding of what is supposed to be placed in the litecoin coinbase transaction to signify that we are merge mining dogecoins. Here is my understanding of the litecoin coinbase transaction's merge mining portion, which you can find embedded within the coinbase transaction printed above:
This string signifies that we are merge mining.
The "hash" parameter obtained from the dogecoin daemon's getauxblock command, verbatim:
The following are used for when multiple merge-mined coins are being sought at the same time, but since we are only merge-mining dogecoins, this is a 4-byte 1 followed by a 4-byte 0.
Here are some of the things I tried and the references I used.
  1. seems to be the primary source on merge mining. However, I noticed that some of the examples in the document don't work with dogecoins. For example, the "block hash" in the auxiliary proof of work that is submitted to namecoin in that document (the second field) looks like the proof of work hash for the block, since it ends in a string of zeroes. Looking at that, I tried placing the scrypt proof of work hash in that field, but it didn't work.
My understanding of the "block hash" is that when you call getblock from a daemon, you provide the double SHA-256 hash of the block header, not the scrypt proof of work hash. The "block hash" is not the scrypt proof of work hash.
  1. I tried reversing various hashes in the fields of the blocks on the theory that endianness was the problem, but 16 different permutations didn't work. I tried reversing the dogecoin auxiliary hash, the block hash, the merkle branch hashes (when there are transactions in the litecoin block, which there are not in this example), and even the block header of the litecoin block. None of these things worked. I couldn't find a permutation of reversed and non-reversed hashes that made any difference. Of course, it is possible that, since there are so many permutations, that I missed the correct one and the hashes are not in the correct endianness in the example.
  2. At, there is a poster who offers advice on how to submit merge mined blocks to getauxblock, although that information is specific to namecoin. I reviewed what I was doing and it appears to be identical to what he is suggesting.
  3. After reviewing the documentation for what a merkle tree is, it took me an entire day to figure out what happens when there are an odd number of transactions in the tree. It turns out that the algorithm is to hash the nodes with themselves. Seeing this, I took the example above and I tried specifying the length of the "merkle branch" for the coinbase transaction as "01," and then provided the hash of the coinbase transaction as the only hash in the "merkle branch." The long-shot idea was that perhaps the dogecoin daemon was looking to hash the coinbase transaction with itself, and use that as the root of the tree. It still returned the same error.
  4. In the litecoin coinbase transaction, the 44-byte merge mining part (fabe + "mm") is preceded by the length (44, or 2c) in some examples, but not in others. Apparently, this length is not necessary if the merge mining string is provided within the first 20 characters of the script, so I left it out in this example. However, in previous iterations, I added an additional byte of "2c" before the merge mining portion and it did not result in any difference in this error.
  5. In these examples, I always assumed that the merkle branches are double-sha256 hashes, even for scrypt coins. All the documentation I read seems to indicate that in scrypt, the only difference is the algorithm used to verify work. From what I can tell, the rest of the block still is stored using SHA-256 hashes, as is the hash of the block headers and even the hashes of the transactions. If there is some difference between scrypt and SHA-256 in how the merge mining headers are stored, that could be a clue.
Thanks to anyone who is willing to try to point out what is wrong here. We have about 15 features ready for release and merge mining is the only one that is holding back the release. Your help is greatly appreciated.
submitted by chris_sokolowski to test [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).
This is a Final Version, but its the same as 0.9.0rc3
Bitcoin Core version 0.9.0 is now available from:
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:

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; * Mac OS 10.6 or later (see

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 "./; ./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.


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

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

ASIC Block Erupter (336 mh/s!) Visualizing Bitcoin Blockchain Block Hashes Bitcoin and cryptocurrency mining explained - YouTube Blockchain in Bitcoin mining. Block Cryptocurrency Mining In Your Web Browser

With bitcoin price goes up, more people joined the mining industry.At present it is hard to mine with the difficulties of mining increased. Large-scale mining era Currently, we can see professional mining farms with thousands of miners and full-time maintenance personnel who work for 24 hours a day.The stable temperature and humidity in the environment is required to keep the machines running ... Bitcoin Mining Operations Need Renewable Energy; Cloud Mining: Here’s How You Can Mine Bitcoin or Altcoins without the Mining Rigs; Wish to make YOUR CONTENT VIRAL Want to submit a PRESS RELEASE GET IN TOUCH. Crypto Prices. zrx. $0.4328 (10.33%) btc. $12868.5 (-1.56%) esbc. $0.01817 (0.42%) eth. $407.66 (-2.42%) lno. $0.01287 (-19.89%) scriv . $0.00029 (1.66%) Your Name. Your Mail. SUBSCRIBE ... Mining. Adding new blocks to the blockchain. Mining is the process of trying to add a new block of transactions on to the blockchain.It is basically a network-wide competition where any node on the network can work to try and add the next block on to the chain.. Each newly-mined block is broadcast across the network, where each node independently verifies it before adding it on to their ... Bitcoin mining nodes. All Bitcoin nodes can be divided into two types: lightweight nodes and full nodes. Lightweight nodes are for those users who send and receive crypto. They pay for transactions and don’t keep the whole blockchain on their computers. Full nodes are another story. They verify Bitcoin transactions and protect the network from being attacked. To determine who is going to ... Bitcoin is unique, however, since the block reward schedule is public. All Bitcoin users and miners know the approximate date of each halving, meaning the Bitcoin price may not be affected when the halving happens. Bitcoin’s first block halving happened on November 28, 2012. The block reward dropped from 50 bitcoins per block to 25 per block ...

[index] [35894] [35824] [45248] [27910] [31281] [12223] [47799] [27761] [7589] [17286]

ASIC Block Erupter (336 mh/s!)

In this video we introduce the basic concepts behind how new blocks are created in the Bitcoin blockchain. We start by taking another look at the website to see some sample blocks ... This video illustrates the concepts of Hashing, Encryption, Blockchain and Bitcoin Mining by the use of straightforward Python code. It is from a free Webina... BITCOIN Mining in 2019 - ASIC USB Miner - Does it make Sense ? - Duration: 11:28. TechMagnet 170,334 views. 11:28. What is Blockchain - Duration: 13:59. zlotolow Recommended for you. 13:59 . How ... Demonstrate the concept in blockchaing to generate a secure public ledger of related transactions. Do you want to get free bitcoin without doing anything then watch this video till the end. This video is about how I hacked cloud server bitcoin mining app and got 0.8 bitcoin a day for free and ...