Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2013-06-11 📝 Original message:On Tuesday, June 11, 2013 ...
📅 Original date posted:2013-06-11
📝 Original message: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+).
> 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".
> 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.
Luke
Published at
2023-06-07 15:03:18Event JSON
{
"id": "65e6a16e07a337ce5e5fbaed0b637d31aaeab136955ce392e74754ac2afd075f",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686150198,
"kind": 1,
"tags": [
[
"e",
"00f0cd0ec6462b49a3551d696bff351453e496031b95df7ebfa12b2f9e5efaae",
"",
"root"
],
[
"e",
"63585e2e35ff1d6b513f5e2825197ace274d634eb26e59d8d9f043bad9f43113",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-06-11\n📝 Original message:On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:\n\u003e For the sake of argument let's say that opaque means that you can tell\n\u003e nothing about the address by examining the characters.\n\nThis is true or false based on CONTEXT.\n\nObviously, an implementation of transaction handling (eg, wallets) needs to be \nable to translate addresses to and from what they represent.\n\nOn the other hand, things like URI handlers do not (and should not) try to \ninterpret the address as anything other than an arbitrary word (\\w+).\n\n\u003e My understanding was that they are NOT opaque, and that if that has\n\u003e changed, it will invalidate much at least some wiki page, for examples at\n\u003e least some of the following would now be false:\n\nThe wiki goes into much detail on how addresses work, which is not the concern \nof most software in the Bitcoin ecosystem, but may be of interest to humans \nand developers working on the one component that operates the \"black box\" that \naddresses are.\n\n\u003e --------\n\u003e \u003csnip\u003e\n\u003e --------\n\nThese aren't FALSE, they are \"true at the moment, but subject to revision by \nnewer standards\".\n\n\u003e I also here that there is a LIKELY change from the base58 encoding ... when\n\u003e was this established?\n\nI stated (on IRC) that it was likely Bitcoin would change from the base58 \nencoding for addresses ... at some unspecified time in the future, to some \nunspecified new encoding that addressed known limitations of base58. What \nthose changes will be, or when, are not all established at this time. The only \ncurrently-planned change to addresses (very loosely defined) is inclusion of \nthe Payment Protocol URIs. But the point is that software developers shouldn't \nassume that addresses will remain base58 forever.\n\nLuke",
"sig": "6cf81378f6a3c856fcf8c51b4413876681fc4f661555e84c6b234aac997124fd68ba44a9fb3cc619419fd0913048e01ee25119e833d43e6849482e7b31a1f4e1"
}