Walter Stanish [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-15 🗒️ Summary of this message: The proposal to ...
📅 Original date posted:2011-12-15
🗒️ Summary of this message: The proposal to use URIs for Bitcoin addresses lacks the necessary interaction for generating temporary addresses. The IIBAN proposal is open for discussion and modification.
📝 Original message:>> Why don't just...
>>
>> bitcoin://url.without.explicitly.specifying.provider
>> bitcoin://alias@provider
>> bitcoin://IIBAN@authorizedBitcoinInstitution ??
> Andy sounded very convincing when talking in favor of URLs. What's
> wrong with his proposal?
A URI identifies a resource and is in effect an alias itself.
Identifying a resource is different from interacting with it. So,
while <resource-type>://<resource-type-specific-alias> will work
sufficiently for the identification, it does not explain the
interaction.
Interaction is a requirement, since there seems to be a widely felt
need to preserve anonymity through the use of temporary addresses.
Generating a temporary address requires some actual processing to
achieve, since the issuing of the new address cannot be done without
interacting with the entity hosting the wallet (unless I'm missing
something?).
> By the way, I don't like the fact that a single authorized institution
> needs to map the IIBANs to bitcoin addresses.
This is not the case. Please read my earlier response to Gavin and the
IIBAN specification itself to clarify. That would be a total breach
of privacy since the entity would have access to financial information
on all transactions using the IIBAN identifiers... prior to
transactions being executed.
It *is* true that under the current IIBAN proposal there would be one
entity (IANA) in charge of issuing namespace portions ('institution
codes' - probably best to rename these...), however:
- The policy is strict and something similar to 'give one out to
anyone except existing financial instutions with the pre-existing
capacity to issue IBAN'.
- IANA have a pretty reasonable track record
- This suggestion, like the entire proposal, is open for discussion
and modification. If you can think of a more efficient and fair way
of assigning namespace prefixes to random entities on the internet
that doesn't require someone *without* an established track record of
doing this for the internet community to take up IANA's place, then
I'd be happy to hear it. Whilst a bitcoin-like 'community consensus'
system is conceivably possible to deploy in its place, I don't think
it's necessary.
Regards,
Walter Stanish
Payward, Inc.
Published at
2023-06-07 02:47:19Event JSON
{
"id": "6cfc2737f34c9c611a2baddb2c42370c9852f6b513cfe30e715603d01f2f9476",
"pubkey": "77979142f3407f28a5a71956e33342e486ee981e614e0d2ea36ddaf27b8a5a67",
"created_at": 1686106039,
"kind": 1,
"tags": [
[
"e",
"f45e7ca88e6eb3dd1e645e8e3cbb476c5b24e8003cb71eebe205594bb2a4d152",
"",
"root"
],
[
"e",
"95a3425a7c00fe5e8edf68f23c3082e8d72df1b16b7d47f17528acbed3346f8c",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2011-12-15\n🗒️ Summary of this message: The proposal to use URIs for Bitcoin addresses lacks the necessary interaction for generating temporary addresses. The IIBAN proposal is open for discussion and modification.\n📝 Original message:\u003e\u003e Why don't just...\n\u003e\u003e\n\u003e\u003e bitcoin://url.without.explicitly.specifying.provider\n\u003e\u003e bitcoin://alias@provider\n\u003e\u003e bitcoin://IIBAN@authorizedBitcoinInstitution ??\n\n\u003e Andy sounded very convincing when talking in favor of URLs. What's\n\u003e wrong with his proposal?\n\nA URI identifies a resource and is in effect an alias itself.\nIdentifying a resource is different from interacting with it. So,\nwhile \u003cresource-type\u003e://\u003cresource-type-specific-alias\u003e will work\nsufficiently for the identification, it does not explain the\ninteraction.\n\nInteraction is a requirement, since there seems to be a widely felt\nneed to preserve anonymity through the use of temporary addresses.\nGenerating a temporary address requires some actual processing to\nachieve, since the issuing of the new address cannot be done without\ninteracting with the entity hosting the wallet (unless I'm missing\nsomething?).\n\n\u003e By the way, I don't like the fact that a single authorized institution\n\u003e needs to map the IIBANs to bitcoin addresses.\n\nThis is not the case. Please read my earlier response to Gavin and the\nIIBAN specification itself to clarify. That would be a total breach\nof privacy since the entity would have access to financial information\non all transactions using the IIBAN identifiers... prior to\ntransactions being executed.\n\nIt *is* true that under the current IIBAN proposal there would be one\nentity (IANA) in charge of issuing namespace portions ('institution\ncodes' - probably best to rename these...), however:\n - The policy is strict and something similar to 'give one out to\nanyone except existing financial instutions with the pre-existing\ncapacity to issue IBAN'.\n - IANA have a pretty reasonable track record\n - This suggestion, like the entire proposal, is open for discussion\nand modification. If you can think of a more efficient and fair way\nof assigning namespace prefixes to random entities on the internet\nthat doesn't require someone *without* an established track record of\ndoing this for the internet community to take up IANA's place, then\nI'd be happy to hear it. Whilst a bitcoin-like 'community consensus'\nsystem is conceivably possible to deploy in its place, I don't think\nit's necessary.\n\nRegards,\nWalter Stanish\nPayward, Inc.",
"sig": "6776e2b1cdcffbf6e897a9e57f38ac311b3af237890b503241cc99e3e8afb07b3e34346de9de30220c24798a7e052279c71c94d56c50ba495298b7e2a6b29272"
}