Nostr notes by

📅 Original date posted:2016-09-10 📝 Original message:On ...

2023-06-07T19:53:19+02:00

In reply to nevent1q…ntcl
_________________________

📅 Original date posted:2016-09-10
📝 Original message:On Sat, Sep 10, 2016 at 12:42:30AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
>
> It has been removed completely in Bitcoin Core after being disabled for a while.

As it has been disabled in relevant software I think it's mostly symbolic at
this point, but yes, it makes sense to 'officially' retire the key. Let's
pin the date and make it widely known.

Doing this in organized fashion is much better than the whodunit that would
undoubtly follow when the key would simply leak, which could happen at any
time, as no one can know who it has spread to over all those years.

Re: timing, I'd say leave three months grace time after this announcement for
altcoins and such that may have accidentally have copied it to remove it, then
at the beginning of 2017 broadcast the final alert.

After that it's neutered, it's up to each of us that has the key to reveal it
or not or when. It's a historical curiosity then.

Wladimir

📅 Original date posted:2015-09-17 📝 Original message:Hello, ...

2023-06-07T19:40:49+02:00

In reply to nevent1q…m7wr
_________________________

📅 Original date posted:2015-09-17
📝 Original message:Hello,

At Monday's code sprint we had a good idea to schedule a regular developer meeting in #bitcoin-dev.

Attendance is of course voluntary, but it may be good to have a time that many people are expected to be present and current issues can be discussed.

Any preference for days/times?

What about e.g. every week 15:00-16:00 UTC on Thursday?

Wladimir

📅 Original date posted:2015-09-17 📝 Original message:On ...

2023-06-07T19:40:18+02:00

In reply to nevent1q…d9wr
_________________________

📅 Original date posted:2015-09-17
📝 Original message:On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev wrote:

> I've run into a number of cases where companies were maintaining forks
> of Bitcoin Core unnecessarily, where a different, loosely coupled,
> architecture could do what they needed to do without including the new
> logic in the codebase itself.

This is the same point I have been making to Jeff privately.

Refactors are a means to an end: a more modular, reusable and maintainable codebase. This goal is that new functionality can be plugged in more easily, and rebase work for e.g. functionality built on top can go down, not up, if it just hooks into well-defined interfaces here and there.

Although there has been a lot of progress, bitcoind's design is still too monolithic. To add a more involved feature, like say a new index over the block chain data, code needs to be touched all over the place. This change interacts with all other functionality, potentially breaking the base node functionality - risk for users that do NOT use the functionality. This increases risk and review time.

- *If possible* functionality should be built without changing bitcoind's code at all. An external process should be able to keep up to date with the chain, notice reorgs, and process block data accordingly. If bitcoind's interface does not allow that, or it is too difficult, that is what should be fixed.
- *if not possible* then a change should at least touch the code in as few places as possible, and integrate with e.g. signal notification.

To name an example of it done right, IMO: Monero's 'simplewallet'. It is a command-line utility wallet that communicates with the node software, and remembers where it was in the chain, and processes changes to the chain state since its last invocation when it 'refreshes'.
What is nice is that one can run an arbitary number of simplewallets against one node daemon, and unlike bitcoind's wallet it doesn't need to run as always-on daemon itself. It can be invoked when the user wants to do something with the wallet, or see if there are new transactions.

An index could be implemented entirely externally in a similar way, while still fully handling reorgs.

What one needs for that, I think, is a library that communicate with the node, and which offers functionality abstractly be similar to 'git pull': give me the tree path from my current known tip to the best tip, and supply the block hashes (and block data) along the way.

My long-term vision of bitcoind is a P2P node with validation and blockchain store, with a couple of data sources that can be subscribed to or pulled from.

Wladimir

📅 Original date posted:2015-08-24 📝 Original message:> ...

2023-06-07T19:37:39+02:00

In reply to nevent1q…hs6q
_________________________

📅 Original date posted:2015-08-24
📝 Original message:> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they do have).

But is this useful without having decided on a way to signal which blocks pruned nodes do have?

It looks like the part between paranthesis is speculation and should be left to a future BIP.

Wladimir

📅 Original date posted:2015-07-12 📝 Original ...

2023-06-07T17:42:02+02:00

In reply to nevent1q…k5gg
_________________________

📅 Original date posted:2015-07-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

/Re-transmission-2: signature was botched in previous mails due to UTF-8 conversion issue, last attempt/

Bitcoin Core version 0.11.0 is now available from:

<https://bitcoin.org/bin/bitcoin-core-0.11.0/>;

This is a new major version release, bringing both new features and
bug fixes.

