New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiwallet: simplest endpoint support #10849

Merged
merged 6 commits into from Jul 18, 2017

Conversation

Projects
None yet
@jonasschnelli
Member

jonasschnelli commented Jul 17, 2017

Alternative for #10829 and #10650.
It adds the most simplest form of wallet based endpoint support (/wallet/<filename>).
No v1 and no node/wallet endpoint split.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jul 17, 2017

Member

Looks good to me too, utACK c8115e3.

Member

laanwj commented Jul 17, 2017

Looks good to me too, utACK c8115e3.

@laanwj laanwj added this to the 0.15.0 milestone Jul 17, 2017

@ryanofsky

This comment has been minimized.

Show comment
Hide comment
@ryanofsky

ryanofsky Jul 17, 2017

Contributor

This has no documentation. If we think this approach is a good idea, I would like to see in what way it can be explained to users. Is there going to be a doc/JSPON-RPC-interface.md to complement https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md? Will endpoint be considered experimental (unchanging semantics but possibly temporary) or unstable (possibly changing semantics and possibly temporary)?

Also, from the other issue I think something like -rpcwallet=filename would be better than -usewallet=filename. It's hard to see how "use" could convey any meaning when you would expect any command line option that you specify to be used.

And, also from other issue I think '?wallet=filename makes more sense than /wallet/filename as more extensible and conventional way of passing options (as opposed to required arguments) in urls.

Contributor

ryanofsky commented Jul 17, 2017

This has no documentation. If we think this approach is a good idea, I would like to see in what way it can be explained to users. Is there going to be a doc/JSPON-RPC-interface.md to complement https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md? Will endpoint be considered experimental (unchanging semantics but possibly temporary) or unstable (possibly changing semantics and possibly temporary)?

Also, from the other issue I think something like -rpcwallet=filename would be better than -usewallet=filename. It's hard to see how "use" could convey any meaning when you would expect any command line option that you specify to be used.

And, also from other issue I think '?wallet=filename makes more sense than /wallet/filename as more extensible and conventional way of passing options (as opposed to required arguments) in urls.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jul 17, 2017

Member

And, also from other issue I think '?wallet=filename makes more sense than /wallet/filename as more extensible and conventional way of passing options (as opposed to required arguments) in urls.

Definitely no! Let's not repeat this: JSON-RPC uses POST only, and with POST it is weird to have ?a=b URL-encoded arguments in the URL as well. It also implies more arguments could be added later, which is not true. This is only to select the wallet, which is inherently hierarchical.
(also e.g. ?a=b syntax isn't deterministic, it's possible to add arguments that are ignored, change the order of the arguments, etc, whereas a /wallet/<name>/ URL is simply a fixed thing)

Member

laanwj commented Jul 17, 2017

And, also from other issue I think '?wallet=filename makes more sense than /wallet/filename as more extensible and conventional way of passing options (as opposed to required arguments) in urls.

Definitely no! Let's not repeat this: JSON-RPC uses POST only, and with POST it is weird to have ?a=b URL-encoded arguments in the URL as well. It also implies more arguments could be added later, which is not true. This is only to select the wallet, which is inherently hierarchical.
(also e.g. ?a=b syntax isn't deterministic, it's possible to add arguments that are ignored, change the order of the arguments, etc, whereas a /wallet/<name>/ URL is simply a fixed thing)

@ryanofsky

This comment has been minimized.

Show comment
Hide comment
@ryanofsky

ryanofsky Jul 17, 2017

Contributor

POST it is weird to have ?a=b URL-encoded arguments in the URL as well

Don't know your source for this but this is done all the time.

It also implies more arguments could be added later, which is not true.

I don't know why it wouldn't be true. I can think of lots of RPC options you might want to add outside the RPC request: timeouts, completions handlers, etc.

?a=b syntax isn't deterministic, it's possible to add arguments that are ignored, change the order of the arguments, etc, whereas a /wallet// URL is simply a fixed thing

Not true, you don't have to ignore any option, but it is good practice to accept options in any order. This is one of the reasons people choose to used named options instead of positional arguments.

Contributor

ryanofsky commented Jul 17, 2017

POST it is weird to have ?a=b URL-encoded arguments in the URL as well

Don't know your source for this but this is done all the time.

It also implies more arguments could be added later, which is not true.

I don't know why it wouldn't be true. I can think of lots of RPC options you might want to add outside the RPC request: timeouts, completions handlers, etc.

?a=b syntax isn't deterministic, it's possible to add arguments that are ignored, change the order of the arguments, etc, whereas a /wallet// URL is simply a fixed thing

Not true, you don't have to ignore any option, but it is good practice to accept options in any order. This is one of the reasons people choose to used named options instead of positional arguments.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jul 17, 2017

Member

I don't know why it it wouldn't be true, but ok. I can think of lots of RPC options you might want to add outside the RPC request: timeouts, completions handlers, etc.

Those really shouldn't be passed in the URL. The URL locates something, such as the wallet in this case.

Member

laanwj commented Jul 17, 2017

I don't know why it it wouldn't be true, but ok. I can think of lots of RPC options you might want to add outside the RPC request: timeouts, completions handlers, etc.

Those really shouldn't be passed in the URL. The URL locates something, such as the wallet in this case.

@ryanofsky

This comment has been minimized.

Show comment
Hide comment
@ryanofsky

ryanofsky Jul 17, 2017

Contributor

Those really shouldn't be passed in the URL. The URL locates something, such as the wallet in this case.

They shouldn't be part of the uri-path, but you would have to explain more why they shouldn't be options in a query string...

Contributor

ryanofsky commented Jul 17, 2017

Those really shouldn't be passed in the URL. The URL locates something, such as the wallet in this case.

They shouldn't be part of the uri-path, but you would have to explain more why they shouldn't be options in a query string...

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Jul 17, 2017

Member

ryanofsky: Among other reasons the path approach will already work with most but not all software, e.g. you change your RPC endpoint url to be one with the path, and tada-- done, no source code modifications in some things. I believe a query string would not achieve this, and in some cases require deep spelunking.

I could see an argument that something like a timeout might make sense as a query like parameter, but a wallet seems like a pretty perfect 'navigation' like element.

Member

gmaxwell commented Jul 17, 2017

ryanofsky: Among other reasons the path approach will already work with most but not all software, e.g. you change your RPC endpoint url to be one with the path, and tada-- done, no source code modifications in some things. I believe a query string would not achieve this, and in some cases require deep spelunking.

I could see an argument that something like a timeout might make sense as a query like parameter, but a wallet seems like a pretty perfect 'navigation' like element.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jul 17, 2017

Member

Is there going to be a doc/JSPON-RPC-interface.md to complement https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md?

And yes, there should be. Documentation is good.
But that's not a requirement for the feature freeze. This is an experimental API, it could be changed completely for next release, so not having it documented 100% on first release is not a problem.
(we should make an attempt in the release notes, of course)

Member

laanwj commented Jul 17, 2017

Is there going to be a doc/JSPON-RPC-interface.md to complement https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md?

And yes, there should be. Documentation is good.
But that's not a requirement for the feature freeze. This is an experimental API, it could be changed completely for next release, so not having it documented 100% on first release is not a problem.
(we should make an attempt in the release notes, of course)

@ryanofsky

This comment has been minimized.

Show comment
Hide comment
@ryanofsky

ryanofsky Jul 17, 2017

Contributor

you change your RPC endpoint url to be one with the patch, and tada-- done

This is true for this PR but not #10650 which is a big reason why I think this PR is better and less user-hostile than #10650.

@laanwj, my bigger point is about extensibility . We want to add a wallet option right now. Great, so that can be as simple as adding ?wallet=filename to the query string to provide the nice user benefit Greg cites. And maybe you have a problem with timeouts or completion handlers, but lets say we want to add a ?network=name parameter in the future (maybe to add extra way to specify that an operation is done on mainnet or testnet, or in some dystopia where there are multiple chains, but no need to go there...). The point is you want to be able to add some new option. With query strings you have a standard way to do this. ?wallet=filename&network=name&timeout=30s works just as well as ?timeout=30s&wallet=filename&network=name as established by long-running convention.

If we use paths instead, are we requiring /wallet/filename/network/name or /network/name/filename or /wallet/filename?network=name, or something else completely arbitrary based on historical accident? Or because a filename is a "location" but a network name isn't?

I guess another thing that is motivating me is that I would like to see less uri-path space annexed for this one multiwallet feature. Right now json-rpc calls go directly to / handler and REST calls go directly to /rest handler. Everything else right now (but not with these endpoint prs) is wide open right now. I'd be happier if more of the path space could be free for other applications like a web interface. If these prs added stuff under an /rpc path, that would also seem like an improvement to me.

Also, so my other points doesn't get lost above, it would be great to see something done on documentation and -usewallet if we are taking this endpoint approach. Even if there is not "100% documentation" I think it would be very helpful to see uri-path endpoints explained from user point of view.

Contributor

ryanofsky commented Jul 17, 2017

you change your RPC endpoint url to be one with the patch, and tada-- done

This is true for this PR but not #10650 which is a big reason why I think this PR is better and less user-hostile than #10650.

@laanwj, my bigger point is about extensibility . We want to add a wallet option right now. Great, so that can be as simple as adding ?wallet=filename to the query string to provide the nice user benefit Greg cites. And maybe you have a problem with timeouts or completion handlers, but lets say we want to add a ?network=name parameter in the future (maybe to add extra way to specify that an operation is done on mainnet or testnet, or in some dystopia where there are multiple chains, but no need to go there...). The point is you want to be able to add some new option. With query strings you have a standard way to do this. ?wallet=filename&network=name&timeout=30s works just as well as ?timeout=30s&wallet=filename&network=name as established by long-running convention.

If we use paths instead, are we requiring /wallet/filename/network/name or /network/name/filename or /wallet/filename?network=name, or something else completely arbitrary based on historical accident? Or because a filename is a "location" but a network name isn't?

I guess another thing that is motivating me is that I would like to see less uri-path space annexed for this one multiwallet feature. Right now json-rpc calls go directly to / handler and REST calls go directly to /rest handler. Everything else right now (but not with these endpoint prs) is wide open right now. I'd be happier if more of the path space could be free for other applications like a web interface. If these prs added stuff under an /rpc path, that would also seem like an improvement to me.

Also, so my other points doesn't get lost above, it would be great to see something done on documentation and -usewallet if we are taking this endpoint approach. Even if there is not "100% documentation" I think it would be very helpful to see uri-path endpoints explained from user point of view.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Jul 17, 2017

Member

I'd be happier if more of the path space could be free for other applications like a web interface. If all this stuff was moved under an /rpc path

It's under /wallet/ at least, so I think it won't have any clashes with other use.

As far as usewallet-- I think we intend that argument to eventually specify all wallets that get loaded, not just specific to rpc. e.g. it would also tell it which ones to load in the UI when that support is complete.

Member

gmaxwell commented Jul 17, 2017

I'd be happier if more of the path space could be free for other applications like a web interface. If all this stuff was moved under an /rpc path

It's under /wallet/ at least, so I think it won't have any clashes with other use.

As far as usewallet-- I think we intend that argument to eventually specify all wallets that get loaded, not just specific to rpc. e.g. it would also tell it which ones to load in the UI when that support is complete.

@ryanofsky

This comment has been minimized.

Show comment
Hide comment
@ryanofsky

ryanofsky Jul 17, 2017

