Andrew Chow bada9636d7
Merge bitcoin/bitcoin#24043: Add (sorted)multi_a descriptor for k-of-n multisig inside tr
4828d53eccd52a67631c64cef0ba7df90dff138d Add (sorted)multi_a descriptors to doc/descriptors.md (Pieter Wuille)
b5f33ac1f82aea290b4653af36ac2ad1bf1cce7b Simplify wallet_taproot.py functional test (Pieter Wuille)
eb0667ea96d52db9135514a5e95ab943f6abd8a6 Add tests for (sorted)multi_a derivation/signing (Pieter Wuille)
c17c6aa08df81aa0086d80b50187c8cd60ecc222 Add signing support for (sorted)multi_a scripts (Pieter Wuille)
3eed6fca57d1fa7544f372e6e7de0a9ae1b5715a Add multi_a descriptor inference (Pieter Wuille)
79728c4a3d8a74f276daf1e72abbdecdab85a5d8 Add (sorted)multi_a descriptor and script derivation (Pieter Wuille)
25e95f9ff89a97b87ce218f28274c3c821b2d54d Merge/generalize IsValidMultisigKeyCount/GetMultisigKeyCount (Pieter Wuille)

Pull request description:

  This adds a new `multi_a(k,key_1,key_2,...,key_n)` (and corresponding `sortedmulti_a`) descriptor for k-of-n policies inside `tr()`. Semantically it is very similar to the existing `multi()` descriptor, but with the following changes:
  * The corresponding script is `<key1> OP_CHECKSIG <key2> OP_CHECKSIGADD <key3> OP_CHECKSIGADD ... <key_n> OP_CHECKSIGADD <k> OP_NUMEQUAL`, rather than the traditional `OP_CHECKMULTISIG`-based script, making it usable inside the `tr()` descriptor.
  * The keys can optionally be specified in x-only notation.
  * Both the number of keys and the threshold can be as high as 999; this is the limit due to the consensus stacksize=1000 limit

  I expect that this functionality will later be replaced with a miniscript-based implementation, but I don't think it's necessary to wait for that.

  Limitations:
  * The wallet code will for not estimate witness size incorrectly for script path spends, which may result in a (dramatic) fee underpayment with large multi_a scripts.
  * The multi_a script construction is (slightly) suboptimal for n-of-n (where a `<key1> OP_CHECKSIGVERIFY ... <key_n-1> OP_CHECKSIGVERIFY <key_n> OP_CHECKSIG` would be better). Such a construction is not included here.

ACKs for top commit:
  achow101:
    ACK 4828d53eccd52a67631c64cef0ba7df90dff138d
  gruve-p:
    ACK 4828d53ecc
  sanket1729:
    code review ACK 4828d53eccd52a67631c64cef0ba7df90dff138d
  darosior:
    Code review ACK 4828d53eccd52a67631c64cef0ba7df90dff138d

Tree-SHA512: 5dcd434b79585f0ff830f7d501d27df5e346f5749f47a3109ec309ebf2cbbad0e1da541eec654026d911ab67fd7cf7793fab0f765628d68d81b96ef2a4d234ce
2022-03-04 07:28:23 -05:00
..
2022-02-14 10:04:51 +00:00
2021-10-04 16:40:00 -04:00
2022-02-22 18:16:43 +01:00
2021-07-30 11:21:51 +02:00
2021-12-13 02:33:32 -03:00
2022-03-03 19:05:37 +01:00
2022-02-18 20:48:52 +05:30
2021-12-06 13:31:28 -03:00

Bitcoin Core

Setup

Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires a few hundred gigabytes of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.

To download Bitcoin Core, visit bitcoincore.org.

Running

The following are some helpful notes on how to run Bitcoin Core on your native platform.

Unix

Unpack the files into a directory and run:

  • bin/bitcoin-qt (GUI) or
  • bin/bitcoind (headless)

Windows

Unpack the files into a directory, and then run bitcoin-qt.exe.

macOS

Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.

Need Help?

Building

The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.

Development

The Bitcoin repo's root README contains relevant information on the development process and automated testing.

Resources

Miscellaneous

License

Distributed under the MIT software license.