[bitcoin-dev] BIP 174 thoughts

[Pieter Wuille via bitcoin-dev]

Hello all,

given some recent work and discussions around BIP 174 (Partially
Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.

First of all, it's unclear to me to what extent projects have already
worked on implementations, and thus to what extent the specification
is still subject to change. A response of "this is way too late" is
perfectly fine.

So here goes:

* Key-value map model or set model.

This was suggested in this thread:
https://twitter.com/matejcik/status/1002618633472892929

The motivation behind using a key-value model rather than a simple
list of records was that PSBTs can be duplicated (given to multiple
people for signing, for example), and merged back together after
signing. With a generic key-value model, any implementation can remove
the duplication even if they don't understand fields that may have
been added in future extensions.

However, almost the same can be accomplished by using the simpler set
model (the file consists of a set of records, with no duplication
allowed). This would mean that it would technically be legal to have
two partial signatures with the same key for the same input, if a
non-deterministic signer is used.

On the other hand, this means that certain data currently encoded
inside keys can be dropped, reducing the PSBT size. This is
particularly true for redeemscripts and witnessscripts, as they can
just be computed by the client when deserializing. The two types could
even be merged into just "scripts" records - as they don't need to be
separated based on the way they're looked up (Hash160 for P2SH, SHA256
for P2WSH). The same could be done for the BIP32 derivation paths,
though this may be expensive, as the client would need to derive all
keys before being able to figure out which one(s) it needs.

