BitShares Forum
Main => General Discussion => Topic started by: bytemaster on April 05, 2015, 03:56:30 am
-
I would like to do a survey of the most advanced tech in the industry. The goal is to aggregate all of the "ideas" into one place and label / sort them. This can be thought of as one of the largest repositories of white papers out there. The purpose of this is to help me keep up to date with the latest ideas without having to search for it all myself.
I would also like some help gathering performance measures / benchmarks of our primary competitors. So have the following questions:
1) What is the fastest implementation of reindexing the Bitcoin blockchain without signature checks, how may transactions per second does it process. This would probably be like reindexing Bitcoin prior to a checkpoint.
2) How long does it take to do the equivalent of reindexing with Nxt? how many blocks and/or transactions per second can Nxt reindex.
3) Same question for Ripple
4) How many transactions per second can Etherem reindex? How many operations per second can their scripting engine execute?
The goal of these benchmarks is to evaluate how well the existing implementations scale in the real world.
Today BitShares can reindex at close to 1000 transactions per second. This hits the limit of the current implementation, but an updated implementation could easily get BitShares up to 10x that.
I would also like to know everything there is to know about multi-sig technology offered by the various platforms.
Lastly a survey of the various approaches to zero knowledge proofs for cryptographic privacy on a blockchain.
-
About Nxt,:
I just use the web wallet of Nxt at secureae.com. How long of its sycn time is not important to me.
-
I would like to do a survey of the most advanced tech in the industry. The goal is to aggregate all of the "ideas" into one place and label / sort them. This can be thought of as one of the largest repositories of white papers out there. The purpose of this is to help me keep up to date with the latest ideas without having to search for it all myself.
I would also like some help gathering performance measures / benchmarks of our primary competitors. So have the following questions:
1) What is the fastest implementation of reindexing the Bitcoin blockchain without signature checks, how may transactions per second does it process. This would probably be like reindexing Bitcoin prior to a checkpoint.
2) How long does it take to do the equivalent of reindexing with Nxt? how many blocks and/or transactions per second can Nxt reindex.
3) Same question for Ripple
4) How many transactions per second can Etherem reindex? How many operations per second can their scripting engine execute?
The goal of these benchmarks is to evaluate how well the existing implementations scale in the real world.
Today BitShares can reindex at close to 1000 transactions per second. This hits the limit of the current implementation, but an updated implementation could easily get BitShares up to 10x that.
I would also like to know everything there is to know about multi-sig technology offered by the various platforms.
Lastly a survey of the various approaches to zero knowledge proofs for cryptographic privacy on a blockchain.
Why not just use a Google alert? Or do you want someone to read the papers and organize it into some kind of wiki? Maybe you want a SWOT analysis?
https://en.wikipedia.org/wiki/SWOT_analysis
In any case maybe I'll be able to help out. I read a lot of whitepapers.
-
About Nxt,:
I just use the web wallet of Nxt at secureae.com. How long of its sycn time is not important to me.
Sync time is VERY important to understand scalability of the architecture of the "miners".... and not DOWNLOAD time but REINDEX/REPLAY time that removes all network sync overhead from the calculation.
-
ZeroCash paper: http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf
Extended version: http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf
ZeroCash claims to improve on ZeroCoin by using zero knowledge Succinct Non-interactive ARguments of Knowledge (zkSNARK), bringing transaction sizes down to <1KB and verification times down to <6ms.
Here's a work in progress C++ library for zkSNARKS: https://github.com/scipr-lab/libsnark
I can investigate further if you let me know what you're after, but I should warn you that I really don't understand the math behind these at all.
-
Here is an interesting paper I found from 2014.
http://p2sh.net/file/Purely%20p2p%20crypto-currency%20with%20finite%20mini-blockchain.pdf
I don't know if it's exactly what Bytemaster is looking for but it's what I could find so far. Anyone want to take a look at it and see if it's helpful?
ZeroCash paper: http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf
Extended version: http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf
ZeroCash claims to improve on ZeroCoin by using zero knowledge Succinct Non-interactive ARguments of Knowledge (zkSNARK), bringing transaction sizes down to <1KB and verification times down to <6ms.
Here's a work in progress C++ library for zkSNARKS: https://github.com/scipr-lab/libsnark
Libsnark is so complicated I don't know anyone in the industry except the developers working on it who understand it. I think if we do pick an algorithm or cryptography it helps if it's simple enough to be understood. When you implement something no one understands there is risk in that.
At the same time it's said to be the most private option available.
-
About Nxt,:
I just use the web wallet of Nxt at secureae.com. How long of its sycn time is not important to me.
Sync time is VERY important to understand scalability of the architecture of the "miners".... and not DOWNLOAD time but REINDEX/REPLAY time that removes all network sync overhead from the calculation.
what is the purpose of this survey?
-
About Nxt,:
I just use the web wallet of Nxt at secureae.com. How long of its sycn time is not important to me.
Sync time is VERY important to understand scalability of the architecture of the "miners".... and not DOWNLOAD time but REINDEX/REPLAY time that removes all network sync overhead from the calculation.
what is the purpose of this survey?
It is stated in the OP:
"The purpose of this is to help me keep up to date with the latest ideas without having to search for it all myself."
-
Here is an interesting paper I found from 2014.
http://p2sh.net/file/Purely%20p2p%20crypto-currency%20with%20finite%20mini-blockchain.pdf
I don't know if it's exactly what Bytemaster is looking for but it's what I could find so far. Anyone want to take a look at it and see if it's helpful?
ZeroCash paper: http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf
Extended version: http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf
ZeroCash claims to improve on ZeroCoin by using zero knowledge Succinct Non-interactive ARguments of Knowledge (zkSNARK), bringing transaction sizes down to <1KB and verification times down to <6ms.
Here's a work in progress C++ library for zkSNARKS: https://github.com/scipr-lab/libsnark
Libsnark is so complicated I don't know anyone in the industry except the developers working on it who understand it. I think if we do pick an algorithm or cryptography it helps if it's simple enough to be understood. When you implement something no one understands there is risk in that.
At the same time it's said to be the most private option available.
The zero cash white paper is very dense but if it delivers what it claims looks quite viable.
-
Make real anonymous transactions or something obfuscated enough that a unsophisticated third party can not analyze then perhaps you have a chance to turn it around.
-
NEM
http://www.ournem.com/
https://forum.ournem.com/index.php
http://blog.nem.io/overview/
http://blog.nem.io/how-to-use-multi-signature-accounts/
-
Factom https://github.com/FactomProject/FactomDocs/raw/master/Factom_Whitepaper.pdf
-
NEM
http://www.ournem.com/
https://forum.ournem.com/index.php
http://blog.nem.io/overview/
http://blog.nem.io/how-to-use-multi-signature-accounts/
The NEM approach to multi sig is the best I have seen outside our internal design meetings. Is there anything else close or better than it?
Sent from my iPhone using Tapatalk
-
Why not call multisig accounts (shared accounts)?
-
Why not call multisig accounts (shared accounts)?
Shared accounts I think generally allow any member to spend independently of the others. Perhaps "corporate accounts"?
-
3) Same question for Ripple
I have read that Ripple "transaction validators" don't need prior "ledgers" to operate, they just sign current ones and not necessarily store previous ledgers (in fact ledger before #32570 is already lost and not "recoverable", someone says.)
They claim they solved "scalability problems" by adopting this method and many people say Ripple does not use "Blockchain" technology.
That's actually a problem currently - there is no server on the network that has any ledger before 32570 (the older ledgers got corrupted in "ye olden days" and nobody got around to fixing them). ...
(https://forum.ripple.com/viewtopic.php?f=1&t=4717&f=1&t=4717#p28026)
Btw, regarding consensus technology (which is the most basic foundation of crypto and the most important part, I think),
I found that Nxt's algorithm is super-cool.
Here is the graphical inspiration: (http://nxtportal.org/forgers/)
[Re: Concise but complete technical description of various proof-of-stake (PoS) schemes?]
(Come-from-Beyond says:) The software determines the best chain by analyzing ratio of transactions belonging to well-known participants (e.g. Walmart, Alibaba, Coinbase) of the economical cluster using Nxt. Non-legit chains can't include such transactions because every transaction refers to a block mined several minutes before the transaction timestamp, which prevents inclusion of majority of the transactions into chains with lower cumulative difficulty or into chains generated by an adversary.
(https://bitcointalk.org/index.php?topic=1012241.msg10987520#msg10987520)
-
That a great opportunity for a website: to aggregate all whitepaper under one roof.
Who in the community is up for it?
(
-
https://github.com/vbuterin/scalability_paper/raw/master/scalability.pdf
-
https://docs.google.com/document/d/1IxZqTQFhyhUDe8peeSEmjVVb32hzzQ_53bgs98yOTKA/edit?usp=sharing
-
Why not call multisig accounts (shared accounts)?
Shared accounts I think generally allow any member to spend independently of the others. Perhaps "corporate accounts"?
joint account, multikey account, ..
-
are we not able to prune old orders that are processed already with small stubs for accounting purposes? Maybe we can reprocess the chain as maybe some infirmtion about old orders is not needed?
-
Notes on Scalable Blockchain Protocols.
https://raw.githubusercontent.com/vbuterin/scalability_paper/master/scalability.pdf
-
The Stellar Consensus Protocol:
A Federated Model for Internet-level Consensus
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
-
Lots of really great stuff has come out the last few months:
Bitcoin meets strong consistency (the same proposal we presented at one of our Monday skype calls, minds are converging) http://arxiv.org/pdf/1412.7935v1.pdf
Open-Transactions: Secure Contracts between Untrusted Parties http://www.opentransactions.org/open-transactions.pdf
Authenticated Data Structures, Generically http://www.cs.umd.edu/~mwh/papers/gpads.pdf
NuDB: A Key/Value Store For Decentralized Systems https://github.com/ripple/rippled/blob/master/src/beast/beast/nudb/README.md
A note on crypto currency stabilization: Seigniorage Shares https://github.com/rmsams/stablecoins/blob/master/00-main.pdf
Invertible Bloom Lookup Tables http://arxiv.org/pdf/1101.2245.pdf
The Mini-Blockchain Scheme http://cryptonite.info/files/mbc-scheme-rev2.pdf
Device democracy- Saving the future of the Internet of Things http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=PM&subtype=XB&htmlfid=GBE03620USEN#loaded
Tezos — a self-amending crypto-ledger
White Paper http://tezos.com/white_paper.pdf
Position Paper http://tezos.com/position_paper.pdf
-
The Stellar Consensus Protocol:
A Federated Model for Internet-level Consensus
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
This seems interesting. Can someone ELI5 how "quorum slices" work and the scalability of this method?
-
The Stellar Consensus Protocol:
A Federated Model for Internet-level Consensus
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
BM please note that Stellar has been rewritten and is no longer a clone of Ripple: https://www.stellar.org/blog/stellar-consensus-protocol-proof-code/
-
The Stellar Consensus Protocol:
A Federated Model for Internet-level Consensus
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
BM please note that Stellar has been rewritten and is no longer a clone of Ripple: https://www.stellar.org/blog/stellar-consensus-protocol-proof-code/
I recently took a look at the new stellar, based on SQL and simple operations. It looks like it is trying to be similar to BTS in transaction design. Ultimately SQL is going to be a bottleneck. I will look closer to see if we can glean any good ideas from it.
-
The Stellar Consensus Protocol:
A Federated Model for Internet-level Consensus
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
BM please note that Stellar has been rewritten and is no longer a clone of Ripple: https://www.stellar.org/blog/stellar-consensus-protocol-proof-code/
I recently took a look at the new stellar, based on SQL and simple operations. It looks like it is trying to be similar to BTS in transaction design. Ultimately SQL is going to be a bottleneck. I will look closer to see if we can glean any good ideas from it.
Is it possible to run some sort of quick simulations or tests of different designs? Can we automate this test process?
Also can we look at nature to see how nature does it? It seems to me the most scale-able architectures come from biomimicry. I think it's important not to over engineer in the top down way but instead figure out how you can take advantage of the emergent self organizing properties.
Bitcoin/blockchain wasn't focused so much on efficiency because it was the first to ever do it.
We need to use something like this and then post the comparative simulation results to the public:
https://en.wikipedia.org/wiki/MATLAB
https://www.mathworks.com/products/distriben/
http://www.geatbx.com/docu/
Then we can discuss the results of different approaches. This way prior to it having to reach the test phase in Devshares it could have been proven in simulation to be a good design. That way time can be saved for developers and testers. Also specs speak for themselves once it's explained to everyone what the most important numbers to look for are.
I don't know enough about Bitshares internal processes and it's possible Bitshares already is using the simulation approach.
-
This thread is a rabbit hole of whitepapers. Awesome!!
Read this report on a flight today. The report dicusses different ways to classify projects using blockchain ledgers in centralized and decentralized manners. BitShares was mentioned once (in reference to Pactum). Use cases in the financial system are described as well. Good job Tim.
http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf
-
This thread is a rabbit hole of whitepapers. Awesome!!
Read this report on a flight today. The report dicusses different ways to classify projects using blockchain ledgers in centralized and decentralized manners. BitShares was mentioned once (in reference to Pactum). Use cases in the financial system are described as well. Good job Tim.
http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf
We're the guys behind Pactum btw.
-
This thread is a rabbit hole of whitepapers. Awesome!!
Read this report on a flight today. The report dicusses different ways to classify projects using blockchain ledgers in centralized and decentralized manners. BitShares was mentioned once (in reference to Pactum). Use cases in the financial system are described as well. Good job Tim.
http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf
We're the guys behind Pactum btw.
The report says it is tokenless but also uses DPOS. Can you talk about what mechanism you use to vote for delegates in a tokenless DPOS?
-
This thread is a rabbit hole of whitepapers. Awesome!!
Read this report on a flight today. The report dicusses different ways to classify projects using blockchain ledgers in centralized and decentralized manners. BitShares was mentioned once (in reference to Pactum). Use cases in the financial system are described as well. Good job Tim.
http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf
We're the guys behind Pactum btw.
The report says it is tokenless but also uses DPOS. Can you talk about what mechanism you use to vote for delegates in a tokenless DPOS?
For DPOS to work you need shares (a percentage of ownership which everybody agrees on). This percentage can be dynamic and the result of a contract rather than fixed tokens. In Pactum's case it represents the a specific ratio of past reimbursement of IOUs towards all other players in the game.
Pactum's goal is to assign in a distributed and P2P trustless manner counterparty risk coefficients to any state machines (blockchains, servers, smart contracts, governments, companies, legal systems, etc). These coefficients can then be for risk hedging between state machines. The side-effect is that it organically creates a global unit of account, by definition stable and independent of any governments. This unit of account can be used by any bitAsset or stable-coin system as the ultimate price feed.
We believe that without such a risk determining and hedging mechanism you can't have "an internet of blockchains" nor true globalization of commerce.
-
From the beginning, we were trying to design [Stellar] to be able to reach hundreds of millions of accounts, thousands of transactions. So we’ve stress tested to 100 million accounts and a few hundred transactions per second, and its holding up under those loads.
http://www.coindesk.com/stellar-founder-jed-mccaleb-new-protocol/
-
From the beginning, we were trying to design [Stellar] to be able to reach hundreds of millions of accounts, thousands of transactions. So we’ve stress tested to 100 million accounts and a few hundred transactions per second, and its holding up under those loads.
http://www.coindesk.com/stellar-founder-jed-mccaleb-new-protocol/
Thanks... this will give us a good benchmark for us. I am curious what their latency is (block confirmation time).
-
From the beginning, we were trying to design [Stellar] to be able to reach hundreds of millions of accounts, thousands of transactions. So we’ve stress tested to 100 million accounts and a few hundred transactions per second, and its holding up under those loads.
http://www.coindesk.com/stellar-founder-jed-mccaleb-new-protocol/
Thanks... this will give us a good benchmark for us. I am curious what their latency is (block confirmation time).
Low latency. In practice, nodes can reach consensus at timescales humans
expect for web or payment transactions—i.e., a few seconds at most.
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
-
This thread is a rabbit hole of whitepapers. Awesome!!
Read this report on a flight today. The report dicusses different ways to classify projects using blockchain ledgers in centralized and decentralized manners. BitShares was mentioned once (in reference to Pactum). Use cases in the financial system are described as well. Good job Tim.
http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf
We're the guys behind Pactum btw.
The report says it is tokenless but also uses DPOS. Can you talk about what mechanism you use to vote for delegates in a tokenless DPOS?
For DPOS to work you need shares (a percentage of ownership which everybody agrees on). This percentage can be dynamic and the result of a contract rather than fixed tokens. In Pactum's case it represents the a specific ratio of past reimbursement of IOUs towards all other players in the game.
Pactum's goal is to assign in a distributed and P2P trustless manner counterparty risk coefficients to any state machines (blockchains, servers, smart contracts, governments, companies, legal systems, etc). These coefficients can then be for risk hedging between state machines. The side-effect is that it organically creates a global unit of account, by definition stable and independent of any governments. This unit of account can be used by any bitAsset or stable-coin system as the ultimate price feed.
We believe that without such a risk determining and hedging mechanism you can't have "an internet of blockchains" nor true globalization of commerce.
I have gotten an idea of the message in your post but did not understand it fully. Would you / Can you talk in more detail about that in a mumble hangout or here on the forum? What are the specific use cases of Pactum?