Question for everyone:
Does your token protocol have a scheme for encrypted receipts/documentation related to the token transactions, where several parties with individual private keys can decrypt the receipts/documentation?
The Elas Protocol is confined to an input-output pair, the combination of which constitutes a token exchange. You can do multiple token exchanges from multiple token ledgers within a single transaction and can include data or bitcoin inputs from other sources such as normal bitcoin or other token types. You also have the freedom to create FALSE RETURN scripts in your transaction for the purposes of storing data, but ideally you'd keep the financial action 'air gapped' from the record by storing it in a separate transaction or off the permanent ledger...
Question for everyone:
Does your token protocol have a scheme for encrypted receipts/documentation related to the token transactions, where several parties with individual private keys can decrypt the receipts/documentation?
This thread is based on the assumption that one single* token protocol based on Bitcoin (BSV) will be dominant globally in the future because of the network effect.
The goal of the thread is to figure out which protocol it will be as soon as possible with as much certainty as possible.
[...]
-----------
* There may be two dominant protocols if they differ substantially in a fundamental way.
reading through the answers so far (and it's quite a bit to take in), it begins to look like stein's fundamental assumption could be unwarranted. why would one or two token protocols dominate? the situation is different than with the base layer itself, where the network effect is necessary for blockchain tech as a whole to take hold, and economies of scale to develop. but at the token/smart contract level? each proposal will no doubt work technically, so it will probably come down to use case satisfaction, and this shifts with consumer needs and preferences. choosing one token protocol over another one might in the end be a decision akin to choosing among competing workflow platforms or apps.
Question for everyone:
Does your token protocol have a scheme for encrypted receipts/documentation related to the token transactions, where several parties with individual private keys can decrypt the receipts/documentation?
Yes, we have accounted for that. We want to lay the foundation for a global shared ledger and we think receipts, invoices, tags, customer contract numbers, etc. are important data to be stored within the transaction. We have done this in a way that the information can be public, private to both transaction parties, and private to one party. We're also developing ways to amend the user-generated metadata.
If you are interested in thinking more about the implications on accounting then I recommend checking out Kip Twitchell. He has a lot of interesting things to say on the topic of accounting/ledgers/shared ledgers/financial reporting/financial data processing. There's a lot to think about wrt to private security tokens and how they fit into accounting systems.
"Finsysvlogger's Financial System Vlog, the best financial systems vlog there is. Making financial systems education about more than blockchain hype." I atte...
Wow, there are some really interesting high-quality posts here! Thank you all for contributing.
@eamesyi, that's a solid pitch for Tokenized! I'm very glad you can share this much at this stage, and I understand that a complete system like Tokenized takes time to develop. You talked a little about central bank issued e-money at the BSV DevCon this weekend. Would this be like pseudonymous yet traceable digital cash, or more like M1 bank accounts in terms of privacy?
FYI we use identity oracles as an 'identity-focused certificate authority' which are commercial entities (private sector) that perform KYC verification functions and link public keys to those verified entities (and their agents) in off-chain databases. They then operate services that issue time-based certificates (ECDSA signatures that cover public keys, asset IDs, an expiration date, and/or specific questions relating to PII). Those certificates come with an expiration timestamp and can be added to a transaction payload to hold the identity oracle accountable and allow for the transacting parties to get all of the information they need if there is a commercial dispute. It also allows for keeping some token types from transferring to entities outside of a whitelist. For many financial instruments and many jurisdictions, this is a really important feature.
The smart contract system can also use the identity oracles to restrict transfers to entities that fall within certain groups based on PII (age, location, status), depending on the issuing entity's wishes/compliance requirements which are declared in the on-chain contract metadata (C2 action). All optional of course.
Authority oracles are similar but they are permitted to freeze, thaw, and confiscate tokens. These could be regulated financial institutions, or government agencies (e.g. court orders/property seizures by LE/courts). We believe it to be likely that identity oracles and authority oracles will be operated together by a single entity, but the services are separated to provide flexibility for all kinds of commercial arrangements.
For E-Money, we believe that whitelisting will be critical for most central banks, and that oracles will use certificates to monitor 'who owns what' similar to how banks operate today. However, if you think about this, it is a more elegant solution to open banking that allows for open-source wallets/GUIs to do what they do best in a very simple way, both technically and commercially. So, similar to how bank accounts work today, but not exactly the same, and still non-custodial.
When you consider all of the advantages on aggregate, we believe the solution has the potential to do the following: lower the regulatory and compliance burdens placed upon financial institutions, lower the costs of insurance across the entire global financial system, and lower the operational costs and base capital requirements of running regulated financial businesses. These benefits also come with, and/or are a result of, holding everyone in the entire financial system to a higher standard of accountability and performance. The full argument for this is a full essay though.
KYC is coming to Bitcoin and AML/CTF regulations aren't going away. With that in mind, we believe that on-chain certificates issued by identity oracles are the most effective, performant, and accountable solution that still allows for all of the benefits that Bitcoin has promised.
Our proposal to the Bank of England was very long and a lot of the important details I have glossed over. If anything resonates with anyone, I can get more into the details.
reading through the answers so far (and it's quite a bit to take in), it begins to look like stein's fundamental assumption could be unwarranted. why would one or two token protocols dominate? the situation is different than with the base layer itself, where the network effect is necessary for blockchain tech as a whole to take hold, and economies of scale to develop. but at the token/smart contract level? each proposal will no doubt work technically, so it will probably come down to use case satisfaction, and this shifts with consumer needs and preferences. choosing one token protocol over another one might in the end be a decision akin to choosing among competing workflow platforms or apps.
I think one protocol will dominate financial instruments and commercially-focused utility tokens. Think about how the financial system works today using standards, and how simple it is compared to a smart contract enabled future. Standards and a common protocol/framework will be an important part of making this thing commercially feasible at scale.
For other token use cases, I agree that there will probably be a few competing options.
I'll guess we'll have to see how these predictions play out in the market!
I justified my belief in 1(max 2) dominant protocols with just two words in the intro to this thread: Network effect. So I'll elaborate.
First of all, I think it's important to distinguish between a protocol and the software implementation of a protocol. I think most people in sum will benefit from using the same static protocol but have competing and improving implementations of this protocol.
My phone has too damn many apps today. Apps for each different bank, apps for each loyalty point on each hotel chain, airline, retail chain, apps for concert tickets, apps for public transportation, etc.
Imagine having just one single app for all these tokens. Easier for users, easier for issuers and easier exchange between different tokens. Expensive integration developers may have to find something else to do for a living. We don't have to reinvent the wheel over and over again.
I think a good token protocol on BSV will be able to do (almost) every use-case, and I think we all benefit from using the same protocol.
"After evaluating Ethereum we progressed to building on Tokenized’s specs, but quickly realized, due to the governed approach, the specifications would not be able to handle the high volume of transactions given our goal of bringing tokenization to the mass market." [From: ]
- Wrong. The Tokenized Protocol's transactional throughput is only limited by the capacity of the Bitcoin SV network itself. Smart contract agents can operate on an SPV-basis and are inherently more scalable than a BSV node.
"Many token schemes are isolated from the Bitcoin SV transaction process and therefore usually require additional validation on the token user side." [From: ]
- This is an inferior design in comparison to the fully on-chain request-response mechanism. It also still requires a software agent to interpret/sign on behalf of the issuing entity (or authority for freezes/confiscations) which results in the same security model as Tokenized Protocol, but with users being at the mercy of having to have token transfers approved/ignored/rejected through an off-chain request.
FWIW they haven't really proposed a protocol. Unless I am missing something, I believe they've basically copied sCrypt's utxo-based token protocol (UTP), and rehashed a basic send action in their own words. Nothing else has been specified that I am aware of. They then go on to indicate that their solution Fabrik is more of a bridge between tokenization protocols:
"While working with the sCrypt team, we realized that the wider Bitcoin community should not have to choose between tokenized and sCrypt (or any other specifications for that matter), so we decided to create a bridge that acts as a connecting application to the underlying power of the Bitcoin SV Blockchain. This enables the community to create Bitcoin smart contracts that issue and transfer tokens via a high-level interface across multiple specifications. Now you don’t have to guess or wait to see who’s tokenization protocol will become the standard."
They also say some things that make me think they haven't got their finger on the pulse, such as:
"Instead, we embed the token transactions using Pay-to-Script-Hash scripts (P2SH) so that it becomes inherently the same process of a Bitcoin SV transaction."
@Norway, I don't think you'll see one app handling all your tokens... I could be wrong, but I think many issuers will want to customise the user experience - especially when those tokens are tied to other value add services which are managed through an app layer.
Thanks @Norway for starting this thread and for all who have contributed. Extremely relevant to a business decision we want to take very soon. For Centi, the main factors we are currently trying to assess for each solution are the following (in no specific order):
License Cost
Implementation Cost / Complexity
Project Maturity
Availability of Libraries
Emulation of other Tokens?
Interoperatability (Ecosystem)
Compliance
Ecosystem Size
Exchanges
Miner Enforced?
Whitelists / Blacklists Possible?
Time to Validate TX
Team Size
Enterprise Support?
Presentation
White Paper
Other Documentation
Website
Contact
One of the most important things being: "How fast can we get a working system up and running which we have confidence in?"
Our token needs are threefold:
1. High regulatory oversight token like a stable-coin (from a legal side we have what we believe is a working concept, so we need a token that can fulfill the legal needs.
2. Lower regulatory oversight tokens such a tickets, vouchers, coupons, loyalty points... etc.
3. Ecosystem:We would like to start interacting with many other businesses. This is only an example, but e.g. for each real purchase made through us, a TrueReview token could be handed out, which is sort of on a "verified purchase" level. Again, this is just one small example and I would wish for many such collaborations in the future. Therefore it's a difficult time to make that decision, as not many are using tokens yet, and these that do seem to be using a set of different standards.
That all stated, if any of the reps from a protocol would like to comment on any of my bullet points above, you are more than welcome. I can always keep track of my own assessment as well as assessments coming directly from the creators.
I disagree with his assessment. I researched the actual issuance of US currency. The cash supply is represented by around 60 billion notes and coins total, meaning the entire physical cash supply could be tokenized on roughly 600BSV. The entire world's physical currencies are captured in around 40x that many notes and coins as near as I can tell, so a global transition to a digital cash format could be done using around 25,000BSV or about 0.14% of the overall supply.
To tailor the cash to microtransaction markets, you would probably issue a lot more of the smaller denomination coins and notes, so it's possible that you might use a larger quantity than this, but it's still small potatoes in the grand scheme.
A lot of the other markets James mentions aren't well suited to this style of token and would probably consider using something more like tokenized. Hence why I don't get wrapped up in the idea of a single token standard.
I disagree with his assessment. I researched the actual issuance of US currency. The cash supply is represented by around 60 billion notes and coins total, meaning the entire physical cash supply could be tokenized on roughly 600BSV. The entire world's physical currencies are captured in around 40x that many notes and coins as near as I can tell, so a global transition to a digital cash format could be done using around 25,000BSV or about 0.14% of the overall supply.
A lot of the other markets James mentions aren't well suited to this style of token and would probably consider using something more like tokenized. Hence why I don't get wrapped up in the idea of a single token standard.
We want smart contracts issued for every demand deposit and certificate of deposit in the world, as well as digital cash and physical banknotes...and divisible to (aka tokens representing) 1/1000th of a cent or less.
We are moving the entire global financial system over to the Bitcoin SV network.
I disagree with his assessment. I researched the actual issuance of US currency. The cash supply is represented by around 60 billion notes and coins total, meaning the entire physical cash supply could be tokenized on roughly 600BSV. The entire world's physical currencies are captured in around 40x that many notes and coins as near as I can tell, so a global transition to a digital cash format could be done using around 25,000BSV or about 0.14% of the overall supply.
This is based on M0, but the potential for e-money is at least M1, perhaps M2 and up. Central banks issue M0 today. This is both coins/notes and digital money. (Most people have never seen digital central bank M0. This is because it's only used for settlements between banks a few times per day.)
I believe central banks want to get into the market for digital money at the consumer level like M1, and the only reason they have not done it before was the technological hurdles that bitcoin removes.
I certainly share @brendans concern regarding privacy, but even more the overreaching power of a single entity's ability to take a citizen off a money whitelist with the click of a button. This dystopian nightmare can be compared to being able to prevent any person from eating food or drinking water by a remote single action.
Like I said, there are some aspects of these many interwoven systems that work better as UTXO based tokens, and some that work better as Tokenized type systems. For interbank transfers and central bank issuance of e-money against bonds this is fine, but for cash on the street, IMHO a digital replication of the notes and coins we use today is viable, simple and understandable for people and government. It's also a form of cash you can now take and plug into a website with a single click. Very low friction cash for an internet where micropayments rule. Thanks to the way we use UTXOs as the live token, they can also be spent into payment channels which allows them to be used as the basis for sub-cent services. Think about a 1c payment channel that stays open for either 1 month, or 100 clicks of a button...
The trouble you get into with digital 'banknotes' is money laundering.
Money laundering with physical banknotes is largely restrained geographically and through the practicalities of actually transacting, counting, moving, hiding, storing, and 'washing' the paper notes. There's a lot of time, effort, and expense in laundering a lot of physical money.
A point of reference worth keeping in mind:
'If you are using $100 bills, you need 10,000 of them to get to $1,000,000. The weight is 22 pounds. The size is length and width of a $100 bill is 2.61 inches wide and 6.14 inches long, .0043 inches thick and weigh 1 gram. For 10,000 bills that is 43 inches in height. Or 21.5 inches high by 12.28 inches to gives you a double stack. About the size of a briefcase. I think you could find a briefcase that would fit it. 22 pounds is not heavy, it is not light either.' [From: https://www.quora.com/How-much-space-does-a-million-dollars-take]
A digital currency with ultra-low fees, microtransactions, and no oversight/reporting is a money launderer's dream. It's worth thinking through how easy it would be to launder hundreds of millions of dollars through online businesses that charge digital currency for 'digital services'.
What we are suggesting with the Tokenized Protocol is functionally the same in terms of privacy as the current financial system except it is more accountable, transparent, and fair for all parties...regulators and financial institutions included. So if a regulated institution stopped providing identity oracle services to you, you could easily get served by another one, or all of them at once. If any money is taken/frozen from you, there is an on-chain record of who, how much, when, and why....and you can prove it was yours with your private keys.
I don't really know anyone that keeps much of their net worth in physical banknotes, but I'm an advocate for keeping physical cash as an option.
I don't think you can expect everyone to submit to overbearing scrutiny because of a few bad apples. The thing about this form of banknote is that every single transaction that happens is done in public, so it becomes very simple to perform analysis on patterns across a ledger of cash bills. Bills can be seeded into suspect operations and their path on the ledger can trace flows through a launder cycle making it much easier to catch.
I submit that while it is physically easier to move these bills, the act of cleaning them of the traces of crime is not so simple at all.
This site uses cookies to help personalize content, tailor your experience, and keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.