📅 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>
Pavol Rusnak [ARCHIVE] /
npub1wc…3hnuq
2023-06-07 15:29:27
in reply to nevent1q…ufhk
Author Public Key
npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuqPublished at
2023-06-07 15:29:27Event JSON
{
"id": "4225bb8085e923d74296f834a6878b50567d50cb6d1f5f06fdab0fc671869882",
"pubkey": "7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63",
"created_at": 1686151767,
"kind": 1,
"tags": [
[
"e",
"da5dfa7015ad7eb23fb699400b79b743db94aa85c8d6df42489b5ad471f64cea",
"",
"root"
],
[
"e",
"e6e682c92fdb6aa04ec344609d78836051a57ecad1d5086393a95f795115ac64",
"",
"reply"
],
[
"p",
"a45b2071acb27d4e292ae549d3ac8f24f003e25f0c5145990646328e2236f5b9"
]
],
"content": "📅 Original date posted:2015-02-03\n📝 Original message:On 03/02/15 10:33, Levin Keller wrote:\n\u003e bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]\u0026path=[path in\n\u003e derivation tree]\u0026subchains=[numbers]\u0026creationdate=[unixtimestamp]\n\nI cannot come up with an usecase where \"path\" parameter would be needed.\nFWIW childnumber and depth are already expressed in xpub itself.\n\nI like the general idea of \"subchains\" parameter, but I would like to\nfurther specify it:\n\na) parameter should contain values described as comma separated\n list of values (such as 0,1,2,3,4)\n\nb) consecutive values can be shortened via dash (0,1,2,3 == 0-3)\n\nc) should we allow non-consecutive values (e.g. 0,1,3,8)?\n I am not sure. If not the \"subchains\" param can contain just upper\n bound of indexes to scan (e.g. \"3\")\n\nd) a wallet uses just the first specified chain to generate receiving\n addresses, uses the other chains just to add to the balance\n\n OR should a wallet be able to generate receiving address for second,\n third, etc. external chain? if yes, we should split \"subchains\" param\n into \"external\" and \"internal\" params both containing a list of\n numbers. this seems like an overkill to me and I am fine with using\n just the first chain as the external one.\n\n\u003e Why not have more descriptive parameters? Saving on data?\n\nYes. The longer the string, the bigger the QR code.\n\n\u003e I am a big fan of unix timestamps. Would vote for Andreas' format on the\n\u003e creation date.\n\nI am not against Unix timestamps, I just said I expected something else\nthere. Unix timestamps have a lot of advantages. Another option that\nmight make sense is the block number.\n\n-- \nBest Regards / S pozdravom,\n\nPavol Rusnak \u003cstick at gk2.sk\u003e",
"sig": "8a2c0cfd2e4113f6da1e5134af2940ccb90d98c7912d92256bfba2b9aa6feee9892c6dbfffc8aafb45f1b137d6e8cf848a07cb9ce22610bae432d6d38fcfec37"
}