Contributor

It's under /wallet/ at least, so I think it won't have any clashes with other use.

I could easily imagine a web interface wanting to handle /wallet path. The point is that if RPCs are restricted to exactly one path / (current case) or two paths / and /rpc then it's then it's clean and easy to do anything else with the rest of the space. If there's a bigger changing list of RPC paths, that would seem to make things messier.

As far as usewallet-- I think we intend that argument to eventually specify all wallets that get loaded, not just specific to rpc. e.g. it would also tell it which ones to load in the UI when that support is complete.

That's interesting. I thought the UI was would just have tabs or a dropdown to choose between any of the loaded wallets. But I guess the advantage of having the bitcoin-qt executable accept a -usewallet=filename instead of a more descriptive -showwallet=filename or -onlyshowwallet=filename would be that you can specify -usewallet in your bitcoind.conf and have it picked up by both bitcoin-cli and bitcoin-qt.

Contributor

ryanofsky commented Jul 17, 2017

It's under /wallet/ at least, so I think it won't have any clashes with other use.

I could easily imagine a web interface wanting to handle /wallet path. The point is that if RPCs are restricted to exactly one path / (current case) or two paths / and /rpc then it's then it's clean and easy to do anything else with the rest of the space. If there's a bigger changing list of RPC paths, that would seem to make things messier.

As far as usewallet-- I think we intend that argument to eventually specify all wallets that get loaded, not just specific to rpc. e.g. it would also tell it which ones to load in the UI when that support is complete.

That's interesting. I thought the UI was would just have tabs or a dropdown to choose between any of the loaded wallets. But I guess the advantage of having the bitcoin-qt executable accept a -usewallet=filename instead of a more descriptive -showwallet=filename or -onlyshowwallet=filename would be that you can specify -usewallet in your bitcoind.conf and have it picked up by both bitcoin-cli and bitcoin-qt.

Show outdated Hide outdated src/bitcoin-cli.cpp Outdated
@jnewbery

This comment has been minimized.

Show comment
Hide comment
@jnewbery

jnewbery Jul 17, 2017

Member

It's a shame that this PR doesn't prevent individual wallet endpoints from accessing server-level RPCs. However that can be added at a later date.

I have a branch here: https://github.com/jnewbery/bitcoin/tree/pr10849 that does a couple of things:

  • fixes #10849 (comment) (in commit bugfix - allow bitcoin-cli to work without -wallet parameter)
  • prevents bitcoin-cli from reading -wallet arguments from the conf file and removes the -usewallet argument. That means that to run a command on a wallet in multiwallet mode, the bitcoin-cli user must specify -wallet on the command line.

Feel free to squash the first commit and cherry-pick the next two if you think they're useful.

Member

jnewbery commented Jul 17, 2017

It's a shame that this PR doesn't prevent individual wallet endpoints from accessing server-level RPCs. However that can be added at a later date.

I have a branch here: https://github.com/jnewbery/bitcoin/tree/pr10849 that does a couple of things:

  • fixes #10849 (comment) (in commit bugfix - allow bitcoin-cli to work without -wallet parameter)
  • prevents bitcoin-cli from reading -wallet arguments from the conf file and removes the -usewallet argument. That means that to run a command on a wallet in multiwallet mode, the bitcoin-cli user must specify -wallet on the command line.

Feel free to squash the first commit and cherry-pick the next two if you think they're useful.

jonasschnelli and others added some commits Jul 13, 2017

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jul 17, 2017

Member

Force push fixed the endpoint issue (thanks @jnewbery).
I think we should keep it minimal with a hope this can slip in before 0.15 freeze.

Fixes can be done later.

Member

jonasschnelli commented Jul 17, 2017

Force push fixed the endpoint issue (thanks @jnewbery).
I think we should keep it minimal with a hope this can slip in before 0.15 freeze.

Fixes can be done later.

@jnewbery

This comment has been minimized.

Show comment
Hide comment
@jnewbery

jnewbery Jul 17, 2017

Member

Fixes can be done later.

Agree. Multiwallet interface should be considered unstable for v0.15.

Member

jnewbery commented Jul 17, 2017

Fixes can be done later.

Agree. Multiwallet interface should be considered unstable for v0.15.

@achow101

This comment has been minimized.

Show comment
Hide comment
@achow101

achow101 Jul 17, 2017

Member

So this will remove the concept of "default wallet" from the RPCs? Any attempt to use a wallet RPC without specifying a wallet will fail, right?

Member

achow101 commented Jul 17, 2017

So this will remove the concept of "default wallet" from the RPCs? Any attempt to use a wallet RPC without specifying a wallet will fail, right?

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jul 17, 2017

Member

@achow101: only if you call a wallet RPC and if you run with multiple wallets.

Member

jonasschnelli commented Jul 17, 2017

@achow101: only if you call a wallet RPC and if you run with multiple wallets.

@achow101

This comment has been minimized.

Show comment
Hide comment
@achow101

achow101 Jul 17, 2017

Member

@jonasschnelli Ok, cool!

utACK 6b9faf7

Member

achow101 commented Jul 17, 2017

@jonasschnelli Ok, cool!

utACK 6b9faf7

super().__init__()
self.setup_clean_chain = True
self.num_nodes = 1
self.extra_args = [['-wallet=w1', '-wallet=w2', '-wallet=w3']]

This comment has been minimized.

@theuni

theuni Jul 17, 2017

Member

Could you change one of these to just 'w' to catch possible length extension bugs? If we're asking for w2, we want to make sure that we don't get w. on accident.

@theuni

theuni Jul 17, 2017

Member

Could you change one of these to just 'w' to catch possible length extension bugs? If we're asking for w2, we want to make sure that we don't get w. on accident.

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Jul 18, 2017

Member

Code review utACK 6b9faf7. No opinion on the endpoint discussion.

Member

theuni commented Jul 18, 2017

Code review utACK 6b9faf7. No opinion on the endpoint discussion.

@sipa

utACK 6b9faf7

I like this endpoints based approach, as it's simple for clients to adopt (just make the URI configurable, which immediately prepares it for future changes that move things to other hosts/ports), and does not force adopting named arguments.

As for not introducing 'v1' or separating off node calls, I think this is fine. Once we do introduce a new API, it'll need more thought about which calls are available where (ideally, reasonable clients only need access to one URI).

endpoint = "/wallet/"+ std::string(encodedURI);
free(encodedURI);
}
else {

This comment has been minimized.

@sipa

sipa Jul 18, 2017

Member

Nit: else on the same line as '}'

@sipa

sipa Jul 18, 2017

Member

Nit: else on the same line as '}'

@MeshCollider

This comment has been minimized.

Show comment
Hide comment
@MeshCollider

MeshCollider Jul 18, 2017

Member

utACK 6b9faf7 looks good to me

Member

MeshCollider commented Jul 18, 2017

utACK 6b9faf7 looks good to me

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Jul 18, 2017

Member

utACK 6b9faf7

However, this badly needs documentation for the user.

Also I am not happy with the fact that passing multiple -usewallet arguments to the commandline results in the last wallet getting used, that should be an error.

Member

morcos commented Jul 18, 2017

utACK 6b9faf7

However, this badly needs documentation for the user.

Also I am not happy with the fact that passing multiple -usewallet arguments to the commandline results in the last wallet getting used, that should be an error.

@laanwj laanwj merged commit 6b9faf7 into bitcoin:master Jul 18, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Jul 18, 2017

Merge #10849: Multiwallet: simplest endpoint support
6b9faf7 [QA] add basic multiwallet test (Jonas Schnelli)
979d0b8 [tests] [wallet] Add wallet endpoint support to authproxy (John Newbery)
76603b1 Select wallet based on the given endpoint (Jonas Schnelli)
32c9710 Fix test_bitcoin circular dependency issue (Jonas Schnelli)
31e0720 Add wallet endpoint support to bitcoin-cli (-usewallet) (Jonas Schnelli)
dd2185c Register wallet endpoint (Jonas Schnelli)

Pull request description:

  Alternative for #10829 and #10650.
  It adds the most simplest form of wallet based endpoint support (`/wallet/<filename>`).
  No v1 and no node/wallet endpoint split.

Tree-SHA512: 23de1fd2f9b48d94682928b582fb6909e16ca507c2ee19e1f989d5a4f3aa706194c4b1fe8854d1d79ba531b7092434239776cae1ae715ff536e829424f59f9be
@jnewbery

This comment has been minimized.

Show comment
Hide comment
@jnewbery

jnewbery Jul 18, 2017

Member

@morcos - does #10868 (for merge after v0.15) resolve your issue with -usewallet?

Suggestions for where to put the documentation? I'm happy to work on that.

Member

jnewbery commented Jul 18, 2017

@morcos - does #10868 (for merge after v0.15) resolve your issue with -usewallet?

Suggestions for where to put the documentation? I'm happy to work on that.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Sep 2, 2017

Member

This is incompatible with RPC batching. :( (you can't batch a /wallets/ request with one which does not use it)

Member

NicolasDorier commented Sep 2, 2017

This is incompatible with RPC batching. :( (you can't batch a /wallets/ request with one which does not use it)

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Sep 2, 2017

Member

Ok disregard my comment. I thought that adding /wallet/w1 to a non wallet RPC method would fail. This is not the case, so no issue!

Member

NicolasDorier commented Sep 2, 2017

Ok disregard my comment. I thought that adding /wallet/w1 to a non wallet RPC method would fail. This is not the case, so no issue!

walletinfo = w1.getwalletinfo()
assert_equal(walletinfo['immature_balance'], 50)
#check w1 wallet balance

This comment has been minimized.

@MarcoFalke

MarcoFalke Nov 10, 2017

Member

nit: w2

@MarcoFalke

MarcoFalke Nov 10, 2017

Member

nit: w2

MarcoFalke added a commit that referenced this pull request Nov 22, 2017

Merge #11743: qa: Add multiwallet prefix test
fa61c6f qa: Add multiwallet prefix test (MarcoFalke)

Pull request description:

  Fixes #10849 (comment)

Tree-SHA512: 7967be04e76d935398b3bea60c864ffc9e38dbb4cfb55890bb146a6f16c28d81ca5d89736275e2d0b03642806f6f7093beeea979f5257c464f437c4e5a9684f1

ftrader pushed a commit to ftrader-bitcoinabc/bitcoin-abc that referenced this pull request Feb 5, 2018

qa: Add multiwallet prefix test
Summary:
Merge #11743: qa: Add multiwallet prefix test

fa61c6f qa: Add multiwallet prefix test (MarcoFalke)

Pull request description:

  Fixes bitcoin/bitcoin#10849 (comment)

Tree-SHA512: 7967be04e76d935398b3bea60c864ffc9e38dbb4cfb55890bb146a6f16c28d81ca5d89736275e2d0b03642806f6f7093beeea979f5257c464f437c4e5a9684f1

Core PR11743

Fixes T177

Test Plan: ./test/functional/test_runner.py multiwallet

Reviewers: #bitcoin_abc, deadalnix

Reviewed By: #bitcoin_abc, deadalnix

Subscribers: teamcity

Maniphest Tasks: T177

Differential Revision: https://reviews.bitcoinabc.org/D1055

@str4d str4d referenced this pull request Aug 4, 2018

Merged

ZIP 32 preparations #3447

zkbot added a commit to zcash/zcash that referenced this pull request Aug 4, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 4, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment