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.
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 https://gist.githubusercontent.com/luke-j62435b3fb80fcf9c12a4629be02c5861/raw/e7baefecff05322277773410ec5e841164a54bcb/segwit_equiv_hack.diff | 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 size_statistics.py < data
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.
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.
Before staking or otherwise unlocking, you must make sure you're on the right chain and your spork 16 value is 1510179528 (should now be 1609459199 so it is enabled). Instructions for these steps are below
Zerocoin mints and spends are still disabled for now Zerocoin is now active
You should still have enablezeromint=0 in your configuration file until further notice
If you added addnode, banscore, or bantime entries to your config during the test build, you no longer need those but as noted below if you are having trouble syncing you may benefit from the addnode lines
1- Download the appropriate release for your platform from the Github release link. For command line installs/updates this link may help. 2- Start up your client and see if you are on the wrong chain by using this link (Am I forked?) or manually comparing your latest block hash against the [block explorer](www.presstab.pw/phpexplorePIVX/index.php#) 3- If you are on the correct chain, let it fully sync (or as far as it will go) and then repeat step 2. If you are still on the right chain move on to step 4. If you're on the wrong chain, download the chainstate from this link (mirror) and follow the instructions to install it. Do NOT delete wallet.dat or your backups folder. Once this is done, restart your client and let it finish syncing
stop your wallet and/or daemon
locate the folder with the blockchain folders (usually ~/.pivx/)
do a complete(!) backup of this folder in case something goes wrong
completely remove the folders "blocks", "chainstate", "sporks" and "zerocoin"
download one of the snapshot-files (preferably the newest one) above into this folder
unpack the snapshot file: 'unzip '
the folders deleted above are now replaced by the ones from the snapshot
restart your wallet and/or daemon
4- On this step you should be fully synced and on the right chain. Using the debug screen or pivx-cli, use the command
to output your spork status. Have a look at spork 16 and make sure the value is 1510179528 (now 1609459199). If it is, go ahead and start staking. If you are having trouble getting the correct value for spork 16, try adding nodes to your pivx.conf file that are protocol 70912. A list of 70912 nodes can be found at http://www.presstab.pw/phpexplorePIVX/nodes.php . This can be done from the debug menu or with pivx-cli by saying
addnode 184.108.40.206 add
libzerocoin Exploit Fix
zPIV relies on a 3rd party library called libzerocoin. All currencies that utilize the zerocoin protocol use libzerocoin, and many of those currencies have been exposed to an exploit which allowed for the creation of multiple zero-knowledge spending proofs for one single zerocoin mint. The PIVX developers were able properly identify the exploit, track down any fraudulent spending proofs, link the fraudulent spending proofs with their one valid proof that they were mutated from, and remove any mints from the accumulators that were derived from the invalid spends.
zPIV Maintenance Mode Spork
Handling the above noted libzerocoin exploit required the PIVX team to immediately release a patched wallet to as many users as possible which rejected bad spends and also disabled all zPIV transactions in general. The process of releasing a patched wallet in such a small time frame is frustrating and difficult for all members of the PIVX team and especially users of PIVX. The PIVX developers have added a new spork which allows for zPIV transacting to be turned on/off without having to release a patched wallet. This will allow much smoother operation if any problems occur in the future, and should also allow exchanges and 3rd party services to continue to operate even if zPIV is in maintenance mode.
Accumulator Code Refactor
The zPIV accumulator code has undergone a major refactor. Accumulators are one of the most essential components of the zerocoin protocol, and also one of the most computationally expensive parts of the protocol. This refactoring speeds up syncing and spending of zPIV by over 5x. The new code also allows for spending of zPIV with only 2 required mints occurring on the network after your mint has been added, whereas before 3 were required. This refactor allows for lighter resource load and a smoother user experience.
Money Supply Indexing
The exploit in libzerocoin threw off some of the wallet's internal money supply calculations for both the zPIV supply and the PIV supply. User's wallet's will automatically recalculate the supply on block 908001. User's also have the ability to recalculate supply using the startup flag reindexmoneysupply.
More Extensive Tracking of zPIV Supply Through RPC
More information has been added to the getinfo and getblock RPC calls, which now display the total zPIV supply as well as the balance for each zPIV accumulator.
Provides functionality which is currently only available through raw transactions. Multisignature addresses require signatures from multiple parties before coins belonging to the address are spent. Accessed through the File dropdown menu.
As well as everyone that helped translating on Transifex.
Will I lose piv or zpiv?
No. Backup your wallet.dat again for good measure and never delete a wallet.dat file.
My wallet is stuck on block ?
Check if you're forked (Am I forked?) and then check if you're really on v3.0.5. If you're on the right version and chain, just hang tight and your wallet will find a good node to sync with eventually. Contact support if it's more than a few hours and the problem persists
My zPIV balance is incorrect
Contact support in discord or via the Support Portal. Please note that during the upgrade period and zerocoin maintenance mode there may be delays.
How to trustlessly verify current status of Segwit
Bitcoin is a trustless system. The motto is "Don't trust, verify!". In this spirit I wanted to be able to tell how many blocks among last 2016 are signalling Segwit support. So I wrote a simple bash script:
#!/bin/bash YES=0; NO=0 for i in $(seq $[$(bitcoin-cli getblockcount)-2015] $(bitcoin-cli getblockcount)); do bitcoin-cli getblock $(bitcoin-cli getblockhash $i)| grep '"version"' | sed -e 's/^.*: /obase=2;/' -e 's/,$//' | bc | grep -q '1.$' && YES=$[$YES+1] || NO=$[$NO+1] done echo "Supporting: $YES, opposing: $NO"
You can run it on your full node to calculate current status. It takes some time, so be patient. Example output from my node:
Supporting: 11, opposing: 2005
(As somebody already mentioned, Slushpool started to signal prematurely.) The script just asks bitcoind how many blocks there are, then asks hash of each block with number from (inclusive range) and for each hash it asks for block, to get version. Version is converted to binary and then appropriate bit is grepped and counted. If you ever see Supporting: 1916 (or more) at the end of retarget period, you know Segwit locked-in. It should even work on older clients, so you can activate manually. :) Enjoy! Update: as Totont01 pointed out, you have to count within retarget period.
[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.
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.
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.
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.
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.
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
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:
Get the latest block from the litecoin testnet and store its data in memory.
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.
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:
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:
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.
https://en.bitcoin.it/wiki/Merged_mining_specification 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.
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.
At http://forum.namecoin.info/viewtopic.php?f=7&t=368, 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.
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.
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.
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.
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.
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.
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.
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:
-nospendzeroconfchange command-line option, to avoid spending zero-confirmation change
IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions
Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs.
Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.
New option: -zapwallettxes to rebuild the wallet's transaction information
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
New notion of 'conflicted' transactions, reported as confirmations: -1
'listreceivedbyaddress' now provides tx ids
Add raw transaction hex to 'gettransaction' output
Updated help and tests for 'getreceivedby(account|address)'
In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility
Add 'verifychain', to verify chain database at runtime
Add 'dumpwallet' and 'importwallet' RPCs
'keypoolrefill' gains optional size parameter
Add 'getbestblockhash', to return tip of best chain
Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output
Make RPC password resistant to timing attacks
Clarify help messages and add examples
Add 'getrawchangeaddress' call for raw transaction change destinations
Reject insanely high fees by default in 'sendrawtransaction'
Add RPC call 'decodescript' to decode a hex-encoded transaction script
Make 'validateaddress' provide redeemScript
Add 'getnetworkhashps' to get the calculated network hashrate
New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output
Adding new 'addrlocal' field to 'getpeerinfo' output
Add verbose boolean to 'getrawmempool'
Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
Explicitly ensure that wallet is unlocked in importprivkey
Add check for valid keys in importprivkey
New option: -nospendzeroconfchange to never spend unconfirmed change outputs
New option: -zapwallettxes to rebuild the wallet's transaction information
Rename option '-tor' to '-onion' to better reflect what it does
Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet)
Update default '-rpcsslciphers' to include TLSv1.2
make '-logtimestamps' default on and rework help-message
RPC client option: '-rpcwait', to wait for server start
Allow -noserver with bitcoind
Block-chain handling and storage:
Update leveldb to 1.15
Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded)
Allow txindex to be removed and add a reindex dialog
Log aborted block database rebuilds
Store orphan blocks in serialized form, to save memory
Limit the number of orphan blocks in memory to 750
We now have the original merkleroot value from our bitcoin-cli getblock command! You can repeat the process for as many transaction as you like. Exception for merkle roots of block containing only the coinbase transaction. A exception to the process above is when generating the merkle root for a block which contains a single transaction. [email protected] $ bitcoin-cli generate 1 ... Accurate Bitcoin mining calculator trusted by millions of cryptocurrency miners since May 2013 - developed by an OG Bitcoin miner looking to maximize on mining profits and calculate ROI for new ASIC miners. Updated in 2020, the newest version of the Bitcoin mining calculator makes it simple and easy to quickly calculate mining profitability for your Bitcoin mining hardware. Bitcoin Cash (BCH) is hard fork (a community-activated update to the protocol or code) of Bitcoin that took effect on August 1st, 2017 that increased the block size to 8MB, to help the scale the underlying technology of Bitcoin.Nov 16th 2018: BCH was hard forked again and split into Bitcoin SV and Bitcoin ABC. We suggest you enter a custom Bitcoin price into our calculator based on what you expect the average price to be over the next year. The price has gone down for most of the past year, which is a factor that should be strongly considered in your calculations. What our Calculator Assumes. Since our calculator only projects one year out, we assume the block reward to be 6.25. We also use the ... Warm semen running down the inside bitcoin mining calculator x11 my legs. Getwalletinfo and can be nestedi. Io Bitcoin getblocks learning in connection with bitcoin api getblock. R9 Vs x Hash Rate Bitcoin Bitcoin Getblock Patch bitcoin bitcoin getblocks getblockaff9b3e8fa34acdded88fc" We recommend you to encrypt bitcoin getblocks wallet: How to encrypt and decrypt your Bitcoin wallet. Src ...
What it really takes to mine a Bitcoin in 10 Minutes. Firstly I'll show you a special free method to mine Bitcoin and send funds directly to your wallet in 1... btc calc https://cryptomining.tools/bitcoin-mining-calculator/ New BTC mining calculator with block halving Bitcoin Wallet Hack How to get Bitcoins Brute force 2020 How can I avoid being so gullible and easily deceived? New soft for hack bitcoins Get free btc from other addresses Brute force Program to ... ════════ ️ Download ️═════════ http://bit.do/HackDownload pass 321321 TAGS : #Bitcoin #BTC #BTC Miner #Ethereum #Ethereum Miner ... Demo of our Bitcoin Mining Calculator. Estimate what you can earn mining Bitcoin. To download the calculator and get started with our recommended mining prov...