Split off wallet to seperate repository #3882

issue laanwj openend this issue on March 16, 2014
  1. laanwj commented at 12:24 pm on March 16, 2014: member

    Recent events made me realize that we really need to do this. Binding development of the core network infrastructure to development of a wallet gives people the wrong impression.

    Also it gets us all kinds of end user concerns and bike-shedding in this project, which distracts from core infrastructure work.

    What concretely needs to be done here? At least

    1. Factor out parts needed by both the bitcoind and the wallet into a library (basically the current libbitcoin_common + libbitcoin_server).
      • Install .h files and .a/.so files in a way that they can be used by another project
      • Create a new project on github for this library? Or just build it as part of this repository for now?
    2. Create a new project on github under bitcoin, bitcoin-core-wallet, move the wallet specific parts to here (libbitcoin_wallet, wallet specific tests, wallet GUI code). This project uses the aforementioned library.
    3. The wallet should be able to work as SPV client, at least with a trusted bitcoind instance. Headers-first is a move in this direction.
    4. Wallet GUI should be changed to be able to launch a bitcoind process in the background (an option which defaults to on) and stop it when shutting down. This keeps the user experience consistent.
    5. Gitian build / release process should build and ship both projects.

    Some of these steps can be done independently of each other.

    Anything I forgot? Please keep discussion to concrete development.

  2. laanwj added the label Wallet on Mar 16, 2014
  3. laanwj added the label Priority Medium on Mar 16, 2014
  4. leofidus commented at 10:47 pm on March 16, 2014: none
    I agree that completely seperating wallet and network deamon would be a good idea. I think the first step towards that would be an explicit decision whether the wallet should use the network component as a library or via the existing RPC interface. The former would probably faster to develop and may generate a smoother end-user experience, but on the other hand the rpc interface could greatly benefit from being used for the official wallet. Also, if the wallet only communicates via RPC with bitcoind, that would simplyfy dogecoind to only one interface.
  5. int03h commented at 10:54 pm on March 16, 2014: none

    @laanwj RPC articulation . Define standard for interface to daemon (IF not already defined).

    A nice upside would be to pay the “provider” for hosting the daemon properly and providing availability and scalabity. i.e. if you host the files and can propagate a transaction super fast .. cash for timmy. ( this is bonus points ) … ignore if too hard.

  6. int03h commented at 11:01 pm on March 16, 2014: none
    oh .. overall proposal gets a massive +1.
  7. laanwj commented at 7:24 am on March 17, 2014: member
    @leofidus: I assume that it will be possible to use the bitcoind through SPV (so the P2P network) and RPC (for progress queries, and managing). If step 3 is left out, there would be indeed an intermediate phase in which the wallet embeds bitcoind as a library just as it does now. Then only the project layouts would change. @int03h: No changes to RPC interface are needed for this apart from a split. The walletd would implement the wallet side of the RPCs, bitcoind would implement the blockchain/query part of the RPCs. For backward compatibility with clients that assume both are in the same process, the walletd could act as a proxy for those commands.
  8. jmcorgan commented at 5:36 pm on March 17, 2014: contributor
    Agree that splitting these would be good. I’m not clear on the need for a full SPV node implementation, though, for walletd to talk to bitcoind. It seems the RPC interface on bitcoind is only lacking an asynchronous (non-polled) way of delivering notifications of wallet related events to walletd. That could implemented in a variety of ways.
  9. leofidus commented at 5:49 pm on March 17, 2014: none
    If we use the RPC interface, then it should be build out to support everything the wallet needs. That would benefit everyone using bitcoind.
  10. sipa commented at 7:04 pm on March 17, 2014: member

    I don’t believe RPC is the appropriate medium for communication between a P2P node and a wallet. It’s inefficient and synchronous.

    On the other hand, the walletd can just be made an SPV client, which optionally connects to a decidated full node. There is only one feature I know of where the wallet actually needs a full node for, namely the recently added conflict-checking through the mempool. Perhaps some overlay or extension for trusted connections could be added (though I don’t like where that may lead…).

  11. jmcorgan commented at 8:12 pm on March 17, 2014: contributor
    @sipa This is what I was thinking as well. If the walletd will be an actual SPV node, it doesn’t need the bitcoind RPC interface at all. Then it becomes a wallet like any other.
  12. laanwj commented at 9:59 pm on March 17, 2014: member
    @sipa The only reason I mention the RPC interface is for the management part. At least for backwards compatibility of the user experience we want walletd to be able manage a bitcoind instance in the beginning (to ship a wallet+node like now). I was not proposing it as interface between the P2P node and wallet, indeed that would be inefficient.
  13. laanwj commented at 9:11 pm on March 19, 2014: member
    @sipa You’re right though, the mempool-based transaction conflict handling does complicate things. Same for upcoming floating fee computations. It looks like walletd will somehow have to mirror the mempool of the ‘master’ bitcoind (maybe with an RPC to receive an initial mempool and then updates from there?).
  14. sipa commented at 9:25 pm on March 19, 2014: member
    @laanwj It’s functionality that is inherently impossible to do for SPV clients, so it could just be limited to outsourcing the 0-conf validation to a trusted full node. Without trusted full node (i.e., no local one), it would simply be unavailable.
  15. laanwj renamed this:
    Split off wallet to seperate project
    Split off wallet to seperate repository
    on Mar 29, 2014
  16. laanwj closed this on Apr 25, 2017
  17. dcousens commented at 1:25 pm on April 25, 2017: contributor
    Why close?
  18. laanwj commented at 8:21 am on April 26, 2017: member
    It’s more than three year old, and I’m not going to work on this anytime soon.
  19. DrahtBot locked this on Sep 8, 2021


laanwj leofidus int03h jmcorgan sipa dcousens

Labels
Wallet

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-18 21:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me