public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Wed, 19 Jun 2013 18:47:22 -0400	[thread overview]
Message-ID: <51C234FA.5030909@gmail.com> (raw)
In-Reply-To: <53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
> Hi Alan,
>
>> “BIP 32 does not prescribe a way to use multiple chains like you described 
>> with the convenient type-2 derivation (though we could create a variant 
>> that does)”
> What do you think is missing from BIP32 for this? A wallet creates a 
> child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, 
> and then generally expects transactions to come in starting at /0 and 
> incrementing monotonically.
>


You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting.  I
disagree.  I am okay with using different wallets for different parties
*/if the user wants to/*.  But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services.  And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.

BIP 32 already specifies how to use the first three tree levels: 
M/i/j/k, i~wallet, j~Internal/External, k~address.  The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet.  So it's not
"free" to create new wallets unless we redefine how the levels work. 
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
 
-- Do these extra wallet chains behave as different wallets, or
sub-wallets? 
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism?  Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.

All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet.  With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity.  If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets.  But it's not the only way.

To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications. 

-Alan

[-- Attachment #2: Type: text/html, Size: 3339 bytes --]

  reply	other threads:[~2013-06-19 22:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 19:29 Jeremy Spilman
2013-06-19 20:10 ` Alan Reiner
2013-06-19 21:58   ` Jeremy Spilman
2013-06-19 22:47     ` Alan Reiner [this message]
2013-06-20  3:54       ` Jeremy Spilman
2013-06-20  7:32         ` Mike Hearn
2013-06-26 15:29           ` Alan Reiner
2013-08-09 17:57             ` [Bitcoin-development] Optional "wallet-linkable" address format (Re-request) Alan Reiner
2013-08-09 19:58               ` Mike Hearn
2013-08-09 20:12                 ` Alan Reiner
2013-08-09 20:35                   ` Mike Hearn
2013-08-09 21:51               ` Gavin Andresen
  -- strict thread matches above, loose matches on Subject: below --
2013-06-18  3:48 [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol Alan Reiner
2013-06-19 12:19 ` Melvin Carvalho
2013-06-19 13:37   ` Alan Reiner
2013-06-19 13:54 ` Pieter Wuille
2013-06-19 14:25 ` Timo Hanke
2013-06-19 14:39   ` Alan Reiner
2013-06-19 15:28     ` Adam Back
2013-06-19 18:36       ` Adam Back
2013-06-19 19:00         ` Alan Reiner
2013-06-20  7:48       ` Timo Hanke
2013-06-20  9:10         ` Jeremy Spilman
2013-06-20 16:09           ` Alan Reiner
2013-06-19 20:03     ` Timo Hanke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51C234FA.5030909@gmail.com \
    --to=etotheipi@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox