Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
which could involve proving something to a third party that has not seen
the communication between payer and payee.
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt of the funds
It's easy to prove what public key it was sent to (it's the preimage), but
you can't prove the parent of that public key. You can provide any number of
ParentPubKey * Multiplier that could have been used, so the 3rd party is
unconvinced by a matching ParentPubKey * Multiplier.
However, if you calculated the destination using: PubKeyParent *
HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
PubKeyParent and Multiplier (or Addend) that produces the destination
address, you've proven the payment is in fact spendable by PubKeyParent, and
they can't deny receipt. Very cool.
Sorry for echoing this back, it took me a little while to work it out, so
I thought I'd write it down. Hope I got it right...
If you give {PubKey, ChainCode} you do get this feature. If you give
{ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
having plausible deniability.
If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
could give HMAC(cpar, i) instead of Addend, and then you would get this
feature; a way to 'skip down' a level in the wallet hierarchy, keep the
'chain of custody' so to speak back to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 18 June 2013 05:48, Alan Reiner etothe...@gmail.com wrote:
*Goal*: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead of
the standard one-use Base58-Hash160 addresses. This allows parties with a
persistent relationship to be able to prove that payment addresses they
provide each other are linked to a particular wallet, reducing exposure to
MitM attacks without the need for SSL or a web of trust, and without
compromising the privacy of either party.For instance, this could be
used between businesses that frequently do business, by exchanging and
verifying public keys beforehand, or could be used by an exchange to
identify if a customer withdrawal address is related to their last deposit
address, and if not enforce extra authentication measures.
*Background**:*
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling it
wallet-linkable addresses, which would be an optional second form for
sending someone your address. With BIP 32, the address is computed by the
payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
|| checksum)
What I'd like to do is have the option, when specifying an address through
the payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]}
and let the receiver of that address compute the address on their own.
This is no significant burden on the receiver, but it does provide the
useful property that they can recognize when addresses specified in this
way come from the same wallet -- because the PubKeyParent will be the
same. Remember, this is *optional* for the person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the chaincode (I think Pieter started
calling it the tweak). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's not
useful to derive any of the other addresses unless they also have the
chaincode. But they can verify that the PublicKeyParent is identical
between transactions, and thus is accessible only to that wallet. It
allows them validate a specific address provided by the payee, but not
generate or identify any other addresses.
*Use Cases:*
(1) So, just like with PGP/GPG, when two parties decide they will start a
relationship, they can start by exchanging the public keys of their wallet
and verify them in a reliable manner. After that, when one party requests
a payment address from the other, they can optionally send {PubKey,
Multiplier}, and the payer's software will identify the owner of that
address, or let you select who you think the address belongs to and it will
verify it. If the payee's system is compromised and address is replaced,
the address received by the payer won't validate. This doesn't help if the
side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will send
money from an address in their wallet and the software will provide the
exchange the {PubKey,Mult}. When the customer later provides a withdrawal
address, the site can automatically trust the address as long it is
provided in the alternate form and the public keys match. If they don't,
it might be the same customer just requesting a withdrawal to a different
wallet, which is fine, but they'll have to go through an extra verification
step to do so.
*Downsides:*
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under the
hood by the software. Instead of providing a 20-byte hash of a script, you
provide all the public keys and multipliers for the individual addresses.
The payer's software automatically verifies all addresses and creates the
P2SH script itself (after a divine decree that public keys will always be
sorted lexicographically in the multi-sig script). The blockchain still
benefits from the compression of moving the bulky scripts to the TxIn,
but it does require revealing more information than is necessary for the
payer to pay the payee. But it may not *really* be a problem, given the
benefits. It might just be slightly longer strings to exchange during
initialization and for each transaction.
I have various reasons I'd like to use this, and it'd be nice to have some
community backing, so I don't have to twist anyone's arm to trust me that
it's legit.
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be less
keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However, there's
little things like it
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be
less keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However,
there's little things like it never actually defines a deterministic
wallet in the Abstract. But, I'll keep trying to understand and see
if I can use the test vectors.
This has nothing to do with the blockchain. This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address. The same thing ends up in the
blockchain, either way.
Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)
I can always give you version #1, and that's what everyone does right
now. Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key).
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote: _*Goal*_: An alternative address format made possible by BIP 32, which allows one to specify a Wallet ID and One-time payment code, instead of the standard one-use Base58-Hash160 addresses. This allows parties with a persistent relationship to be able to prove that payment addresses they provide each other are linked to a particular wallet, reducing exposure to MitM attacks without the need for SSL or a web of trust, and without compromising the privacy of either party.For instance, this could be used between businesses that frequently do business, by exchanging and verifying public keys beforehand, or could be used by an exchange to identify if a customer withdrawal address is related to their last deposit address, and if not enforce extra authentication measures. Have you seen Timo Hanke's pay-to-contract presentation at the San Jose conference? It seems very related: http://www.youtube.com/watch?v=qwyALGlG33Q -- Pieter -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
Goal: An alternative address format made possible by BIP 32, which allows one
to specify a Wallet ID and One-time payment code, instead of the standard
one-use Base58-Hash160 addresses. This allows parties with a persistent
relationship to be able to prove that payment addresses they provide each
other
are linked to a particular wallet, reducing exposure to MitM attacks without
the need for SSL or a web of trust, and without compromising the privacy of
either party.For instance, this could be used between businesses that
frequently do business, by exchanging and verifying public keys beforehand, or
could be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra authentication
measures.
Background:
I haven't been following the payment protocol discussions/development much, so
I apologize if this has already been addressed. I'm calling it
wallet-linkable addresses, which would be an optional second form for
sending
someone your address. With BIP 32, the address is computed by the payee (the
person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
What I'd like to do is have the option, when specifying an address through the
payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]} and let
the receiver of that address compute the address on their own. This is no
significant burden on the receiver, but it does provide the useful property
that they can recognize when addresses specified in this way come from the
same
wallet -- because the PubKeyParent will be the same. Remember, this is
optional for the person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used above
does not actually reveal the chaincode (I think Pieter started calling it
the
tweak). It is derived from the chaincode but doesn't reveal it.
Therefore,
the payer sees the parent public key, but that's not useful to derive any of
the other addresses unless they also have the chaincode. But they can verify
that the PublicKeyParent is identical between transactions, and thus is
accessible only to that wallet. It allows them validate a specific address
provided by the payee, but not generate or identify any other addresses.
Use Cases:
(1) So, just like with PGP/GPG, when two parties decide they will start a
relationship, they can start by exchanging the public keys of their wallet and
verify them in a reliable manner. After that, when one party requests a
payment address from the other, they can optionally send {PubKey, Multiplier},
and the payer's software will identify the owner of that address, or let you
select who you think the address belongs to and it will verify it. If the
payee's system is compromised and address is replaced, the address received by
the payer won't validate. This doesn't help if the side sending the money is
compromised.
(2) When a customer first provides a deposit to an exchange, it will send
money from an address in their wallet and the software will provide the
exchange the {PubKey,Mult}. When the customer later provides a withdrawal
address, the site can automatically trust the address as long it is provided
in
the alternate form and the public keys match. If they don't, it might be the
same customer just requesting a withdrawal to a different wallet, which is
fine, but they'll have to go through an extra verification step to do so.
Downsides:
Multi-sig/P2SH - The only way this works with P2SH, violates one of the goals
of P2SH slightly, but may not matter much if it's all done under the hood by
the software. Instead of
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
This maybe simpler and trivially compatible with existing type2 public keys (ones that are multiples of a parent public key): send an ECDSA signature of the multiplier, and as we know you can compute (recover) the parent public key from an the ECDSA signature made using it. Adam On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote: [q-th root with unknown no discrete log artefact] If it was a concern I guess you could require a proof of knowledge of discrete log. ie as well as public key parent, multiplier the address must include ECDSA sig or Schnorr proof of knowledge (which both demonstrate knowledge of the discrete log of Q to base G.) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 02:36 PM, Adam Back wrote:
This maybe simpler and trivially compatible with existing type2 public
keys
(ones that are multiples of a parent public key): send an ECDSA
signature of
the multiplier, and as we know you can compute (recover) the parent
public
key from an the ECDSA signature made using it.
Adam
On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
[q-th root with unknown no discrete log artefact]
If it was a concern I guess you could require a proof of knowledge of
discrete log. ie as well as public key parent, multiplier the
address must
include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The observer wallet should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
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--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
||
checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to destination, which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same destination.
Depending on what you have in mind that the transaction should prove
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
Correct, for a given PubC in advance you can't create such a malicious
relation to PubB. You can only reversely construct new PubC from given
PubB.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys.
Depends on who is you. The arbitrary person who produces {PubX, Mult}
won't have the private key, but the person who knows the private key for
PubA will have it (assuming that PubB was computed from {PubA, Mult} in
the first place).
In the end, it all depends on your application. What proves enough for
one party doing repeated transactions with another may not suffice for a
third party doing auditing. On the other hand, ambiguity about PubA may
just as well be a wanted feature for deniability reasons.
Timo
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
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 you just described is complimentary to what I am proposing. There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances. 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). And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory.
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts. For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity. If I
don't want that, I use your method. If I do want that, I use my
method. Given its simplicity, I don't know why both can't be options.
Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
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. Also, I'm not sure I follow your point about the 128kB hardware wallet -- it's a signing device, so assuming it's even validating output amounts, at worst it cares about the number of inputs to the outputs being spent, but in many cases you're just handing it a sighash and the BIP32 path (/1/54/27/0) to generate the right private key for signing. The hardware wallet is not actually listening on the P2P network and detecting payments, so it's unaffected by dedicating child-nodes to each contact. Consider the benefits of gaining critical mass of support for a technique which [I think] can be used in all cases, and increases security and privacy for everyone. I think there are huge benefits to leaving the age of 'single address generation' behind us... Thanks, --Jeremy -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
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 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
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.
Initially I was thinking that you would share the public key and chain code
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
value of 'i' for each receive chain.
For the case of generating new receive chains from a *watch-only* wallet, as
you say, the options are to either keep a cache of PubKey/ChainCode for
unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] -- the
concept of 'internal/'external' and change addresses at Depth=2 don't make
sense for handing out receive chains to lots of people anyway, and certainly
BIP32 doesn't *require* 0 = j = 1. So I think incrementing 'j' is the way
to go here...
The default layout of BIP32 does NOT mean that implementations should not
check for transactions with j 1. That would be a useless constraint and
obviously self-limiting. It might be helpful to add to the 'Compatibility'
section some minimum expectations about how a wallet should be 'probed' when
imported. If you don't feel completely free to monotonically increment 'j'
to your hearts content to achieve major usability benefits, then I say BIP32
could use some clarifying.
BTW - the spec calls for addition not multiplication now, so we should call
it the 'Addend' not the 'Multiplier' :-)
Do these extra wallet chains behave as different wallets, or sub-wallets?
They could, but they certainly don't need to! A single-wallet
implementation treats this merely as an address-generation algorithm, and
does not expose any hierarchy to the user interface. The user just
“magically” gets the ability to send multiple payments to their contacts
without immediately sacrificing their privacy
(http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
goes into the same ledger, balance, coin pool, etc. Most of the code base is
unaware BIP32 is even in use.
While it is *possible* to support separate ledgers, balances, etc. it is
certainly not required, and you get all the benefits either way.
I think, since your proposal generates and receives payments into
BIP32-style addresses, we both need similar underlying wallet code. The only
difference is that you are passing the Kpar for [m/i'/0/k] and the *result*
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and
leaving 'k' out of it, letting the receive choose 'k'.
For instance, maybe there's a benefit to using the same parent pubkey
across multiple services, as a form of identity. If I don't want that, I
use your method. If I do want that, I use my method.
I think it's a interesting idea using static public keys as a means for
persistent identity and hence security from MitM. If you want a shared
public key across multiple services we could just combine both ideas and get
all the benefits, by making the data structure { ParentPubKey, Addend,
ChainCode }:
ParentPubKey: Public key of m/i' -- 33 bytes
Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
All that remains secret is the ChainCode from [m/i'] -- and of course the
private keys. The ParentPubKey is a common value across multiple services,
corresponding to user's identity rooted in [m/i']. Each service gets their
own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With the
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
increasing 'k'. Again, from the user perspective all transactions under
[m/i'] can be presented in a single ledger, or not.
Anyway, fundamentally my feedback is if you are designing for persistent
long-term relationships, you could build in a mechanism for generating
address chains so you don't need any further communication after the initial
exchange, and it need not complicate the wallet.
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party.For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.
_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling
it wallet-linkable addresses, which would be an optional second form
for sending someone your address. With BIP 32, the address is computed
by the payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)
What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own. This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same. Remember, this is _optional_ for the
person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the chaincode (I think Pieter started
calling it the tweak). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode. But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet. It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.
*_Use Cases:_*
(1) So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner. After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it. If the payee's system is compromised and address
is replaced, the address received by the payer won't validate. This
doesn't help if the side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}. When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match. If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so.
_*Downsides:*_
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software. Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses. The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script). The blockchain still benefits from the compression of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee. But it
may not /really/ be a problem, given the benefits. It might just be
slightly longer strings to exchange during initialization and for each
transaction.
I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.
-Alan
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