One exception is the "transaction" record, which needs to be unique.
That can either be done by adding an exception ("there can only be one
transaction record"), or by encoding it separately outside the normal
records (that may also be useful to make it clear that it is always
required).

* Ability for Combiners to verify two PSBT are for the same transaction

Clearly two PSBTs for incompatible transactions cannot be combined,
and this should not be allowed.

It may be easier to enforce this if the "transaction" record inside a
PSBT was required to be in a canonical form, meaning with empty
scriptSigs and witnesses. In order to do so, there could be per-input
records for "finalized scriptSig" and "finalized witness". Actually
placing those inside the transaction itself would only be allowed when
all inputs are finalized.

* Optional signing

I think all operation for the Signer responsibility should be
optional. This will inevitably lead to incompatibilities, but with the
intent of being forward compatible with future developments, I don't
think it is possible to require every implementation to support the
same set of scripts or contracts. For example, some signers may only
implement single-key P2PKH, or may only support signing SegWit inputs.
It's the user's responsibility to find compatible signers (which is
generally not an issue, as the different participants in a setup
necessarily have this figured out before being able to create an
address). This does mean that there can't be an unconditional test
vector that specifies the produced signature in certain circumstances,
but there could be "For implementations that choose to implement
signing for P2PKH inputs using RFC6979, the expected output given
input X and access to key Y is Z".

On the other hand, the Combiner and Finalizer roles can probably be
specified much more accurately than they are now.

* Derivation from xpub or fingerprint

For BIP32 derivation paths, the spec currently only encodes the 32-bit
fingerprint of the parent or master xpub. When the Signer only has a
single xprv from which everything is derived, this is obviously
sufficient. When there are many xprv, or when they're not available
indexed by fingerprint, this may be less convenient for the signer.
Furthermore, it violates the "PSBT contains all information necessary
for signing, excluding private keys" idea - at least if we don't treat
the chaincode as part of the private key.

For that reason I would suggest that the derivation paths include the
full public key and chaincode of the parent or master things are
derived from. This does mean that the Creator needs to know the full
xpub which things are derived from, rather than just its fingerprint.

* Generic key offset derivation

Whenever a BIP32 derivation path does not include any hardened steps,
the entirety of the derivation can be conveyed as "The private key for
P is equal to the private key for Q plus x", with P and Q points and x
a scalar. This representation is more flexible (it also supports
pay-to-contract derivations), more efficient, and more compact. The
downside is that it requires the Signer to support such derivation,
which I don't believe any 

[bitcoin-core-dev] Bitcoin Core 0.16.1 released

[Wladimir J. van der Laan via bitcoin-core-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.1 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:91069028aaf9f6bb3279e71bfd9ab164922e578e=bitcoin-core-0.16.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969
 

This is a new minor version release, with various bugfixes
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 for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Miner block size removed
- 

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

0.16.1 change log
- --

### Policy
- - #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012)

### Mining
- - #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery)

### Block and transaction handling
- - #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after 
reconsiderblock (sdaftuar)
- - #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees)

### P2P protocol and network code
- - #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS 
seeder (EthanHeilman)

### Wallet
- - #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync 
(laanwj)
- - #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery)

### GUI
- - #12999 `1720eb3` Show the Window when double clicking the taskbar icon 
(ken2812221)
- - #12650 `f118a7a` Fix issue: "default port not shown correctly in settings 
dialog" (251Labs)
- - #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy 
address default (fanquake)

### Build system
- - #12474 `b0f692f` Allow depends system to support armv7l (hkjn)
- - #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake)
- - #12648 `46ca8f3` test: Update trusted git root (MarcoFalke)
- - #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake)
- - #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake)
- - #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake)
- - #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o 
config (TheBlueMatt)

### Tests and QA
- - #12447 `01f931b` Add missing signal.h header (laanwj)
- - #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact)
- - #12804 `4bdb0ce` Fix intermittent rpc_net.py failure. (jnewbery)
- - #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact)
- - #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount 
(kallewoof)
- - #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery)
- - #12475 `41c29f6` Fix python TypeError in script.py (MarcoFalke)
- - #12638 `0a76ed2` Cache only chain and wallet for regtest datadir 
(MarcoFalke)
- - #12902 `7460945` Handle potential cookie race when starting node (sdaftuar)
- - #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end 
(sdaftuar)
- - #13049 `9ea62a3` Backports (MarcoFalke)
- - #13201 `b8aacd6` Handle disconnect_node 

[bitcoin-dev] Bitcoin Core 0.16.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.16.1 is now available from:

  

Or through bittorrent:

  
magnet:?xt=urn:btih:91069028aaf9f6bb3279e71bfd9ab164922e578e=bitcoin-core-0.16.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969
 

This is a new minor version release, with various bugfixes
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 for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will 
be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. 
Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. 
Existing
wallets that were created with older versions are not affected by this.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes
===

Miner block size removed
- 

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

0.16.1 change log
- --

### Policy
- - #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012)

### Mining
- - #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery)

### Block and transaction handling
- - #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after 
reconsiderblock (sdaftuar)
- - #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees)

### P2P protocol and network code
- - #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS 
seeder (EthanHeilman)

### Wallet
- - #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync 
(laanwj)
- - #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery)

### GUI
- - #12999 `1720eb3` Show the Window when double clicking the taskbar icon 
(ken2812221)
- - #12650 `f118a7a` Fix issue: "default port not shown correctly in settings 
dialog" (251Labs)
- - #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy 
address default (fanquake)

### Build system
- - #12474 `b0f692f` Allow depends system to support armv7l (hkjn)
- - #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake)
- - #12648 `46ca8f3` test: Update trusted git root (MarcoFalke)
- - #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake)
- - #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake)
- - #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake)
- - #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o 
config (TheBlueMatt)

### Tests and QA
- - #12447 `01f931b` Add missing signal.h header (laanwj)
- - #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact)
- - #12804 `4bdb0ce` Fix intermittent rpc_net.py failure. (jnewbery)
- - #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact)
- - #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount 
(kallewoof)
- - #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery)
- - #12475 `41c29f6` Fix python TypeError in script.py (MarcoFalke)
- - #12638 `0a76ed2` Cache only chain and wallet for regtest datadir 
(MarcoFalke)
- - #12902 `7460945` Handle potential cookie race when starting node (sdaftuar)
- - #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end 
(sdaftuar)
- - #13049 `9ea62a3` Backports (MarcoFalke)
- - #13201 `b8aacd6` Handle disconnect_node 

Re: [bitcoin-dev] New serialization/encoding format for key material

[Russell O'Connor via bitcoin-dev]

> For codes designed for length 341 (the first length enough to support
> 512 bits of data):
> * correct 1 error = 3 checksum characters
> * correct 2 errors = 7 checksum characters
> * correct 3 errors = 11 checksum characters
> * correct 4 errors = 15 checksum characters
> * correct 5 errors = 19 checksum characters
> * ...
> * correct 7 errors = 26 checksum characters (~ length * 1.25)
> * correct 13 errors = 51 checksum characters (~ length * 1.5)
> * correct 28 errors = 102 checksum characters (~ length * 2)
>
> So it really boils down to a trade-off between length of the code, and
> recovery properties.
>

At the risk of making the proposal more complex, I wonder if it might be
better to support multiple checksum variants?  The trade-off between code
length and recovery seems to be largely determined by the user's medium of
storage, which is likely to vary from person to person.  I personally would
probably be interested in the 51 or even 102 character checksums variants.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev