[CHIA-307] (long-lived) Vault #16610

Source hash: e80ab1c Remaining commits: 0 Merge conflict resolutions: https://quexington.github.io/merge-diffs/29a01058f5b89aa07bd9c335d7b215e756e093c2.html

…3e3b630fbd507c607fe7' into quex.signer_protocol

…tation'

…ning_from_wallet

…vation_root

…tocol

…vation_root

…ctions_rpc

…tocol

…ort_layer

Source hash: 84f3e3d Remaining commits: 0 Merge conflict resolutions: https://quexington.github.io/merge-diffs/bea085d265798537b15d99525ee4f61d12883ee9.html

…ation

…ning_from_wallet

…vation_root

…ctions_rpc

…tocol

…ort_layer

…1f33738f9c522ac70b10' into quex.signer_protocol

…ation

…ning_from_wallet

Source hash: aeecaca Remaining commits: 0 Merge diffs: quexington.github.io/merge-diffs/8bb2c25e446927bf94a10b9dd030105d54f5939a.html

…vation_root

…tocol

…ctions_rpc

…ort_layer

This PR introduces a couple of new things in service of a new protocol between a wallet implementation and a transaction signer like an hsms or mobile device: * New `ClvmStreamable` parent class. Contains all `Streamable` functionality with new methods `.as_program` and `.from_program`. A child class inheriting from this parent class will also automatically become a dataclass (and automatically apply the `@streamable` wrapper). * New `clvm_serialization_mode` context manager. When code under this context manager attempts to access the streamable library, the bytes serialization is overridden to first convert the object to a `Program` and _then_ to bytes. In addition, the JSON serialization is overridden so that instead of continuing to JSON serialize past `ClvmStreamable` objects, the serialization instead just terminates with the byte representation in place like so: _without context manager_ ``` { "some key on a regular streamable": { "key on clvm streamable": foo, "key 2 on clvm streamable": bar, } } ``` _with context manager_ ``` { "some key on a regular streamable": "0xclvm_streamable_as_program_bytes" } ``` * Of course the actual protocol message definitions. These should not be taken as official without a corresponding CHIP.

…ult_from_main_c6f1a57c565fb3e66afe7991669df93958dbe049

…7991669df93958dbe049' into quex.wallet_signer_implementation

…ning_from_wallet

Co-authored-by: Kyle Altendorf <sda@fstab.net>

…ctions_rpc

…ort_layer

…vation_root

…tocol

Source hash: 07fcecd Remaining commits: 0 Merge diff: https://quexington.github.io/merge-diffs/a4b573272e0c8a0018a1ac3fbf87f38e64e1efd1.html

This PR implements the wallet signer protocol (CHIPs TBD) in the chia wallet. It does not only implement the wallet role, it also implements the signer role for the spends that require signatures from BLS secret keys.

This change removes the default behavior of wallets to sign a transaction before returning it. That responsibility has been moved to clients (usually the RPC handling it automatically in our case). As such, a lot of specific signing code has been deleted in favor of the more generic version introduced in #16895.

…long_lived_vault_from_main_368fecc17eb902551d21fad4e39b0f26befbbe67

…ult_from_main_368fecc17eb902551d21fad4e39b0f26befbbe67

…fad4e39b0f26befbbe67' into quex.allow_only_pks

Source hash: 368fecc Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/d03844c53ef64468bd4590437a56f578cec08111.html

This adds support for entries in the keyring that have no secret information associated with them. This is perhaps a silly choice to keep in the keyring since it is public information but since the keyring is the standard area where we manage keys right now it seems like the logical choice at least in the short term.

…ctions_rpc

…vation_root

…ort_layer

…vation_root

…tocol

This PR removes the need of any code to rely on `WalletStateManager.private_key`. This has been possible since #16896 which was the main need for the private key in the wallet (besides finding non-observer addresses which is obviously impossible if you run without the private key now). This does not however remove the _ability_ to have a private key in the wallet and operate as usual.

…4496f57423173acd62b75dfd64d7c1a30e4c7

This PR introduces the finishing touches on a pure "observer" mode. This pipes in the ability to add public key only entries in the keyring to the CLI so users can add just public information and still sync their wallet and view balances etc. It also updates the wallet signing function to work without the master private key. This is crucial infrastructure for hypothetical multi-sig as there are operations that a final aggregator needs to take even if they are not an owner of any of the relevant secret keys.

…sign_clvm_streamable

…ult_from_main_4df4496f57423173acd62b75dfd64d7c1a30e4c7

…2b75dfd64d7c1a30e4c7' into quex.wallet_rpc_client_types

…in_4df4496f57423173acd62b75dfd64d7c1a30e4c7' into quex.pubkey_to_observation_root

…vation_root

…in_4df4496f57423173acd62b75dfd64d7c1a30e4c7' into quex.redesign_clvm_streamable

…tocol

…ctions_rpc

…ort_layer

Source hash: b08713f Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/622109356ae5b37faf9596708379986379e2b73e.html

…et_rpc_client_types

…ey_to_observation_root

… BLS (#16953) This PR adds a new dimension to the keychain in which it can store more than one type of public information. It converts most instances of `G1Element` to a new Protocol called `ObservationRoot` which must simply implement the ability to serialize to bytes and generate a fingerprint. This is crucial for upcoming applications in which the public information used to sync a wallet is not a BLS public key but rather a launcher ID, or perhaps other key types like SECP, etc. The private information is left constrained to BLS secret keys for now as it is less immediately useful.

…ctions_rpc

This attempts to rework how the clvm_serde library from hsms is plugged into chia-blockchain. It was reworked this way to avoid the following pitfalls of the previous approach: * Use of a metaclass * Requiring (an additional) homegrown base class for new types * Implicit protocols rather than explicit protocol usage * Use of a context manager for serialization configuration Some new downsides to this approach: * Explicit protocol specification, while safer, is sometimes inconvenient and less flexible * Worse ergonomics for defining new types * Greater exposure to changes in the streamable library * Heavier touch on streamable library (though still very light, just making some implicit defaults explicit and overridable)

…et_rpc_client_types

This PR essentially changes `WalletStateManager.root_pubkey: G1Element` into `WalletStateManager.observation_root: ObservationRoot` and deals with all relevant effects from that change.

This PR replaces the assumption in the wallet as a whole that the wallet that controls the inner puzzle of a coin will be of type `Wallet` with a new assumption that that wallet will match the `MainWalletProtocol`.

This PR converts the return values of the wallet RPC client into the marshal-able types introduced in #17201 . Previously, the client was very ad-hoc in what it returned: sometimes dictionaries, sometimes a specific part of the response deserialized, sometimes nothing. The purpose of standardizing like this is so that the whole of each RPC response is available when you call an RPC from the python client. This is important for upcoming PRs which take advantage of the output transactions that every tx_endpoint now returns.

…long_lived_vault_from_main_02a7e8b1b55b0f43add5c224fb5744313872b5b6

…c224fb5744313872b5b6' into quex.prep_for_vault_wallet

…c224fb5744313872b5b6' into quex.add_tx_out_decorator

Source hash: 02a7e8b Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/92b1cc59a906daa4aace5c816b12a5c6569626d1.html

This PR contains the last miscellaneous changes needed to make space for the hypothetical vault wallet. It adds a test for a generic `MainWalletProtocol` type object and handles any remaining difficulties that adding that hypothetical new wallet type reveals.

…long_lived_vault_from_main_646c416622b4512097bdee7a9d48259136d41f1a

Source hash: 646c416 Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/ed66cc778cd2c40973b3aa9c49213932f0a29589.html

This adds a new command decorator (unused for now but more PRs to come) that automatically adds the functionality to export transactions rather than automatically push them.

This adds the new @tx_out_cmd decorator to the `chia wallet send` command. This allows the command to output a transaction file instead of pushing the transaction automatically.

…long_lived_vault_from_main_bd3a638db10ee92a15f138ceaef06648c3c7b480

source hash: bd3a638 remaining commits: 0 merge diffs: https://quexington.github.io/merge-diffs/618e4f9fca621ea263c489d8f953337c0eab3e53.html

This brings another set of commands to the `@tx_out_cmd` decorator which gives it the capability to optionally push a transaction and export the transactions to a local file.

This brings another set of commands to the @tx_out_cmd decorator which gives it the capability to optionally push a transaction and export the transactions to a local file.

…ning_instructions_rpc

…ort_layer

…ling) (#18065) This brings another set of commands to the @tx_out_cmd decorator which gives it the capability to optionally push a transaction and export the transactions to a local file. This PR being the last in a chain of similar PRs, I have included some comments explaining that DL and pooling endpoints will not be ported to the decorator at this time. Didn't think that necessitated its own PR and CI run :)

…long_lived_vault_from_main_32fd48159f761ad7c59e5b8f02a7aed17e2503e9

Source hash: 32fd481 Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/5c407ea9bbab94ca2da71e786e8264f8197bfa08.html

This adds an RPC endpoint for the wallet to act as a signer for unsigned transactions generated by other wallets.

This PR introduces a new `TranslationLayer` concept to the `@clvm_streamable` library enabling reconstruction from CHIP-27 APIs into more specific responses for different types of clients. CHIP-28 is one such chip and support for it is enable as well.

This PR caps off a thread of work that supports external signers for transactions generated by the wallet. With these commands, it should be possible to run two wallets with different security qualities and transport transactions back and forth between them for the colder one to sign. It currently uses binary files/QR codes to accomplish this although other methods of transport are certainly on the table.

…long_lived_vault_from_main_9ea4609618cba2229dc9f4b916ec82927c79a0d6

…puzzle_w_aggregator

Source hash: 9ea4609 Remaining commits: 0 Merge-diffs: https://quexington.github.io/merge-diffs/13ccfa7a4758099c00943be6d4d1a59afa4c854b.html

The existing version of this was built somewhat specifically for DAOs. I've renamed that one and added this new one as a simplification/generalization.

…long_lived_vault_from_main_9e1a4dceb724d7ebf56e3d8a75e8692184997805

Source hash: 9e1a4dc Remaining commits: 0 Merge diffs: https://quexington.github.io/merge-diffs/844cb8ea94ce7f419c3d26ba471f747de021784f.html

Commits on Jan 19, 2024

Add to sdist only allowed list

Quexington committed Jan 19, 2024

1 Configuration menu

View commit details

Copy full SHA for 39bab6d

Browse repository at this point

Copy the full SHA

39bab6d View commit details

Browse the repository at this point in the history

Commits on Feb 1, 2024

Test coverage

Quexington committed Feb 1, 2024

Configuration menu

View commit details

Copy full SHA for 43889e4

Browse repository at this point

Copy the full SHA

43889e4 View commit details

Browse the repository at this point in the history

Commits on Feb 5, 2024

Add better type checking to framework

Quexington committed Feb 5, 2024

Configuration menu

View commit details

Copy full SHA for f53440f

Browse repository at this point

Copy the full SHA

f53440f View commit details

Browse the repository at this point in the history

Commits on Mar 15, 2024

Redesign clvm_streamable

Quexington committed Mar 15, 2024

Configuration menu

View commit details

Copy full SHA for 7eb45ab

Browse repository at this point

Copy the full SHA

7eb45ab View commit details

Browse the repository at this point in the history

Commits on Mar 19, 2024

Address comments by @altendky

Quexington committed Mar 19, 2024

Configuration menu

View commit details

Copy full SHA for 713bf95

Browse repository at this point

Copy the full SHA

713bf95 View commit details

Browse the repository at this point in the history

Commits on May 8, 2024

Add get_public_key

Quexington committed May 8, 2024

Configuration menu

View commit details

Copy full SHA for 1abae41

Browse repository at this point

Copy the full SHA

1abae41 View commit details

Browse the repository at this point in the history

Commits on Jun 4, 2024

add test for BSTLSigningInstructions

Quexington committed Jun 4, 2024

Configuration menu

View commit details

Copy full SHA for 95ac9f1

Browse repository at this point

Copy the full SHA

95ac9f1 View commit details

Browse the repository at this point in the history

Commits on Jun 18, 2024

Add test coverage

Quexington committed Jun 18, 2024

Configuration menu

View commit details

Copy full SHA for 0c993a0

Browse repository at this point

Copy the full SHA

0c993a0 View commit details

Browse the repository at this point in the history

Commits on Jun 20, 2024

test coverage again

Quexington committed Jun 20, 2024

Configuration menu

View commit details

Copy full SHA for 62e73a0

Browse repository at this point

Copy the full SHA

62e73a0 View commit details

Browse the repository at this point in the history

[CHIA-307] (long-lived) Vault #16610

Are you sure you want to change the base?

[CHIA-307] (long-lived) Vault #16610

Commits on Jan 5, 2024

Commits on Jan 8, 2024

Commits on Jan 19, 2024

Commits on Jan 22, 2024

Commits on Jan 23, 2024

Commits on Jan 24, 2024

Commits on Jan 25, 2024

Commits on Jan 26, 2024

Commits on Jan 29, 2024

Commits on Jan 30, 2024

Commits on Jan 31, 2024

Commits on Feb 1, 2024

Commits on Feb 2, 2024

Commits on Feb 5, 2024

Commits on Feb 6, 2024

Commits on Feb 7, 2024

Commits on Feb 8, 2024

Commits on Feb 12, 2024

Commits on Feb 20, 2024

Commits on Feb 23, 2024

Commits on Feb 26, 2024

Commits on Feb 27, 2024

Commits on Feb 28, 2024

Commits on Feb 29, 2024

Commits on Mar 15, 2024

Commits on Mar 18, 2024

Commits on Mar 19, 2024

Commits on Mar 20, 2024

Commits on Mar 21, 2024

Commits on Mar 22, 2024

Commits on Mar 25, 2024

Commits on Mar 26, 2024

Commits on Mar 27, 2024

Commits on Mar 28, 2024

Commits on Mar 29, 2024

Commits on Apr 1, 2024

Commits on Apr 8, 2024

Commits on Apr 9, 2024

Commits on Apr 16, 2024

Commits on Apr 25, 2024

Commits on May 6, 2024

Commits on May 7, 2024

Commits on May 8, 2024

Commits on May 9, 2024

Commits on May 15, 2024

Commits on May 16, 2024

Commits on May 17, 2024

Commits on May 20, 2024

Commits on May 21, 2024

Commits on May 22, 2024

Commits on May 23, 2024

Commits on May 28, 2024

Commits on Jun 3, 2024

Commits on Jun 4, 2024

Commits on Jun 5, 2024

Commits on Jun 11, 2024

Commits on Jun 17, 2024

Commits on Jun 18, 2024

Commits on Jun 20, 2024

Commits on Jun 24, 2024

Commits on Jun 25, 2024

Commits on Jun 26, 2024

Commits on Jul 8, 2024