📅 Original date posted:2013-06-15
📝 Original message:On 11 June 2013 17:29, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
> > For the sake of argument let's say that opaque means that you can tell
> > nothing about the address by examining the characters.
>
> This is true or false based on CONTEXT.
>
> Obviously, an implementation of transaction handling (eg, wallets) needs
> to be
> able to translate addresses to and from what they represent.
>
> On the other hand, things like URI handlers do not (and should not) try to
> interpret the address as anything other than an arbitrary word (\w+).
>
I think this statement may need to be justified.
>
> > My understanding was that they are NOT opaque, and that if that has
> > changed, it will invalidate much at least some wiki page, for examples at
> > least some of the following would now be false:
>
> The wiki goes into much detail on how addresses work, which is not the
> concern
> of most software in the Bitcoin ecosystem, but may be of interest to humans
> and developers working on the one component that operates the "black box"
> that
> addresses are.
>
> > --------
> > <snip>
> > --------
>
> These aren't FALSE, they are "true at the moment, but subject to revision
> by
> newer standards".
>
Got it.
>
> > I also here that there is a LIKELY change from the base58 encoding ...
> when
> > was this established?
>
> I stated (on IRC) that it was likely Bitcoin would change from the base58
> encoding for addresses ... at some unspecified time in the future, to some
> unspecified new encoding that addressed known limitations of base58. What
> those changes will be, or when, are not all established at this time. The
> only
> currently-planned change to addresses (very loosely defined) is inclusion
> of
> the Payment Protocol URIs. But the point is that software developers
> shouldn't
> assume that addresses will remain base58 forever.
>
Does this mean that people should not be investing in "vanity addresses"?
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130615/7197e065/attachment.html>;
Melvin Carvalho [ARCHIVE] /
npub1uv…saxrt
2023-06-07 15:03:18
in reply to nevent1q…j70j
Author Public Key
npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrtPublished at
2023-06-07 15:03:18Event JSON
{
"id": "f3d6254b9d501298187eeed3d64f130614be7555250b4d39ac03843e4fa454b0",
"pubkey": "e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19",
"created_at": 1686150198,
"kind": 1,
"tags": [
[
"e",
"00f0cd0ec6462b49a3551d696bff351453e496031b95df7ebfa12b2f9e5efaae",
"",
"root"
],
[
"e",
"65e6a16e07a337ce5e5fbaed0b637d31aaeab136955ce392e74754ac2afd075f",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2013-06-15\n📝 Original message:On 11 June 2013 17:29, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:\n\u003e \u003e For the sake of argument let's say that opaque means that you can tell\n\u003e \u003e nothing about the address by examining the characters.\n\u003e\n\u003e This is true or false based on CONTEXT.\n\u003e\n\u003e Obviously, an implementation of transaction handling (eg, wallets) needs\n\u003e to be\n\u003e able to translate addresses to and from what they represent.\n\u003e\n\u003e On the other hand, things like URI handlers do not (and should not) try to\n\u003e interpret the address as anything other than an arbitrary word (\\w+).\n\u003e\n\nI think this statement may need to be justified.\n\n\n\u003e\n\u003e \u003e My understanding was that they are NOT opaque, and that if that has\n\u003e \u003e changed, it will invalidate much at least some wiki page, for examples at\n\u003e \u003e least some of the following would now be false:\n\u003e\n\u003e The wiki goes into much detail on how addresses work, which is not the\n\u003e concern\n\u003e of most software in the Bitcoin ecosystem, but may be of interest to humans\n\u003e and developers working on the one component that operates the \"black box\"\n\u003e that\n\u003e addresses are.\n\u003e\n\u003e \u003e --------\n\u003e \u003e \u003csnip\u003e\n\u003e \u003e --------\n\u003e\n\u003e These aren't FALSE, they are \"true at the moment, but subject to revision\n\u003e by\n\u003e newer standards\".\n\u003e\n\nGot it.\n\n\n\u003e\n\u003e \u003e I also here that there is a LIKELY change from the base58 encoding ...\n\u003e when\n\u003e \u003e was this established?\n\u003e\n\u003e I stated (on IRC) that it was likely Bitcoin would change from the base58\n\u003e encoding for addresses ... at some unspecified time in the future, to some\n\u003e unspecified new encoding that addressed known limitations of base58. What\n\u003e those changes will be, or when, are not all established at this time. The\n\u003e only\n\u003e currently-planned change to addresses (very loosely defined) is inclusion\n\u003e of\n\u003e the Payment Protocol URIs. But the point is that software developers\n\u003e shouldn't\n\u003e assume that addresses will remain base58 forever.\n\u003e\n\nDoes this mean that people should not be investing in \"vanity addresses\"?\n\n\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130615/7197e065/attachment.html\u003e",
"sig": "a6019d462282ad953a7a446dc6d55b7132d25db4f490301fbd329e6a1daec9ba636975e9eec8dc010d5185b8c49fc7fd403778a271009d309b5a3e86d48d2d45"
}