--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agile-banking?hl=en.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
Presumably the human-readable part would be one of the properties of the contract. (Along with currency symbol, terms and conditions, redemption and liability, public keys, etc.)
When the wallet (or server) software loads the contract, it hashes the contract to determine the contract ID. It also loads the display name out of the contract to list on the screen for the user. In this way, you also guarantee a few things: 1) The ID will always be unique. 2) The ID will be consistent across all servers. 3) Changing the contract automatically changes the ID. (Software should always hash the contract to verify the ID, and also verify the signature on the contract using the public key inside of it.) 4) No need for a central "DNS server" for looking up the IDs based on the names. 5) No ability for attacker to substitute a different contract. This is not my idea btw, although I have incorporated it into Open Transactions. (The "Ricardian Contract" was invented by Ian Grigg.) -FT
> No need for a central "DNS server" for looking up the IDs based on
> the names.
Ok, but what about the reverse: given an asset ID, how do I locate the contract? or it this irrelevant in the OT world?
G
G
--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
> A contract would more often (and practically speaking) be related to an
> underlying commercial provider. I don't think it needs to be part of the
> core transaction, but is part of the discovery process instead.
>
> P
>
> On Mon, Aug 23, 2010 at 1:49 PM, Guillaume P. Lebleu
> <guil...@lebleu.org <mailto:guil...@lebleu.org>> wrote:
>
>
> On Aug 23, 2010, at 3:50 AM, Fellow Traveler wrote:
>
> > No need for a central "DNS server" for looking up the IDs based on
> > the names.
>
> Ok, but what about the reverse: given an asset ID, how do I locate
> the contract? or it this irrelevant in the OT world?
>
> G
Mr. Braendgaard is correct, IMO.
Presumably if you are transacting in a certain currency, then you have
already seen the contract, no? Or at least you have a good incentive to
have already seen it. This is true NO MATTER HOW you generate the
currency ID, whether it uses a message digest or a lookup server or
whatever.
In that case, where did you GET the contract in the first place?
The first, best place to get it is from the issuer himself. Maybe it's posted
on his website (it's signed.) So Open Transactions assumes first of all that
the primary source of the contract is the issuer himself.
You can STILL get the contract from a trusted 3rd party, via a DNS-style
lookup. While this sort of lookup is not necessary for OT to operate, it
IS necessary in the case of a REVERSE-lookup (as you describe.)
Assuming OT comes into regular use, more likely: aggregater websites
will appear, tracking the various currency contracts and providing
search functionality over them, just as torrent tracker sites operate
now for torrents. (There's no risk of forgery in these cases since the contract
is signed and self-authenticating.)
People are also free to try to keep certain contracts secret -- the system
operates fine without having to list them on any tracker site. But there's
nothing stopping people from putting up tracker sites, either. This is similar
to Loom I think.
-FT
Looking at this again, this does bear emphasis; amounts should be some
sort of integer or rational type and this should be strictly enforced.
I once had the displeasure of working with a large CRM/ERP package
that used floating point for amounts, leading to many obvious bugs
wherever equality was being checked, and others. People who should
have known better did not get this right on their own.
This seems to me to be an implementation issue, not a protocol issue.
If the payment message says the amount is "43.234", then that's
well-defined. It's up to the implementation to decode it as a proper
decimal type and not floating point. I'm not sure insisting on
integer amounts only would make it any easier for the implementer who
has to deal with decimal amounts in the user interface.
I guess the desire to operate on integers only boils down to limiting
the number of digits permissible after the decimal point, since once
that's defined, any implementation can convert to integers if need be.
It might be useful to define this limit anyways, since
implementations shouldn't be expected to handle potentially
unlimited-length numbers. The limit should be fairly high though,
since some people might want to transact penny-value amounts in
kilograms of gold, for example, requiring something like 10 decimal
digits at least.
Interesting question.
Ryan
> --
> You received this message because you are subscribed to the Google Groups "agile-banking" group.
> To post to this group, send email to agile-...@googlegroups.com.
> To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
The currency contract should define the smallest (sub)unit available to use, and the implementation should enforce that in this unit, only integers are used. One way is to define the typical unit (ex. dollar) and the precision used in the currency contract (ex. 2 for cents). This is what I believe Trubanc does.
Currency contract aside, it's not a protocol/interface issue, I agree.
Guillaume
PKTP is guilty of floating point messiness, but it seemed the best
compromise. Internally floats are used storing grams of metal, with
user transacting in units from mg to kg, troy ounces or penny
weights. If it becomes a practical problem I will revisit it.
cya, Andrew...
A com.bankofamerica.usd is somethingentirely different than a gov.fed.usd and there should be mechanism on
the design level that makes such things transparent.
law to mean "unit of paper issued by the FED" so that today it's a
"unit of digital bookkeeping that the issuing bank claims it can
exchange for units of thin air issued by the FED" :)
--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
On Wed, Aug 25, 2010 at 06:39, David Nicol <david...@gmail.com> wrote:
...
--
You received this message because you are subscribed to the Google Groups "agile-banking" group.
To post to this group, send email to agile-...@googlegroups.com.
To unsubscribe from this group, send email to agile-bankin...@googlegroups.com.
Reserve requirements apply only to transaction accounts, which are components of M1, a narrowly defined measure of money. Deposits that are components of M2 and M3 (but not M1), such as savings accounts and time deposits, have no reserve requirements and therefore can expand without regard to reserve levels. Furthermore, the Federal Reserve operates in a way that permits banks to acquire the reserves they need to meet their requirements from the money market, so long as they are willing to pay the prevailing price (the federal funds rate) for borrowed reserves. Consequently, reserve requirements currently play a relatively limited role in money creation in the United States. [http://www.newyorkfed.org/aboutthefed/fedpoint/fed45.html]
Yikes.
I liked the "debt is money" cartoon