Incorporation of the Bank of Tantalus and New Britannian Stock Exchange

You are going around in a circle Shares are not ledgers but then you make my point for me - they are NOT creating a ledger or just a way of tracking transactions they are creating a way to MAKE money without having money Shares.

 

I was never arguing against you

 

1. Yes, of course! It is just a .txt file.
2. Yes, you can see the creator's name on the object. If you look at picture 2 above, look at my inventory where my cursor is over the book. The pop-up box shows my name in yellow.

That's cool. Didn't know this idea was gaining traction within so many different groups.

As always I encourage people to review my thread in the dev+ area. It would make sense for some sort of "standard" to emerge. I think that would allow for greater interaction across the community. https://www.shroudoftheavatar.com/forum/index.php?threads/r12-testing-books-as-contracts.16732/

Having the two numbers that you suggest is a nice idea. I hadn't considered it quite like that. I have considered numbering, just not in the way you suggested, but your idea is good food for thought (more testing needed!).

From how I read your post I think it is actually the same idea (roughly) as having the two tokens (two books) that I presented for my idea "Tradeable Secure Certificates of Deposit"(these had the additional security that if they are lost due to PVP the money is still safe). I've mentioned having a public spreadsheet (read only, ofc!) such that people can verify the contract they own. However, I've also considered whether people would want a non-public contract due to some privacy concern. So I've tried to consider the necessary steps needed in order to make that work too (trust in an environment where no one else can prove the details of a contract!).

With regards to your idea: the bank # in the title is an identifier, while the number in the contents allows the bearer to redeem the contract (assuming a deposit). This could work where the authenticity numbers are not guessable, but verifiable online. Obviously, the books need to have been created by someone who is known as "a signer for the bank".

There is a lot of discussion we could have around that, and in particular some sort of online system (web app).

 

Quoting you again so you can see the reply to the below (related).

Some sort of web app would go a long way in helping this idea fly. Input boxes would make life easier for the players and guarantee that the input is always formatted correctly. A web app would be able to automate the tracking process (which y'all know), and make life a lot easier.

The contents of a book I believe are private to the person holding the book. The Cert ID (not guessable) is probably enough for the bank to know that the certificate is genuine: the Cert ID is a private nonce. A simple spreadsheet could list all the relevant details but without the Cert ID: the two most important would be Bank Note ID and the hash (assuming we do that). The hash is private to the person holding the book, for sure, and the Bank Note ID is private to the holder and anyone who eventually sees the book in a trade window. I don't think book contents can be checked in a trade window (would be good to check).

• If we only had spreadsheets (or similar), the simplest way to check is:
  • The bank note ID and hash in the book should match the spreadsheet to verify authenticity. The name on the book should also be a known trusted name (who work for the bank).
  • The spreadsheet should really contain the name of book creator. Always a good first check.
• If we had a web app:
  • When a player inserts the Bank Note ID and Cert ID it should reproduce the hash, and hence verify authenticity.
  • We'd only need those two values to verify, but we could also add the name of the book creator.

In the latter we trust the web app with the private Cert ID value, in the former we couldn't display that private value in a public place.

We might need to cut the hash in half and perhaps encode it in a friendly manner. I can't see people being happy to copy / paste and check all characters of a 32 character alphanumeric string. I think we are somewhat safe from problems of hash collisions since genuine bank notes can only be signed by authorised members.

 

We will, and yes there will be trade agreements, and no we won't laugh too hard when the idea is successful and you are missing out.

Correct, we are not creating ledgers. The transactions will be tracked out of the game.

Not 100% sure on your final statement though: "creating a way to MAKE money without having money Shares."

 

What we need is flourish. (Try an image search.)

This might not look so good in a variable-width font, but it's a start - something I came up with a long time ago to encode timestamps and digital signatures in a way to help not make them look so much so. Plus they help to delineate the content of the book from the stuff we add for verification, etc. (Also it is meant to be machine readable to recover the actual values and to identify what they should be interpreted as.)


/-=00--00==00--00=-^^-=00--00==00--00=-\
|-=AA--AA==0E--BC=-vv-=32--0C==F4--A5=-|

Bank Note #1
Worth: exactly less than nothing

|-=02--A7==51--66=-vv-=65--5F==62--A4=-|
\-=30--FE==7D--5F=-^^-=06--B9==AA--AA=-/

 

3 thoughts:

No doubt this can be a great role-playing idea. But how much can there be hope for more, considering the necessity of well-designed economic incentives? E.g., the need to raise capital. All these ideas arise out of complex, well-functioning systems that may be too hard to replicate in this game. Getting an economy functioning that well seems a somewhat unrealistic expectation. Beyond corporations, one small example is that bank notes would not achieve the purpose for which bank notes are used in real. Gold in a game is already like a bank note: easy to carry and traded for everything. It can be stored in banks safely and transported in non-PvP ways safely (single player online mode).

Second, what beyond a role-playing perspective encourages people to do things this way instead of the more easily accessible and more public fora? Let's say I was a property manager who would rent houses (if the economy will make that lucrative, big if as in first point). To advertise and sell, I'd rather have my listings easily accessible outside of game so that the greater number of people see them and could easily access them. Since the listings are there, I'd also want to record rental contracts and other information there. Asking somebody to travel to me in game, or to a library or something, places an additional burden on completing the transaction. In other words, doing things in-game would be a bad choice from a marketing perspective. You'll also be able to add limitless functionality to a forum, whereas you'd constantly need to create workarounds with books that require standard templates with rule sheets, etc.

Third, these both lead to the desire to ask devs for additional functionality which is always great. But the more functionality that gets added, the question could be raised as to why they should not just bite the bullet and create a system. For example, with the current permission list, and like property tax, it would be easy to set up some functionality that would auto-deduct payment from a renter. I'd hate to see little things added here and there when it would make more sense, in some cases, just to bite the bullet and add the support.

 

That's neat. Do you envisage players copying and pasting the whole thing into a web form though? There could even be a checksum hidden in the flourish. (the series of lines and dashes are an encoding of a different hash)


Tradeable Secure Certificates of Deposit

I'll go through a protocol run of my idea (simplified)

D = Depositor
B = Bank (i.e. TTP)
R = Redeemer (R could equal D)

1. D -> B: 100 gold.
2. B -> D: Token_D
   1. Token_D = {"Certificate of Deposit" | "100 gold" | "Depositor Name" | "0123456"}_bank
   2. As you can guess the braces are the contents of the book and the underscore denotes the signer's name. The number is the serial number of the note.
3. D -> R: Token_D | Token_R
   1. (Concurrent) R -> D: some item, e.g. a sword)
   2. Token_R = {"Certificate of Permission" | "100 gold" | "Depositor Name" | "0123456"}_depositor
   3. This new token (CoP) is signed by the depositor and shows intent to trade.
4. R -> B: Token_D | Token_R

Comments

• The CoD proves that the depositor made the deposit. It is signed by the bank who must be trusted (otherwise protocol fails). When the bank receives the CoD at the end it knows the certificate is real since it has been signed by the bank itself (plus the contents will check with the records).
• The CoP proves the depositor's intent to trade. The depositor creates this from a blank book and copies the details of the CoD.
• The bank will check the name of the CoP creator. It must match the name in the contents of the CoD (CoP isn't necessary since the book is "signed").
• The depositor could lose the CoD and still not lose their deposit. Will leave the details out for now but consider what that means for PVP zones.
• None of this requires spreadsheets, provided the redeemer trusts the name of the bank (the CoD creator -- inserted by the game, since my screenshots before).

 

A fair point. When I originally devised my idea I didn't consider going to single player to avoid PvP zones. I came up with a protocol (see post above) that would allow players to traverse PvP zones and still trade securely. I don't think that can be done with gold since gold can be taken when a player is killed (tell me if that is incorrect). In my protocol above the player is still safe even if the book is stolen.

You are correct in implying that books are not necessary for any of this functionality. Books are a nice to have though. Somehow it feels more interactive to have them as "tokens".

The economy is designed to be regionalised so already there are burdens placed upon the player. For me this means that some sort of hawala is going to be desireable. Moreover, the books might be able to provide a neater way of doing that which stops players jumping back to their browser. I think we are still pretty early in the development of this idea that we can't quite tell if books will just be an unnecessary burden.

True, I believe all such systems are still possible with the features that the devs have already promised. The reason I didn't want to request anything is that I'm not one to throw my toys out of the pram and demand that the devs add certain features (unlike some other forumers...). As some people had strong hostility to these ideas before I was not keen to push my luck in fear that it created more drama. However, if the devs decided that they wanted to add some more these features because it looked popular then it would be greatly appreciated.

 

Yes. Into a giant textarea. Which someone can style to look like an in-game book.

Then click a button and find out if it is valid or whatever. Or click another button to 'sign' the document you just pasted in. Or export something to a plain text file that can be used to publish a book in-game. etc

There appears to be a UX issue, in that I'm not sure if you can 'select' the entire contents of a book in-game, or if it is only one page at a time.

 

Think of this as a meta-game or intellectual exercise.

As for development work, I think Port will do a good job of adding features or not.

Did they need to implement the Gustball pet? No.
Is it fun? Probably, but I haven't gotten one in-game yet.
Does it help to support/foster the community? I'd claim it does.
Is it cost-effective or beneficial? Does it even matter?

 

I totally agree... but I probably didn't explain myself the best. My point was simply that if they are going to add functionality in little pieces (signatures, date stamps, whatever), they might just consider adding a whole system. Might be easier just to do it all at once then dribble things out.

 

This kinda hits the nail on the head. We feel like there are people out there that enjoy this kind of play style. We would like to see a meta game similar to eve in the long run. This is a Pre-Alpha test and will take shape while the game does. What we know now is that we would like to do banking and shipping with the possibility of a stock market. We have about 30 locations that there will be some sort of bank/shipping point scattered throughout New Brittania. Is it easy? No. Is it fun to some people? Yes. Could it possibly draw in new players that like this level of roleplay and game style? Yes. And last but not least, is it healthy for SotA? We think that is a definite yes.

If this type of stuff catches anyone's interest, please join the Tantalus Consortium.

 

I'm not aware of your other posts you've linked so I'll have to read them and get back to you. Thanks for the heads up.

 

He already is.

Slimmed down version of the protocol (for "money") is a couple posts up:

https://www.shroudoftheavatar.com/f...nnian-stock-exchange.33151/page-2#post-387758

Did some simple texts in game to see how the certificates might look. Pics soon. I actually went for the title containing a serial number idea.

 

Just happened to put that shameless plug in at the end for anyone else that is interested. heh

 

Example Certificates of Deposit
i.e. what you get from a bank when you deposit money. Each picture gets progressively more complicated with more details added.

The basic structure has the serial number (bank note number) as the title of the book and is also included in the contents of the book. I checked with Aevans that the contents of a book are not viewable in the trade window, which is good for keeping private serial numbers (Violation's authenticity numbers) private until trade.

Picture was an attempt to add a hash within a flourish plus some extra formatting. The fourth is a re-working of 3. Many of the characters are of different widths which makes it a pain to standardize widths and attempt to make formatting pretty. :-/

​

Quoting you two just to grab your attention and solicit feedback on the following idea:


Public records

Creating a public spreadsheets will help for accountability and build trust, but having the records of a bank in a single place might not instill enough trust. If pictures are taken and posted to Twitter / imgur, then there is a way to create a time-stamped post. The difficulty is if those pictures are ever removed or edited, then the integrity provided by such a post is zero. They could perhaps be another part of the procedure to help instill trust.

What might be more helpful is if "rival" banks make a copy of each other's transaction log. The suggestion here is that the overall system will self-regulate and that each bank will essentially provide an integrity check for each of the other banks. While we could make a full copy of each other's transaction logs (a big spreadsheet), we could suffice to just copy hashes rather than full transactions. Moreover, we could be more efficient still by chaining the hashes and just store the final hash of the other banks (you store a record of your own bank's full transaction details). This was actually inspired by Bitcoin, I had another look at the whitepaper last night.

Example
(just for clarity --- although this is not necessarily the precise / final formulation but an illustration)

Spreadsheet contains:

• Columns for Certificate of Deposit Details (see pictures above), date / time, hash.
• CoD details are (e.g.): Name of Bank, Amount, Name of Banker, Name of Depositor, Serial Number (Violation's bank note number), Private Serial Number (Violation's authenticity number)

Day 1

• Transaction 1 : [Certificate of Deposit Details_1], [Date / time], [Hash_1].
  • Hash_1 = [Certificate of Deposit Details] | [Date] | [Time] | [00000000]
  • The | denotes string concatenation, and the string of zeroes at the end is essentially an initialization vector
• Transaction 2 : [Certificate of Deposit Details_2], [Date / Time], [Hash_2].
  • Hash_2 = [Certificate of Deposit Details_2] | [Date] | [Time] | [Hash_1]
  • Note that the final piece of Hash_2 is the previous hash and not the initialization vector or a nonce.
• Transaction 3 : [Certificate of Deposit Details_3], [date / time], [Hash_3].
  • Hash_3 = [Certificate of Deposit Details_3] | [Date] | [Time] | [Hash_2]
  • The hashes keep chaining as you would expect. Hash_2 contained Hash_1 in its calculation.

Day 2

• Transaction 4 : [Certificate of Deposit Details_4], [Date / time], [Hash_4].
  • Hash_4 = [Certificate of Deposit Details_4] | [Date] | [Time] | [Hash_3]
  • I propose that all days follows on from the previous day. Therefore hashes chain over every day and don't "reset".
• Transaction 5 : [Certificate of Deposit Details_5], [Date / time], [Hash_5].
  • Hash_5 = [Certificate of Deposit Details_5] | [Date] | [Time] | [Hash_4]

I propose that "rival" banks store the most recent hash of the other "rival" banks. Simply storing the latest hash (a single value) would dramatically reduce storage requirements and arguably make life simpler. While you could copy / paste all into a new sheet on G docs, this method would only require one cell per "rival" bank which could all be contained within a single column (which could be on its own sheet).

Ultimately it would be great if this could be scripted and automated, but it isn't a huge problem if it isn't. Part of the reason for taking the final hash is to make it simple. To account for the fact that we will be on at different times then I update my proposal to taking the most recent "end-of-day" hash. So if Day 5 was still on-going then you would save the last hash from the previous day. While the hashes chain anyway, I think it is a clearer procedure to only store end of day hashes rather than random middle-of-the-day hashes (which is too ad-hoc, especially if across several banks). I'm expecting things to get out of sync but with some diligence things can match up at the end of a week, or end of month at worst (we obviously need to account for vacation time).

Additionally, it would make sense to check each other's calculation which provides a basic level of auditing. Obviously if this can all be automated then cross-checking could be automated too (just a thought).

 

I believe chain hashing in various forms pre-dates BitCoin by 2 or 3 decades.

https://en.wikipedia.org/wiki/Linked_timestamping
https://en.wikipedia.org/wiki/Hash_chain

 

There are some other ways to keep information encoded in a book but not directly visible. See also: https://en.wikipedia.org/wiki/Steganography

For example purposes I added 25 lines of text to push the real content to the second page. You can try to use the same technique to move the Private Serial Number or other private information to the second (or any even numbered) page. Then you can take a screenshot of the 'public' content without revealing the private content. You store the private content privately and map it to the public data for verification later, but it is still in the book proper.






Here we see the public information on the left, and the private information on the right. Normally they would not be visible at the same time, I just did it this way for demonstrations.

You may notice the very lightly colored Private Serial Number on the right hand page. There is probably a better color choice to blend in with the background, but it actually doesn't matter.

We can take advantage of the color changing markup codes to embed numeric values hidden in the contents of the book. Copy and paste the page of the book into your text editor and you will still have the markup, but now you can read it. (We no longer need flourish to embed hashes or Private Serial Numbers or whatever. But it does require possession of the book in order to copy and paste and recover the hidden data. And it counts towards the character limit, but these are small documents, so less of an issue.

You will notice on the right hand page that I encoded the Private Serial Number in color code markup (with spaces to make it visible, again the demo). I prefixed and postfixed the data with a block of all zeros, cuz I could. You would want to left-pad values with zeros to make the data divisible by 6 characters, which is needed for the color codes.

[000000][123445][678912][000000]

In this example, I treated each of the 6 characters in the color markup as base-10 and wrote out the actual Private Serial Number in the 2 center color code blocks. Of course you could encode the data in base-16 hex values (or base-8, binary, whatever).

 

If the goal is transparency, and we don't object to having the public records outside of the game (e.g. web site or something), we might want to consider PubSubHubbub along with RSS/Atom or some form of JSON feed. Using which ever along with whatever semantic markup or extensions are available, we would basically publish every transaction to a feed and notify a hub of the change.

One copy of the public record would be the feed itself, and all historic data from the start. Other public records could be created by subscribing to that feed at that hub and making local copies. Also the stream being pushed from the hub would give you a near real-time transaction log to follow along.

Spoiler

For even more fun you create a 'numbers station' a la Avatar's Radio or whatever else can be picked up by the in game radios. Then have an automated voice read out the transaction logs as soon as they show up having been pushed from the hub. Could also work for a near real-time stock ticker.

You don't want to blindly concatenate fields together before you hash them. I think it's an extension attack or something. Either way you would probably want an actual field separator, something not allowed in any of the fields. But you still don't want to concatenate. HMAC is meant for cases where you would try to do this. It is designed to deal with the attack vectors that present themselves from concatenation. You would want something closer to

HMAC( IV, HMAC( timestamp, CoD_content) )

(And your initialization vector should go first. )