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,
s
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
---
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 P
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
BIP32-hierarch
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
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 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 i
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
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
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 ho
On 02.02.2015 15:17, Andreas Schildbach 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
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 BIP
On 02/02/15 13:38, Andreas Schildbach 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?)
> c=123456 for the creation date of the wallet (
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 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=b&c=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 hierarch
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 (S
We generally don't edit BIPs like that after they've been written except to
add helpful links, examples etc and other things that don't add new
functionality. For this you'd write a new BIP. It doesn't have to be hard.
The process is:
1) Adapt the template BIP and fill it out with your motivation,
17 matches
Mail list logo