Please report bugs using the issue tracker at github:

<https://github.com/bitcoin/bitcoin/issues>;

The entire distribution is also available as torrent:

magnet:?xt=urn:btih:82f0d2fa100d6db8a8c1338768dcb9e4e524da13&dn=bitcoin-core-0.11.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F

Upgrading and downgrading
=========================

How to Upgrade
- --------------

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- ------------------

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.

Important information
======================

Transaction flooding
- ---------------------

At the time of this release, the P2P network is being flooded with low-fee
transactions. This causes a ballooning of the mempool size.

If this growth of the mempool causes problematic memory use on your node, it is
possible to change a few configuration options to work around this. The growth
of the mempool can be monitored with the RPC command `getmempoolinfo`.

One is to increase the minimum transaction relay fee `minrelaytxfee`, which
defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be
rejected, and thus fewer transactions entering the mempool.

The other is to restrict the relaying of free transactions with
`limitfreerelay`. This option sets the number of kB/minute at which
free transactions (with enough priority) will be accepted. It defaults to 15.
Reducing this number reduces the speed at which the mempool can grow due
to free transactions.

For example, add the following to `bitcoin.conf`:

minrelaytxfee=0.00005
limitfreerelay=5

More robust solutions are being worked on for a follow-up release.

Notable changes
===============

Block file pruning
- ----------------------

This release supports running a fully validating node without maintaining a copy
of the raw block and undo data on disk. To recap, there are four types of data
related to the blockchain in the bitcoin system: the raw blocks as received over
the network (blk???.dat), the undo data (rev???.dat), the block index and the
UTXO set (both LevelDB databases). The databases are built from the raw data.

Block pruning allows Bitcoin Core to delete the raw block and undo data once
it's been validated and used to build the databases. At that point, the raw data
is used only to relay blocks to other nodes, to handle reorganizations, to look
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
for rescanning the wallet. The block index continues to hold the metadata about
all blocks in the blockchain.

The user specifies how much space to allot for block & undo files. The minimum
allowed is 550MB. Note that this is in addition to whatever is required for the
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
minutes per block). In rare instances it is possible that the amount of space
used will exceed the pruning target in order to keep the required last 288
blocks on disk.

Block pruning works during initial sync in the same way as during steady state,
by deleting block files "as you go" whenever disk space is allocated. Thus, if
the user specifies 550MB, once that level is reached the program will begin
deleting the oldest block and undo files, while continuing to download the
blockchain.

For now, block pruning disables block relay. In the future, nodes with block
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
active chain.

Block pruning is currently incompatible with running a wallet due to the fact
that block data is used for rescanning the wallet and importing keys or
addresses (which require a rescan.) However, running the wallet with block
pruning will be supported in the near future, subject to those limitations.

Block pruning is also incompatible with -txindex and will automatically disable
it.

Once you have pruned blocks, going back to unpruned state requires
re-downloading the entire blockchain. To do this, re-start the node with
- -reindex. Note also that any problem that would cause a user to reindex (e.g.,
disk corruption) will cause a pruned node to redownload the entire blockchain.
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
and rev???.dat files in the data directory prior to restarting the download.

To enable block pruning on the command line:

- - `-prune=N`: where N is the number of MB to allot for raw block & undo data.

Modified RPC calls:

- - `getblockchaininfo` now includes whether we are in pruned mode or not.
- - `getblock` will check if the block's data has been pruned and if so, return an
error.
- - `getrawtransaction` will no longer be able to locate a transaction that has a
UTXO but where its block file has been pruned.

Pruning is disabled by default.

Big endian support
- --------------------

Experimental support for big-endian CPU architectures was added in this
release. All little-endian specific code was replaced with endian-neutral
constructs. This has been tested on at least MIPS and PPC hosts. The build
system will automatically detect the endianness of the target.

Memory usage optimization
- --------------------------

There have been many changes in this release to reduce the default memory usage
of a node, among which:

