<unnamed>

Public Key

npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55c

Profile Code

nprofile1qqs809u3gte5qleg5kn3j4hrxdpwfphwnq0xznsd963kmkhj0w995ecpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqd85cxw

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 10:41:16 UTC

- reply

📅 Original date posted:2012-11-28
📝 Original message:> RE: the ifex-project and other electronic invoicing standards: Thanks
> for the pointers, Walter! I'm all for adopting the best ideas that
> have come before, as long as we end up with something useful and small
> enough to convince ourselves it is as secure as we can make it.
Fair enough, although I would posit:
0. You can't get more secure than not doing it at all.
1. Small is sometimes beautiful, but sometimes just the 999th
crippled and half-featured attempt at a nontrivial problem space
(...linked heavily to implementation-time assumptions and/or specific
peer systems, and by its very nature destined for the dustbin of time?
Well, maybe. Eventually, we all are.)
2. X.509 is not small (or beautiful, unless one is some weird new
kind of centralized cryptographic trust fetishist, of some sort you
might see with furrowed brows, boozing at midday sporting key & anchor
tattoos in old convention polo-shirts, mumbling to themselves about
the employee-motivation benefits of single sign-on...)
> looked at the ifex spec, and quickly got lost. It would help me if you
> could write up what our motivating use cases would look like if
> implemented on top of ifex.
Yes. Understandable. Thoughts around an IFEX protocol proposal, unlike
the other proposals, are still drafty (err...as a coastal verandah?)
and not the clearest. However, we have much research and progress has
been achieved in the odd year-or-so since beginning. The fundamental
concerns of such a protocol (regarding the establishment of neutral,
open and technically-viable proposals for internet-wide
currency/commodity, market and financial endpoint identification) have
already been reasonably met.
This has opened the door to the potential for faster progress on the
IFEX protocol itself ("a mechanism for the identification,
negotiation, description, execution and management of financial
transactions over their lifetime"), like, right about now. Which is
kind of the same zone of potential functionality (at least in a naive,
linguistic comparison sense) that people are talking about here.
Because of the hope to garner more interest from the Bitcoin community
with this post (do read on!), I spent a bunch of hours today cleaning
up and converting the IFEX Protocol's current breezy-draft form back
from the wiki formatting it had been lazing and grazing (and growing,
albeit slowly) in for the greater part of the year and moving to
Github (forks and issues very much encouraged) over here:
https://github.com/globalcitizen/ifex-protocol
(Discussion list at http://group.ifex-project.org/ actually has
quite a few members at present, despite appearances to the contrary)
> implemented on top of ifex.
Re: "implemented on top of ifex", this is kind of opposite to how IFEX works.
IFEX's idea is to provide a flexible yet stable protocol that lets
individual (potential, ongoing, or completed) transactions on
arbitrary (legacy, conventional, emerging, or future) settlement
systems (in arbitrary currencies/commodities) to be described and
facilitated (executed, routed, monitored, etc.) in real time, by
describing accurately the objective properties of each of those
systems and components.
So, for example, an end user, requiring a transfer of <x> of <y>
currency/commodity from 'point a' to 'point b' would find routes to
achieve that, evaluate them in terms of monetary and temporal
overheads against their own trust and risk models plus any legal,
privacy or other requirements in order to select and effect the most
appropriate manner of settlement.
In short, IFEX sees Bitcoin as having such-and-such properties,
matches that to a need to transfer some funds, and effects the
transfer, monitoring and/or reporting on its state in a normalized
fashion throughout its lifetime.
I'll try again to describe the motivating use case:
==============
Recognising that Bitcoin is not the only emerging financial community
or settlement system facing real world business integration
challenges, and recognising the significant complexity of these in
common situations (multi-hop transactions, arbitrary currency
transactions, foreign exchange automation, liquidity guarantee
challenges, settlement latency negotiation, invoicing periods,
commercial payment or shipping terms, sovereign (exchange rate
fluctuation) and other forms of risk management, potentially
simultaneous multi-level fee, tax and discount requirements,
product/service coding, line items, complex tax calculations
(particularly in the US, and which may be based on both buyer and
seller geolocation), legal requirements to include various metadata,
etc.), instead of investing valuable developer time on internal
implementation (and subsequent maintenance) of a tightly-scoped
(==crippled?) business-level protocol extension to Bitcoin that can be
perhaps fairly characterised as unlikely to quickly evolve to meet
many of these real world requirements, and with as yet unclear real
world demand for such from the Bitcoin community, who must already
overcome significant complexity hurdles to use Bitcoin at all, Bitcoin
developers can instead simply declare this "out of scope" (win!) and
focus on Bitcoin's current roles as a digital commodity and settlement
system.
This approach to scope limitation has excellent historical support
from the unix community - "do one thing and do it well". Bitcoin
already does a few things, notably in its triple roles as
network-community, currency-like-commodity, and settlement system.
The alternative is that instead of creating load for the Bitcoin
developers, who may be ill-equipped and ill-resourced to properly
tackle these peripheral requirements, interested parties instead
contribute to projects like IFEX that view systems such as Bitcoin as
core use cases but are not limited by Bitcoin developer time or
project trajectory, and promise re-usability for other conventional,
emerging and future currencies/commodities/settlement systems, thus
retaining the capacity to attract interest and resources from those
communities (and broader, internet-centric interest groups and
infrastructure) toward a common goal, while creating a valuable shared
platform for interoperability between Bitcoin and those other systems
(including legacy financial systems) that allows Bitcoin to
objectively showcase its strengths.
Net result: Bitcoin developers can focus on Bitcoin. Meanwhile,
business level integration things completely tangential to the core
bitcoin codebase get done with a far broader scope and applicability,
providing a broader community and potential resource base for moving
things forward, and presenting a less "shifting-sands" approach to
potential implementers (who are safe in the knowledge that their now
standardized infrastructure can support a wide range of
currencies/commodities, settlement systems, financial network
topologies settlement paradigms, and will not critically rely upon any
given component system as a single point of failure). Bitcoin, through
the platform IFEX develops, gets to compete at the business level on a
fair and even basis with legacy and other emerging systems based upon
its highly desirable objective properties (speed, reach, low
overheads, rapid connection, lack of wacky X.509 certificate
purchasing requirements... yet, etc.), such that a business case *not*
to use it in various commercial settings becomes difficult to field.
Everyone wins.
==============
Note that the above basically echoes much of the (less verbose? more
digestible?) information available at http://ifex-project.org/ where -
along with http://tools.ietf.org/ - the full text of existing
proposals are also available, but attempts to do so in a more specific
fashion for Bitcoin developer community.
Considering the above, and that a single system is never going to meet
every person's needs all of the time (yes, even Bitcoin!), I really
hope that the Bitcoin developer community will see the benefits of
supporting an external rather than internal solution to business level
(or at least non directly settlement-facilitating) financial
transaction requirements, both for the Bitcoin project itself, its
users, and for that broader and longer-term goal (in very much the
same spirit) of effecting some sorely-needed, socially positive and
lasting change in global financial systems. Nothing can be all things
to all people (especially X.509, which can be completely different
kinds of pain to all who come in to contact with it) - but at least
with an open, platform neutral financial transaction oriented protocol
outside of individual settlement system, currency and commodity
projects, each new system can stand on its own merit and support the
others, deriving shared fruits of increased user base, usability and
liquidity through heterogeneous interoperability.
Sincerely, hoping to work together with interested parties to move
forward in this area (come issue/fork the github repo!), and with the
utmost respect for all of the valuable work of the Bitcoin community
(though scratching my head a bit on the lack of an April 1 date or
punchline for this X.509 stuff!!), and, and, out of breath,
Walter Stanish

2023-06-07 10:40:45 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:>> We are not establishing an IETF working group, which is an option that
>> was explored prior to the Paris meeting and has been sidelined at
>> present for depth-of-bureaucracy by the backing commercial entities.
>> Rather, we are establishing a top-level IANA registry group. This is
>> not anticipated by the IETF old-guard working with us to be either (a)
>> controversial or (b) possible to block.
>
> My last note in this sub-thread.
Mine too!
> There are no IANA registry groups, there is no such thing, and no way
> to form one.
Reading between the lines, I believe this phrase, which is not my own
but that of experienced IETF staff, refers to the groups visible at
http://www.iana.org/protocols/ (which you yourself cited). Whether it
is formally used or not is unknown to me.
> The IETF can ask the IANA to form a registry but these
> things take lots of support and take a long time,
Expert opinion estimates six weeks, and by current estimates, we
should have an arrival circa February.
> and these are only
> created through standards track RFC. ICANN runs the IANA and there is
> no such framework that you elude to. Review
> http://www.iana.org/protocols/
I would like to suggest that perhaps exactly this sort of banter is an
excellent illustration for the Bitcoin community of what we have been
up against in this (conceivable simple an public benefit oriented)
endeavour. If you also look at the fact that the ISO4217 registry (to
take currency/commodity codes as just one example) there is apparently
not even a public list of requirements for codepoint issue. This sort
of thing is *exactly* why the internet community appears to
desperately need an open registry - allowing public internet bodies
(IANA) to function to support innovation and interconnectivity for all
sectors of the internet's various financial communities so that
anyone, including innovators, can obtain interoperability via simple,
hassle-free paths, without encountering self-important bureaucrats.
We anticipate victory circa February.
- Walter

2023-06-07 10:40:38 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:>> We are currently working with IETF staff, with open offers of support
>> from multiple well funded commercial bodies, to transition these
>> proposals through to IANA management.
>
> I hate to inform you that you have been mislead. The IETF and the IANA
> do not operate as you outlined above. Having spent too many years
> within ICANN/IETF/IANA I can assure you are mistaken.
> Your drafts are expired and it appears that there is no support for a
> "finance" working group in the IETF.
We are not establishing an IETF working group, which is an option that
was explored prior to the Paris meeting and has been sidelined at
present for depth-of-bureaucracy by the backing commercial entities.
Rather, we are establishing a top-level IANA registry group. This is
not anticipated by the IETF old-guard working with us to be either (a)
controversial or (b) possible to block.
- Walter

2023-06-07 10:40:32 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:>> X-ISO4217-A3
>
> I see that draft-stanish-x-iso4217-a3 is not standards track, is there
> a reason for this?
Of the three currently published proposals, all are essentially IANA
registry proposals.
We are currently working with IETF staff, with open offers of support
from multiple well funded commercial bodies, to transition these
proposals through to IANA management.
It appears that the Independent Stream Editor path will be used to
transition these through to IANA, at which time the proposals
themselves will be converted to Informational status.
(As far as I understand right now, Within the IETF, Standards Track
has special meaning and entails relatively large degrees of
bureaucracy that are not within the current contributors' resources.
It is also worth pointing out that many popular protocols implemented
on the majority of systems (IIRC, such as IMAP) never reach formal
standardization for this reason. It should be noted that in these
cases, this does not make the protocols any less attractive as
potential components for system implementation.)
> It also doesn't appear to address ~any of the the targeted items here.
> Is there another draft I should be looking for which has more overlap
> with the discussion here?
As outlined in the previous post:
- Internet Financial EXchange (IFEX). A proposal under development
that facilitates the negotiation of financial transactions between
internet-based financial endpoints. (The area we would love your
input) http://www.ifex-project.org/our-proposals/ifex
As well as the information linked to above, significant but not
particularly well grounded discussions have occurred regarding the
IFEX-based paradigm for settlement versus some other proposed
paradigms, in particular Ripple (as it appeared some months ago),
which can be read here:
https://groups.google.com/forum/?fromgroups#!topic/rippleusers/v4bEBZZVEsA[1-25]
Kind regards and with the hopes of combining our efforts as a joint
proposal that can benefit other currencies/commodities and settlement
systems as well as Bitcoin,
Walter Stanish
Skype:walter.stanish

2023-06-07 10:40:25 UTC

- reply

📅 Original date posted:2012-11-27
📝 Original message:> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
I agree this is a very pertinent subject, and with a bit of looking
around it is clear that there is a requirement here for emerging
financial ecosystems of many types, certainly not just for the Bitcoin
community, which until now seems to have been getting along just about
OK despite the current levels of complexity.
That said, I have a number of serious concerns with the proposal.
1. Undue Broadening of Scope: From an architectural perspective, if
one accepts the unix mantra of "do one thing and do it well" as
reasonable and time-proven doctrine, given that Bitcoin is already
trying to be both a commodity and a distributed consensus-based
settlement system, does it really make sense to attempt to tack-on
business-level functions?
2. X.509: I have read (somewhere or other, recently) that it is
generally considered bad form to mandate specific cryptographic
systems in new protocols where open support is possible. Given the
recent issues with X.509, the security nightmare that already exists
with the volume of (sometimes cracked, sometimes
government-compromised?) issuers, and the complexity of the scheme, it
seems a little strange to singularly mandate X.509, despite its
widespread use at present. There are also a swathe of potential
issues around DNS interdependence, information leakage within
certificates themselves and/or their DNS-interpretation by clients,
etc. I would consider suggesting open support with initial support for
GPG, as it is apparently preferred as a simple and further
decentralized solution by the majority of the open source and
cryptographic software development community.
3. Failure to Review Existing Work: I would urge anyone to be wary of
adopting any proposal that does not inform itself through reference to
existing protocols in the same area. In this area there are a few
protocols in current use (chiefly in Europe) such as those listed at
http://en.wikipedia.org/wiki/Invoice#Electronic_invoices as well as
various hosted platforms such as http://xero.co.nz/ (chiefly
Australia/New Zealand). Often, existing work shows its age with
after-the-fact alterations that sit poorly with initial assumptions:
exactly the kind of situation one can walk in to developing against a
proposal before adequately researching the area.
4. Complexity of Metadata: Physical and digital invoicing for
businesses operating at scale often requires delivery terms, product
classification codes, locale-specific taxation (often at multiple
levels), various fees and discounts (sometimes fulfillment-speed
linked with multiple tiers/thresholds), and other features that I am
skeptical are ever going to be made fully available within a business
protocol tacked on to a hybrid digital currency/settlement system
(like Bitcoin) as a secondary concern.
5. Non-BTC Currencies/Currency-like Commodities: No approach to
non-BTC currencies appears to have been made, which makes the
"invoice" of limited utility for almost all businesses, save those
willing to accept all of the 'capital risk' (exchange rate fluctuation
risk) inherent in a BTC-based fulfilment process with a potential term
long enough to justify an invoicing process. (Does this narrow scope
actually cover any existing business?)
6. DNS: As already mentioned with regards to X.509: a huge red flag as
an area of potential vulnerability, or at least information leakage.
I must now admit that in raising the above I am definitely biased. My
employer (Payward, Inc.) and other organizations (OpenCoin, Inc.,
etc.) have been working with the Internet Engineering Task Force
(IETF) on tabling some open proposals within this area under the
auspices of the Internet Financial Exchange Project
(http://ifex-project.org/). Our hope is to facilitate the requisite
standardisation within internet-connected systems to deal with what is
perhaps fairly characterised as a relatively heterogeneous outlook on
the rise of cryptographic (and other alternate) currencies and
commodities, and emerging settlement infrastructures.
Whilst the current Bitcoin proposal is admirable for correctly raising
the area as one of immediate concern, I hope that the above points out
some of the perhaps as-yet unconsidered complexities and draws in to
question whether Bitcoin is in fact the appropriate place to implement
a solution, given the hassles that will entail. After all, wouldn't
Bitcoin developer time would be better spent improving the core of
bitcoin (ie. distributed settlement system and commodity) rather than
adding new features?
I would invite parties within the Bitcoin community with an interest
in non directly settlement-linked financial transaction negotiation
and reporting features to consider contributing to the existing,
re-usable efforts at the IFEX Project, rather than supporting the
extension of one currency/commodity and settlement infrastructure (ie.
Bitcoin) which IMHO is likely to detract from developer time, increase
complexity, and perhaps result in a less polished and re-applicable
solution overall.
Our proposals:
- X-ISO4217-A3 (X-ISO4217-A3). A published proposal that provides a
mechanism for the open identification of currencies or currency-like
commodities on the internet. (Bitcoin is registered as XBTC).
http://www.ifex-project.org/our-proposals/x-iso4217-a3
- Internet IBAN (IIBAN). A published proposal that provides a
mechanism for the open identification of financial endpoints on the
internet. (IBAN compatible, checksum-included, name-squatting problem
avoiding. The registry of entities is IANA-managed, encourages GPG
use, and avoids the X.509 requirement.)
http://www.ifex-project.org/our-proposals/iiban
- Internet MIC (IMIC). A published proposal that provides a mechanism
for the open identification of financial markets on the internet.
(Such as most Bitcoin exchanges)
http://www.ifex-project.org/our-proposals/imic
- Internet Financial EXchange (IFEX). A proposal under development
that facilitates the negotiation of financial transactions between
internet-based financial endpoints. (The area we would love your
input) http://www.ifex-project.org/our-proposals/ifex
Sincerely and with the utmost respect for the Bitcoin project's excellent work,
Walter Stanish

2023-06-07 10:04:41 UTC

- reply

📅 Original date posted:2012-04-13
📝 Original message:The Internet Financial EXchange (IFEX) Project is an open body for the
discussion and development of financial standards for the internet
community. The project seeks to focus on enhancing interoperability
between financial settlement systems of all types, including
conventional financial systems, emerging digital currencies,
alternative financial communities, and financial service providers.
Interested parties are invited to review the proposals on the website
at http://www.ifex-project.org/ and join the mailing list at
http://group.ifex-project.org/
Two items on the site that may be of particular interest:
(1) The latest version of the IIBAN Proposal (v1) for financial
endpoint identification at
http://www.ifex-project.org/our-proposals/iiban. This latest version
includes initial IANA registry contents and a reference mechanism for
financial endpoint transcription error correction. (Relevance: In
contrast to settlement system-specific financial endpoint identifiers,
IIBAN provides a democratically allocated, 13 character identifier
that is already familiar in format to users in Europe and other
countries and is theoretically compatible with conventional banking
infrastructure in those regions. In addition, IIBAN is not tied to
any specific financial commodity or settlement system, and provides
strong protection against identifier transcription errors.)
(2) The IFEX Protocol is a *work in progress* that hopes to bridge the
gap between conventional financial systems, emerging digital
currencies, alternative financial communities, and financial service
providers by providing a standard protocol for transaction and
settlement path negotiation with arbitrary financial instruments,
currencies or assets. (Relevance: better connectivity, lower
settlement fees, real time redundant financial routing, arbitrary
instrument/currency/asset handling)
How IFEX's proposed infrastructure differs from existing projects:
- Not a currency, not a settlement-network, but a mechanism for bridging them.
- Broader and more inclusive scope than existing vendor-specific APIs
and conventional finance industry networking protocols. Global focus.
No legacy 'features'. No artificial barriers to innovators.
The hope is to move towards an open source implementation of the (work
in progress) IFEX protocol that interoperates with major and emerging
settlement networks for the benefit of all parts of the community. We
have already had expressions of interest from representatives in a
range of communities (Bitcoin, CES, Ripple, W3C Web Payments, digital
currency exchange developers, etc.), and look forward your input on
the mailing list.
Happy Friday the 13th!
Regards,
Walter Stanish
The IFEX Project
http://www.ifex-project.org/

2023-06-07 02:48:39 UTC

- reply

📅 Original date posted:2011-12-14
🗒️ Summary of this message: Alias systems for Bitcoin addresses should not be mandated by the network. IIBAN proposes large numbers of parties to register as institutions within the registry.
📝 Original message:> Nifty! Thanks for the pointers, I think we should avoid reinventing
> wheels whenever possible.
Hear hear!
> When composing my last response in this thread I wrote, and then erased:
>
> "There doesn't have to be one solution: I'd like to see some
> experimentation, with clients supporting different schemes for bitcoin
> address aliases, and maybe supporting plugins to extend the schemes
> supported (a plugin would take a string, do some
> behind-the-scenes-magic, and return a bitcoin address or public key)."
Sure. Alias systems are a usability focused requirement and as such
should probably not be mandated by the network itself, anyway.
> Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts",
> seems like a forward-thinking idea, although I'm not clear on exactly
> how those 2.2billion "accounts" would get allocated and mapped into
> bitcoin addresses.
It seems a clarification is in order, apologies for not being clearer.
Under the IIBAN scheme, whilst Bitcoin *could* define some default
mechanism for automatically creating IIBANs that map to Bitcoin
addresses (for example, Bitcoin client authors could provide hosted
lookup), this was not the style of integration in mind while writing
the IIBAN draft.
Rather than simply defining Bitcoin as a single 'institution'
(namespace segment) within the IIBAN standard, Payward Inc. envisages
large numbers of parties (including individuals or small groups of
individuals) operating individual Bitcoin-related (or LETS, or other
alternate currency) services to register as institutions (really just
'namespace holders') within the IIBAN registry. Each such party may
then define its own mapping system between Bitcoin, LETS, or other
alternate currency financial endpoints that it 'manages' (proxies for)
and IIBAN, within its namespace. As detailed within the IIBAN
proposal, this process could be peer to peer or centralized,
supporting one time or short-term use addresses as well as permanent
addresses. A permanent address within IIBAN could map via the
institution managing that portion of the IIBAN address space to a
single use address on the Bitcoin network.
Institutions are important for the following reasons (from
http://tools.ietf.org/html/draft-iiban-00#section-4.3.2):
With the advent of decentralized virtual currencies such as [BITCOIN]
the conventional idea of a financial institution (such as a bank) may
be seen by some as somewhat superfluous. However, the notion remains
useful:
* Conventional currencies will not disappear in the conceivable
future, so the notion of financial institutions is expected
to endure at least as providers of currency exchange and holding
services.
* Systems such as [BITCOIN] have quirks that require slightly
delayed settlement due to the nature of their decentralized,
consensus-based approach to fiscal transfer. Users requiring
instant settlement MAY thus see benefit in the use of a
centralized proxy system or organization as an instantaneous
financial settlement provider (the 'institution').
* IANA MAY delegate management of portions of the IIBAN name space
through such institutions.
Furthermore from http://tools.ietf.org/html/draft-iiban-00#section-4.3.1:
[Under IIBAN's combined issue paradigm] proxied issue is
facilitated through IANA managed institution registration, provision
for two types of privately issued addresses is reserved within this
document, and registered institutions COULD provide DHT or similar
mechanisms for the management of their delegated name space. The
combined issue paradigm offers adequate provision for both
manageability and decentralization, whilst maintaining heterogeneity.
So the idea is that many institutions each provide mappings between
IIBAN and Bitcoin, in a range of ways, and we do not see the emergence
of a single mandated standard. There is no suggestion that Bitcoin
developers should implement a hard-coded mechanism.
> I imagine some central organization that maps IIBAN account numbers to
> domain names... and then clients (or plugins in the clients) query
> that trusted central organization and then the account holder's domain
> to get a (possibly unique) public key or bitcoin address.
This style of solution - in which a central organization becomes aware
of every single IIBAN-based transaction in the network - is not
necessary or desirable. Instead, under the IIBAN recommendation IANA
would publish the registry of IIBAN institutions for everyone to use
without the need to query any party.
In the case of a financial transfer, a client or peer instutition
seeking to send funds to an IIBAN-denominated address would use some
hitherto-underfined mechanism* for translating the appropriate entry
within that registry (corresponding to the transfer's destination
address) to some kind of internet node representing the institution's
systems.
* This mechanism may necessitate the storage of public keys within the
IIBAN institution registry and will be addressed within the next
version of the IIBAN draft. Community input is encouraged.
In a second yet-to-be-define protocol**, various settlement-system
neutral (ie: not specific to Bitcoin, LETS, or any other system)
transaction-related metadata would then be exchanged, prior to any
actual transaction. Such metadata could include aspects of the
transaction such as description, financial system endpoint ('account')
holder name, account exists verification, settlement path negotiation
(based upon feasibility, transaction overheads, latency, etc.), which
party is to pay overheads, information mandated by local jurisdiction
such as business tax numbers (required in some countries of Europe, I
believe, for domestic B2B settlements), etc.
** This mechanism does need to be defined, and Payward Inc. has
completed a not insubstantial amount of research in to existing
protocols and concerns within this area, which touches upon high
frequency automated banking, financial market support, and interbank
settlement policy. An additional Internet Draft proposing one such
potential mechanism will probably be published 'soon'.
At the conclusion of this metadata exchange, the two nodes would have
either aborted the transaction, suspended it to seek human input (such
as settlement path selection based upon fee and latency metadata
garnered), or agreed upon financial settlement system specific
information to use in executing the transaction itself, likely out of
band. In the case of Bitcoin, this *might* include information such as
the blockcount after which the transaction will be considered settled
by the receiving institution, an effective 'gentleman's agreement' on
the terms of any opt-in notion of reversibility, a one time Bitcoin
address provided by the recipient institution for the sender to make a
Bitcoin transaction to, etc.
>From the perspective of a settlement system such as Bitcoin, IIBAN's
provision of settlement system neutral financial endpoint
identification provides the benefits outlined in the previous email,
as well as the possibility to publish a permanent, fixed address
without disclosing one's corresponding Bitcoin-derived income. From
the broader perspective of effective financial system innovation, it
hopes to provide a common basis upon which many such systems can
conceivably interoperate, regardless of their underlying systemic
differences.
> As long as IIBANs are not the ONLY way of aliasing bitcoin addresses
> to more-human-friendly strings I think that would be a fine way to do
> it.
Thank you for your vote of confidence.
Regards,
Walter Stanish
Payward Inc.

2023-06-07 02:48:29 UTC

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: IIBAN, an Internet Standards Draft, proposes a solution for translating human-readable addresses into Bitcoin addresses, with mature error detection and a fixed length.
📝 Original message:Interesting thread.
Given the following paragraph and the limited feedback garnered upon
its announcement to this list last month, I couldn't help but chime in
again to mention IIBAN, an Internet Standards Draft available at
http://tools.ietf.org/html/draft-iiban-00 (A related proposal for
internet connected financial market identification, IMIC, is also
available: http://tools.ietf.org/html/draft-imic-00) which - fair
declaration of bias - I authored on behalf of my employer, Payward
Inc., while working on Bitcoin-related development.
> I think the scope of this BIP is not so well defined right now. We need a
> way for merchants to translate a human readable, and more importantly
> human-writeable, address into a bitcoin address.
I believe that IIBAN solves this problem fairly elegantly:
(1) Mature transposition error detection (think "Oops, that's a zero
not an 'oh'! I wrote it wrong!"). This functions via checksum digits
using a known algorithm, leveraging decades of experience in
conventional financial institutions. The same functionality provides
for simple suggested error correction on common transposition errors
(0->O, 1->I, etc.).
(2) Fixed length.
(3) Far shorter than both bitcoin addresses and many national bank
account numbers at 13 characters (less than half of the size of a
bitcoin address).
(4) Fewer characters (no lowercase), resulting in less transposition
issues and greater legibility.
(5) Superset-compatible with existing financial networks utilizing the
IBAN standard (mandated in Europe, increasingly popular elsewhere),
resulting in greater ease of uptake.
(5) Centralized, delegatable namespace allocation but with clear rules
governing allocation that aim to minimize potential room for any
potential abuse of power.
(6) Settlement system neutral - ie: not bitcoin-centric. By leaving
Bitcoin to be Bitcoin, Bitcoin developers can focus on core concerns
rather than becoming embroiled in formatting and user experience
concerns. Also, a single address could be paid via multiple channels
(conventional financial systems, bitcoin, LETS systems, etc.)
resulting in greater ease of uptake and higher user confidence over
time since published banking information is no longer held hostage to
the assumed longevity, liquidity, legality or other liabilities of an
individual settlement system (such as Bitcoin).
(7) Provides defined private address spaces for internal transfers
(eg: within an organization's own systems, for financial simulations,
MMORPGs, etc.) and a documentation/public works of fiction address
space to address common usage concerns in similar network addressing
schemes.
(8) Heterogeneous management of different parts of the address space.
Whilst the proposed IANA (Internet Assigned Numbers Authority)
management of IIBAN's initial institution namespace is indeed
centralized and will no doubt raise eyebrows from within parts of the
community for that reason alone, the IIBAN draft is liberal in its
assignment policy, which can be viewed within the draft document
linked to above, and whose terms are binding for IANA. It's also
worth noting that four of the most similar global systems deployed
today, SWIFT's BIC and IBAN, the ITU's E.164 international telephone
numbering scheme and IANA's IP address space management are
implemented as similar centralized-but-delegated style schemes.
Furthermore, due to the flat nature of the registry, a
http://convergence.io/ style 'trust agility' model (ie: multiple
'centralized' parties share their network view, and user-prioritized
source consensus/acceptance/approval determine end-user perspective)
is wholly compatible.
In closing, a quick mention that a new version of the IIBAN draft will
be released very shortly including a draft IIBAN institutions registry
that will be established in order to facilitate implementation and
testing. Drop me an email if you'd like a portion of the address space
and your early assignment will appear within that draft.
Regards,
Walter Stanish
Payward, Inc.

2023-06-07 02:47:31 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Temporary addresses require interaction with wallet hosts for issuance. Options include static addresses, hosted wallets, or recipient-provided addresses managed by the server. Instant settlement may require a centralized proxy system.
📝 Original message:>> 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?).
>
> I thought the interaction was just the server answering with an
> address (maybe also amount and other details). But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.
Sure, but this falls short of requirements for most users.
> -The servers stores the recipient private keys and generates a new one
> for each payment.
Equivalent to hosted wallet, which is decentralization in a BIG way,
but apparently a very popular choice (for pragmatic reasons).
Probably not going away.
> -The server stores a set of addresses provided by the recipient and it
> manages what address it gives in each request (like in the web service
> I told you I can't find).
True. However, probably a poor user experience for most users re:
provision of temporary addresses to the alias host. Also the
knowledge of which entity for which inbound payment has been allocated
which temporary address would be a significant complexity in the alias
host / end user relationship that you gloss over. This is important
for businesses, since inbound payments are only really possible to
track - AFAIK (correct me if I'm wrong, the two exceptions being the
edge case of people requesting inbound transactions where every single
transaction is of a unique amount and no 'partial payment' (2x
transactions for one inbound payment) and the case where every single
inbound payer's sending address is previously known) - by issuing
unique recipient addresses to each client. In short, it's kind of
similar to hosted wallet as well, since you need to absolutely trust
your host (they could tell people wishing to make payments to you to
pay someone else instead!).
> IANA reserves some namespace for bitcoin. All right.
> The problem comes later.
> "
> * Systems such as [BITCOIN] have quirks that require slightly
> delayed settlement due to the nature of their decentralized,
> consensus-based approach to fiscal transfer. Users requiring
> instant settlement MAY thus see benefit in the use of a
> centralized proxy system or organization as an instantaneous
> financial settlement provider (the 'institution').
> "
> As I understand it (probably I'm wrong, because I haven't read the
> whole IIBAN draft) there would be a "bitcoin institution" that would
> map bitcoin addresses to the bitcoin subspace of the IIBAN.
Many people can get namespace management rights as
'institutions' (in the current draft's terminology), then manage
the assignement of IIBANs within that space as they wish.
There would be many institutions with many IIBANs. The
association of a bitcoin address (or many addresses, or
the capacity to generate temporary addresses as required)
with an IIBAN would be the responsibility of either that
namespace manager ('institution') or the individual who
has acquired that IIBAN via that namespace manager
('insitution').
> " * IANA MAY delegate management of portions of the IIBAN name space
> through such institutions."
>
> If we can find a deterministic method to map the subspace the all
> possible bitcoin addresses, everything's fine again. But if that's not
> possible, we would need a central institution to manage the mapping
> and that would be a step back in decentralization.
Many institutions, many policies, no absolute centralization, though
admittedly increased centralization. However, this is a problem shared
with two of your proposals (the subset not disqualified as failing to
meet most user's requirements) when you consider that most users (if
you consider 'the whole world's mobile devices' a potential userbase,
as I prefer to do) do not have the technical skills to configure,
secure and manage their own 'always on' alias service hosts, nor the
capacity to host blockchain copies on those devices (either due to
space or bandwidth requirements. As an aside, this is a large part of
the unfortunate reality that is tending to push Bitcoin towards hosted
wallet solutions)
> I can't find the answer of Gavin's question "How is the mapping done?"
> in your post. I'll re-read it though.
Near the top, beginning "It seems a clarification is in order,
apologies for not being clearer." (Re-reading, it's still not that
clear!)
Regards,
Walter Stanish
Payward, Inc.

2023-06-07 02:47:19 UTC

- reply

📅 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.

2023-06-07 02:47:06 UTC

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: HTTP is easier to set up than DNS for dynamically responding with addresses. Third-party hosted services are more likely to provide aliasing resolution. Additional functionality could be added during the pre-transaction exchange process.
📝 Original message:>> Just so we're clear, what is the need for HTTP at all?
>> A query for a string and an answer can all be handled via DNS.
> It is a lot easier to set up an HTTP server to dynamically respond
> with addresses than a DNS record.
Interesting that you bring up the effort factor.
The notion that every individual will want to run their own DNS or
HTTP based alias system to dispense transaction-specific bitcoin
addresses seems - on this basis - alone a little far fetched. Such a
system would provide very little added value at significant hassle to
the small subset of users who could be bothered setting up such a
scheme. Also, remember that most people in the world don't even know
what DNS is, nor do they have the capacity or motivation to set up a
program on a web server for what amounts to minor ongoing time savings
and some vanity thrills.
To my mind, it is far more likely that third party hosted services
(such as providers of hosted wallet, conventional currency holding and
exchange services) will provide aliasing resolution, and that these
alias resolution services will operate on an alias at provider mechanism
(for example, IIBAN and its 'institution' codes @ ).
In addition, during the 'pre-transaction exchange' that the alias
resolution process essentially represents, additional value could be
added by these types of service providers by providing functionality
presently excluded from Bitcoin but relevant to real world financial
systems. For example this 'pre-transaction exchange' process might
include, in addition to alias resolution, transaction metadata
exchange (transaction description, invoice/order number, taxation
information, schedules of fees and charges, pre-arranged currency
exchange rates if filling an payment for an amount quoted in another
(eg: conventional) currency, shipping terms, transaction reversal
(cancellation) terms, escrow terms, etc.)
Regards,
Walter Stanish
Payward Inc.

2023-06-07 02:43:25 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Bitcoin needs to maintain its decentralized feature, but people want alternate representations of bitcoin addresses. Blockchain bloat is an issue, and an extra-blockchain aliasing system must prioritize usability and absolute security. Arbitrary aliases are not in use in mature financial systems, and checksum systems detect transposition errors.
📝 Original message:> Bitcoin itself is decentralised by design, in my opinion it seems obvious
> that it needs to continue to maintain this feature.
What's the real issue?
- People want to use alternate representations ('aliases') of bitcoin
addresses, for various reasons.
- The blockchain is the only way to create distributed consensus
within the bitcoin network.
- Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
- Some people want throw-away (single use) aliases, others want
permanent ones. This means many addresses.
- Blockchain bloat is already acknowledged as an issue.
- The blockchain is not really a good option.
Leaving out the blockchain, there are still ways to implement aliasing.
What is the core problem for an extra-blockchain aliasing system?
At the core is usability - people basically want aliases to make it
easier to type in or remember addresses. So a solution that
sacrifices usability too far is a broken one.
Another requirement is absolute security. A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default) of getting it back if it's sent somewhere wrong by
accident'. Such an accident might be mistyping an alias. It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.). As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.
So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.
First, arbitrary aliases are not in use. This means that memory-based
mnemonics are not subject to predictable squatting-style attacks. For
our purposes, this means that if you are payments at business1.com, I
can't go and register payments at busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address. Likewise, if you're 'someuser at hostedwalletservice.com' I
can't go and register as 'someuse at hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.
Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks. IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!) With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.
Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction. This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties. Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason. However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)
Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users. Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
the case of IIBAN which is not specific to any given currency, the
need to register, recall and manage yet another account identifier),
which was one of the original goals. None of the other proposals
mentioned have this property.
I won't go in to other benefits previously mentioned of the IIBAN
proposal, but I still cannot see any reason to either:
- Include aliasing within bitcoind itself
- Re-invent the wheel
- Scare off non-technical users
- Dodge the fact that there are unique properties of bitcoin that
will always remain and should perhaps simply be acknowledged and
worked around OUTSIDE of the codebase, rather than within.
Unix/internet philosophy is that it's usually best to keep code as
simple as possible, to 'do one thing' and 'do it well'. For bitcoind
(despite sharing a codebase with the GUI), that something is achieving
a distributed internet-based financial system that is free from legacy
centralized currencies. It is *not* worrying about making it look
pretty or easy to use, which can be achieved by layering totally
external systems through simply translating various alternate
representations ('aliases') to the well defined bitcoin addressing
scheme.
Just to avoid any notion of table-banging (Hah! A lost cause?), this
will be the last IIBAN-related post I will make on this thread, but
there will be some further announcements in the near future.
Keep up the good work everyone.
Regards,
Walter Stanish
Payward Inc.