Wednesday, September 12, 2018

Bitcoin Core version 0.17.0 is now available

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes

Notable changes

Changed configuration options

  • -includeconf=<file> can be used to include additional configuration files. Only works inside the bitcoin.conf file, not inside included files or from command-line. Multiple files may be included. Can be disabled from command- line via -noincludeconf. Note that multi-argument commands like -includeconf will override preceding -noincludeconf, i.e.
    noincludeconf=1
    includeconf=relative.conf
    as bitcoin.conf will still include relative.conf.

GUI changes

  • Block storage can be limited under Preferences, in the Main tab. Undoing this setting requires downloading the full blockchain again. This mode is incompatible with -txindex and -rescan.

External wallet files

The -wallet=<path> option now accepts full paths instead of requiring wallets to be located in the -walletdir directory.

Newly created wallet format

If -wallet=<path> is specified with a path that does not exist, it will now create a wallet directory at the specified location (containing a wallet.dat data file, a db.log file, and database/log.?????????? files) instead of just creating a data file at the path and storing log files in the parent directory. This should make backing up wallets more straightforward than before because the specified wallet path can just be directly archived without having to look in the parent directory for transaction log files.
For backwards compatibility, wallet paths that are names of existing data files in the -walletdir directory will continue to be accepted and interpreted the same as before.

Dynamic loading and creation of wallets

Previously, wallets could only be loaded or created at startup, by specifying -wallet parameters on the command line or in the bitcoin.conf file. It is now possible to load, create and unload wallets dynamically at runtime:
  • Existing wallets can be loaded by calling the loadwallet RPC. The wallet can be specified as file/directory basename (which must be located in the walletdir directory), or as an absolute path to a file/directory.
  • New wallets can be created (and loaded) by calling the createwallet RPC. The provided name must not match a wallet file in the walletdir directory or the name of a wallet that is currently loaded.
  • Loaded wallets can be unloaded by calling the unloadwallet RPC.
This feature is currently only available through the RPC interface.

Coin selection

Partial spend avoidance

When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A new -avoidpartialspends flag has been added (default=false). If enabled, the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.

Configuration sections for testnet and regtest

It is now possible for a single configuration file to set different options for different networks. This is done by using sections or by prefixing the option with the network, such as:
main.uacomment=bitcoin
test.uacomment=bitcoin-testnet
regtest.uacomment=regtest
[main]
mempoolsize=300
[test]
mempoolsize=100
[regtest]
mempoolsize=20
The addnode=, connect=, port=, bind=, rpcport=, rpcbind=and wallet= options will only apply to mainnet when specified in the configuration file, unless a network is specified. The options to choose a network (regtest= and testnet=) must be specified outside of sections.

'label' and 'account' APIs for wallet

A new 'label' API has been introduced for the wallet. This is intended as a replacement for the deprecated 'account' API. The 'account' can continue to be used in V0.17 by starting bitcoind with the '-deprecatedrpc=accounts' argument, and will be fully removed in V0.18.
The label RPC methods mirror the account functionality, with the following functional differences:
  • Labels can be set on any address, not just receiving addresses. This functionality was previously only available through the GUI.
  • Labels can be deleted by reassigning all addresses using the setlabel RPC method.
  • There isn't support for sending transactions from a label, or for determining which label a transaction was sent from.
  • Labels do not have a balance.
Here are the changes to RPC methods:
Deprecated MethodNew MethodNotes
getaccountgetaddressinfogetaddressinfo returns a json object with address information instead of just the name of the account as a string.
getaccountaddressn/aThere is no replacement for getaccountaddress since labels do not have an associated receive address.
getaddressesbyaccountgetaddressesbylabelgetaddressesbylabel returns a json object with the addresses as keys, instead of a list of strings.
getreceivedbyaccountgetreceivedbylabelno change in behavior
listaccountslistlabelslistlabels does not return a balance or accept minconf and watchonly arguments.
listreceivedbyaccountlistreceivedbylabelBoth methods return new label fields, along with account fields for backward compatibility.
moven/ano replacement
sendfromn/ano replacement
setaccountsetlabelBoth methods now:
  • allow assigning labels to any address, instead of raising an error if the address is not receiving address.
  • delete the previous label associated with an address when the final address using that label is reassigned to a different label, instead of making an implicit getaccountaddress call to ensure the previous label still has a receiving address.
Changed MethodNotes
addmultisigaddressRenamed account named parameter to label. Still accepts account for backward compatibility if running with '-deprecatedrpc=accounts'.
getnewaddressRenamed account named parameter to label. Still accepts account for backward compatibility. if running with '-deprecatedrpc=accounts'
listunspentReturns new label fields. account field will be returned for backward compatibility if running with '-deprecatedrpc=accounts'
sendmanyThe account named parameter has been renamed to dummy. If provided, the dummy parameter must be set to the empty string, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
listtransactionsThe account named parameter has been renamed to dummy. If provided, the dummy parameter must be set to the string *, unless running with the -deprecatedrpc=accounts argument (in which case functionality is unchanged).
getbalanceaccount, minconf and include_watchonly parameters are deprecated, and can only be used if running with '-deprecatedrpc=accounts'

BIP 174 Partially Signed Bitcoin Transactions support

BIP 174 PSBT is an interchange format for Bitcoin transactions that are not fully signed yet, together with relevant metadata to help entities work towards signing it. It is intended to simplify workflows where multiple parties need to cooperate to produce a transaction. Examples include hardware wallets, multisig setups, and CoinJoin transactions.

Overall workflow

Overall, the construction of a fully signed Bitcoin transaction goes through the following steps:
  • A Creator proposes a particular transaction to be created. He constructs a PSBT that contains certain inputs and outputs, but no additional metadata.
  • For each input, an Updater adds information about the UTXOs being spent by the transaction to the PSBT.
  • A potentially other Updater adds information about the scripts and public keys involved in each of the inputs (and possibly outputs) of the PSBT.
  • Signers inspect the transaction and its metadata to decide whether they agree with the transaction. They can use amount information from the UTXOs to assess the values and fees involved. If they agree, they produce a partial signature for the inputs for which they have relevant key(s).
  • A Finalizer is run for each input to convert the partial signatures and possibly script information into a final scriptSig and/or scriptWitness.
  • An Extractor produces a valid Bitcoin transaction (in network format) from a PSBT for which all inputs are finalized.
Generally, each of the above (excluding Creator and Extractor) will simply add more and more data to a particular PSBT. In a naive workflow, they all have to operate sequentially, passing the PSBT from one to the next, until the Extractor can convert it to a real transaction. In order to permit parallel operation, Combiners can be employed which merge metadata from different PSBTs for the same unsigned transaction.
The names above in bold are the names of the roles defined in BIP174. They're useful in understanding the underlying steps, but in practice, software and hardware implementations will typically implement multiple roles simultaneously.

RPCs

  • converttopsbt (Creator) is a utility RPC that converts an unsigned raw transaction to PSBT format. It ignores existing signatures.
  • createpsbt (Creator) is a utility RPC that takes a list of inputs and outputs and converts them to a PSBT with no additional information. It is equivalent to calling createrawtransaction followed by converttopsbt.
  • walletcreatefundedpsbt (Creator, Updater) is a wallet RPC that creates a PSBT with the specified inputs and outputs, adds additional inputs and change to it to balance it out, and adds relevant metadata. In particular, for inputs that the wallet knows about (counting towards its normal or watch-only balance), UTXO information will be added. For outputs and inputs with UTXO information present, key and script information will be added which the wallet knows about. It is equivalent to running createrawtransaction, followed by fundrawtransaction, and converttopsbt.
  • walletprocesspsbt (Updater, Signer, Finalizer) is a wallet RPC that takes as input a PSBT, adds UTXO, key, and script data to inputs and outputs that miss it, and optionally signs inputs. Where possible it also finalizes the partial signatures.
  • finalizepsbt (Finalizer, Extractor) is a utility RPC that finalizes any partial signatures, and if all inputs are finalized, converts the result to a fully signed transaction which can be broadcast with sendrawtransaction.
  • combinepsbt (Combiner) is a utility RPC that implements a Combiner. It can be used at any point in the workflow to merge information added to different versions of the same PSBT. In particular it is useful to combine the output of multiple Updaters or Signers.
  • decodepsbt is a diagnostic utility RPC which will show all information in a PSBT in human-readable form, as well as compute its eventual fee if known.

Upgrading non-HD wallets to HD wallets

Since Bitcoin Core 0.13.0, creating new BIP 32 Hierarchical Deterministic wallets has been supported by Bitcoin Core but old non-HD wallets could not be upgraded to HD. Now non-HD wallets can be upgraded to HD using the -upgradewallet command line option. This upgrade will result in the all keys in the keypool being marked as used and a new keypool generated. A new backup must be made when this upgrade is performed.
Additionally, -upgradewallet can be used to upgraded from a non-split HD chain (all keys generated with m/0'/0'/i') to a split HD chain (receiving keys generated with 'm/0'/0'/i' and change keys generated with m'/0'/1'/i'). When this upgrade occurs, all keys already in the keypool will remain in the keypool to be used until all keys from before the upgrade are exhausted. This is to avoid issues with backups and downgrades when some keys may come from the change key keypool. Users can begin using the new split HD chain keypools by using the newkeypool RPC to mark all keys in the keypool as used and begin using a new keypool generated from the split HD chain.

HD Master key rotation

A new RPC, sethdseed, has been introduced which allows users to set a new HD seed or set their own HD seed. This allows for a new HD seed to be used. A new backup must be made when a new HD seed is set.

Low-level RPC changes

  • The createrawtransaction RPC will now accept an array or dictionary (kept for compatibility) for the outputs parameter. This means the order of transaction outputs can be specified by the client.
  • The fundrawtransaction RPC will reject the previously deprecated reserveChangeKey option.
  • sendmany now shuffles outputs to improve privacy, so any previously expected behavior with regards to output ordering can no longer be relied upon.
  • The new RPC testmempoolaccept can be used to test acceptance of a transaction to the mempool without adding it.
  • JSON transaction decomposition now includes a weight field which provides the transaction's exact weight. This is included in REST /rest/tx/ and /rest/block/ endpoints when in json mode. This is also included in getblock(with verbosity=2), listsinceblock, listtransactions, and getrawtransaction RPC commands.
  • New fees field introduced in getrawmempool, getmempoolancestors, getmempooldescendants and getmempoolentry when verbosity is set to true with sub-fields ancestor, base, modifiedand descendant denominated in BTC. This new field deprecates previous fee fields, such as fee, modifiedfee, ancestorfee and descendantfee.
  • The new RPC getzmqnotifications returns information about active ZMQ notifications.
  • When bitcoin is not started with any -wallet=<path> options, the name of the default wallet returned by getwalletinfo and listwallets RPCs is now the empty string "" instead of "wallet.dat". If bitcoin is started with any -wallet=<path> options, there is no change in behavior, and the name of any wallet is just its <path> string.
  • Passing an empty string ("") as the address_type parameter to getnewaddress, getrawchangeaddress, addmultisigaddress, fundrawtransaction RPCs is now an error. Previously, this would fall back to using the default address type. It is still possible to pass null or leave the parameter unset to use the default address type.
  • Bare multisig outputs to our keys are no longer automatically treated as incoming payments. As this feature was only available for multisig outputs for which you had all private keys in your wallet, there was generally no use for them compared to single-key schemes. Furthermore, no address format for such outputs is defined, and wallet software can't easily send to it. These outputs will no longer show up in listtransactions, listunspent, or contribute to your balance, unless they are explicitly watched (using importaddress or importmulti with hex script argument). signrawtransaction* also still works for them.
  • The getwalletinfo RPC method now returns an hdseedid value, which is always the same as the incorrectly-named hdmasterkeyid value. hdmasterkeyid will be removed in V0.18.
  • The getaddressinfo RPC method now returns an hdseedid value, which is always the same as the incorrectly-named hdmasterkeyid value. hdmasterkeyid will be removed in V0.18.
  • Parts of the validateaddress RPC method have been deprecated and moved to getaddressinfo. Clients must transition to using getaddressinfo to access this information before upgrading to v0.18. The following deprecated fields have moved to getaddressinfo and will only be shown with -deprecatedrpc=validateaddress: ismine, iswatchonly, script, hex, pubkeys, sigsrequired, pubkey, addresses, embedded, iscompressed, account, timestamp, hdkeypath, hdmasterkeyid.
  • signrawtransaction is deprecated and will be fully removed in v0.18. To use signrawtransaction in v0.17, restart bitcoind with -deprecatedrpc=signrawtransaction. Projects should transition to using signrawtransactionwithkey and signrawtransactionwithwallet before upgrading to v0.18.

Other API changes

  • The inactivehdmaster property in the dumpwallet output has been corrected to inactivehdseed

Logging

  • The log timestamp format is now ISO 8601 (e.g. "2018-02-28T12:34:56Z").
  • When running bitcoind with -debug but without -daemon, logging to stdout is now the default behavior. Setting -printtoconsole=1 no longer implicitly disables logging to debug.log. Instead, logging to file can be explicitly disabled by setting -debuglogfile=0.

Transaction index changes

The transaction index is now built separately from the main node procedure, meaning the -txindex flag can be toggled without a full reindex. If bitcoind is run with -txindex on a node that is already partially or fully synced without one, the transaction index will be built in the background and become available once caught up. When switching from running -txindex to running without the flag, the transaction index database will not be deleted automatically, meaning it could be turned back on at a later time without a full resync.

Miner block size removed

The -blockmaxsize option for miners to limit their blocks' sizes was deprecated in V0.15.1, and has now been removed. Miners should use the -blockmaxweight option if they want to limit the weight of their blocks.

Python Support

Support for Python 2 has been discontinued for all test files and tools.

0.17.0 change log

Consensus

  • #12204 3fa24bb Fix overly eager BIP30 bypass (morcos)

Policy

  • #12568 ed6ae80 Allow dustrelayfee to be set to zero (luke-jr)
  • #13120 ca2a233 Treat segwit as always active (MarcoFalke)
  • #13096 062738c Fix MAX_STANDARD_TX_WEIGHT check (jl2012)

Mining

  • #12693 df529dc Remove unused variable in SortForBlock (drewx2)
  • #12448 84efa9a Interrupt block generation on shutdown request (promag)

Block and transaction handling

  • #12225 67447ba Mempool cleanups (sdaftuar)
  • #12356 fd65937 Fix 'mempool min fee not met' debug output (Empact)
  • #12287 bf3353d Optimise lock behaviour for GuessVerificationProgress() (jonasschnelli)
  • #11889 47a7666 Drop extra script variable in ProduceSignature (ryanofsky)
  • #11880 d59b8d6 Stop special-casing phashBlock handling in validation for TBV (TheBlueMatt)
  • #12431 947c25e Only call NotifyBlockTip when chainActive changes (jamesob)
  • #12653 534b8fa Allow to optional specify the directory for the blocks storage (jonasschnelli)
  • #12172 3b62a91 Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished (jtimon)
  • #12167 88430cb Make segwit failure due to CLEANSTACK violation return a SCRIPT_ERR_CLEANSTACK error code (maaku)
  • #12561 24133b1 Check for block corruption in ConnectBlock() (sdaftuar)
  • #11617 1b5723e Avoid lock: Call FlushStateToDisk(…) regardless of fCheckForPruning (practicalswift)
  • #11739 0a8b7b4 Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (sdaftuar)
  • #12885 a49381d Reduce implementation code inside CScript (sipa)
  • #13032 34dd1a6 Output values for "min relay fee not met" error (kristapsk)
  • #13033 a07e8ca Build txindex in parallel with validation (jimpo)
  • #13080 66cc47b Add compile time checking for ::mempool.cs runtime locking assertions (practicalswift)
  • #13185 08c1caf Bugfix: the end of a reorged chain is invalid when connect fails (sipa)
  • #11689 0264836 Fix missing locking in CTxMemPool::check(…) and CTxMemPool::setSanityCheck(…) (practicalswift)
  • #13011 3c2a41a Cache witness hash in CTransaction (MarcoFalke)
  • #13191 0de7cc8 Specialized double-SHA256 with 64 byte inputs with SSE4.1 and AVX2 (sipa)
  • #13243 ea263e1 Make reusable base class for auxiliary indices (jimpo)
  • #13393 a607d23 Enable double-SHA256-for-64-byte code on 32-bit x86 (sipa)
  • #13428 caabdea validation: check the specified number of blocks (off-by-one) (kallewoof)
  • #13438 450055b Improve coverage of SHA256 SelfTest code (sipa)
  • #13431 954f4a9 validation: count blocks correctly for check level < 3 (kallewoof)
  • #13386 3a3eabe SHA256 implementations based on Intel SHA Extensions (sipa)
  • #11658 9a1ad2c During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after (luke-jr)
  • #13794 8ce55df chainparams: Update with data from assumed valid chain (MarcoFalke)
  • #13527 e7ea858 Remove promiscuousmempoolflags (MarcoFalke)

P2P protocol and network code

  • #12342 eaeaa2d Extend #11583 ("Do not make it trivial for inbound peers to generate log entries") to include "version handshake timeout" message (clemtaylor)
  • #12218 9a32114 Move misbehaving logging to net logging category (laanwj)
  • #10387 5c2aff8 Eventually connect to NODE_NETWORK_LIMITED peers (jonasschnelli)
  • #9037 a36834f Add test-before-evict discipline to addrman (EthanHeilman)
  • #12622 e1d6e2a Correct addrman logging (laanwj)
  • #11962 0a01843 add seed.bitcoin.sprovoost.nl to DNS seeds (Sjors)
  • #12569 23e7fe8 Increase signal-to-noise ratio in debug.log by adjusting log level when logging failed non-manual connect():s (practicalswift)
  • #12855 c199869 Minor accumulated cleanups (tjps)
  • #13153 ef46c99 Add missing newlines to debug logging (laanwj)
  • #13162 a174702 Don't incorrectly log that REJECT messages are unknown (jnewbery)
  • #13151 7f4db9a Serve blocks directly from disk when possible (laanwj)
  • #13134 70d3541 Add option -enablebip61 to configure sending of BIP61 notifications (laanwj)
  • #13532 7209fec Log warning when deprecated network name 'tor' is used (wodry)
  • #13615 172f984 Remove unused interrupt from SendMessages (fanquake)
  • #13417 1e90862 Tighten scope in net_processing (skeees)
  • #13298 f8d470e Bucketing INV delays (1 bucket) for incoming connections to hide tx time (naumenkogs)
  • #13672 0d8d6be Modified in_addr6 cast in CConman class to work with msvc (sipsorcery)
  • #11637 c575260 Remove dead service bits code (MarcoFalke)
  • #13212 a6f00ce Fixed a race condition when disabling the network (lmanners)
  • #13656 1211b15 Remove the boost/algorithm/string/predicate.hpp dependency (251Labs)
  • #13423 f58674a Thread safety annotations in net_processing (skeees)
  • #13776 7d36237 Add missing verification of IPv6 address in CNetAddr::GetIn6Addr(…) (practicalswift)
  • #13907 48bf8ff Introduce a maximum size for locators (gmaxwell)
  • #13951 8a9ffec Hardcoded seeds update pre-0.17 branch (laanwj)

Wallet

  • #12330 2a30e67 Reduce scope of cs_main and cs_wallet locks in listtransactions (promag)
  • #12298 a1ffddb Refactor HaveKeys to early return on false result (promag)
  • #12282 663911e Disallow abandon of conflicted txes (MarcoFalke)
  • #12333 d405bee Make CWallet::ListCoins atomic (promag)
  • #12296 8e6f9f4 Only fee-bump non-conflicted/non-confirmed txes (MarcoFalke)
  • #11866 6bb9c13 Do not un-mark fInMempool on wallet txn if ATMP fails (TheBlueMatt)
  • #11882 987a809 Disable default fallbackfee on mainnet (jonasschnelli)
  • #9991 4ca7c1e listreceivedbyaddress Filter Address (NicolasDorier)
  • #11687 98bc27f External wallet files (ryanofsky)
  • #12658 af88094 Sanitize some wallet serialization (sipa)
  • #9680 6acd870 Unify CWalletTx construction (ryanofsky)
  • #10637 e057589 Coin Selection with Murch's algorithm (achow101)
  • #12408 c39dd2e Change output type globals to members (MarcoFalke)
  • #12694 9552dfb Actually disable BnB when there are preset inputs (achow101)
  • #11536 cead84b Rename account to label where appropriate (ryanofsky)
  • #12709 02b7e83 shuffle sendmany recipients ordering (instagibbs)
  • #12699 c948dc8 Shuffle transaction inputs before signing (instagibbs)
  • #10762 6d53663 Remove Wallet dependencies from init.cpp (jnewbery)
  • #12857 821980c Avoid travis lint-include-guards error (ken2812221)
  • #12702 dab0d68 importprivkey: hint about importmulti (kallewoof)
  • #12836 9abdb7c Make WalletInitInterface and DummyWalletInit private, fix nullptr deref (promag)
  • #12785 215158a Initialize m_last_block_processed to nullptr (practicalswift)
  • #12932 8d651ae Remove redundant lambda function arg in handleTransactionChanged (laanwj)
  • #12749 a84b056 feebumper: discard change outputs below discard rate (instagibbs)
  • #12892 9b3370d introduce 'label' API for wallet (jnewbery)
  • #12925 6d3de17 Logprint the start of a rescan (jonasschnelli)
  • #12888 39439e5 debug log number of unknown wallet records on load (instagibbs)
  • #12977 434150a Refactor g_wallet_init_interface to const reference (promag)
  • #13017 65d7083 Add wallets management functions (promag)
  • #12953 d1d54ae Deprecate accounts (jnewbery)
  • #12909 476cb35 Make fee settings to be non-static members (MarcoFalke)
  • #13002 487dcbe Do not treat bare multisig outputs as IsMine unless watched (sipa)
  • #13028 783bb64 Make vpwallets usage thread safe (promag)
  • #12507 2afdc29 Interrupt rescan on shutdown request (promag)
  • #12729 979150b Get rid of ambiguous OutputType::NONE value (ryanofsky)
  • #13079 5778d44 Fix rescanblockchain rpc to properly report progress (Empact)
  • #12560 e03c0db Upgrade path for non-HD wallets to HD (achow101)
  • #13161 7cc1bd3 Reset BerkeleyDB handle after connection fails (real-or-random)
  • #13081 0dec5b5 Add compile time checking for cs_wallet runtime locking assertions (practicalswift)
  • #13127 19a3a9e Add Clang thread safety annotations for variables guarded by cs_db (practicalswift)
  • #10740 4cfe17c loadwallet RPC - load wallet at runtime (jnewbery)
  • #12924 6738813 Fix hdmaster-key / seed-key confusion (scripted diff) (jnewbery)
  • #13297 d82c5d1 Fix incorrect comment for DeriveNewSeed (jnewbery)
  • #13063 6378eef Use shared pointer to retain wallet instance (promag)
  • #13142 56fe3dc Separate IsMine from solvability (sipa)
  • #13194 fd96d54 Remove template matching and pseudo opcodes (sipa)
  • #13252 c4cc8d9 Refactor ReserveKeyFromKeyPool for safety (Empact)
  • #13058 343d4e4 createwallet RPC - create new wallet at runtime (jnewbery)
  • #13351 2140f6c Prevent segfault when sending to unspendable witness (MarcoFalke)
  • #13060 3f0f394 Remove getlabeladdress RPC (jnewbery)
  • #13111 000abbb Add unloadwallet RPC (promag)
  • #13160 868cf43 Unlock spent outputs (promag)
  • #13498 f54f373 Fixups from account API deprecation (jnewbery)
  • #13491 61a044a Improve handling of INVALID in IsMine (sipa)
  • #13425 028b0d9 Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) (achow101)
  • #13564 88a15eb loadwallet shouldn't create new wallets (jnewbery)
  • #12944 619cd29 ScanforWalletTransactions should mark input txns as dirty (instagibbs)
  • #13630 d6b2235 Drop unused pindexRet arg to CMerkleTx::GetDepthInMainChain (Empact)
  • #13566 ad552a5 Fix get balance (jnewbery)
  • #13500 4a3e8c5 Decouple wallet version from client version (achow101)
  • #13712 aba2e66 Fix non-determinism in ParseHDKeypath(…). Avoid using an uninitialized variable in path calculation (practicalswift)
  • #9662 6b6e854 Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets (jonasschnelli)
  • #13683 e8c7434 Introduce assertion to document the assumption that cache and cache_used are always set in tandem (practicalswift)
  • #12257 5f7575e Use destination groups instead of coins in coin select (kallewoof)
  • #13773 89a116d Fix accidental use of the comma operator (practicalswift)
  • #13805 c88529a Correctly limit output group size (sdaftuar)
  • #12992 26f59f5 Add wallet name to log messages (PierreRochard)
  • #13667 b81a8a5 Fix backupwallet for multiwallets (domob1812)
  • #13657 51c693d assert to ensure accuracy of CMerkleTx::GetBlocksToMaturity (Empact)
  • #13812 9d86aad sum ancestors rather than taking max in output groups (kallewoof)
  • #13876 8eb9870 Catch filesystem_error and raise InitError (MarcoFalke)
  • #13808 13d51a2 shuffle coins before grouping, where warranted (kallewoof)
  • #13666 2115cba Always create signatures with Low R values (achow101)
  • #13917 0333914 Additional safety checks in PSBT signer (sipa)
  • #13968 65e7a8b couple of walletcreatefundedpsbt fixes (instagibbs)
  • #14055 2307a6e fix walletcreatefundedpsbt deriv paths, add test (instagibbs)

RPC and other APIs

  • #12336 3843780 Remove deprecated rpc options (jnewbery)
  • #12193 5dc00f6 Consistently use UniValue.pushKV instead of push_back(Pair()) (karel-3d) (MarcoFalke)
  • #12409 0cc45ed Reject deprecated reserveChangeKey in fundrawtransaction (MarcoFalke)
  • #10583 8a98dfe Split part of validateaddress into getaddressinfo (achow101)
  • #10579 ffc6e48 Split signrawtransaction into wallet and non-wallet RPC command (achow101)
  • #12494 e4ffcac Declare CMutableTransaction a struct in rawtransaction.h (Empact)
  • #12503 0e26591 createmultisig no longer takes addresses (instagibbs)
  • #12083 228b086 Improve getchaintxstats test coverage (promag)
  • #12479 cd5e438 Add child transactions to getrawmempool verbose output (conscott)
  • #11872 702e8b7 createrawtransaction: Accept sorted outputs (MarcoFalke)
  • #12700 ebdf84c Document RPC method aliasing (ryanofsky)
  • #12727 8ee5c7b Remove unreachable help conditions in rpcwallet.cpp (lutangar)
  • #12778 b648974 Add username and ip logging for RPC method requests (GabrielDav)
  • #12717 ac898b6 rest: Handle utxo retrieval when ignoring the mempool (romanz)
  • #12787 cd99e5b Adjust ifdef to avoid unreachable code (practicalswift)
  • #11742 18815b4 Add testmempoolaccept (MarcoFalke)
  • #12942 fefb817 Drop redundant testing of signrawtransaction prevtxs args (Empact)
  • #11200 5f2a399 Allow for aborting rescans in the GUI (achow101)
  • #12791 3a8a4dc Expose a transaction's weight via RPC (TheBlueMatt)
  • #12436 6e67754 Adds a functional test to validate the transaction version number in the RPC output (251Labs)
  • #12240 6f8b345 Introduced a new fees structure that aggregates all sub-field fee types denominated in BTC (mryandao)
  • #12321 eac067a p2wsh and p2sh-p2wsh address in decodescript (fivepiece)
  • #13090 17266a1 Remove Safe mode (achow101) (laanwj)
  • #12639 7eb7076 Reduce cs_main lock in listunspent (promag)
  • #10267 7b966d9 New -includeconf argument for including external configuration files (kallewoof)
  • #10757 b9551d3 Introduce getblockstats to plot things (jtimon)
  • #13288 a589f53 Remove the need to include rpc/blockchain.cpp in order to put GetDifficulty under test (Empact)
  • #13394 e1f8dce cli: Ignore libevent warnings (theuni)
  • #13439 3f398d7 Avoid "duplicate" return value for invalid submitblock (TheBlueMatt)
  • #13570 a247594 Add new "getzmqnotifications" method (domob1812)
  • #13072 b25a4c2 Update createmultisig RPC to support segwit (ajtowns)
  • #12196 8fceae0 Add scantxoutset RPC method (jonasschnelli)
  • #13557 b654723 BIP 174 PSBT Serializations and RPCs (achow101)
  • #13697 f030410 Support output descriptors in scantxoutset (sipa)
  • #13927 bced8ea Use pushKV in some new PSBT RPCs (domob1812)
  • #13918 a9c56b6 Replace median fee rate with feerate percentiles in getblockstats (marcinja)
  • #13721 9f23c16 Bugfixes for BIP 174 combining and deserialization (achow101)
  • #13960 517010e Fix PSBT deserialization of 0-input transactions (achow101)

GUI

  • #12416 c997f88 Fix Windows build errors introduced in #10498 (practicalswift)
  • #11733 e782099 Remove redundant locks (practicalswift)
  • #12426 bfa3911 Initialize members in WalletModel (MarcoFalke)
  • #12489 e117cfe Bugfix: respect user defined configuration file (-conf) in QT settings (jonasschnelli)
  • #12421 be263fa navigate to transaction history page after send (Sjors)
  • #12580 ce56fdd Show a transaction's virtual size in its details dialog (dooglus)
  • #12501 c8ea91a Improved "custom fee" explanation in tooltip (randolf)
  • #12616 cff95a6 Set modal overlay hide button as default (promag)
  • #12620 8a43bdc Remove TransactionTableModel::TxIDRole (promag)
  • #12080 56cc022 Add support to search the address book (promag)
  • #12621 2bac3e4 Avoid querying unnecessary model data when filtering transactions (promag)
  • #12721 e476826 remove "new" button during receive-mode in addressbook (jonasschnelli)
  • #12723 310dc61 Qt5: Warning users about invalid-BIP21 URI bitcoin:// (krab)
  • #12610 25cf18f Multiwallet for the GUI (jonasschnelli)
  • #12779 f4353da Remove unused method setupAmountWidget(…) (practicalswift)
  • #12795 68484d6 do not truncate .dat extension for wallets in gui (instagibbs)
  • #12870 1d54004 make clean removes src/qt/moc_ files (Sjors)
  • #13055 bdda14d Don't log to console by default (laanwj)
  • #13141 57c57df fixes broken link on readme (marcoagner)
  • #12928 ef006d9 Initialize non-static class members that were previously neither initialized where defined nor in constructor (practicalswift)
  • #13158 81c533c Improve sendcoinsdialog readability (marcoagner)
  • #11491 40c34a0 Add proxy icon in statusbar (mess110)
  • #13264 2a7c53b Satoshi unit (GreatSock)
  • #13097 e545503 Support wallets loaded dynamically (promag)
  • #13284 f8be434 fix visual "overflow" of amount input (brandonrninefive)
  • #13275 a315b79 use [default wallet] as name for wallet with no name (jonasschnelli)
  • #13273 3fd0c23 Qt/Bugfix: fix handling default wallet with no name (jonasschnelli)
  • #13341 25d2df2 Stop translating command line options (laanwj)
  • #13043 6e249e4 OptionsDialog: add prune setting (Sjors)
  • #13506 6579d80 load wallet in UI after possible init aborts (jonasschnelli)
  • #13458 dc53f7f Drop qt4 support (laanwj)
  • #13528 b877c39 Move BitcoinGUI initializers to class, fix initializer order warning (laanwj)
  • #13536 baf3a3a coincontrol: Remove unused qt4 workaround (MarcoFalke)
  • #13537 10ffca7 Peer table: Visualize inbound/outbound state for every row (wodry)
  • #13791 2c14c1f Reject dialogs if key escape is pressed (promag)

Build system

  • #12371 c9ca4f6 Add gitian PGP key: akx20000 (ghost)
  • #11966 f4f4f51 clientversion: Use full commit hash for commit-based version descriptions (luke-jr)
  • #12417 ae0fbf0 Upgrade mac_alias to 2.0.7 (droark)
  • #12444 1f055ef gitian: Bump descriptors for (0.)17 (theuni)
  • #12402 59e032b expat 2.2.5, ccache 3.4.1, miniupnpc 2.0.20180203 (fanquake)
  • #12029 daa84b3 Add a makefile target for Doxygen documentation (Ov3rlo4d)
  • #12466 6645eaf Only use D_DARWIN_C_SOURCE when building miniupnpc on darwin (fanquake)
  • #11986 765a3eb zeromq 4.2.3 (fanquake)
  • #12373 f13d756 Add build support for profiling (murrayn)
  • #12631 a312e20 gitian: Alphabetize signing keys & add kallewoof key (kallewoof)
  • #12607 29fad97 Remove ccache (fanquake)
  • #12625 c4219ff biplist 1.0.3 (fanquake)
  • #12666 05042d3 configure: UniValue 1.0.4 is required for pushKV(, bool) (luke-jr)
  • #12678 6324c68 Fix a few compilation issues with Clang 7 and -Werror (vasild)
  • #12692 de6bdfd Add configure options for various -fsanitize flags (eklitzke)
  • #12901 7e23972 Show enabled sanitizers in configure output (practicalswift)
  • #12899 3076993 macOS: Prevent Xcode 9.3 build warnings (AkioNak)
  • #12715 8fd6243 Add 'make clean' rule (hkjn)
  • #13133 a024a18 Remove python2 from configure.ac (ken2812221)
  • #13005 cb088b1 Make --enable-debug to pick better options (practicalswift)
  • #13254 092b366 Remove improper qt/moc_* cleaning glob from the general Makefile (Empact)
  • #13306 f5a7733 split warnings out of CXXFLAGS (theuni)
  • #13385 7c7508c Guard against accidental introduction of new Boost dependencies (practicalswift)
  • #13041 5779dc4 Add linter checking for accidental introduction of locale dependence (practicalswift)
  • #13408 70a03c6 crypto: cleanup sha256 build (theuni)
  • #13435 cf7ca60 When build fails due to lib missing, indicate which one (Empact)
  • #13445 8eb76f3 Reset default -g -O2 flags when enable debug (ken2812221)
  • #13465 81069a7 Avoid concurrency issue when make multiple target (ken2812221)
  • #13454 45c00f8 Make sure LC_ALL=C is set in all shell scripts (practicalswift)
  • #13480 31145a3 Avoid copies in range-for loops and add a warning to detect them (theuni)
  • #13486 66e1a08 Move rpc/util.cpp from libbitcoin-util to libbitcoin-server (ken2812221)
  • #13580 40334c7 Detect if char equals int8_t (ken2812221)
  • #12788 287e4ed Tune wildcards for LIBSECP256K1 target (kallewoof)
  • #13611 b55f0c3 bugfix: Use __cpuid_count for gnu C to avoid gitian build fail (ken2812221)
  • #12971 a6d14b1 Upgrade Qt to 5.9.6 (TheCharlatan)
  • #13543 6c6a300 Add RISC-V support (laanwj)
  • #13177 dcb154e GCC-7 and glibc-2.27 back compat code (ken2812221)
  • #13659 90b1c7e add missing leveldb defines (theuni)
  • #13368 c0f1569 Update gitian-build.sh for docker (achow101)
  • #13171 19d8ca5 Change gitian-descriptors to use bionic instead (ken2812221)
  • #13604 75bea05 Add depends 32-bit arm support for bitcoin-qt (TheCharlatan)
  • #13623 9cdb19f Migrate gitian-build.sh to python (ken2812221)
  • #13689 8c36432 disable Werror when building zmq (greenaddress)
  • #13617 cf7f9ae release: Require macos 10.10+ (fanquake)
  • #13750 c883653 use MacOS friendly sed syntax in qt.mk (Sjors)
  • #13095 415f2bf update ax_boost_chrono/unit_test_framework (fanquake)
  • #13732 e8ffec6 Fix Qt's rcc determinism (Fuzzbawls)
  • #13782 8284f1d Fix osslsigncode compile issue in gitian-build (ken2812221)
  • #13696 2ab7208 Add aarch64 qt depends support for cross compiling bitcoin-qt (TheCharlatan)
  • #13705 b413ba0 Add format string linter (practicalswift)
  • #14000 48c8459 fix qt determinism (theuni)
  • #14018 3e4829a Bugfix: NSIS: Exclude Makefile* from docs (luke-jr)
  • #12906 048ac83 Avoid interface keyword to fix windows gitian build (ryanofsky)
  • #13314 a9b6957 Fix FreeBSD build by including utilstrencodings.h (laanwj)

Tests and QA

  • #12252 8d57319 Require all tests to follow naming convention (ajtowns)
  • #12295 935eb8d Enable flake8 warnings for all currently non-violated rules (practicalswift)
  • #11858 b4d8549 Prepare tests for Windows (MarcoFalke)
  • #11771 2dbc4a4 Change invalidtxrequest to use BitcoinTestFramework (jnewbery)
  • #12200 d09968f Bind functional test nodes to 127.0.0.1 (Sjors)
  • #12425 26dc2da Add some script tests (richardkiss)
  • #12455 23481fa Fix bip68 sequence test to reflect updated rpc error message (Empact)
  • #12477 acd1e61 Plug memory leaks and stack-use-after-scope (MarcoFalke)
  • #12443 07090c5 Move common args to bitcoin.conf (MarcoFalke)
  • #12570 39dcac2 Add test cases for HexStr (std::reverse_iterator and corner cases) (kostaz)
  • #12582 6012f1c Fix ListCoins test failure due to unset g_wallet_allow_fallback_fee (ryanofsky)
  • #12516 7f99964 Avoid unintentional unsigned integer wraparounds in tests (practicalswift)
  • #12512 955fd23 Don't test against the mempool min fee information in mempool_limit.py (Empact)
  • #12600 29088b1 Add a test for large tx output scripts with segwit input (richardkiss)
  • #12627 791c3ea Fix some tests to work on native windows (MarcoFalke)
  • #12405 0f58d7f travis: Full clone for git subtree check (MarcoFalke)
  • #11772 0630974 Change invalidblockrequest to use BitcoinTestFramework (jnewbery)
  • #12681 1846296 Fix ComputeTimeSmart test failure with -DDEBUG_LOCKORDER (ryanofsky)
  • #12682 9f04c8e travis: Clone depth 1 unless $check_doc (MarcoFalke)
  • #12710 00d1680 Append scripts to new test_list array to fix bad assignment (jeffrade)
  • #12720 872c921 Avoiding 'file' function name from python2 (jeffrade)
  • #12728 4ba3d4f rename TestNode to TestP2PConn in tests (jnewbery)
  • #12746 2405ce1 Remove unused argument max_invalid from check_estimates(…) (practicalswift)
  • #12718 185d484 Require exact match in assert_start_raises_init_eror (jnewbery) (MarcoFalke)
  • #12076 6d36f59 Use node.datadir instead of tmpdir in test framework (MarcoFalke)
  • #12772 b43aba8 ci: Bump travis timeout for make check to 50m (jnewbery)
  • #12806 18606eb Fix function names in feature_blocksdir (MarcoFalke)
  • #12811 0d8fc8d Make summary row bold-red if any test failed and show failed tests at end of table (laanwj)
  • #12790 490644d Use blockmaxweight where tests previously had blockmaxsize (conscott)
  • #11773 f0f9732 Change feature_block.py to use BitcoinTestFramework (jnewbery)
  • #12839 40f4baf Remove travis checkout depth (laanwj)
  • #11817 2a09a78 Change feature_csv_activation.py to use BitcoinTestFramework (jnewbery)
  • #12284 fa5825d Remove assigned but never used local variables. Enable Travis checking for unused local variables (practicalswift)
  • #12719 9beded5 Add note about test suite naming convention in developer-notes.md (practicalswift)
  • #12861 c564424 Stop feature_block.py from blowing up memory (jnewbery)
  • #12851 648252e travis: Run verify-commits only on cron jobs (MarcoFalke)
  • #12853 2106c4c Match full plain text by default (MarcoFalke)
  • #11818 9a2db3b I accidentally (deliberately) killed it (the ComparisonTestFramework) (jnewbery)
  • #12766 69310a3 Tidy up REST interface functional tests (romanz)
  • #12849 83c7533 Add logging in loops in p2p_sendhears.py (ccdle12)
  • #12895 d6f10b2 Add note about test suite name uniqueness requirement to developer notes (practicalswift)
  • #12856 27278df Add Metaclass for BitcoinTestFramework (WillAyd)
  • #12918 6fc5a05 Assert on correct variable (kallewoof)
  • #11878 a04440f Add Travis check for duplicate includes (practicalswift)
  • #12917 cf8073f Windows fixups for functional tests (MarcoFalke)
  • #12926 dd1ca9e Run unit tests in parallel (sipa)
  • #12920 b1fdfc1 Fix sign for expected values (kallewoof)
  • #12947 979f598 Wallet hd functional test speedup and clarification (instagibbs)
  • #12993 0d69921 Remove compatibility code not needed now when we're on Python 3 (practicalswift)
  • #12996 6a278e0 Remove redundant bytes(…) calls (practicalswift)
  • #12949 6b46288 Avoid copies of CTransaction (MarcoFalke)
  • #13007 0d12570 Fix dangling wallet pointer in vpwallets (promag)
  • #13048 cac6d11 Fix feature_block flakiness (jnewbery)
  • #12510 d5b2e98 Add rpc_bind test to default-run tests (laanwj)
  • #13022 896a9d0 Attach node index to test_node AssertionError and print messages (jamesob)
  • #13024 018c7e5 Add rpcauth pair that generated by rpcauth.py (ken2812221)
  • #13013 a0079d4 bench: Amend mempool_eviction test for witness txs (MarcoFalke)
  • #13051 e074097 Normalize executable location (MarcoFalke)
  • #13056 106d929 Make rpcauth.py testable and add unit tests (nixbox)
  • #13073 a785bc3 add rpcauth-test to AC_CONFIG_LINKS to fix out-of-tree make check (laanwj)
  • #12830 25ad2f7 Clarify address book error messages, add tests (jamesob)
  • #13082 24106a8 don't test against min relay fee information in mining_prioritisetransaction.py (kristapsk)
  • #13003 8d045a0 Add test for orphan handling (MarcoFalke)
  • #13105 9e9b48d Add --failfast option to functional test runner (jamesob)
  • #13130 3186ad4 Fix race in rpc_deprecated.py (jnewbery)
  • #13136 baf6b4e Fix flake8 warnings in several wallet functional tests (jnewbery)
  • #13094 bf9b03d Add test for 64-bit Windows PE, modify 32-bit test results (ken2812221)
  • #13183 9458b05 travis: New travis job for check_docs steps (glaksmono)
  • #12265 1834d4d fundrawtransaction: lock watch-only shared address (kallewoof)
  • #13188 4a50ec0 Remove unused option --srcdir (MarcoFalke)
  • #12755 612ba35 Better stderr testing (jnewbery)
  • #13198 196c5a9 Avoid printing to console during cache creation (sdaftuar)
  • #13075 cb9bbf7 Remove 'account' API from wallet functional tests (jnewbery)
  • #13221 ffa86af travis: Rename the build stage check_doc to lint (practicalswift)
  • #13205 3cbd25f Remove spurious error log in p2p_segwit.py (jnewbery)
  • #13291 536120e Don't include torcontrol.cpp into the test file (Empact)
  • #13281 2ac6315 Move linters to test/lint, add readme (MarcoFalke)
  • #13215 f8a29ca travis: Build tests on ubuntu 18.04 with docker (ken2812221)
  • #13349 24f7011 bench: Don't return a bool from main (laanwj)
  • #13347 87a9d03 travis: Skip cache for lint stage (MarcoFalke)
  • #13355 0b1c0c4 Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (practicalswift)
  • #13353 d4f6dac Fixup setting of PATH env var (MarcoFalke)
  • #13352 e24bf1c Avoid checking reject code for now (MarcoFalke)
  • #13383 2722a1f bench: Use non-throwing parsedouble(…) instead of throwing boost::lexical_cast(…) (practicalswift)
  • #13367 264efdc Increase includeconf test coverage (MarcoFalke)
  • #13404 3d3d8ae speed up of tx_validationcache_tests by reusing of CTransaction (lucash-dev)
  • #13421 531a033 Remove portseed_offset from test runner (MarcoFalke)
  • #13440 5315660 Log as utf-8 (MarcoFalke)
  • #13066 fa4b906 Migrate verify-commits script to python, run in travis (ken2812221)
  • #13447 4b1edd3 travis: Increase travis_wait time while verifying commits (ken2812221)
  • #13350 f532d52 Add logging to provide anchor points when debugging p2p_sendheaders (lmanners)
  • #13406 4382f19 travis: Change mac goal to all deploy (ken2812221)
  • #13457 b222138 Drop variadic macro (MarcoFalke)
  • #13512 3a45493 mininode: Expose connection state through is_connected (MarcoFalke)
  • #13496 9ab4c2a Harden lint-filenames.sh (wodry)
  • #13219 08516e0 bench: Add block assemble benchmark (MarcoFalke)
  • #13530 b1dc39d bench: Add missing pow.h header (laanwj)
  • #12686 2643fa5 Add -ftrapv to CFLAGS and CXXFLAGS when --enable-debug is used. Enable -ftrapv in Travis (practicalswift)
  • #12882 d96bdd7 Make test_bitcoin pass under ThreadSanitzer (clang). Fix lock-order-inversion (potential deadlock) (practicalswift)
  • #13535 2328039 wallet_basic: Specify minimum required amount for listunspent (MarcoFalke)
  • #13551 c93c360 Fix incorrect documentation for test case cuckoocache_hit_rate_ok (practicalswift)
  • #13563 b330f3f bench: Simplify coinselection (promag)
  • #13517 a6ed99a Remove need to handle the network thread in tests (MarcoFalke)
  • #13522 686e97a Fix p2p_sendheaders race (jnewbery)
  • #13467 3dc2dcf Make p2p_segwit easier to debug (jnewbery)
  • #13598 0212187 bench: Fix incorrect behaviour in prevector.cpp (AkioNak)
  • #13565 b05ded1 Fix AreInputsStandard test to reference the proper scriptPubKey (Empact)
  • #13145 d3dae3d Use common getPath method to create temp directory in tests (winder)
  • #13645 2ea7eb6 skip rpc_zmq functional test as necessary (jamesob)
  • #13626 8f1106d Fix some TODOs in p2p_segwit (MarcoFalke)
  • #13138 8803c91 Remove accounts from wallet_importprunedfunds.py (jnewbery)
  • #13663 cbc9b50 Avoid read/write to default datadir (MarcoFalke)
  • #13682 f8a32a3 bench: Remove unused variable (practicalswift)
  • #13638 6fcdb5e Use MAX_SCRIPT_ELEMENT_SIZE from script.py (domob1812)
  • #13687 9d26b69 travis: Check that ~/.bitcoin is never created (MarcoFalke)
  • #13715 e1260a7 fixes mininode's P2PConnection sending messages on closing transport (marcoagner)
  • #13729 aa9429a travis: Avoid unnecessarily setting env variables on the lint build (Empact)
  • #13747 ab28b5b Skip P2PConnection's is_closing() check when not available (domob1812)
  • #13650 7a9bca6 travis: Don't store debug info if --enable-debug is set (ken2812221)
  • #13711 f98d1e0 bench: Add benchmark for unserialize prevector (AkioNak)
  • #13771 365384f travis: Retry to fetch docker image (MarcoFalke)
  • #13806 4d550ff Fix bench/block_assemble assert failure (jamesob)
  • #13779 d25079a travis: Improve readability of travis.yml and log outputs (scravy)
  • #13822 0fb9c87 bench: Make coinselection output groups pass eligibility filter (achow101)
  • #13247 e83d82a Add tests to SingleThreadedSchedulerClient() and document the memory model (skeees)
  • #13811 660abc1 travis: Run bench_bitcoin once (MarcoFalke)
  • #13837 990e182 Extract rpc_timewait as test param (MarcoFalke)
  • #13851 9c4324d fix locale for lint-shell (scravy)
  • #13823 489b51b quote path in authproxy for external multiwallets (MarcoFalke)
  • #13849 2b67354 travis: Use only travis jobs: instead of mix of jobs+matrix (scravy)
  • #13859 2384323 Add emojis to test_runner path and wallet filename (MarcoFalke)
  • #13916 8ac7125 wait_for_verack by default (MarcoFalke)
  • #13669 f66e1c7 Cleanup create_transaction implementations (conscott)
  • #13924 09ada21 Simplify comparison in rpc_blockchain.py (domob1812)
  • #13913 a08533c Remove redundant checkmempool/checkblockindex extra_args (MarcoFalke)
  • #13915 a04888a Add test for max number of entries in locator (MarcoFalke)
  • #13867 1b04b55 Make extended tests pass on native Windows (MarcoFalke)
  • #13944 0df7a6c Port usage of deprecated optparse module to argparse module (Kvaciral)
  • #13928 b8eb0df blocktools enforce named args for amount (MarcoFalke)
  • #13054 bffb35f Enable automatic detection of undefined names in Python tests scripts. Remove wildcard imports (practicalswift)
  • #14069 cf3d7f9 Use assert not BOOST_CHECK_* from multithreaded tests (skeees)
  • #14071 fab0fbe Stop txindex thread before calling destructor (MarcoFalke)

Miscellaneous

  • #11909 8897135 contrib: Replace developer keys with list of pgp fingerprints (MarcoFalke)
  • #12394 fe53d5f gitian-builder.sh: fix --setup doc, since lxc is default (Sjors)
  • #12468 294a766 Add missing newline in init.cpp log message (Aesti)
  • #12308 dcfe218 contrib: Add support for out-of-tree builds in gen-manpages.sh (laanwj)
  • #12451 aae64a2 Bump leveldb subtree (MarcoFalke)
  • #12527 d77b4a7 gitian-build.sh: fix signProg being recognized as two parameters (ken2812221)
  • #12588 d74b01d utils: Remove deprecated pyzmq call from python zmq example (kosciej)
  • #10271 bc67982 Use std::thread::hardware_concurrency, instead of Boost, to determine available cores (fanquake)
  • #12097 14475e2 scripts: Lint-whitespace: use perl instead of grep -p (Sjors)
  • #12098 17c44b2 scripts: Lint-whitespace: add param to check last n commits (Sjors)
  • #11900 842f61a script: Simplify checkminimalpush checks, add safety assert (instagibbs)
  • #12567 bb98aec util: Print timestamp strings in logs using iso 8601 formatting (practicalswift)
  • #12572 d8d9162 script: Lint-whitespace: find errors more easily (AkioNak)
  • #10694 ae5bcc7 Remove redundant code in MutateTxSign(CMutableTransaction&, const std::string&) (practicalswift)
  • #12659 3d16f58 Improve Fatal LevelDB Log Messages (eklitzke)
  • #12643 0f0229d util: Remove unused sync_chain (MarcoFalke)
  • #12102 7fb8fb4 Apply hardening measures in bitcoind systemd service file (Flowdalic)
  • #12652 55f490a bitcoin-cli: Provide a better error message when bitcoind is not running (practicalswift)
  • #12630 c290508 Provide useful error message if datadir is not writable (murrayn)
  • #11881 624bee9 Remove Python2 support (jnewbery)
  • #12821 082e26c contrib: Remove unused import string (MarcoFalke)
  • #12829 252c1b0 Python3 fixup (jnewbery)
  • #12822 ff48f62 Revert 7deba93bdc76616011a9f493cbc203d60084416f and fix expired-key-sigs properly (TheBlueMatt)
  • #12820 5e53b80 contrib: Fix check-doc script regexes (MarcoFalke)
  • #12713 4490871 Track negated options in the option parser (eklitzke)
  • #12708 b2e5fe8 Make verify-commits.sh test that merges are clean (sipa)
  • #12891 3190785 logging: Add lint-logs.sh to check for newline termination (jnewbery)
  • #12923 a7cbe38 util: Pass pthread_self() to pthread_setschedparam instead of 0 (laanwj)
  • #12871 fb17fae Add shell script linting: Check for shellcheck warnings in shell scripts (practicalswift)
  • #12970 5df84de logging: Bypass timestamp formatting when not logging (theuni)
  • #12987 fe8fa22 tests/tools: Enable additional Python flake8 rules for automatic linting via Travis (practicalswift)
  • #12972 0782508 Add python3 script shebang lint (ken2812221)
  • #13004 58bbc55 Print to console by default when not run with -daemon (practicalswift)
  • #13039 8b4081a Add logging and error handling for file syncing (laanwj)
  • #13020 4741ca5 Consistently log CValidationState on call failure (Empact)
  • #13031 826acc9 Fix for utiltime to compile with msvc (sipsorcery)
  • #13119 81743b5 Remove script to clean up datadirs (MarcoFalke)
  • #12954 5a66642 util: Refactor logging code into a global object (jimpo)
  • #12769 35eb9d6 Add systemd service to bitcoind in debian package (ghost)
  • #13146 0bc980b rpcauth: Make it possible to provide a custom password (laanwj)
  • #13148 b62b437 logging: Fix potential use-after-free in logprintstr(…) (practicalswift)
  • #13214 0612d96 Enable Travis checking for two Python linting rules we are currently not violating (practicalswift)
  • #13197 6826989 util: Warn about ignored recursive -includeconf calls (kallewoof)
  • #13176 d9ebb63 Improve CRollingBloomFilter performance: replace modulus with FastMod (martinus)
  • #13228 d792e47 Add script to detect circular dependencies between source modules (sipa)
  • #13320 e08c130 Ensure gitian-build.sh uses bash (jhfrontz)
  • #13301 e4082d5 lint: Add linter to error on #include <*.cpp> (Empact)
  • #13374 56f6936 utils and libraries: checking for bitcoin address in translations (kaplanmaxe)
  • #13230 7c32b41 Simplify include analysis by enforcing the developer guide's include syntax (practicalswift)
  • #13450 32bf4c6 Add linter: Enforce the source code file naming convention described in the developer notes (practicalswift)
  • #13479 fa2ea37 contrib: Fix cve-2018-12356 by hardening the regex (loganaden)
  • #13448 a90ca40 Add linter: Make sure we explicitly open all text files using UTF-8 encoding in Python (practicalswift)
  • #13494 d67eff8 Follow-up to #13454: Fix broken build by exporting LC_ALL=C (practicalswift)
  • #13510 03f3925 Scripts and tools: Obsolete #!/bin/bash shebang (DesWurstes)
  • #13577 c9eb8d1 logging: Avoid nstart may be used uninitialized in appinitmain warning (mruddy)
  • #13603 453ae5e bitcoin-tx: Stricter check for valid integers (domob1812)
  • #13118 c05c93c RPCAuth Detection in Logs (Linrono)
  • #13647 4027ec1 Scripts and tools: Fix BIND_NOW check in security-check.py (conradoplg)
  • #13692 f5d166a contrib: Clone core repo in gitian-build (MarcoFalke)
  • #13699 4c6d1b9 contrib: Correct version check (kallewoof)
  • #13695 dcc0cff lint: Add linter for circular dependencies (Empact)
  • #13733 0d1ebf4 utils: Refactor argsmanager a little (AtsukiTak)
  • #13714 29b4ee6 contrib: Add lxc network setup for bionic host (ken2812221)
  • #13764 f8685f4 contrib: Fix test-security-check fail in ubuntu 18.04 (ken2812221)
  • #13809 77168f7 contrib: Remove debian and rpm subfolder (MarcoFalke)
  • #13799 230652c Ignore unknown config file options; warn instead of error (sipa)
  • #13894 df9f712 shutdown: Stop threads before resetting ptrs (MarcoFalke)
  • #13925 71dec5c Merge leveldb subtree (MarcoFalke)
  • #13939 ef86f26 lint: Make format string linter understand basic template parameter syntax (practicalswift)
  • #14105 eb202ea util: Report parse errors in configuration file (laanwj)
  • #12604 9903537 Add DynamicMemoryUsage() to CDBWrapper to estimate LevelDB memory use (eklitzke)
  • #12495 047865e Increase LevelDB max_open_files (eklitzke)
  • #12784 e80716d Fix bug in memory usage calculation (unintended integer division) (practicalswift)
  • #12618 becd8dd Set SCHED_BATCH priority on the loadblk thread (eklitzke)
  • #12854 5ca1509 Add P2P, Network, and Qt categories to the desktop icon (luke-jr)
  • #11862 4366f61 Network specific conf sections (ajtowns)
  • #13441 4a7e64f Prevent shared conf files from failing with different available options in different binaries (achow101)
  • #13471 5eca4e8 For AVX2 code, also check for AVX, XSAVE, and OS support (sipa)
  • #13503 c655b2c Document FreeBSD quirk. Fix FreeBSD build: Use std::min(…) to allow for compilation under certain FreeBSD versions (practicalswift)
  • #13725 07ce278 Fix bitcoin-cli --version (Empact)

Documentation

  • #12306 216f9a4 Improvements to UNIX documentation (axvr)
  • #12309 895fbd7 Explain how to update chainTxData in release process (laanwj)
  • #12317 85123be Document method for reviewers to verify chainTxData (jnewbery)
  • #12331 d32528e Properly alphabetize output of CLI --help option (murrayn)
  • #12322 c345148 Remove step making cloned repository world-writable for Windows build (murrayn)
  • #12354 b264528 add gpg key for fivepiece (fivepiece)
  • #11761 89005dd initial QT documentation (Sjors)
  • #12232 fdc2188 Improve "Turn Windows Features On or Off" step (MCFX2)
  • #12487 4528f74 init: Remove translation for -blockmaxsize option help (laanwj)
  • #12546 a4a5fc7 Minor improvements to Compatibility Notes (randolf)
  • #12434 21e2670 dev-notes: Members should be initialized (MarcoFalke)
  • #12452 71f56da clarified systemd installation instructions in init.md for Ubuntu users (DaveFromBinary)
  • #12615 1f93491 allow for SIGNER containing spaces (ken2812221)
  • #12603 85424d7 PeerLogicValidation interface (jamesob)
  • #12581 12ac2f0 Mention configure without wallet in FreeBSD instructions (dbolser)
  • #12619 8a709fb Give hint about gitian not able to download (kallewoof)
  • #12668 de2fcaa do update before fetching packages in WSL build guide (nvercamm)
  • #12586 e7721e6 Update osx brew install instruction (fanquake)
  • #12760 7466a26 Improve documentation on standard communication channels (jimpo)
  • #12797 0415b1e init: Fix help message for checkblockindex (MarcoFalke)
  • #12800 2d97611 Add note about our preference for scoped enumerations ("enum class") (practicalswift)
  • #12798 174d016 Refer to witness reserved value as spec. in the BIP (MarcoFalke)
  • #12759 d3908e2 Improve formatting of developer notes (eklitzke)
  • #12877 2b54155 Use bitcoind in Tor documentation (knoxcard)
  • #12896 b15485e Fix conflicting statements about initialization in developer notes (practicalswift)
  • #12850 319991d add qrencode to brew install instructions (buddilla)
  • #12007 cd8e45b Clarify the meaning of fee delta not being a fee rate in prioritisetransaction RPC (honzik666)
  • #12927 06ead15 fixed link, replaced QT with Qt (trulex)
  • #12852 ebd786b devtools: Setup ots git integration (MarcoFalke)
  • #12933 3cf76c2 Refine header include policy (MarcoFalke)
  • #12951 6df0c6c Fix comment in FindForkInGlobalIndex (jamesob)
  • #12982 a63b4e3 Fix inconsistent namespace formatting guidelines (ryanofsky)
  • #13026 9b3a67e Fix include comment in src/interfaces/wallet.h (promag)
  • #13012 d1e3c5e Add comments for chainparams.h, validation.cpp (jamesob)
  • #13064 569e381 List support for BIP173 in bips.md (sipa)
  • #12997 646b7f6 build-windows: Switch to Artful, since Zesty is EOL (MarcoFalke)
  • #12384 c5f7efe Add version footnote to tor.md (Willtech)
  • #13165 627c376 Mention good first issue list in CONTRIBUTING.md (fanquake)
  • #13295 fb77310 Update OpenBSD build instructions for OpenBSD 6.3 (practicalswift)
  • #13340 3a8e3f4 remove leftover check-doc documentation (fanquake)
  • #13346 60f0358 update bitcoin-dot-org links in release-process.md (fanquake)
  • #13372 f014933 split FreeBSD build instructions out of build-unix.md (steverusso)
  • #13366 861de3b Rename “OS X” to the newer “macOS” convention (giulio92)
  • #13369 f8bcef3 update transifex doc link (mess110)
  • #13312 b22115d Add a note about the source code filename naming convention (practicalswift)
  • #13460 1939536 Remove note to install all boost dev packages (MarcoFalke)
  • #13476 9501938 Fix incorrect shell quoting in FreeBSD build instructions (murrayn)
  • #13402 43fa355 Document validationinterace callback blocking deadlock potential (TheBlueMatt)
  • #13488 d6cf4bd Improve readability of "Squashing commits" (wodry)
  • #13531 ee02deb Clarify that mempool txiter is const_iterator (MarcoFalke)
  • #13418 01f9098 More precise explanation of parameter onlynet (wodry)
  • #13592 1756cb4 Modify policy to not translate command-line help (ken2812221)
  • #13588 b77c38e Improve doc of options addnode, connect, seednode (wodry)
  • #13614 17e9106 Update command line help for -printtoconsole and -debuglogfile (satwo) (fanquake)
  • #13605 8cc048e corrected text to reflect new(er) process of specifying fingerprints (jhfrontz)
  • #13481 b641f60 Rewrite some validation docs as lock annotations (MarcoFalke)
  • #13680 30640f8 Remove outdated comment about miner ignoring CPFP (jamesob)
  • #13625 7146672 Add release notes for -printtoconsole and -debuglogfile changes (satwo)
  • #13718 f7f574d Specify preferred Python string formatting technique (masonicboom)
  • #12764 10b9a81 Remove field in getblocktemplate help that has never been used (conscott)
  • #13742 d2186b3 Adjust bitcoincore.org links (MarcoFalke)
  • #13706 94dd89e Minor improvements to release-process.md (MitchellCash)
  • #13775 ef4fac0 Remove newlines from error message (practicalswift)
  • #13803 feb7dd9 add note to contributor docs about warranted PR's (kallewoof)
  • #13814 67af7ef Add BIP174 to list of implemented BIPs (sipa)
  • #13835 c1cba35 Fix memory consistency model in comment (skeees)
  • #13824 aa30e4b Remove outdated net comment (MarcoFalke)
  • #13853 317477a correct versions in dependencies.md (fanquake)
  • #13872 37ab117 Reformat -help output for help2man (real-or-random)
  • #13717 8c3c402 Link to python style guidelines from developer notes (masonicboom)
  • #13895 1cd5f2c fix GetWarnings docs to reflect behavior (Empact)
  • #13911 3e3a50a Revert translated string change, clarify wallet log messages (PierreRochard)
  • #13908 d6faea4 upgrade rescan time warning from minutes to >1 hour (masonicboom)
  • #13905 73a09b4 fixed bitcoin-cli -help output for help2man (hebasto)
  • #14100 2936dbc Change documentation for =0 for non-boolean options (laanwj)
  • #14096 465a583 Add reference documentation for descriptors language (sipa)
  • #12757 0c5f67b Clarify include guard naming convention (practicalswift)

Why decentralization matters

From eras of the internet to crypto networks
by Chris Dixon
https://medium.com/@cdixon/why-decentralization-matters-5e3f79f7638e

Tuesday, September 4, 2018

Bitcoin Log view


Do you see it?... low, mid and high

Bitcoin Log 1


Bitcoin Log 2


BTC price model

Wow - great reply in the comment section of The Economist

Bitcoin is a network. It is not like any other asset. People are not trained to think correctly about this phenomenon unless they have training as physicist or mathematicians.
Please plot BTC price in a log-log plot. Not just log but log-log. What you would see is a straight line that goes up, up and up, with some relatively small deviation from general pattern. It is called a power law when you see such a trend. By the way you will need to use a time scale that has zero at genesis one (most available data sets have no data so early on). This is remarkable. Here the graph: https://imgur.com/gallery/mpxUoGR.
This cannot be due to chance. The value of BTC is based on some fundamental phenomenon. It is a network, like cities, the internet, systems of rivers and so on. Physicists are familiar with such complex systems.
The incredible usefulness and utility of BTC is that is a mathematical way to give value to a decentralized network that can transfer information from one place to another. It is encrypted, it is decentralized and if one could hack it, one could make billions of dollars overnight (crashing the system but still enriching fast an individual if he could sell the BTC fast enough). It has not been hacked so people give value to that. This happens with out conscious participation of the agents participating in the network but because the exchange is continuous and pervasive and not manipulated (with the exception of the not significant bubbles you see in the chart) the value increases with time as more participants join in. Please absorb all this and understand.
Before saying meaningless things about one of the most important financial and information theoretic innovations of all the time.

Monday, September 3, 2018

Friday, August 31, 2018

Why bitcoin matters (2014)

The idea of smart contracts (1997)

By Nick Szabo


What is the meaning and purpose of "security"? How does it relate the the relationships we have? I argue that the formalizations of our relationships -- especially contracts -- provide the blueprint for ideal security.

Many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.

Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.

As another example, consider a hypothetical digital security system for automobiles. The smart contract design strategy suggests that we successively refine security protocols to more fully embed in a property the contractual terms which deal with it. These protocols would give control of the cryptographic keys for operating the property to the person who rightfully owns that property, based on the terms of the contract. In the most straightforward implementation, the car can be rendered inoperable unless the proper challenge-response protocol is completed with its rightful owner, preventing theft.

If the car is being used to secure credit, strong security implemented in this traditional way would create a headache for the creditor - the repo man would no longer be able to confiscate a deadbeat's car. To redress this problem, we can create a smart lien protocol: if the owner fails to make payments, the smart contract invokes the lien protocol, which returns control of the car keys to the bank. This protocol might be much cheaper and more effective than a repo man. A further reification would provably remove the lien when the loan has been paid off, as well as account for hardship and operational exceptions. For example, it would be rude to revoke operation of the car while it's doing 75 down the freeway.

In this process of successive refinement we've gone from a crude security system to a reified contract:

          (1) A lock to selectively let in the owner and
              exlude third parties;
          (2) A back door to let in the creditor;
          (3a) Creditor back door switched on only upon nonpayment
               for a certain period of time; and
          (3b) The final electronic payment permanently switches
               off the back door.
Mature security systems will be undertaking different behavior for different contracts. To continue with our example, if the automobile contract were a lease, the final payment would switch off leasee access; for purchase on credit, it would switch off creditor access. A security system, by successive redesign, increasingly approaches the logic of the contract which governs the rights and obligations covering the object, information, or computation being secured. Qualitatively different contractual terms, as well as technological differences in the property, give rise to the need for different protocols.
(Derived from "Formalizing and Securing Relationships on Public Networks" , by Nick Szabo)

A related article discusses a formal language for analyzing contracts and specifying smart contracts.

http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html

Wednesday, August 22, 2018

Plain text of Satoshi Nakamoto Bitcoin White Paper

Bitcoin: A Peer-to-Peer Electronic Cash System

Satoshi Nakamoto

satoshin@gmx.com

www.bitcoin.org

Abstract.

A purely peer-to-peer version of electronic cash would allow online
payments to be sent directly from one party to another without going through a
financial institution. Digital signatures provide part of the solution, but the main
benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing chain of
hash-based proof-of-work, forming a record that cannot be changed without redoing
the proof-of-work. The longest chain not only serves as proof of the sequence of
events witnessed, but proof that it came from the largest pool of CPU power. As
long as a majority of CPU power is controlled by nodes that are not cooperating to
attack the network, they'll generate the longest chain and outpace attackers. The
network itself requires minimal structure. Messages are broadcast on a best effort
basis, and nodes can leave and rejoin the network at will, accepting the longest
proof-of-work chain as proof of what happened while they were gone.

1. Introduction
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as
trusted third parties to process electronic payments. While the system works well enough for
most transactions, it still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since financial institutions cannot
avoid mediating disputes. The cost of mediation increases transaction costs, limiting the
minimum practical transaction size and cutting off the possibility for small casual transactions,
and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible
services. With the possibility of reversal, the need for trust spreads. Merchants must
be wary of their customers, hassling them for more information than they would otherwise need.
A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties
can be avoided in person by using physical currency, but no mechanism exists to make payments
over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic proof instead of trust,
allowing any two willing parties to transact directly with each other without the need for a trusted
third party. Transactions that are computationally impractical to reverse would protect sellers
from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In
this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed
timestamp server to generate computational proof of the chronological order of transactions. The
system is secure as long as honest nodes collectively control more CPU power than any
cooperating group of attacker nodes.


Transactions
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership.

The problem of course is the payee can't verify that one of the owners did not double-spend
the coin. A common solution is to introduce a trusted central authority, or mint, that checks every
transaction for double spending. After each transaction, the coin must be returned to the mint to
issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
The problem with this solution is that the fate of the entire money system depends on the
company running the mint, with every transaction having to go through them, just like a bank.
We need a way for the payee to know that the previous owners did not sign any earlier
transactions. For our purposes, the earliest transaction is the one that counts, so we don't care
about later attempts to double-spend. The only way to confirm the absence of a transaction is to
be aware of all transactions. In the mint based model, the mint was aware of all transactions and
decided which arrived first. To accomplish this without a trusted party, transactions must be
publicly announced [1], and we need a system for participants to agree on a single history of the
order in which they were received. The payee needs proof that at the time of each transaction, the
majority of nodes agreed it was the first received.

Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a
hash of a block of items to be timestamped and widely publishing the hash, such as in a
newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the
time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work
system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts.
The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the
hash begins with a number of zero bits. The average work required is exponential in the number
of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the
block until a value is found that gives the block's hash the required zero bits. Once the CPU
effort has been expended to make it satisfy the proof-of-work, the block cannot be changed
without redoing the work. As later blocks are chained after it, the work to change the block
would include redoing all the blocks after it.
The proof-of-work also solves the problem of determining representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the greatest proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the
fastest and outpace any competing chains. To modify a past block, an attacker would have to
redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the
work of the honest nodes. We will show later that the probability of a slower attacker catching up
diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in running nodes over time,
the proof-of-work difficulty is determined by a moving average targeting an average number of
blocks per hour. If they're generated too fast, the difficulty increases.

5. Network
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work
is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.

Tx Tx ...
New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach
many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped
messages. If a node does not receive a block, it will request it when it receives the next block and
realizes it missed one.

6. Incentive
By convention, the first transaction in a block is a special transaction that starts a new coin owned
by the creator of the block. This adds an incentive for nodes to support the network, and provides
a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant of amount of new coins is analogous to gold miners expending
resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.
The incentive can also be funded with transaction fees. If the output value of a transaction is
less than its input value, the difference is a transaction fee that is added to the incentive value of
the block containing the transaction. Once a predetermined number of coins have entered
circulation, the incentive can transition entirely to transaction fees and be completely inflation
free.
The incentive may help encourage nodes to stay honest. If a greedy attacker is able to
assemble more CPU power than all the honest nodes, he would have to choose between using it
to defraud people by stealing back his payments, or using it to generate new coins. He ought to
find it more profitable to play by the rules, such rules that favour him with more new coins than
everyone else combined, than to undermine the system and the validity of his own wealth.

7. Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space. To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.
A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.

Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep
a copy of the block headers of the longest proof-of-work chain, which he can get by querying
network nodes until he's convinced he has the longest chain, and obtain the Merkle branch
linking the transaction to the block it's timestamped in. He can't check the transaction for
himself, but by linking it to a place in the chain, he can see that a network node has accepted it,
and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker. While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.

9. Combining and Splitting Value
Although it would be possible to handle coins individually, it would be unwieldy to make a
separate transaction for every cent in a transfer. To allow value to be
.

10. Privacy
The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party. The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous. The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone. This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.
As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner. Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner. The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.

11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such
as creating value out of thin air or taking money that never belonged to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes will never accept a block
containing them. An attacker can only try to change one of his own transactions to take back
money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk. The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an
infinite number of trials to try to reach breakeven. We can calculate the probability he ever
reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind

New Privacy Model
Traditional Privacy Model
Given our assumption that p > q, the probability drops exponentially as the number of blocks the
attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky
lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being
sufficiently certain the sender can't change the transaction. We assume the sender is an attacker
who wants to make the recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed. The receiver will be alerted when that happens, but the
sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment. Once the transaction is sent, the dishonest sender starts working in secret on a
parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been
linked after it. He doesn't know the exact amount of progress the attacker has made, but
assuming the honest blocks took the average expected time per block, the attacker's potential
progress will be a Poisson distribution with expected value:

12. Conclusion
We have proposed a system for electronic transactions without relying on trust. We started with
the usual framework of coins made from digital signatures, which provides strong control of
ownership, but is incomplete without a way to prevent double-spending. To solve this, we
proposed a peer-to-peer network using proof-of-work to record a public history of transactions
that quickly becomes computationally impractical for an attacker to change if honest nodes
control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes
work all at once with little coordination. They do not need to be identified, since messages are
not routed to any particular place and only need to be delivered on a best effort basis. Nodes can
leave and rejoin the network at will, accepting the proof-of-work chain as proof of what
happened while they were gone. They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
them. Any needed rules and incentives can be enforced with this consensus mechanism.


References
[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal
trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no
2, pages 99-111, 1991.
[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping,"
In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference
on Computer and Communications Security, pages 28-35, April 1997.
[6] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and
Privacy, IEEE Computer Society, pages 122-133, April 1980.
[8] W. Feller, "An introduction to probability theory and its applications," 1957.

Majority is not Enough: Bitcoin Mining is Vulnerable

Thursday, August 16, 2018

How can Bitcoin fail?

  • Bug discovered or coding error
  • Encryption broken
  • Hacking attack on Bitcoin nodes and Wallets
  • Internet access cut off for countries - undersea cables and satellite
  • Malware / virus deletes blockchain on nodes
  • New cryptographic discover renders Bitcoin obsolete
  • Not physically backed asset - e.g. Gold (even though energy used)
  • No real use case
  • Quantum computing breaks encryption
  • Regulation by Governments with tax policy
  • Regulation by Central banks not allowing Fiat into the Bitcoin ecosystem and out of the Bitcoin ecosystem
  • Satoshi Nakamoto identity revealed or sells Bitcoin
  • Trust issues - no trust, no confidence, trust broken

Monday, August 13, 2018

Great resource: collection of bibliography links for cryptocurrency course

Here are links to research papers. These were listed in the Princeton University cryptocurrency course:

https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=910977

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.9475&rep=rep1&type=pdf

http://www.hashcash.org/papers/hashcash.pdf

https://lamport.azurewebsites.net/pubs/paxos-simple.pdf

https://unglueit-files.s3.amazonaws.com/ebf/05db7df4f31840f0a873d6ea14dcc28d.pdf

https://fc13.ifca.ai/proc/1-2.pdf

https://cs.jhu.edu/~sdoshi/crypto/papers/shamirturing.pdf

https://users.encs.concordia.ca/~clark/papers/2015_ccs.pdf

https://allquantor.at/blockchainbib/pdf/taylor2013bitcoin.pdf

http://www.allied-control.com/publications/Analysis_of_Large-Scale_Bitcoin_Mining_Operations.pdf

http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf

https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf

https://www.econinfosec.org/archive/weis2013/papers/KrollDaveyFeltenWEIS2013.pdf

https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf

https://www.mercatus.org/system/files/Brito_BitcoinPrimer.pdf

https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf

http://antoanthongtin.vn/Portals/0/UploadImages/kiennt2/Sach/Sach-CSDL4/D039.pdf

https://www.cs.ru.nl/~jhh/pub/secsem/chaum1985bigbrother.pdf

https://www.dfs.ny.gov/legal/regulations/adoptions/dfsp200t.pdf

https://www.tarsnap.com/scrypt/scrypt.pdf
http://www.std.org/~msm/common/memorybound.pdf

http://hashcash.org/papers/cuckoo.pdf

https://eprint.iacr.org/2013/784.pdf

http://www.dartmouth.edu/~ericz/predictionmarkets.pdf

https://mason.gmu.edu/~rhanson/PromisePredMkt.pdf
https://blockstream.com/sidechains.pdf

http://randomwalker.info/publications/namespaces.pdf

http://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf

https://eprint.iacr.org/2015/702.pdf

Saturday, August 11, 2018

How to Lose $3 Billion of Bitcoin in India

Investors in India lost an alleged $3B of Bitcoin, in what could be one of the country’s biggest cryptocurrency scams


Archana Chaudhary and Jeanette Rodrigues
August 9, 2018, 10:00 PM

Accusations of tax evasion and police corruption, a kidnapper who was kidnapped, a fugitive politician, and billions in bitcoin lost. This is crypto-trading Gujarat-style.

The ingredients are part of an investigation in Indian Prime Minister Narendra Modi’s home state into allegations that investors poured cash into a bitcoin-based Ponzi scheme that could exceed the country’s largest banking scandal. The fallout extends as far as Texas and has embroiled a former lawmaker, tarnishing Modi’s ruling party months before an election.

Source:
https://www.bloomberg.com/news/articles/2018-08-09/cryptokidnapping-or-how-to-lose-3-billion-of-bitcoin-in-india

Friday, August 10, 2018

Crypto Technicals Flash Pain Ahead, Eye Bitcoin at $4,000

https://www.bloomberg.com/news/articles/2018-08-09/crypto-technicals-flash-more-pain-ahead-eye-bitcoin-at-4-000

Good long read from Arstechnica... Bitcoin primer

Want to really understand how bitcoin works? Here’s a gentle primer

Ars goes deep on the breakthrough online payment network.


Timothy B. Lee - 12/15/2017, 12:35 PM

The soaring price of bitcoin—the virtual currency is now worth more than $250 billion—has gotten a lot of attention in recent weeks. But the real significance of bitcoin isn't just its rising value. It's the technological breakthrough that allowed the network to exist in the first place.

Bitcoin's still anonymous inventor, who went by the pseudonym Satoshi Nakamoto, figured out a completely new way for a decentralized network to reach a consensus about a shared transaction ledger. This innovation made possible the kind of fully decentralized electronic payment systems that cypherpunks had dreamed about for decades.

Continue reading here:
https://arstechnica.com/tech-policy/2017/12/how-bitcoin-works/

Thursday, August 9, 2018

SEC Postpones Decision on Bitcoin ETF Listing to September

SEC Postpones Decision on Bitcoin ETF Listing to September.

The U.S. Securities and Exchange Commission has postponed a decision on whether to allow the listing of an exchange-traded fund backed by Bitcoin.

The agency now has until Sept. 30 to “approve or disapprove, or institute proceedings to determine whether to disapprove” a proposed rule change from Cboe Global Markets Inc. that would allow the fund from VanEck Associates Corp. and SolidX Partners Inc. to list, the SEC said in a statement. An initial deadline was due to expire next week.

The SEC’s delay is another blow to crypto-currency enthusiasts after the regulator denied an exchange’s request to list a similar fund run by Tyler and Cameron Winklevoss late last month. Some had argued that VanEck’s proposal was more likely to gain approval thanks to plans for a high minimum share price that would discourage retail investors, and insurance. The Commission had received more than 1,300 comments on the proposed rule change as of Aug. 6, it said.
https://www.bloomberg.com/news/articles/2018-08-07/sec-postpones-decision-on-vaneck-bitcoin-etf-to-september

Wednesday, August 8, 2018

Read this book written in 1999

Cryptonomicon - by Neal Stephenson

This book is all about crptocurrency and cryptography. Great read!

https://www.goodreads.com/book/show/816.Cryptonomicon

Here is further info about  the book:

Cryptonomicon zooms all over the world, careening conspiratorially back and forth between two time periods--World War II and the present. Our 1940s heroes are the brilliant mathematician Lawrence Waterhouse, crypt analyst extraordinaire, and gung-ho, morphine-addicted marine Bobby Shaftoe. They're part of Detachment 2702, an Allied group trying to break Axis communication codes while simultaneously preventing the enemy from figuring out that their codes have been broken. Their job boils down to layer upon layer of deception. Dr. Alan Turing is also a member of 2702, and he explains the unit's strange workings to Waterhouse. "When we want to sink a convoy, we send out an observation plane first... Of course, to observe is not its real duty--we already know exactly where the convoy is. Its real duty is to be observed... Then, when we come round and sink them, the Germans will not find it suspicious."

All of this secrecy resonates in the present-day story line, in which the grandchildren of the WWII heroes--inimitable programming geek Randy Waterhouse and the lovely and powerful Amy Shaftoe--team up to help create an offshore data haven in Southeast Asia and maybe uncover some gold once destined for Nazi coffers. To top off the paranoiac tone of the book, the mysterious Enoch Root, key member of Detachment 2702 and the Societas Eruditorum, pops up with an unbreakable encryption scheme left over from WWII to befuddle the 1990s protagonists with conspiratorial ties.

Tuesday, August 7, 2018

Visualisation...start of Bitcoin

Here is an interesting interactive graphic.

It shows the entire six-year history of all bitcoin transactions – as recorded in the 35 gigabyte blockchain ledger. 

What insights can be extracted from data, and why are we doing this? Elliptic is working to counter the illicit use of bitcoin, by providing businesses with tools that can analyse cryptocurrency payments and determine whether they are likely to be proceeds of crime. By identifying dark marketplaces, known thefts and other illicit activity on the blockchain we can help businesses to prevent money laundering.


https://info.elliptic.co/hubfs/big-bang/bigbang-v1.html?t=1533042584917

Analysis Websites....

Here are a couple of websites for analysis of transactions.

Chainalysis
https://www.chainalysis.com

Elliptic
https://www.elliptic.co

Could Satoshi Nakamoto be...

There are many theories. Is it one person? Is it a group of people?

Here are the top names that people believe could be Satoshi Nakamoto:

Hal Finney
Many people believe that Hal Finney, the first person to receive a bitcoin transaction, was actually Satoshi Nakamoto. If so, the mystery of the founder’s identity may never be solved, as Finney passed away in 2014 from ALS.

A Russian or Chinese agent
The Obama administration was concerned that Satoshi was an agent of Russia or China — that Bitcoin might be weaponized against us in the future. Knowing the source would help the administration understand their motives.

The CIA/NSA
A group named CIA Project claims that bitcoin is a creation of the CIA or NSA. While the group provided “evidence,” such as stating the name, Satoshi Nakamoto, roughly translates to “Central Intelligence” in Japanese, their perspective is considered to be no more than a conspiracy theory.

Nick Szabo
A reclusive American, deeply involved in the bitcoin project, released a blog expressing interest in the technology before Bitcoin’s release, but later reposted it to alter the publishing date. After the blog post about bit gold was determined to be from before bitcoins release, researchers at Aston University compared his writing style to Satoshi Nakamoto’s. According to Jack Grieve, a lecturer who led the project effort, the similarities were “uncanny.”

A Group of Companies
Some bitcoin users have suggested (jokingly) that Satoshi Nakamoto could actually be a group of four Asian technology companies: Samsung, Toshiba, Nakamichi, and Motorola. The name can be created by taking the “sa” from Samsung, “toshi” from Toshiba, “naka” from Nakamichi, and “moto” from Motorola.

https://bitcoinblockchaincryptodigitalassets.blogspot.com/2018/08/free-book-princeton-university.html




Monday, August 6, 2018

Mt. Gox - Magic: The Gathering Online eXchange

Here is an interesting read. This is all about an exchange that was hacked. The name is/was Mt. Gox - Magic: The Gathering Online eXchange.

http://fortune.com/longform/bitcoin-mt-gox-hack-karpeles/

Mt. Gox and the Surprising Redemption of Bitcoin’s Biggest Villain
He led the world's largest Bitcoin exchange before a mysterious heist made it go bust. As clues emerge and Bitcoin's price surges, Mark Karpelès is on the hunt for answers.
By Jen Wieczner
April 19, 2018

The moment that would change the history of Mt. Gox came without so much as a beep. Mark Karpelès, the CEO of what until recently had been the world’s biggest Bitcoin exchange, was finally alone, save for his tabby cat, in his palatial penthouse with a panoramic view of Tokyo. It was the evening of March 7, 2014, and Karpelès had barely slept in the week since Mt. Gox had sought bankruptcy protection, announcing that 850,000 of its Bitcoins, worth some $473 million at the time—and representing 7% of all Bitcoins then in existence—had somehow disappeared. With protesters and camera crews swarming in front of Mt. Gox’s office and the price of Bitcoin in free fall, the usually unflappable Frenchman had been confined to a self-imposed house arrest, subsisting on the buttery pastries he liked to bake and reading the hate mail that flooded in from all corners of the Internet—most of it accusing him of stealing the money himself. Today the Mt. Gox hack remains the worst disaster in Bitcoin’s short history.

It wasn’t until his lawyers had gone home for the day that Karpelès could retreat to his computer, and that’s when he noticed the shocking number on his screen. Following his company’s collapse, he’d spent days methodically double-checking Mt. Gox’s old digital wallets, where the secret alphanumeric keys for accessing Bitcoins are stored. One after another—a dozen so far—the wallets had come up empty. But this time, when the blockchain-scanning program finished running after six hours, it had silently served up an unexpected result: He’d found 200,000 Bitcoins, stashed away in an archived file in the cloud—apparently forgotten and untouched for three years.

Mark Karpelès in Tokyo’s Shinjuku district. The former Mt. Gox CEO, who once felt safe leaving his laptop on a park bench, refused to set down his bag for fear of theft.
Mark Karpelès in Tokyo’s Shinjuku district. The former Mt. Gox CEO, who once felt safe leaving his laptop on a park bench, refused to set down his bag for fear of theft. Photographed by Eric Rechsteiner for Fortune
In a series of conversations with Fortune, Karpelès shared for the first time the full details of what he says really happened in the final days of Mt. Gox—including his account of how he stumbled on the 200,000 Bitcoins.

The surprise discovery would turn out to be, to this day, the only hope Mt. Gox customers have of getting their money back. It’s been proved that the other 650,000 missing Bitcoins were stolen—we now know, by various hackers. But Karpelès continues to be one of the most infamous figures in cryptocurrency. And his legal fate is uncertain, even as new evidence has emerged that largely exonerates him.

Ironically, today Karpelès doesn’t view the retrieval of the 200,000 Bitcoins as a lucky break. They’ve become such a subject of contention, in fact, that he wonders whether it might have been better if they’d remained lost. “At the time, I felt finding these was a good thing for everyone,” recalls Karpelès, now 32, his French accent still strong after nearly nine years in Japan. “But now this is also the main reason why we are stuck fighting.”

To many, the belated revelation seemed too good to be true—making the unemotional programmer-turned-mogul look even guiltier. Was he just coughing up his go-bag in an attempt to wiggle out of trouble? Soon, they had even more reason to suspect him: Leaked trading records suggested that what could only be an internal Mt. Gox account—widely known today as the “Willy bot”—was artificially inflating its account balance and using the money to buy Bitcoins. When Mt. Gox ran low on Bitcoins, Willy helped make up the shortfall. Sometimes its trades went the other way, selling borrowed Bitcoins to generate cash. Critics speculate that it was a fraudulent, if failed, exercise to keep Mt. Gox afloat.

That suspicious activity by the Willy bot led to Karpelès’s arrest in August 2015 on charges of manipulating electronic data; he admitted in court last summer to running what he called the “obligation exchange” but disputes doing anything illegal. After spending almost a year in jail, Karpelès is currently on trial in Tokyo, facing criminal allegations such as embezzlement and breach of trust, all unrelated to the missing Bitcoins.

But it was an unforeseen twist that today is causing Karpelès the greatest angst. Between the time Mt. Gox shut down and when it entered liquidation in April 2014, the price of Bitcoin had plummeted more than 20% to $483. It would be over two and a half years before Bitcoin would regain its previous high—long enough that many Mt. Gox victims didn’t even bother filing a claim for what they considered an insignificant sum. Then early last year, Bitcoin finally broke its old record. By late May, it was trading at nearly $2,200, making Mt. Gox’s remaining Bitcoins—202,185 to be exact—worth more than everything it owed in claims. When the Bitcoin price peaked at $20,000 in December, the value of Mt. Gox’s assets (by then including Bitcoin derivatives such as Bitcoin Cash) ballooned to $4.4 billion—nearly 10 times the amount Mt. Gox said it lost in the first place. “The fact that you have a bankruptcy where the only asset that it owns goes up by 5,000%, that’s pretty unprecedented,” says Daniel Kelman, a lawyer and Mt. Gox creditor who spent a year in Tokyo working on the case.

After months studying Japan’s bankruptcy code while in solitary confinement, Karpelès knew there was a wrinkle: Under the law, most of that excess would return to shareholders of Mt. Gox, of which he held 88%. At current prices, the windfall would make him a billionaire. It would also mean an interminable nightmare of lawsuits and threats that Karpelès—who is also in personal bankruptcy—is desperate to avoid. He says he’d happily give the money back if it came to him, but the estimated 60% tax triggered in the process would be catastrophic.

“I never expected to get anything out of this,” Karpelès tells me when we meet in Tokyo in March. “It would bring more trouble than anything.”

We’re on the second floor of a Japanese café, in a stuffy meeting room that Karpelès says is not much bigger than his jail cell. Deprived of a computer behind bars, he passed time by measuring the room using the length of his notebook. (After his release, Karpelès sent friends a chart of the 70 pounds he’d lost while detained.) It’s the first day in Tokyo that finally feels like spring, cherry blossoms in bloom, but he has holed up here in the café because it’s roughly equidistant from the offices of his various lawyers, as well as the bankruptcy trustee, whom he meets with regularly out of a sense of “duty” to his former customers. He’s been so busy, he says, he didn’t have time to shave that morning.

Karpelès took control of Mt. Gox—the name is an acronym for Magic: The Gathering Online eXchange, after the trading card game that inspired the original site—in 2011 from founder Jed McCaleb. Employees don’t remember Karpelès ever seeming fazed about anything: He took meetings from a vibrating massage chair and churned out combs using a 3D printer he’d bought for the office. His hallmark reply to questions: “Should be fine.”

But he’s lately developed a sense of gallows humor uncharacteristic of his Mt. Gox days. Even if he wanted to buy Bitcoin today, he doubts he could find an exchange that would take his money, he laughs, and notes that it’s been a few months since he’s received any death threats—“a new record.” He turns serious, though, when he recounts the sleepless nights in February 2014 when he says he first discovered that all of Mt. Gox’s Bitcoins were missing. “I think this really is the worst experience for anyone to have in life,” he says. Still, he’s not sure he could have done the job better. “If I knew at the time what I know today, I would have done things differently, of course,” he says with a practiced tone. “But based on the information I had at the time, and the situation at the time, I still think that I’ve done the best I could do with what I had.”

The question of what Karpelès knew, and when, though, remains more of a mystery than even who stole the coins. Bitcoin’s public ledger, or blockchain, allows anyone to trace the path of transactions, showing the wallets where Mt. Gox’s Bitcoins went. But the same blockchain analysis, multiple experts have confirmed, has also revealed an unsettling fact: By mid-2013, Mt. Gox had already lost all its Bitcoins—eight months before it admitted so publicly.

The timing of this insolvency, analysis shows, coincided with the Willy bot kicking into high gear—perhaps providing a hint as to Karpelès’s true motivations. “I feel that this is a reaction to this revelation that okay, all the money is gone,” says Michael Gronager, CEO of Chainalysis, which was hired by the Mt. Gox bankruptcy trustee to investigate the Bitcoins’ disappearance. Yet it’s also why he doesn’t believe Karpelès was planning to run away with the 200,000 Bitcoins. “I think that had he found them before he went bankrupt, he would never have gone bankrupt,” says Gronager. Rather, he says, Karpelès would have used the hoard to cover his losses.



When Mt. Gox froze Bitcoin withdrawals in 2014, a customer named Kolin Burges hopped a flight from London to Tokyo. For more than two weeks, until Mt. Gox declared bankruptcy, he kept vigil outside the exchange’s headquarters, holding a sign reading, “MTGOX WHERE IS OUR MONEY?” Other protesters soon joined him, demonstrating the frustration of Mt. Gox customers worldwide.

Kim Nilsson was just as vexed, but standing in the snow wasn’t his style. A modest Swedish software engineer with a goatee and a quiet voice, Nilsson, who also owned Bitcoins at Mt. Gox, had never before worked on blockchain technology. But he had a reputation for getting to the bottom of the toughest software bugs; in his off-time, he’d been known to beat all the levels of Super Mario Bros. 2 in an afternoon sitting. And that’s how he approached Mt. Gox: “It was basically just the world’s biggest puzzle at the time—like whoever solves this, imagine the recognition.”

Kim Nilsson, the software engineer who cracked the Mt. Gox case, standing on the street near Shinjuku Station in Tokyo.
Kim Nilsson, the software engineer who cracked the Mt. Gox case, standing on the street near Shinjuku Station in Tokyo. Photographed by Eric Rechsteiner for Fortune
He teamed up with some other Mt. Gox customers to launch WizSec, a blockchain security firm dedicated to cracking the case. But while the company quickly dissolved, Nilsson stayed on the case in secret, teaching himself blockchain analysis and painstakingly tracing the money stolen from Mt. Gox. Although Nilsson started off investigating Karpelès’s role in the theft, he soon realized the CEO was just as eager as he was to know what happened. At a time when Karpelès needed friends most, the WizSec team scored an invite to his apartment by offering to bring the Frenchman the ingredients he needed to bake his famous apple quiche. Soon, Karpelès was feeding Nilsson internal Mt. Gox data that could help solve the case. “I wish I had stolen the money, because then I could just give it back,” Karpelès told them at the time.

Over the next four years, Nilsson estimates he spent a year-and-a-half’s worth of full-time hours pursuing the Mt. Gox hackers. He’s never been paid for his work; his 12.7 Bitcoin claim at Mt. Gox makes him one of its smallest creditors. To J. Maurice, who helped found WizSec but left the company early on and was not involved in the investigation, Nilsson’s effort epitomizes the virtues of Bitcoin—a decentralized system free of government control, which relies instead on individual users to sustain it. “Kim is humble, he doesn’t brag, he doesn’t even want to get rich. He’s just working hard on something for years as his passion project,” Maurice says. “That’s what Bitcoin is.”

By early 2016, Nilsson had a suspect. As he tracked the stolen funds, he saw that, of the 650,000 Bitcoins reported stolen from Mt. Gox, 630,000 had gone straight into wallets controlled by the same person. That person also had an account at Mt. Gox, associated with the username WME. Then Nilsson stumbled across an old post in an online Bitcoin forum in which someone with the handle WME had thrown a tantrum, complaining that another cryptocurrency exchange had frozen his funds. “Give [me] my CLEAN MONEY!” read the post. In the process, WME dropped clues that he owned some of the Bitcoin wallets in question. But the big break came when the same user posted a letter from his lawyer, his first and last name visible for the whole world to see. Nilsson, as he routinely did with his findings, dashed off an email to Gary Alford, a special agent with the IRS in New York who has helped catch cybercriminals.

Then one scorching day last July, police stormed a beach in Greece to arrest a Russian citizen vacationing with his family. U.S. federal prosecutors charged Alexander Vinnik, a 38-year-old IT specialist, with laundering 530,000 of the stolen Mt. Gox Bitcoins through his WME wallets and other accounts. They also accused him of helping to run the exchange BTC-e, whose primary purpose was allegedly to launder money. It is plausible, investigators say, that BTC-e was founded specifically to launder funds stolen from Mt. Gox. Blockchain analysis shows that the hack that devastated Mt. Gox began in autumn 2011, around the time BTC-e started up. Keys to Mt. Gox’s “hot wallet”—its online Bitcoin repository—were stolen and copied, compromising the exchange’s deposit addresses. So for the next two years, in nine out of 10 instances, coins were being stolen as soon as they came in, says Chainalysis’ Gronager, who is also a creditor: “It meant that you had a hole in the bottom of the well, and someone was just draining money.”

Karpelès claims he never noticed because the hackers stole small amounts at a time, and the balances generally seemed to move upward. “Bitcoin didn’t exactly decrease,” he says. “It’s just that they didn’t increase as much as they should.”

Nilsson, who believes he has convincingly linked Vinnik to at least 100,000 more Mt. Gox Bitcoins than the feds allege, still doesn’t know whether he helped the government’s investigation or simply confirmed its conclusions. With Vinnik fighting extradition from Greece and five outstanding defendants whose names remain redacted in the U.S. indictment, the IRS won’t comment on the “active and ongoing” investigation. But Kathryn Haun, a former federal prosecutor who signed off on the indictment, says Vinnik’s use of Bitcoin helps clearly connect him to the crime: “At first blush what seemed unsolvable turned out to be traceable through the use of digital currency.”

For Karpelès, Vinnik’s arrest reinforced a long-held theory: that Russian Bitcoin exchange administrators were behind a series of ­denial-of-service and other cyberattacks that hit Mt. Gox in 2011. Says Karpelès, “What he did, Mt. Gox is a victim of this, which means that all creditors are victims of this, and I am too a victim of this.”

Vinnik, who has denied the charges, has not been charged with stealing from Mt. Gox. But the magnitude and duration of his involvement points to some familiarity with the thieves whose profits he was allegedly laundering: “I assume at least he knows where to send the check,” says Nilsson.

Still, there’s an ironic punch line to the case: Because the stolen Bitcoins were sold right away, allegedly by Vinnik and long before Mt. Gox disclosed the hack, victims lost much more, in dollar value, than the hackers ever made—which, according to Chainalysis, was only about $20 million.

And as soon as the Bitcoins were converted to cash, the blockchain trail was broken. That means that even if authorities seize Bitcoins from the suspects, there won’t be anything to prove they’re from Mt. Gox. Sean Hays, a creditor in Arizona who says his 338 Bitcoin claim would be “life-changing,” adds, “I’ll be glad to have part of it back, but I think there will always be the hunt for where’s the rest?”

But for Burges, the key question that inspired his protest has finally been answered. “We know where the coins went, and we won’t get them back,” he says. “As far as I’m concerned, it’s solved.”

For almost four years, Josh Jones assumed he’d eventually receive his rightful portion of his nearly 44,000 Bitcoins locked inside Mt. Gox. By mid-2017, Bitcoin’s price was soaring, and Mt. Gox had enough to pay out the $430 million it owed in claims several times over. Then last September, Mt. Gox trustee Nobuaki Kobayashi, a top restructuring lawyer also representing Takata in the airbag-maker’s bankruptcy, broke the news: Under Japanese bankruptcy law, the value of creditors’ claims were capped at what they were worth back in 2014: $483 per Bitcoin. “That’s just crazy,” says Jones, who held most of the coins on behalf of his clients at Bitcoin Builder, the service he built to facilitate arbitrage trading at Mt. Gox in its final weeks. “That can’t be how it’s going to work out.”

But while there was little Jones could do back home in Santa Monica, another major creditor took it upon himself to ensure the Bitcoins would be fully divvied up among Mt. Gox victims. Richard Folsom, an American who worked for Bain & Co. in Tokyo before founding one of the first private equity shops in Japan, hired the biggest Japanese law firm and came up with a plan: What if Mt. Gox wasn’t technically bankrupt anymore? Their petition for “civil rehabilitation” of Mt. Gox, filed in November, is now pending before the Tokyo District Court; an outside examiner recommended in its favor in February. Shin Fukuoka, the partner at Nishimura & Asahi leading the effort, is confident it will be approved, as early as the end of April. “We think that the court has sufficient understanding about the problems in the case of proceeding with bankruptcy,” Fukuoka says.

Those problems, of course, include the fact that the majority of Mt. Gox’s assets would otherwise accrue to Mark Karpelès. “Such an outcome would be a travesty,” says Jesse Powell, CEO of Kraken, the San Francisco–based Bitcoin exchange appointed to help investigate and distribute Mt. Gox claims (and himself a substantial creditor).

If Fukuoka’s plan works, it would be the first time in Japan that a business “abolished” in bankruptcy was rehabilitated, he says: “These are very unique circumstances.” In a traditional civil rehabilitation, once the court gives the green light, it typically takes six months for the plan to be finalized—meaning optimistically, creditors could begin to get paid, preferably in Bitcoins, as soon as late this year. Fukuoka says he’s also considering mandating further investigation into the stolen Bitcoins as part of the rehab plan, in hopes more will be recovered. (A $75 million lawsuit from CoinLab that has held up the bankruptcy process could be sidestepped by setting aside a legal reserve fund in the meantime, he adds.) It would be an extraordinary outcome for creditors like Thomas Braziel, managing partner of New York–based hedge fund B.E. Capital Management, who has bought up $1 million worth of claims at 80¢ on the dollar, believing he will turn a profit no matter what. “Of course, if the rehabilitation happens, it’s a bonanza, and you make eight, nine, 10 times your money,” Braziel says.

That would be a relief to Mt. Gox’s disgraced CEO, who says he’s had enough of the cryptocurrency business to last a lifetime: “The only thing I’m touching related to cryptocurrency is how to solve this bankruptcy. Nothing more,” says Karpelès. Besides, he has lost faith in the initial promise of digital money: “Bitcoin right now is, I believe, doomed.”

Since his release from jail two summers ago, Karpelès has been moving apartments every few months out of concerns for his own safety. During three months of all-day interrogations while detained, he refused to confess to the accusations Japanese authorities threw at him—including, at one point, that he was Satoshi Nakamoto, Bitcoin’s mysterious founder. Still, despite what he feels is a weak case against him, he thinks the odds are he’ll be found guilty, at least during this first trial; Japan, which has a more than 99% conviction rate, is also one of a few countries that allows prosecutors to appeal an acquittal twice. In a year or two, he could be sent back behind bars. “After I came out, I felt like in a kind of dream, like I didn’t feel things were real,” he says, over a slice of cake with cream and cherries. “Even today I’m not sure yet.”

Karpelès, though, is not on trial for what even his sympathizers fault him for the most: lying about Mt. Gox’s insolvency. “When Mt. Gox didn’t have any of the coins, he was getting new deposits from other customers to pay off other people—kind of like a Bernie Madoff,” says Kelman, the lawyer.

For now, Karpelès, who’s never been to the United States (and isn’t allowed to leave Japan while on trial), is leveraging his mastery of Japanese and the country’s formal business customs. The arrest of Vinnik has made it easier to find work, he says, by lifting some blame from Karpelès. Even so, the taint of Mt. Gox follows him. “He is unhirable,” says Mike Kayamori, the CEO of Japanese cryptocurrency exchange Quoine.

Yet earlier this year, Mark Karpelès landed a big new job: chief technology officer at London Trust Media, a Denver-based corporation that runs the largest virtual private network (VPN) service in the world. It has recently been expanding into cryptocurrency-related ventures. “I am more than willing to give a second chance to Mark in this fight’s critical hour,” says Andrew Lee, cofounder and chairman of London Trust Media, who also briefly ran Mt. Gox’s U.S. operations.

Even if Mt. Gox’s rehabilitation succeeds, the company is unlikely to take another voyage. Still, that hasn’t stopped Karpelès from dreaming up schemes to get back the missing 650,000 Bitcoins. Even if the original coins can’t be retrieved, perhaps Mt. Gox could be revived long enough to generate revenue to finally make creditors whole; Karpelès also says he’s found one exchange that seems interested in pledging some of its own profits to victims.

But others, such as Kraken’s Powell, say the hole is simply too deep to fill. Besides, even if Mt. Gox did reopen, who would want to trade there? Adds Burges, the Mt. Gox protester, “It’s like having another ship called the Titanic.” For him, closure means letting the rest of the Bitcoins go down with the ship. 

Video from Wired magazine: Blockchain explained

This is a good video from 'Wired' magazine.
Blockchain Expert Explains One Concept in 5 Levels of Difficulty

https://www.youtube.com/watch?v=hYip_Vuv8J0&feature=youtu.be

Sunday, August 5, 2018

Very useful websites...

Here are some very useful websites...

Armory is the most secure and full featured solution available for users and institutions to generate and store Bitcoin private keys.
https://www.bitcoinarmory.com

Cryptowatch is a cryptocurrency charting and trading platform owned by Kraken.
https://cryptowatch.de

Search Bitcoin and Crypto transactions.
https://www.blockchain.com/explorer

Learn about crypto currencies and start to understand some of the fundamental concepts behind the blockchain.
https://www.cryptocompare.com

What is...?

What is Bitcoin? What is Blockchain? What is a cryptocurrency? What is a digital asset? To start answering these questions, I'd recommend to fully look at the material on the website https://bitcoin.org/en/

Saturday, August 4, 2018

Hardware Wallets

I recommend getting a hardware wallet.
You can store your bitcoin, cryptocurrency and digital assets on them. Essentially, with a hardware wallet you own and are in control of your 'Private Key'. The benefit of them, is they store your 'valuables' in your own private vault, that only you can access. Hardware wallets are a more secure way to store your bitcoin, cryptocurrency and digital assets, rather than keeping them on an 'exchange' which could be hacked and you lose all your 'valuables'.
Try these places:
https://www.ledger.com/
https://trezor.io/

Exchanges - how to buy Bitcoin, Cryptocurrency and Digital Assets

Here is a short list of reputable and trustworthy businesses.
From these websites and or exchanges you will be able to purchase Bitcoin, Cryptocurrency and Digital Assets. To do this, you will need to sign up and adhere to verification/identification processes for KYC (Know Your Customer) and AML (Anti Money Laundering). This can sometimes take a long time, so be prepared for this step.

No particular order:
https://www.coinbase.com
https://www.kraken.com
https://gemini.com
https://www.circle.com
https://www.coinfloor.co.uk

Friday, August 3, 2018

Satoshi Nakamoto's White Paper

Satoshi Nakamoto's original paper is still recommended reading for anyone studying how Bitcoin works. Bitcoin: A Peer-to-Peer Electronic Cash System. The paper that first introduced Bitcoin
Download the PDF: https://bitcoin.org/bitcoin.pdf

Free Book - Princeton University

There is a very good free book. This accompanies the Princeton University Bitcoin and Cryptocurrency Technologies Online Course.

"Bitcoin and Cryptocurrency Technologies" provides a comprehensive introduction to the revolutionary yet often misunderstood new technologies of digital currency.

Download the free PDF book at:
https://d28rh4a8wq0iu5.cloudfront.net/bitcointech/readings/princeton_bitcoin_book.pdf

One of the best resources...

One of the best resources I have come across is from Princeton University. There are a set of 12 video lectures on Youtube - https://www.youtube.com/channel/UCNcSSleedtfyDuhBvOQzFzQ

Welcome

Welcome to the blog all about Bitcoin, Blockchain, Crypto and Digital Assets. The aim is to provide interesting links and articles to help learning within the industry/arena/space.

Twitter / X List: Started a simple list of people to follow, focused on the "Bitcoin Log-Log Power Law"

Bitcoin Log-Log Power Law  Resources, information and ideas based on the Bitcoin Log-Log Power Law https://twitter.com/i/lists/1805174747677...