Although I'd still prefer my original request, I get much of what I want
from your guys' recommendation. It complicates the wallet design,
because it requires tracking and associating a matrix of addresses for
each wallet, instead of a single linear list. But if this is what it's
going to take th
On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> 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 know
> 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 Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
> I think Timo's point is that while you cant do discrete log, you can do y-th
> root. So if P = xG is a parent public key (x private key, G base point),
> then your proposed multiplier address is hash of Q=yP. However its easy to
> find
Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose
> 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"
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
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 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 und
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":
> >>Standar
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 multiplie
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 th
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,
I think Timo's point is that while you cant do discrete log, you can do y-th
root. So if P = xG is a parent public key (x private key, G base point),
then your proposed multiplier address is hash of Q=yP. However its easy to
find another P such that Q=zP'. ie just "divide by z" (EC multiply by z
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]) ||
>>
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 out
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 persis
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 fam
On 18 June 2013 05:48, 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
_*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 pro
20 matches
Mail list logo
