Bitcoin Forum
December 08, 2016, 04:30:40 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: New, standardized wallet protocol  (Read 2298 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
February 23, 2011, 12:41:35 AM
 #1

I am proposing the bitcoin development community work together on creating a specification for a new wallet-access protocol. The present bitcoind JSON-RPC has numerous problems (primarily polling requirements and precision issues) which make it unsuitable for efficient usage in a client.

Please feel free to edit https://en.bitcoin.it/wiki/Wallet_protocol

The first task, IMO, should be to define requirements for the protocol. Once those are relatively stable, we can begin on actual specification of the protocol constructs.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481171440
Hero Member
*
Offline Offline

Posts: 1481171440

View Profile Personal Message (Offline)

Ignore
1481171440
Reply with quote  #2

1481171440
Report to moderator
1481171440
Hero Member
*
Offline Offline

Posts: 1481171440

View Profile Personal Message (Offline)

Ignore
1481171440
Reply with quote  #2

1481171440
Report to moderator
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 03, 2011, 03:37:52 PM
 #2

So what's your proposal? I'm willing to get behind this. Show us the code.
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 03, 2011, 03:39:47 PM
 #3

Does DBUS work on Windows or Mac?

It's the default used in all Linux desktops. It's a mature, battle-hardened protocol.

http://www.freedesktop.org/wiki/Software/dbus
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 03, 2011, 04:10:23 PM
 #4

I'm confused. At first I thought this was a discussion for a new wallet. Do you want to replace JSON-RPC, or essentially create a new client, broken into pieces?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 03, 2011, 04:40:39 PM
 #5

So what's your proposal? I'm willing to get behind this. Show us the code.
The goal is to create a proposal. What requirements does the development community have for such a protocol?
Does DBUS work on Windows or Mac?

It's the default used in all Linux desktops. It's a mature, battle-hardened protocol.

http://www.freedesktop.org/wiki/Software/dbus
AFAIK, DBUS only works on *nix, and is desktop-only and local-only, so would be a problem running Wallet on a server, and UI on a phone... correct me if I'm wrong.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 03, 2011, 04:41:29 PM
 #6

I'm confused. At first I thought this was a discussion for a new wallet. Do you want to replace JSON-RPC, or essentially create a new client, broken into pieces?
The current JSON-RPC needs to be replaced (this thread), before splitting the client (or creating a split one) is even possible.

genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 03, 2011, 05:00:51 PM
 #7

The current JSON-RPC needs to be replaced (this thread), before splitting the client (or creating a split one) is even possible.

Yeah well I haven't been too happy at the response. I was told: "let us know what needs to be done to make a client wrapper possible. everything should be possible through the RPC".

- Need initialisation flag. Submit patch. Patch ignored. Workaround hack (that doesn't even work for all cases) proposed instead.
- Not able to import bitcoin RPC values into Python. Propose I write my own JSON RPC lib because Python's implementation is wrong.
- Propose consistent naming scheme for JSON-RPC Api. WONTFIX. Better to leave the inconsistent usage of getblaa or doaction because it's not a problem now.

I mean wtf. Come on.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
March 03, 2011, 06:10:02 PM
 #8

- Propose consistent naming scheme for JSON-RPC Api. WONTFIX. Better to leave the inconsistent usage of getblaa or doaction because it's not a problem now.

I gotta agree with them on that one. Any time you change an API, you mess up people who are using the old API, so you end up having to support both APIs for a long time, which clutters up your software.

Of course we all like the APIs to be tidy, consistent, and easy-to-use. But the time to fix that is when a new API is being written anyway because of some other pressing need.

Refactoring an API for purely aesthetic reasons is rarely worth it.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 04, 2011, 01:18:21 AM
 #9

But the time to fix that is when a new API is being written anyway because of some other pressing need.
Like right now, in this thread... :p

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
March 21, 2011, 08:27:47 PM
 #10

I would appreciate any comments/critiques on https://en.bitcoin.it/wiki/Wallet_protocol#DRAFT_0

Jim Hyslop
Member
**
Offline Offline

Activity: 98


View Profile
March 21, 2011, 11:33:56 PM
 #11

I am proposing the bitcoin development community work together on creating a specification for a new wallet-access protocol.
I'm not sure I agree. I think, at the moment at least, Bitcoin should focus on the creating and exchanging of bitcoins. The wallet is a client-specific item. How you manage your Bitcoins is very much an individual choice. How you pass the bitcoins from one person to another is (and must be) commonly agreed upon by the Bitcoin protocol.

In general, though, I've found it better to first define what you want to do, then define the protocol to accomplish what you want to do. So, what do you want to do with the wallet? Obviously, first and foremost is to accept and spend coins.

Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
sirius
Bitcoiner
Staff
Sr. Member
****
Offline Offline

Activity: 429



View Profile
April 19, 2011, 11:22:19 AM
 #12

In general, though, I've found it better to first define what you want to do, then define the protocol to accomplish what you want to do. So, what do you want to do with the wallet? Obviously, first and foremost is to accept and spend coins.

The idea is that you can store the wallet anywhere and use it through a lightweight terminal, without connecting to the network. For example you could choose to store your coins at mybitcoin.com or your own server. Then you could use them with a Firefox extension or an Android UI.

I think it would be easiest to go with the current JSON-RPC stuff and automatically enable it, or at least add it to the options menu. Well planned is not done.

Identifi - Decentralized address book with trust ratings
I'm not a forum admin - please contact theymos instead.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 19, 2011, 03:54:04 PM
 #13

In general, though, I've found it better to first define what you want to do, then define the protocol to accomplish what you want to do. So, what do you want to do with the wallet? Obviously, first and foremost is to accept and spend coins.

The idea is that you can store the wallet anywhere and use it through a lightweight terminal, without connecting to the network. For example you could choose to store your coins at mybitcoin.com or your own server. Then you could use them with a Firefox extension or an Android UI.

I think it would be easiest to go with the current JSON-RPC stuff and automatically enable it, or at least add it to the options menu. Well planned is not done.
Except that JSON-RPC is utterly unusable to implement any kind of real client. Check out the ugly hacks in Spesmilo and js-remote that only workaround part of the problem.

xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 19, 2011, 04:36:46 PM
 #14

Except that JSON-RPC is utterly unusable to implement any kind of real client.

Can you be more specific?  Sounds like vague handwaving.

BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 19, 2011, 04:40:24 PM
 #15

Except that JSON-RPC is utterly unusable to implement any kind of real client.

Can you be more specific?  Sounds like vague handwaving.

Genjix mentioned some things, but they don't seem to be showstoppers...

Yeah well I haven't been too happy at the response. I was told: "let us know what needs to be done to make a client wrapper possible. everything should be possible through the RPC".

- Need initialisation flag. Submit patch. Patch ignored. Workaround hack (that doesn't even work for all cases) proposed instead. Bitcoin issue
- Not able to import bitcoin RPC values into Python. Propose I write my own JSON RPC lib because Python's implementation is wrong. Python issue
- Propose consistent naming scheme for JSON-RPC Api. WONTFIX. Better to leave the inconsistent usage of getblaa or doaction because it's not a problem now. not an issue

I mean wtf. Come on.
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
April 19, 2011, 06:24:24 PM
 #16

So what's your proposal? I'm willing to get behind this. Show us the code.

I think it's good to let actual needs drive evolution, but that doesn't mean it's not worthwhile in soliciting ideas/requirements if you're about to undertake work like this (but, I do think it would be better, for someone that is so inclined, to collect some input/feedback...and then go write some code and let the code be the specification...I wouldn't agitate too much about getting the specification agreed upon by a large number of people in advance).

So, here's my feedback...first, here's a "user story" I would like it to support:
"As a user, I would like to have very tight control over the handling of my private keys"
    - to support this story, I think you need to boil down the private key handling to the very basic methods that require the use of unencrypted private keys...I think this is basically the creation of new keys (for receiving payments) and the creation of spend transactions (is there anything else?) ...I envision a very simple module (with a very small amount of easily comprehensible code...perhaps in a very readable language other than C++) that supports an API to a) instantiate a set of key pairs from a serialized form (where the private keys are encrypted), b) request the creation of a new key pair, c) request the creation of a transaction, d) request to serialize the public portion of all key pairs e) request to serialize all key pairs (with private keys encrypted)  ...additionally, the key pairs might include a small bit of meta info (like a description of the key as the current client supports) ...an implementation of this very small API would allow for someone to run a very small and trusted bit of code that is used to maintain the privacy and integrity of their keys (about the only UI that module would require is a password prompt used for the encryption of the private keys), while at the same time allowing the rest of the system to manage physical storage and backup of the encrypted keys and create the full wallet GUI (showing a balance, a send bitcoin UI, a transaction listing, an address book, etc).  ... few additional APIs to let the components work with keys individually might also be useful

I would be very interested in a solution that utilized 0mq+protocolbuffers for this.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 19, 2011, 08:28:49 PM
 #17

Except that JSON-RPC is utterly unusable to implement any kind of real client.
Can you be more specific?  Sounds like vague handwaving.
Read the wiki page that talks about requirements. The biggest problem is that JSON-RPC requires polling.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!