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
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
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
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
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
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]) ||
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,
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
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
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 ~
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
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
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
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
14 matches
Mail list logo