- - Accurate UTXO cache size accounting (#6102); this makes the option `-dbcache`
precise where this grossly underestimated memory usage before
- - Reduce size of per-peer data structure (#6064 and others); this increases the
number of connections that can be supported with the same amount of memory
- - Reduce the number of threads (#5964, #5679); lowers the amount of (esp.
virtual) memory needed

Fee estimation changes
- ----------------------

This release improves the algorithm used for fee estimation. Previously, -1
was returned when there was insufficient data to give an estimate. Now, -1
will also be returned when there is no fee or priority high enough for the
desired confirmation target. In those cases, it can help to ask for an estimate
for a higher target number of blocks. It is not uncommon for there to be no
fee or priority high enough to be reliably (85%) included in the next block and
for this reason, the default for `-txconfirmtarget=n` has changed from 1 to 2.

Privacy: Disable wallet transaction broadcast
- ----------------------------------------------

This release adds an option `-walletbroadcast=0` to prevent automatic
transaction broadcast and rebroadcast (#5951). This option allows separating
transaction submission from the node functionality.

Making use of this, third-party scripts can be written to take care of
transaction (re)broadcast:

- - Send the transaction as normal, either through RPC or the GUI
- - Retrieve the transaction data through RPC using `gettransaction` (NOT
`getrawtransaction`). The `hex` field of the result will contain the raw
hexadecimal representation of the transaction
- - The transaction can then be broadcasted through arbitrary mechanisms
supported by the script

One such application is selective Tor usage, where the node runs on the normal
internet but transactions are broadcasted over Tor.

For an example script see [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx).

Privacy: Stream isolation for Tor
- ----------------------------------

This release adds functionality to create a new circuit for every peer
connection, when the software is used with Tor. The new option,
`-proxyrandomize`, is on by default.

When enabled, every outgoing connection will (potentially) go through a
different exit node. That significantly reduces the chance to get unlucky and
pick a single exit node that is either malicious, or widely banned from the P2P
network. This improves connection reliability as well as privacy, especially
for the initial connections.

**Important note:** If a non-Tor SOCKS5 proxy is configured that supports
authentication, but doesn't require it, this change may cause that proxy to reject
connections. A user and password is sent where they weren't before. This setup
is exceedingly rare, but in this case `-proxyrandomize=0` can be passed to
disable the behavior.

0.11.0 Change log
=================

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### RPC and REST
- - #5461 `5f7279a` signrawtransaction: validate private key
- - #5444 `103f66b` Add /rest/headers/<count>/<hash>.<ext>
- - #4964 `95ecc0a` Add scriptPubKey field to validateaddress RPC call
- - #5476 `c986972` Add time offset into getpeerinfo output
- - #5540 `84eba47` Add unconfirmed and immature balances to getwalletinfo
- - #5599 `40e96a3` Get rid of the internal miner's hashmeter
- - #5711 `87ecfb0` Push down RPC locks
- - #5754 `1c4e3f9` fix getblocktemplate lock issue
- - #5756 `5d901d8` Fix getblocktemplate_proposals test by mining one block
- - #5548 `d48ce48` Add /rest/chaininfos
- - #5992 `4c4f1b4` Push down RPC reqWallet flag
- - #6036 `585b5db` Show zero value txouts in listunspent
- - #5199 `6364408` Add RPC call `gettxoutproof` to generate and verify merkle blocks
- - #5418 `16341cc` Report missing inputs in sendrawtransaction
- - #5937 `40f5e8d` show script verification errors in signrawtransaction result
- - #5420 `1fd2d39` getutxos REST command (based on Bip64)
- - #6193 `42746b0` [REST] remove json input for getutxos, limit to query max. 15 outpoints
- - #6226 `5901596` json: fail read_string if string contains trailing garbage

### Configuration and command-line options
- - #5636 `a353ad4` Add option `-allowselfsignedrootcertificate` to allow self signed root certs (for testing payment requests)
- - #5900 `3e8a1f2` Add a consistency check `-checkblockindex` for the block chain data structures
- - #5951 `7efc9cf` Make it possible to disable wallet transaction broadcast (using `-walletbroadcast=0`)
- - #5911 `b6ea3bc` privacy: Stream isolation for Tor (on by default, use `-proxyrandomize=0` to disable)
- - #5863 `c271304` Add autoprune functionality (`-prune=<size>`)
- - #6153 `0bcf04f` Parameter interaction: disable upnp if -proxy set
- - #6274 `4d9c7fe` Add option `-alerts` to opt out of alert system

### Block and transaction handling
- - #5367 `dcc1304` Do all block index writes in a batch
- - #5253 `203632d` Check against MANDATORY flags prior to accepting to mempool
- - #5459 `4406c3e` Reject headers that build on an invalid parent
- - #5481 `055f3ae` Apply AreSane() checks to the fees from the network
- - #5580 `40d65eb` Preemptively catch a few potential bugs
- - #5349 `f55c5e9` Implement test for merkle tree malleability in CPartialMerkleTree
- - #5564 `a89b837` clarify obscure uses of EvalScript()
- - #5521 `8e4578a` Reject non-final txs even in testnet/regtest
- - #5707 `6af674e` Change hardcoded character constants to descriptive named constants for db keys
- - #5286 `fcf646c` Change the default maximum OP_RETURN size to 80 bytes
- - #5710 `175d86e` Add more information to errors in ReadBlockFromDisk
- - #5948 `b36f1ce` Use GetAncestor to compute new target
- - #5959 `a0bfc69` Add additional block index consistency checks
- - #6058 `7e0e7f8` autoprune minor post-merge improvements
- - #5159 `2cc1372` New fee estimation code
- - #6102 `6fb90d8` Implement accurate UTXO cache size accounting
- - #6129 `2a82298` Bug fix for clearing fCheckForPruning
- - #5947 `e9af4e6` Alert if it is very likely we are getting a bad chain
- - #6203 `c00ae64` Remove P2SH coinbase flag, no longer interesting
- - #5985 `37b4e42` Fix removing of orphan transactions
- - #6221 `6cb70ca` Prune: Support noncontiguous block files
- - #6256 `fce474c` Use best header chain timestamps to detect partitioning
- - #6233 `a587606` Advance pindexLastCommonBlock for blocks in chainActive

### P2P protocol and network code
- - #5507 `844ace9` Prevent DOS attacks on in-flight data structures
- - #5770 `32a8b6a` Sanitize command strings before logging them
- - #5859 `dd4ffce` Add correct bool combiner for net signals
- - #5876 `8e4fd0c` Add a NODE_GETUTXO service bit and document NODE_NETWORK
- - #6028 `b9311fb` Move nLastTry from CAddress to CAddrInfo
- - #5662 `5048465` Change download logic to allow calling getdata on inbound peers
- - #5971 `18d2832` replace absolute sleep with conditional wait
- - #5918 `7bf5d5e` Use equivalent PoW for non-main-chain requests
- - #6059 `f026ab6` chainparams: use SeedSpec6's rather than CAddress's for fixed seeds
- - #6080 `31c0bf1` Add jonasschnellis dns seeder
- - #5976 `9f7809f` Reduce download timeouts as blocks arrive
- - #6172 `b4bbad1` Ignore getheaders requests when not synced
- - #5875 `304892f` Be stricter in processing unrequested blocks
- - #6333 `41bbc85` Hardcoded seeds update June 2015

### Validation
- - #5143 `48e1765` Implement BIP62 rule 6
- - #5713 `41e6e4c` Implement BIP66

### Build system
- - #5501 `c76c9d2` Add mips, mipsel and aarch64 to depends platforms
- - #5334 `cf87536` libbitcoinconsensus: Add pkg-config support
- - #5514 `ed11d53` Fix 'make distcheck'
- - #5505 `a99ef7d` Build winshutdownmonitor.cpp on Windows only
- - #5582 `e8a6639` Osx toolchain update
- - #5684 `ab64022` osx: bump build sdk to 10.9
- - #5695 `23ef5b7` depends: latest config.guess and config.sub
- - #5509 `31dedb4` Fixes when compiling in c++11 mode
- - #5819 `f8e68f7` release: use static libstdc++ and disable reduced exports by default
- - #5510 `7c3fbc3` Big endian support
- - #5149 `c7abfa5` Add script to verify all merge commits are signed
- - #6082 `7abbb7e` qt: disable qt tests when one of the checks for the gui fails
- - #6244 `0401aa2` configure: Detect (and reject) LibreSSL
- - #6269 `95aca44` gitian: Use the new bitcoin-detached-sigs git repo for OSX signatures
- - #6285 `ef1d506` Fix scheduler build with some boost versions.
- - #6280 `25c2216` depends: fix Boost 1.55 build on GCC 5
- - #6303 `b711599` gitian: add a gitian-win-signer descriptor
- - #6246 `8ea6d37` Fix build on FreeBSD
- - #6282 `daf956b` fix crash on shutdown when e.g. changing -txindex and abort action
- - #6354 `bdf0d94` Gitian windows signing normalization

### Wallet
- - #2340 `811c71d` Discourage fee sniping with nLockTime
- - #5485 `d01bcc4` Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
- - #5508 `9a5cabf` Add RandAddSeedPerfmon to MakeNewKey
- - #4805 `8204e19` Do not flush the wallet in AddToWalletIfInvolvingMe(..)
- - #5319 `93b7544` Clean up wallet encryption code
- - #5831 `df5c246` Subtract fee from amount
- - #6076 `6c97fd1` wallet: fix boost::get usage with boost 1.58
- - #5511 `23c998d` Sort pending wallet transactions before reaccepting
- - #6126 `26e08a1` Change default nTxConfirmTarget to 2
- - #6183 `75a4d51` Fix off-by-one error w/ nLockTime in the wallet
- - #6276 `c9fd907` Fix getbalance * 0

### GUI
- - #5219 `f3af0c8` New icons
- - #5228 `bb3c75b` HiDPI (retina) support for splash screen
- - #5258 `73cbf0a` The RPC Console should be a QWidget to make window more independent
- - #5488 `851dfc7` Light blue icon color for regtest
- - #5547 `a39aa74` New icon for the debug window
- - #5493 `e515309` Adopt style colour for button icons
- - #5557 `70477a0` On close of splashscreen interrupt verifyDB
- - #5559 `83be8fd` Make the command-line-args dialog better
- - #5144 `c5380a9` Elaborate on signverify message dialog warning
- - #5489 `d1aa3c6` Optimize PNG files
- - #5649 `e0cd2f5` Use text-color icons for system tray Send/Receive menu entries
- - #5651 `848f55d` Coin Control: Use U+2248 "ALMOST EQUAL TO" rather than a simple tilde
- - #5626 `ab0d798` Fix icon sizes and column width
- - #5683 `c7b22aa` add new osx dmg background picture
- - #5620 `7823598` Payment request expiration bug fix
- - #5729 `9c4a5a5` Allow unit changes for read-only BitcoinAmountField
- - #5753 `0f44672` Add bitcoin logo to about screen
- - #5629 `a956586` Prevent amount overflow problem with payment requests
- - #5830 `215475a` Don't save geometry for options and about/help window
- - #5793 `d26f0b2` Honor current network when creating autostart link
- - #5847 `f238add` Startup script for centos, with documentation
- - #5915 `5bd3a92` Fix a static qt5 crash when using certain versions of libxcb
- - #5898 `bb56781` Fix rpc console font size to flexible metrics
- - #5467 `bc8535b` Payment request / server work - part 2
- - #6161 `180c164` Remove movable option for toolbar
- - #6160 `0d862c2` Overviewpage: make sure warning icons gets colored

### Tests
- - #5453 `2f2d337` Add ability to run single test manually to RPC tests
- - #5421 `886eb57` Test unexecuted OP_CODESEPARATOR
- - #5530 `565b300` Additional rpc tests
- - #5611 `37b185c` Fix spurious windows test failures after 012598880c
- - #5613 `2eda47b` Fix smartfees test for change to relay policy
- - #5612 `e3f5727` Fix zapwallettxes test
- - #5642 `30a5b5f` Prepare paymentservertests for new unit tests
- - #5784 `e3a3cd7` Fix usage of NegateSignatureS in script_tests
- - #5813 `ee9f2bf` Add unit tests for next difficulty calculations
- - #5855 `d7989c0` Travis: run unit tests in different orders
- - #5852 `cdae53e` Reinitialize state in between individual unit tests.
- - #5883 `164d7b6` tests: add a BasicTestingSetup and apply to all tests
- - #5940 `446bb70` Regression test for ResendWalletTransactions
- - #6052 `cf7adad` fix and enable bip32 unit test
- - #6039 `734f80a` tests: Error when setgenerate is used on regtest
- - #6074 `948beaf` Correct the PUSHDATA4 minimal encoding test in script_invalid.json
- - #6032 `e08886d` Stop nodes after RPC tests, even with --nocleanup
- - #6075 `df1609f` Add additional script edge condition tests
- - #5981 `da38dc6` Python P2P testing
- - #5958 `9ef00c3` Add multisig rpc tests
- - #6112 `fec5c0e` Add more script edge condition tests

### Miscellaneous
- - #5457, #5506, #5952, #6047 Update libsecp256k1
- - #5437 `84857e8` Add missing CAutoFile::IsNull() check in main
- - #5490 `ec20fd7` Replace uint256/uint160 with opaque blobs where possible
- - #5654, #5764 Adding jonasschnelli's GPG key
- - #5477 `5f04d1d` OS X 10.10: LSSharedFileListItemResolve() is deprecated
- - #5679 `beff11a` Get rid of DetectShutdownThread
- - #5787 `9bd8c9b` Add fanquake PGP key
- - #5366 `47a79bb` No longer check osx compatibility in RenameThread
- - #5689 `07f4386` openssl: abstract out OPENSSL_cleanse
- - #5708 `8b298ca` Add list of implemented BIPs
- - #5809 `46bfbe7` Add bitcoin-cli man page
- - #5839 `86eb461` keys: remove libsecp256k1 verification until it's actually supported
- - #5749 `d734d87` Help messages correctly formatted (79 chars)
- - #5884 `7077fe6` BUGFIX: Stack around the variable 'rv' was corrupted
- - #5849 `41259ca` contrib/init/bitcoind.openrc: Compatibility with previous OpenRC init script variables
- - #5950 `41113e3` Fix locale fallback and guard tests against invalid locale settings
- - #5965 `7c6bfb1` Add git-subtree-check.sh script
- - #6033 `1623f6e` FreeBSD, OpenBSD thread renaming
- - #6064 `b46e7c2` Several changes to mruset
- - #6104 `3e2559c` Show an init message while activating best chain
- - #6125 `351f73e` Clean up parsing of bool command line args
- - #5964 `b4c219b` Lightweight task scheduler
- - #6116 `30dc3c1` [OSX] rename Bitcoin-Qt.app to Bitcoin-Core.app
- - #6168 `b3024f0` contrib/linearize: Support linearization of testnet blocks
- - #6098 `7708fcd` Update Windows resource files (and add one for bitcoin-tx)
- - #6159 `e1412d3` Catch errors on datadir lock and pidfile delete
- - #6186 `182686c` Fix two problems in CSubnet parsing
- - #6174 `df992b9` doc: add translation strings policy
- - #6210 `dfdb6dd` build: disable optional use of gmp in internal secp256k1 build
- - #6264 `94cd705` Remove translation for -help-debug options
- - #6286 `3902c15` Remove berkeley-db4 workaround in MacOSX build docs
- - #6319 `3f8fcc9` doc: update mailing list address

Credits
=======

Thanks to everyone who directly contributed to this release:

- - 21E14
- - Adam Weiss
- - Alex Morcos
- - ayeowch
- - azeteki
- - Ben Holden-Crowther
- - bikinibabe
- - BitcoinPRReadingGroup
- - Blake Jakopovic
- - BtcDrak
- - charlescharles
- - Chris Arnesen
- - Ciemon
- - CohibAA
- - Corinne Dashjr
- - Cory Fields
- - Cozz Lovan
- - Daira Hopwood
- - Daniel Kraft
- - Dave Collins
- - David A. Harding
- - dexX7
- - Earlz
- - Eric Lombrozo
- - Eric R. Schulz
- - Everett Forth
- - Flavien Charlon
- - fsb4000
- - Gavin Andresen
- - Gregory Maxwell
- - Heath
- - Ivan Pustogarov
- - Jacob Welsh
- - Jameson Lopp
- - Jason Lewicki
- - Jeff Garzik
- - Jonas Schnelli
- - Jonathan Brown
- - Jorge Timón
- - joshr
- - jtimon
- - Julian Yap
- - Luca Venturini
- - Luke Dashjr
- - Manuel Araoz
- - MarcoFalke
- - Matt Bogosian
- - Matt Corallo
- - Micha
- - Michael Ford
- - Mike Hearn
- - mrbandrews
- - Nicolas Benoit
- - paveljanik
- - Pavel Janík
- - Pavel Vasin
- - Peter Todd
- - Philip Kaufmann
- - Pieter Wuille
- - pstratem
- - randy-waterhouse
- - rion
- - Rob Van Mieghem
- - Ross Nicoll
- - Ruben de Vries
- - sandakersmann
- - Shaul Kfir
- - Shawn Wilkinson
- - sinetek
- - Suhas Daftuar
- - svost
- - Thomas Zander
- - Tom Harding
- - UdjinM6
- - Vitalii Demianets
- - Wladimir J. van der Laan

And all those who contributed additional code review and/or security research:

- - Sergio Demian Lerner

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVoqAZAAoJEHSBCwEjRsmmgEUH/iUJPAweG5lEQRg1WnCVFz0w
ZlbrKfVOp9UVMpqH5rEnwizhBVWwT9zGqwflXczWa+MlGPb9YFd7yqxW7Jb8Ip5g
1zLOBy+GFw2uA1dEoFXnjEJhFblaDMUN+Yqvcrw5V/gtLfiaX0Z0aP/cyS+dFKpQ
Kpjv4IhW3nGlvQJS1FvdEoMR6rbERPxCRKAZdIVluyfJibo9NFVfGywjp+OZMmiS
EcoX+ucF3TfsiUo7oxDWlq8SLJm2aqHe/IPtYGOVCn/97JTQ3E0r/lxvI6t89LBU
fokEunKmzrgXOIkSk3cSHJWBLYAXk60/OV0rZtJwakInpsTu9+dUdN7C5aOSycs=
=jEo7
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-27 📝 Original message:On ...

2023-06-07T17:40:38+02:00

In reply to nevent1q…unl5
_________________________

📅 Original date posted:2015-06-27
📝 Original message:On Sat, Jun 27, 2015 at 12:55:01PM +0300, NxtChg wrote:
>
> > They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry.
>
> Except the block size is not gravity. It's more like an arbitrary decision to limit planes' wingspan to the most typical hangar door of 1940.
>
> And now we have a "controversy" that we can't have modern planes out of the fear they won't fit into some of the old hangars.
>
> And to continue with this nice example, some people are even arguing that "the demand for flight is, essentially, limitless, so why bother making larger jets at all?"

At least there's always an 'exit' option. At this point it would be more realistic to create a sidechain, or altcoin with larger blocks, and not experiment with the current one in-flight. Then you won't risk the other 'passengers' who don't consent to it.

It's important to face reality instead of being wishful here. I'd also have preferred to have one happy family, but it is clear that is not the case, and pretending is only going to cause damage by creating false expectations, or eventually even double-spending possibility because of conflicting forks.

Wladimir

📅 Original date posted:2015-06-27 📝 Original ...

2023-06-07T17:40:38+02:00

In reply to nevent1q…c9tz
_________________________

📅 Original date posted:2015-06-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Jun 26, 2015 at 04:09:18PM +0200, Pieter Wuille wrote:

> People say that larger blocks are necessary. In the long term, I agree - in
> the sense that systems that do not evolve tend to be replaced by other
> systems. This evolution can come in terms of layers on top of Bitcoin's
> blockchain, in terms of the technology underlying various aspects of the
> blockchain itself, and also in the scale that this technology supports.
>
> I do, however, fundamentally disagree that a fear for a change in economics
> should be considered to necessitate larger blocks. If it is, and there is
> consensus that we should adapt to it, then there is effectively no limit
> going forward. This is similar to how Congress voting to increase the
> copyright term retroactively from time to time is really no different from
> having an infinite copyright term in the first place. This scares me.

Fully agree Pieter. Couldn't have stated it better.

It has been disappointing and scary to see political pressure tactics being used to change a distributed consensus system.

By using the system everyone agreed on one set of consensus rules, that was the "social contract" of Bitcoin. To me, the consensus rules are more like rules of physics than laws. They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry.

It is shocking to hear wide misunderstanding that it is supposedly 'the developers' that decide on such changes. As if this is merely a private top-down project. No, the point was that this can continue without any kind of central guidance, with expected stability. As a developer I work on improving the technical aspects and fixing bugs, not on 'governing' it.
By expecting a few developers to make controversial decisions you are breaking the expectations, as well as making life dangerous for those developers. I'll jump ship before being forced to merge an even remotely controversial hardfork.

The stressful conditions of last weeks have thus made me hostile toward the idea of hardforks. At least to hardforks that make politically loaded changes. In this case further centralization to well-connected geographic locales by increasing network bandwidth requirements.

Resiliency and decentralization are the key aspects. I would not want to risk breaking the system, or at least wildly changing its properties and applicability out of perceived necessity, and fear.

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVjlOMAAoJEHSBCwEjRsmmveAH+wWN6j+0LsLibl2XWs3hxs64
nOT63JMNEIYzSsxZkEkzU4AWsdPG8TWXeaYhaR5rd7pXspFHHFYpPNxyOAWB4nY9
yS9eI4JRkOLtZY+rulFppkvnpggL82MFcT5rMNom+S1+EKE6C1NFqXl+OzZqatWL
pysza7ZHg/d3hKWkm/JtlfTYTOgrxFIX6INghfQiOl2hEyXE5iZF8+CRnZQA4dG7
jr/Jn2H4EzkUF8SDYVkIYsX+hPL5ib9mMm12ZXH8M8lFkdwweJCwbA7tVtNoalG3
dzHb/8rotlqiDTNuLIlB7TE4maivcr2cXVKTfry6HBRJvNf0cD3oP67vCQj6iis=
=pipo
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T17:38:29+02:00

In reply to nevent1q…hy3c
_________________________

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Jun 18, 2015 at 03:49:06PM +0200, Mike Hearn wrote:
> One reason I keep banging on about *process* and how Wladimir needs to be
> The Decider is that the current attempt at "process" is so vague, not only
> is it unexplainable, but it's wide open to manipulation.

It looks as if you entirely missed my point. I'm The Decider for *code issues* regarding Bitcoin Core. Consensus issues should not be considered part of that, they span multiple implementations.

So I'm *not* the decider for anything that concerns the behavior of the global consensus, and I cannot be, as I have explained in the previous post, and as Sipa explained in his.

Speaking of process, let me remind you that there is a BIP processs: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki

If you think it's not clear enough, which may explain why you did not even attempt to follow it for your block size increase, feel free to make improvements.

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVgtAOAAoJEHSBCwEjRsmmLPUH/1ug5pvLz6ptIhvuROclV7Jh
z0Szk5FOqfg4ejT3nYV5LRV5WNHUGDdFnHZJRFsKYH9B0LFgOlnkc488Qg6hBb+1
rf5zEF/D2X4MhPIx6GqI++gvhDzdBH2t9yxbU7LVZALo7+wtW+ms5eHHFs8WrU0z
m7NgiZRen4cpQUiBWHlt0PojmXBVZQNU0CD6ErcOpQXhN8J0sb0l0DuFswQgUqxk
rrNe3LvKp89xT0kDxyzQts/CeIG/8kQYLwIJ1QQDXvYayj2aHHYMkSEWfDlew3IC
zQkFgHCTGihGHPFeow+dnuW1DI1l92yPYNDLbxivSam3X+qCAGzUTOWTFE+iprk=
=tE4K
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T17:38:27+02:00

In reply to nevent1q…fg6v
_________________________

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:

> Core is in the weird position where there's no decision making ability at
> all, because anyone who shows up and shouts enough can generate
> 'controversy', then Wladimir sees there is disagreement and won't touch the
> issue in question. So it just runs and runs and *anyone* with commit access
> can then block any change.

Bitcoin Core is completely different from your average open source project in one aspect: where it concerns consensus.

Like in any open source project there is lots of decision making ability for code changes. I'd say look at the changelog for e.g. 0.11 https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, or follow pull requests for a while, to see how many decisions about changes are made from day to day. No, I'm not sitting on my hands, and so is none of the other contributors that you'd like to get rid of.

Consensus changes are *much* more difficult, on the other hand. Even relatively straightforward softforks come with a long discussion process (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone needs to upgrade their software!), and simply not possible if almost the entire technical community disagrees with you.

Bitcoin is supposed to be a robust, global, decentralized network beyond anyone's control. It makes *no sense* to try to run it as a dictatorship. This would create a handy central position where power can be applied, pushing through changes to the behavior of the system, either by force or other ways of motivation. I refuse to take part in that.

Hence, anything that is controversial needs to be considered really carefully. If I suddenly start making changes to the consensus code without full agreement, by all means take away my commit privileges.

(a major reason for the ongoing libconsensus work is to separate "Bitcoin Core, the node software" and "The Bitcoin Consensus" along clear lines, to avoid this kind of nasty confusion)

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
+NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=
=W26K
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T17:38:27+02:00

In reply to nevent1q…ptzd
_________________________

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Jun 18, 2015 at 01:14:09PM +0200, Wladimir J. van der Laan wrote:

> On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
>
> > Core is in the weird position where there's no decision making ability at
> > all, because anyone who shows up and shouts enough can generate
> > 'controversy', then Wladimir sees there is disagreement and won't touch the
> > issue in question. So it just runs and runs and *anyone* with commit access
> > can then block any change.

And allegations that the project is "run like wikipedia" or "an edit war" are verifyably untrue.
Check the commit history.
How many reverts do you see? How many of those do you see that are not simply to get rid of unexpected bugs, to be re-merged later?

Not much more than two, in ~5500 commit over six years. I feel sorry for you that `getutxos` was rejected in a messy way, still you are so held up about it and keep repeating it as if it is a daily occurence. Disingenuous, at the least.

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVgq/WAAoJEHSBCwEjRsmm8NUIAI/csucOmfF9e+BtSH+uruhl
ox32stQfD3hwcKropLEPFfKvmOcRU1nXBy6lcvhG+axw+WqpC48EvpD73P/BuSv7
RvlLayqP+D6oiNsH+7S7C0/ndy+Pne04D+srSSBhXKfZMqruBqmUSontziJZTeLR
C6CCFwFSAvSXGV873I3i4M4U5QqIrE5PyuK75wjl2SFisd2LjBgfzZh4HDbz85Qr
gApLpdTxu4gDkGx4B9txCkfyb5W2z8nawWYb7+O7y/NbFL1Qlb36MzGuVKL6Zj1z
B8kJrOLVW9ItduVRY/03wLsqBuGC9fjuhWexjKenvMpxfO//VvOxIBA7sCDrxjU=
=lisE
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-06 📝 Original message:On ...

2023-06-07T17:36:42+02:00

In reply to nevent1q…vqnw
_________________________

📅 Original date posted:2015-06-06
📝 Original message:On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
> Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
> assurance contracts among other things. Sometimes the ordering is set by
> the signing logic itself...

But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense.
I think this move to verifyable, deterministic methods where possible is good.

Wladimir