[bitcoin-dev] Bitcoin Core 23.0 released

2022-04-25 Thread W. J. van der Laan via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 23.0 is now available from:

  

Or through BitTorrent:

   
magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954&dn=bitcoin-core-23.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes
===

P2P and network changes
- ---

- - A bitcoind node will no longer rumour addresses to inbound peers by default.
  They will become eligible for address gossip after sending an ADDR, ADDRV2,
  or GETADDR message. (#21528)

- - Before this release, Bitcoin Core had a strong preference to try to connect 
only to peers that listen on port 8333. As a result of that, Bitcoin nodes 
listening on non-standard ports would likely not get any Bitcoin Core peers 
connecting to them. This preference has been removed. (#23542)

- - Full support has been added for the CJDNS network. See the new option 
`-cjdnsreachable` and 
[doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) 
(#23077)

Fee estimation changes
- --

- - Fee estimation now takes the feerate of replacement (RBF) transactions into
  account. (#22539)

Rescan startup parameter removed
- 

The `-rescan` startup parameter has been removed. Wallets which require
rescanning due to corruption will still be rescanned on startup.
Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. (#23123)

Tracepoints and Userspace, Statically Defined Tracing support
- -

Bitcoin Core release binaries for Linux now include experimental tracepoints 
which
act as an interface for process-internal events. These can be used for review,
debugging, monitoring, and more. The tracepoint API is semi-stable. While the 
API
is tested, process internals might change between releases requiring changes to 
the
tracepoints. Information about the existing tracepoints can be found under
[doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) 
and
usage examples are provided in 
[contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing).

Updated RPCs
- 

- - The `validateaddress` RPC now returns an `error_locations` array for invalid
  addresses, with the indices of invalid character locations in the address (if
  known). For example, this will attempt to locate up to two Bech32 errors, and
  return their locations if successful. Success and correctness are only 
guaranteed
  if fewer than two substitution errors have been made.
  The error message returned in the `error` field now also returns more specific
  errors when decoding fails. (#16807)

- - The `-deprecatedrpc=addresses` configuration option has been removed.  RPCs
  `gettxout`, `getrawtransaction`, `decoderawtransaction`, `decodescript`,
  `gettransaction verbose=true` and REST endpoints `/rest/tx`, `/rest/getutxos`,
  `/rest/block` no longer return the `addresses` and `reqSigs` fields, which
  were previously deprecated in 22.0. (#22650)
- - The `getblock` RPC command now supports verbosity level 3 containing 
transaction inputs'
  `prevout` information.  The existing `/rest/block/` REST endpoint is modified 
to contain
  this information too. Every `vin` field will contain an additional `prevout` 
subfield
  describing the spent output. `prevout` contains the following keys:

[bitcoin-dev] Bitcoin Core 22.0 released

2021-09-13 Thread W. J. van der Laan via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

22.0 Release Notes
==

Bitcoin Core version 22.0 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:1538a3b3962215f12e0e5f60105457332cf8fee4&dn=bitcoin-core-22.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.14+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no 
longer supported.

Notable changes
===

P2P and network changes
- ---
- - Added support for running Bitcoin Core as an
  [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) service
  and connect to such services. See 
[i2p.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/i2p.md) for details. 
(#20685)
- - This release removes support for Tor version 2 hidden services in favor of 
Tor
  v3 only, as the Tor network [dropped support for Tor
  v2](https://blog.torproject.org/v2-deprecation-timeline) with the release of
  Tor version 0.4.6.  Henceforth, Bitcoin Core ignores Tor v2 addresses; it
  neither rumors them over the network to other peers, nor stores them in memory
  or to `peers.dat`.  (#22050)

- - Added NAT-PMP port mapping support via
  [`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). (#18077)

New and Updated RPCs
- 

- - Due to [BIP 
350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
  being implemented, behavior for all RPCs that accept addresses is changed when
  a native witness version 1 (or higher) is passed. These now require a Bech32m
  encoding instead of a Bech32 one, and Bech32m encoding will be used for such
  addresses in RPC output as well. No version 1 addresses should be created
  for mainnet until consensus rules are adopted that give them meaning
  (as will happen through [BIP 
341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
  Once that happens, Bech32m is expected to be used for them, so this shouldn't
  affect any production systems, but may be observed on other networks where 
such
  addresses already have meaning (like signet). (#20861)

- - The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and
  `bip152_hb_from`, that respectively indicate whether we selected a peer to be
  in compact blocks high-bandwidth mode or whether a peer selected us as a
  compact blocks high-bandwidth peer. High-bandwidth peers send new block
  announcements via a `cmpctblock` message rather than the usual inv/headers
  announcements. See BIP 152 for more details. (#19776)

- - `getpeerinfo` no longer returns the following fields: `addnode`, `banscore`,
  and `whitelisted`, which were previously deprecated in 0.21. Instead of
  `addnode`, the `connection_type` field returns manual. Instead of
  `whitelisted`, the `permissions` field indicates if the peer has special
  privileges. The `banscore` field has simply been removed. (#20755)

- - The following RPCs:  `gettxout`, `getrawtransaction`, 
`decoderawtransaction`,
  `decodescript`, `gettransaction`, and REST endpoints: `/rest/tx`,
  `/rest/getutxos`, `/rest/block` deprecated the following fields (which are no
  longer returned in the responses by default): `addresses`, `reqSigs`.
  The `-deprecatedrpc=addresses` flag must be passed for these fields to be
  included in the RPC response. This flag/option will be available only for 
this major release, after which
  the deprecation will be r

[bitcoin-dev] Bitcoin Core 0.21.1 released

2021-05-02 Thread W. J. van der Laan via bitcoin-dev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.21.1 Release Notes


Bitcoin Core version 0.21.1 is now available from:

  

Or through Bittorrent:

  
magnet:?xt=urn:btih:205b0189271c50a02fe966491e15737a01f94e08&dn=bitcoin-core-0.21.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This minor release includes various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

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 in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Notable changes
===

## Taproot Soft Fork

Included in this release are the mainnet and testnet activation
parameters for the taproot soft fork (BIP341) which also adds support
for schnorr signatures (BIP340) and tapscript (BIP342).

If activated, these improvements will allow users of single-signature
scripts, multisignature scripts, and complex contracts to all use
identical-appearing commitments that enhance their privacy and the
fungibility of all bitcoins. Spenders will enjoy lower fees and the
ability to resolve many multisig scripts and complex contracts with the
same efficiency, low fees, and large anonymity set as single-sig users.
Taproot and schnorr also include efficiency improvements for full nodes
such as the ability to batch signature verification.  Together, the
improvements lay the groundwork for future potential
upgrades that may improve efficiency, privacy, and fungibility further.

Activation for taproot is being managed using a variation of BIP9
versionbits called Speedy Trial (described in BIP341). Taproot's
versionbit is bit 2, and nodes will begin tracking which blocks signal
support for taproot at the beginning of the first retarget period after
taproot’s start date of 24 April 2021.  If 90% of blocks within a
2,016-block retarget period (about two weeks) signal support for taproot
prior to the first retarget period beginning after the time of 11 August
2021, the soft fork will be locked in, and taproot will then be active
as of block 709632 (expected in early or mid November).

Should taproot not be locked in via Speedy Trial activation, it is
expected that a follow-up activation mechanism will be deployed, with
changes to address the reasons the Speedy Trial method failed.

This release includes the ability to pay taproot addresses, although
payments to such addresses are not secure until taproot activates.
It also includes the ability to relay and mine taproot transactions
after activation.  Beyond those two basic capabilities, this release
does not include any code that allows anyone to directly use taproot.
The addition of taproot-related features to Bitcoin Core's wallet is
expected in later releases once taproot activation is assured.

All users, businesses, and miners are encouraged to upgrade to this
release (or a subsequent compatible release) unless they object to
activation of taproot.  If taproot is locked in, then upgrading before
block 709632 is highly recommended to help enforce taproot's new rules
and to avoid the unlikely case of seeing falsely confirmed transactions.

Miners who want to activate Taproot should preferably use this release
to control their signaling.  The `getblocktemplate` RPC results will
automatically be updated to signal once the appropriate start has been
reached and continue signaling until the timeout occurs or taproot
activates.  Alternatively, miners may manually start signaling on bit 2
at any tim

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

2021-04-27 Thread W. J. van der Laan via bitcoin-dev 
On Monday, April 26th, 2021 at 9:43 PM, David A. Harding via bitcoin-dev 
 wrote:

> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
>
> > In general, I think its time we all agree the BIP process has simply failed
> >
> > and move on. Luckily its not really all that critical and proposed protocol
> >
> > documents can be placed nearly anywhere with the same effect.
>

I like the idea of decentralizing the BIPs process. It is a historical artifact 
that the bips repository is part of the same organization that bitcoin core is 
part of. But there shouldn't be the perception that standardization is driven 
by that, or that there is any kind of (non-trivial) gatekeeping.

I understand where this perception is coming from, though. There being 111 PRs 
open at https://github.com/bitcoin/bips/pulls indicates that there is some kind 
of bottleneck. I hope adding more BIP editors can mitigate this somewhat.

Though it also happens that the BIP author simply don't care about changes 
anymore and doesn't respond, in which case the PR lingers without any fault 
from the BIPs maintainer. So something is to be said of having the BIP 
repository mirror/aggregate author's own work trees, and changes needing to be 
proposed there instead of "upstream".

-W
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

2021-04-26 Thread W. J. van der Laan via bitcoin-dev 


On Friday, April 23rd, 2021 at 4:09 AM, Luke Dashjr via bitcoin-dev 
 wrote:

> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.

ACK on adding Kalle.

I'm happy to finally see someone else interested in BIP maintainer role, for 
years no one really seemed to care about doing this mostly 
procedural/bureaucratic function, which is (part of) the reason Luke-Jr ended 
up as the only BIP maintainer for such a long time.

And I disagree that a bot could do this just as well. Auto-merging would open 
it up to all kinds of DoS attacks, vandalism, and low-effort scams that a 
person can easily ward against.

-W
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev