From: "Jeremy Spilman" <jeremy@taplink•co>
To: "Bitcoin Dev" <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Wed, 19 Jun 2013 12:29:19 -0700 [thread overview]
Message-ID: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR> (raw)
[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]
If you have two parties who want to form a persistent relationship, by exchanging and verifying public keys beforehand, then I think the canonical way to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual multipliers, if what you desire is a persistent relationship. If each party dedicates a child-wallet for receiving coins, and saves a PubKey/ChainCode for sending coins, the two parties can transaction securely forever without ever exchanging any more information, and without any address reuse.
I think ideally, the default behavior is that wallets always dedicate a new child node {PubKey, ChainCode} to each party they transact with. At the presentation layer, you have a “contact” and each contact has a transaction history. You can send coins to a contact at any time, and internally the wallet picks the next address in their sequence. Any funds received on pubkeys from contact’s sequence are attributed to that contact. The wallet can organize the contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’ however they want – it could be based on the underlying BIP32 hierarchy or perhaps not. The cost of watching large a number of pubkeys, even if you ‘look ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.
What might be nice is a ‘Contact Request’ protocol, basically the same as a PaymentRequest but no actual payments are sent, just child wallets created:
message Contact {
optional uint32 contact_version = 1 [default = 1];
optional string pki_type = 2 [default = "none"];
optional bytes pki_data = 3;
required bytes serialized_contact_details = 4;
optional bytes signature = 5;
}
message ContactDetails {
optional string network = 1 [default = "main"];
required bytes pubkey = 2;
required bytes chaincode = 3;
optional string memo = 4;
optional string response_url = 5;
}
Alice sends a Contact+ContactDetails to Bob. If Bob accepts, he sends his own Contact+ContactDetails (without a response_url) back to Alice. Basically just like adding a contact to your IM contacts.
Alice could send a Contact+ContactDetails to Bob without a response_url, in which case after accepting the contact, Bob could send funds to Alice, but not receive funds.
You could probably pack the whole message inside a bitcoin:// URI if you wanted to.
Thanks,
--Jeremy
[-- Attachment #2: Type: text/html, Size: 3617 bytes --]
next reply other threads:[~2013-06-19 19:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 19:29 Jeremy Spilman [this message]
2013-06-19 20:10 ` Alan Reiner
2013-06-19 21:58 ` Jeremy Spilman
2013-06-19 22:47 ` Alan Reiner
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=5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR \
--to=jeremy@taplink$(echo .)co \
--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