Pavol Rusnak [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-03 📝 Original message:On 03/02/15 10:33, Levin ...
📅 Original date posted:2015-02-03
📝 Original message: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 xpub itself.
I like the general idea of "subchains" parameter, but I would like to
further specify it:
a) parameter should contain values described as comma separated
list of values (such as 0,1,2,3,4)
b) consecutive values can be shortened via dash (0,1,2,3 == 0-3)
c) should we allow non-consecutive values (e.g. 0,1,3,8)?
I am not sure. If not the "subchains" param can contain just upper
bound of indexes to scan (e.g. "3")
d) a wallet uses just the first specified chain to generate receiving
addresses, uses the other chains just to add to the balance
OR should a wallet be able to generate receiving address for second,
third, etc. external chain? if yes, we should split "subchains" param
into "external" and "internal" params both containing a list of
numbers. this seems like an overkill to me and I am fine with using
just the first chain as the external one.
> Why not have more descriptive parameters? Saving on data?
Yes. The longer the string, the bigger the QR code.
> I am a big fan of unix timestamps. Would vote for Andreas' format on the
> creation date.
I am not against Unix timestamps, I just said I expected something else
there. Unix timestamps have a lot of advantages. Another option that
might make sense is the block number.
--
Best Regards / S pozdravom,
Pavol Rusnak <stick at gk2.sk>
📝 Original message: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 xpub itself.
I like the general idea of "subchains" parameter, but I would like to
further specify it:
a) parameter should contain values described as comma separated
list of values (such as 0,1,2,3,4)
b) consecutive values can be shortened via dash (0,1,2,3 == 0-3)
c) should we allow non-consecutive values (e.g. 0,1,3,8)?
I am not sure. If not the "subchains" param can contain just upper
bound of indexes to scan (e.g. "3")
d) a wallet uses just the first specified chain to generate receiving
addresses, uses the other chains just to add to the balance
OR should a wallet be able to generate receiving address for second,
third, etc. external chain? if yes, we should split "subchains" param
into "external" and "internal" params both containing a list of
numbers. this seems like an overkill to me and I am fine with using
just the first chain as the external one.
> Why not have more descriptive parameters? Saving on data?
Yes. The longer the string, the bigger the QR code.
> I am a big fan of unix timestamps. Would vote for Andreas' format on the
> creation date.
I am not against Unix timestamps, I just said I expected something else
there. Unix timestamps have a lot of advantages. Another option that
might make sense is the block number.
--
Best Regards / S pozdravom,
Pavol Rusnak <stick at gk2.sk>