Why even bother with the specific HD scheme such as BIP32 or BIP44. What
are the interesting parameters?
Required:
- gap limit
Optional:
- which node of the derivation chain is actually exported (m0' for
BIP32, m44'0'account' for BIP44)
- which subnodes are used for external and
On 02/03/2015 10:33 AM, Levin Keller wrote:
Why not have more descriptive parameters? Saving on data?
Yes. QR codes are very size sensitive.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
On 03/02/15 11:37, Andreas Schildbach wrote:
Not really IMHO. Keys can be used on multiple blockchains.
Ah, correct. Timestamp it is.
Nitpick: They cannot be used on multiple blockchains according to BIP32.
In BIP43 we fixed that. :-)
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
On 02/03/2015 01:22 AM, Pavol Rusnak wrote:
Hm, let me put the questions the other way around:
What gap limit should a wallet use if it encounters h=bip32?
It should follow the spec. I know BIP32-hierarchy is short on gap
limits, which is why (amongst other reasons) I expect
On 02/03/2015 11:10 AM, Pavol Rusnak wrote:
Another option that might make sense is the block number.
Not really IMHO. Keys can be used on multiple blockchains.
--
Dive into the World of Parallel Programming. The Go
On 03/02/15 10:33, Levin Keller wrote:
bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]path=[path in
derivation tree]subchains=[numbers]creationdate=[unixtimestamp]
I cannot come up with an usecase where path parameter would be needed.
FWIW childnumber and depth are already expressed in
On 03/02/15 01:05, Andreas Schildbach wrote:
I don't think that parameterizing will work, we can't predict future
BIPs. It's the same as for BIP43, in the end we agreed on just putting
the BIP number.
Hm, let me put the questions the other way around:
What gap limit should a wallet use if it
On 02/02/2015 03:47 PM, vv01f wrote:
Uff, I would expect MMDD there so it's human readable as well.
Those strings are not meant to be read by humans. MMDD is more
complicated than necessary, given that Bitcoin deals with seconds since
epoch everywhere.
First that is a pitty .. as
On 02/02/2015 03:56 PM, Pavol Rusnak wrote:
To me it seems more important to describe how addresses should be
discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
instead of how the xpub was created/obtained (bip32 vs bip44).
What do you thing about changing ?h=bip32 to
On 02/02/2015 12:33 PM, Mike Hearn wrote:
I looked at what Andreas is doing a few days ago - basically it's just
an xpub string with a ?a=bc=d query string added to the end, with a
hierarchy type specifier and something else I forgot, encoded into a QR
code.
It's h=bip32 for the hierarchy
On 02/02/15 12:33, Mike Hearn wrote:
We generally don't edit BIPs like that after they've been written except to
I think this could end up in BIP43, which deals with hierarchies and is
still in Draft state although widely used. Allocating new BIP seems like
a overkill to me.
--
Best Regards /
On 02/02/2015 01:59 PM, Pavol Rusnak wrote:
It's h=bip32 for the hierarchy used and
Do I understand this correctly and h=bip32 hierarchy means that both
xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44
generated xpubs as well?)
Yes, except that BIP32-hierarchy and BIP44
On Mon, 2 Feb 2015, Levin Keller wrote:
Hello everyone,
I think this is my first email to this mailinglist so I will shortly introduce
myself:
I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin,
mathematician. Bitcoiner since 2011.
And now the reason for this email: Andreas
On 02/02/15 15:17, Andreas Schildbach wrote:
Yes, except that BIP32-hierarchy and BIP44 differ in some requirements
(e.g. gap limit).
Right.
To me it seems more important to describe how addresses should be
discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
instead of how
14 matches
Mail list logo
