|
SlipperySlope (OP)
|
 |
April 25, 2014, 09:11:37 PM
Last edit: April 13, 2015, 05:22:15 PM by SlipperySlope |
|
[April 13, 2015] On the advice of our diverse set of financial and regulatory attorneys, we are postponing the launch of AI Coin until such time as we have obtained the necessary money services business licenses in 48 States, and BitLicense or equivalent licenses in jurisdictions requiring them. To go forward without those in place would make our business plan a legal risk. [October 22, 2014 - I changed the project name to AI Coin. Drew Hingorani is the co-founder and President, I am CTO] The A.I. Coin project is a multi-year effort to achieve a no-proof-of-work mining implementation in an cryptocurrency that ... Meets or beats the existing proof-of-work implementation with regard to securing the blockchain against attack. Provides sub second response time when acknowledging transactions for certain incorporation into the blockchain, in contrast to Satoshi's Bitcoin which only promises best effort which takes more than a second to reach all nodes and takes minutes on average for the first confirmation. Does not permit double-spending fraud attacks, whereas Satoshi's Bitcoin sometimes does, e.g. the BitUndo service. Meets or beats the existing implementation with regard to no trusted third parties, as Satoshi's Bitcoin is evolving towards hashers' trust of a single, dominant industrial mining pool. Preserves to the greatest possible extent, Satoshi's social contract between developers and users. Specifies how a nomadic mint agent creates new blocks without effort, and allocates block creation rewards to secure the distributed network using conventional data security techniques. Permits the issuance, relay and blockchain storage of microtransactions having 100x lower fees than Satoshi's Bitcoin. Explicitly pays for for the creation, ongoing enhancement, and operation, of the enterprise-class, scalable, secure, and robust networking infrastructure that can accommodate all the world's financial transactions. In contrast, the Satoshi Bitcoin full node network consists of mostly unpaid volunteers. Provides a multi-agent framework upon which human agents and intelligent software agents can be vetted, integrated and paid for skills delivered.
Note that the May 2013 whitepaper below describes a hard fork of bitcoin. That cannot possibly happen unless A.I. Coin is successful and subsequently convinces the Bitcoin community that a good alternative exists for the current industrial mining method. Furthermore, the current approach is not conventional proof-of-stake, rather the block rewards are used to pay for network infrastructure, developers and community support, e. g. through institutions such as the Bitcoin Foundation. It appears that there is no need to pay staking dividends to secure the network. Whitepaper: Bitcoin Cooperative Proof-of-Stake Stephen Reed A hard-fork reconfiguration of the peer to peer Bitcoin network is described that substitutes tamper-evident logs and proof-of-stake consensus for proof-of-work consensus. The block creation rewards and transaction fees are reallocated to establish and staff a secure financial data network capable of handling the world’s transactions with sub-second response time. The new system pays dividends to stake-offering bitcoin holders. In contrast to Satoshi Nakamoto’s mesh network consisting of competing peers, this system uses an enterprise class network that is efficient, robust, and scalable, consisting of cooperating peers. The network backbone nodes host trustless nomadic agents. Thousands of distributed full nodes are paid to replicate a singleton blockchain built upon every 10 minutes by a nomadic mint agent whose actions are verified by its peers. This arrangement enables immediate acknowledgment to an issuing node that its transaction has been accepted. Less effort means that subsidized transaction costs will be lower. Network reconfiguration enables the processing of numerous microtransactions. Stake-weighted distributed consensus is achieved when necessary with less than one-half arbitrarily faulty nodes. Important invariants of the Satoshi Social Contract between core developers and users are maintained: The reward schedule, the blockchain format, the fixed number of bitcoins, and the decentralized, trustless protocol are untouched. The system remains a global distributed database, with additions to the database by consent of the majority, based on a set of transparent rules they follow. GitHub: TexaiCognitiveArchitecture stephenreed@yahoo.comLinkedIn: stephenreedmobile: 1-512-791-7860 Descriptive posts . . . Project Development Approach . . . - Migrate the Texai cognitive architecture project to a public GitHub repository.
- Write software agents to sandbox the Bitcoin Core program - bitcoind, demonstrating the smallest possible network.
- Write additional software agents to complete the verification of peers, migration of responsibilities, and network operations.
Reading List, the current situation . . . - Bitcoin open source implementation of P2P currency Satoshi Nakamoto, February 11, 2009
- Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto, 2009
- Bitcoin Protocol Specification Protocol Version 0.8.6 Krzysztof Okupski
- ASICs and Decentralization FAQ andytoshi
- A Treatise on Altcoins Andytoshi, January 9, 2014
- Anonymous Byzantine Consensus from
Moderately-Hard Puzzles: A Model for Bitcoin Andrew Miller, Joseph J. LaViola, Jr. - The Proof-of-Work Concept Daniel Krawisz, June 24, 2013
- What are checkpoints in bitcoin code?
- Bitcoin Hurdles: the Public Goods Costs of Securing a Decentralized Seigniorage Network which Incentivizes Alternatives and Centralization Tim Swanson, April 9, 2014
- Learning from Bitcoin’s past to improve its future Tim Swanson, April 27, 2014
- Satoshi Client Operation: Overview bitrick
- Global Bitcoin Full Nodes Distribution
- DNS Seeds
- Network Propagation Statistics
- DNS Seeds Availability
- Estimating the number of bitcoin miners Organ Ofcorti
- Wiki - Scalability
- Some Thoughts on Bitcoin Dan Kaminsky
- Dan Kaminskys thoughts on scalability Mike Hearn
- PSA: The amount of full Bitcoin nodes is dropping. Please consider running a full node.
- Bitcoin Nodes: How Many is Enough? Jameson Lopp
- What Are Bitcoin Nodes and Why Do We Need Them? Daniel Cawrey, May 9,2014
- An Order-of-Magnitude Estimate of the Relative Sustainability of the Bitcoin Network Hass McCook, June 5, 2014
- Transactions Withholding Attack AnonyMint
- The Sybil Attack John R. Douceur
- Wiki - Common Vulnerabilities and Exposures
- Wiki - Weaknesses
- Deanonymisation of clients in Bitcoin P2P network Alex Biryukov, Dmitry Khovratovich, Ivan Pustogarov, May 28, 2014
- On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies Nicolas T. Courtois, May 2, 2014
- Primecoin: Cryptocurrency with Prime Number Proof-of-Work Sunny King, July 7, 2013
- CryptoNote v 2.0 Nicolas van Saberhagen, October 17, 2013
- Fullnode Provision full nodes in a datacenter for $20 per month
- On Mining Vitalik Buterin
- The Anatomy of a Money-like Informational Commodity: A Study of Bitcoin [Kindle Edition] Tim Swanson, August 3, 2014 - also available as a free download
- An Investor's Investigation Into The Mining Statistics Of Bitcoin Alternatives Devtome
- The Math Behind Bitcoin ericrykwalder
Reading List, suggested improvements to the Bitcoin network . . . - Information Propagation in the Bitcoin Network Christian Decker, Roger Wattenhofer, 2013
- On Bitcoin and Red Balloons Moshe Babaioff, Shahar Dobzinski, Sigal Oren, and Aviv Zohar, June 2012
- Accelerating Bitcoin’s Transaction Processing, Fast Money Grows on Trees, Not Chains Yonatan Sompolinsky, Aviv Zohar, 2013
- O(1) Block Propagation Gavin Andresen, August 2014
- Bitcoin Improvement Proposals GitHub
- Could Bitcoin Transactions Be 100x Faster? Nicolas T. Courtois, Pinar Emirdag and Daniel A. Nagy, August 2014
- A Scalability Roadmap Gavin Andresen, October 6 2014
- Enabling Blockchain Innovations with Pegged Sidechains Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, October 22, 2014
Reading List, the incumbent competition . . . Reading List, proof-of-stake . . . - Proof of stake instead of proof of work QuantumMechanic, earliest reference - July 10, 2011
- Proof of Stake ripper234, March 11, 2012
- Proof of Stake (Bitcoin Wiki)
- Proof of blockchain fair sharing Bitcoin Wiki
- Crypto-Currency Market Capitalizations
- Proof of Stake Coin List
- What Proof of Stake Is And Why It Matters Vitalik Buterin, Bitcoin Magazine, August 26, 2013
- User:Gmaxwell/alt ideas
- Can we have a serious, constructively critical, but respectful discussion about Proof-of-Stake and "nothing at stake"?
- Proof of Stake Andrew Poelstra, May 28, 2014
- Peercoin Whitepaper
- Decentralised currencies are probably impossible (but let’s at least make them efficient). Ben Laurie, July 5, 2011
- Delegated Proof-of-Stake (DPOS) Daniel Larimer April 3, 2014
- What are the pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work? David Schwartz, April 25, 2013
- Video: How Ripple Works - The Consensus Process
- Slasher: A Punitive Proof-of-Stake Algorithm Vitalik Buterin
- It will cost you nothing to ”kill” a Proof-of-Stake crypto-currency Nicolas Houy, 2014
- POS is MORE vulnerable to 51% attacks than POW (even though wiki says the opposite) Reddit /r/BitcoinSerious 2014
- Proof of Stake Velocity: Building the Social Currency of the Digital Age Larry Ren, April 2014
- TenderMint: Consensus without Mining Jae Kwon
- Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake Iddo Bentov, Charles Lee, Alex Mizrahi, Meni Rosenfeld, June 2014
- Cryptocurrencies without Proof of Work Iddo Bentov, Ariel Gabizon, Alex Mizrahi, June 2014
- Proof of Stake Investment - HBN/PHS/TEK/CAP and more StakeHunter
Reading List, misc altcoin ideas . . . Reading List, global networking . . . - Global Networks: Engineering, Operations and Design, G. Keith Cambron
Reading List, super-peer network introduction . . . Reading List, super-peer network service discovery . . . Reading List, network security and fault tolerance . . . - Distributing Authorities and Verifying Their Claims Nick Szabo, 1997
- The God Protocols Nick Szabo, 1999
- Confidential Auditing Nick Szabo, 1998
- Advances in Distributed Security Nick Szabo, 2003
- Trusted Third Parties Are Security Holes Nick Szabo, 2005
- Pacemaker: Fighting selfishness in availability-aware large-scale networks Fabrice Le Fessant, Gigdem Sengul, Anne-Marie Kermarrec, 2008
- An Approach to Generalising the Self-Repair of Overlay Networks Barry Francis Porter, 2004
- Byzantine consensus in asynchronous message-passing systems: a survey Miguel Correia, Giuliana Santos Veronese, Nuno Ferreira Neves, Paulo Verissimo, 2011
- The Byzantine Generals Problem Mark Nelson, March 18, 2008
- Practical Byzantine fault-tolerance and proactive recovery M. Castro and B. Liskov, 2002
- Byzantine fault-tolerant transaction processing for replicated databases Aldelir Fernando Luiz, Lau Cheuk Lung, Miguel Correia, 2011
- A Robust Byzantine Fault-Tolerant Replication Technique for Peer-to-Peer Content Distribution Ayyasamy Sellappan and Sivanandam Natarajan, 2011
- Secure routing for structured peer-to-peer overlay networks M. Castro, P. Druschel, Y. C. Hu and A. Rowstron, 2002
- Performance and Dependability of structured peer-to-peer overlays M. Castro, M. Costa and A. Rowstron, 2004
- Authenticated Data Structures, Generically Andrew Miller, Michael Hicks, Jonathan Katz, and Elaine Shi, 2014
- Byzantine Fault Tolerant Public Key Authentication in Peer-to-Peer Systems Vivek Pathak, Liviu Iftode
- Secure History Preservation through Timeline Entanglement Petros Maniatis, Mary Baker, 2002
- PeerReview: Practical Accountability for Distributed Systems Andreas Haeberlen, Petr Kuznetsov, Peter Druschel, 2007
- Secure Network Provenance (Technical Report) Wenchao Zhou, Qiong Fei, Arjun Narayan, Andreas Haeberlen, Boon Thau Loo, and Micah Sherr, 2011
- Remote Attestation on Program Execution Liang G, Xuhua Ding, Robert H. Deng, Bing Xie, Hong Mei, 2008
- Attested Append-Only Memory: Making Adversaries Stick to their Word Byung-Gon Chun, Petros Maniatis, Scott Shenker, John Kubiatowicz, 2007
- Attestation Turns Crash Tolerance into Byzantine Tolerance Jonathan Herzog, Jonathan Millen, Brian O’Hanlon, John D. Ramsdell, Ariel Segall,
- Intel Trusted Execution Technology for Server Platforms, William Futral and James Greene, Apress Media, 2013
- vSphere Security and the Virtualization Layer VMware
- Enhanced Cloud Security with HyTrust and VMware Intel
- Building Trust and Compliance in the Cloud with Intel ® Trusted Execution Technology Intel
- Ensuring Content Integrity for Untrusted Peer-to-Peer Content Distribution Networks Nikolaos Michalakis, Robert Soule, Robert Grimm, 2007
- DEFEATING DDOS ATTACKS Cisco Systems
- Closing the Floodgates: DDoS Mitigation Techniques Symantec
- CloudFlare security CloudFlare
- Denial of Service attacks and mitigation techniques: Real time implementation with detailed analysis Subramani rao Sridhar rao
- Three-Tier Security Model for E-Business: Building Trust and Security for Internet Banking Services Yu Lasheng, and MUKWENDE Placide, 2009
- Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.9 CA/Browser Forum, August 4, 2014
- NIST SP 800-57 Recommendation for Key Management Part 3: Application-Specific Key Management Guidance NIST, May 2014
- Distributed Systems Mikito Takada
- In Search of an Understandable Consensus Algorithm (Raft) Diego Ongaro and John Ousterhout, May 2014
- Daily Solar Data U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center
- Latest Solar Radio Flux Report from DRAO, Penticton Natural Resources Canada
- Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees Ahto Buldas, Andres Kroonmaa and Risto Laanoja, 2013
- Efficient Data Structures for Tamper-Evident Logging Scott A. Crosby, Dan S. Wallach, 2009
- Efficient Data Structures for Tamper-Evident Logging slide presentation Scott A. Crosby, Dan S. Wallach, 2009
- Origin-Bound Certificates BrowserAuth.net
Texai Cognitive Architecture Developer bookmarks . . . GitHub & SourceForge Developer bookmarks . . . |
|
|
|
|
|
|
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
SlipperySlope (OP)
|
|
April 25, 2014, 09:14:18 PM |
|
The problems to address as viewed by a member of the developers email list . . . The problem with proof of stake is essentially that there is no cost to creating a proof-of-stake. So there are two problems here: One is that stake voters are free to vote for multiple chains, and since only one will be the "real" chain, i.e. the one with the longest proof of stake, the extra votes will simply go away. So there is no cost to voting for multiple blocks. (A way to discourage this might be to use a signature scheme where signing multiple signatures with the same key causes the key to be revealed. But it is not clear what should be done after the fact, since there is no consensus on which blocks exist or are 'valid' for the proof of stake to fall back on.) Another problem is that the stake voters are chosen 'randomly' but deterministic ally by the content of earlier blocks. This gives a voter to grind through blocks until he finds one which will give him more votes in the future than he otherwise should get. Then the proof of stake becomes a proof-of-work, but one that discourages consensus since all voters will want to do this. The problem is what wrecked Peercoin, which I understand is now centralized (all blocks are signed by the developers to be valid). It is also a problem with NXT, as of the last time any of us at #bitcoin-wizards looked at their code. I talk about this a bit in Section 5 of my document on ASICs and proof of work: https://download.wpsoftware.net/bitcoin/asic-faq.pdfA goal of proof-of-stake is that it should be easy and cheap to create a history, at least relative to proof-of-work. Perhaps people want this for environmental reasons or some sort of "the people should own the means of production" mentality. But this makes it easy to overwrite history. As I described above, an attempt to force all participants to participate in such fraud (thereby making it unfeasible) by, say, having each block voted on by several random participants, doesn't work because the random selection can always be gamed. There have been fun conversations on #bitcoin-wizards about getting random numbers from the sun, or cosmic radiation, or pulsars, since these numbers would be both random and verifiable by many parties. Certainly this would require expensive equipment for all verifying parties, which intuitively is bad for Bitcoin because people verify transactions for free and we want this to be as cheap and easy as possible. (To the best of my knowledge nobody has suggested choosing stake voters from such random numbers, though there have been many ideas and I might've missed it. Pulsars are nice because they give us a clock which everyone within several light years can agree on, which is good for e.g. sharing the Bitcoin blockchain with Martians. This is almost always a more popular discussion topic than PoS.) It's also unclear that PoS can be equitable anyway, since selecting voters based on "stake" seems to favor the very rich disproportionately. |
|
|
|
|
|
SlipperySlope (OP)
|
|
April 25, 2014, 09:43:44 PM |
|
A good problem solving technique is to first solve a simpler problem.
May I suggest setting aside the issue of new coin rewards,
and simply focus on how to achieve consensus
between nodes without PoW.
It quickly becomes clear that if solvable, it is non-trivial.
The core developers stated that no one has achieved
this so far.
This is what Meni said too -- you still need PoW as
issuance mechanism.
We are talking about a node creating a new block
and the rest of the network accepting it.
I think it may be possible with some kind of cryptographic
handshake between nodes, but my ideas on this are
vague at best.
EDIT: If you want to simplify the problem even further, assume all nodes trust each other and are honest.
|
|
|
|
|
|
clout
|
|
April 26, 2014, 08:32:08 AM |
|
The problems to address as viewed by a member of the developers email list . . . The problem with proof of stake is essentially that there is no cost to creating a proof-of-stake. So there are two problems here: One is that stake voters are free to vote for multiple chains, and since only one will be the "real" chain, i.e. the one with the longest proof of stake, the extra votes will simply go away. So there is no cost to voting for multiple blocks. (A way to discourage this might be to use a signature scheme where signing multiple signatures with the same key causes the key to be revealed. But it is not clear what should be done after the fact, since there is no consensus on which blocks exist or are 'valid' for the proof of stake to fall back on.) Another problem is that the stake voters are chosen 'randomly' but deterministic ally by the content of earlier blocks. This gives a voter to grind through blocks until he finds one which will give him more votes in the future than he otherwise should get. Then the proof of stake becomes a proof-of-work, but one that discourages consensus since all voters will want to do this. The problem is what wrecked Peercoin, which I understand is now centralized (all blocks are signed by the developers to be valid). It is also a problem with NXT, as of the last time any of us at #bitcoin-wizards looked at their code. I talk about this a bit in Section 5 of my document on ASICs and proof of work: https://download.wpsoftware.net/bitcoin/asic-faq.pdfA goal of proof-of-stake is that it should be easy and cheap to create a history, at least relative to proof-of-work. Perhaps people want this for environmental reasons or some sort of "the people should own the means of production" mentality. But this makes it easy to overwrite history. As I described above, an attempt to force all participants to participate in such fraud (thereby making it unfeasible) by, say, having each block voted on by several random participants, doesn't work because the random selection can always be gamed. There have been fun conversations on #bitcoin-wizards about getting random numbers from the sun, or cosmic radiation, or pulsars, since these numbers would be both random and verifiable by many parties. Certainly this would require expensive equipment for all verifying parties, which intuitively is bad for Bitcoin because people verify transactions for free and we want this to be as cheap and easy as possible. (To the best of my knowledge nobody has suggested choosing stake voters from such random numbers, though there have been many ideas and I might've missed it. Pulsars are nice because they give us a clock which everyone within several light years can agree on, which is good for e.g. sharing the Bitcoin blockchain with Martians. This is almost always a more popular discussion topic than PoS.) It's also unclear that PoS can be equitable anyway, since selecting voters based on "stake" seems to favor the very rich disproportionately. transactions as proof of stake solves these issues. proof of work mining is still used to produce blocks randomly, but proof of stake ( coin days destroyed from transactions) is used for consensus. http://the-iland.net/static/downloads/TransactionsAsProofOfStake.pdf |
|
|
|
|
|
calian
|
|
April 26, 2014, 10:13:39 AM |
|
I would argue that you can't break the 21,000,000 coin guarantee and still have Bitcoin so the inflationary model of PPC is out. Instead I'd suggest a hard fork to a hybrid POW/POS system with target block times of 2 minutes. POW blocks would still target 10 minute block times and receive the block rewards + transaction fees. POS blocks would target 2.5 minute block times and receive any transaction fees included in their block. This solution continues to reward those who have invested millions in Bitcoin specific hardware while encouraging Bitcoin holders with any significant stake to run nodes.
|
|
|
|
|
Peter R
Legendary
 Offline
Activity: 1162
Merit: 1007
|
|
April 26, 2014, 07:43:25 PM |
|
Will the initial distribution of wealth in Bitcoin-PoS be exactly as per the unspent outputs in the bitcoin blockchain at a certain point in time in the future, or will you consider redistribution of wealth if you find popular support for it?
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 01:45:10 AM |
|
Will the initial distribution of wealth in Bitcoin-PoS be exactly as per the unspent outputs in the bitcoin blockchain at a certain point in time in the future, or will you consider redistribution of wealth if you find popular support for it?
I would keep the blockchain as is. The best case for redistribution to add to Satoshi's social contract would be to make permanent the up-to-now unspent coins that Satoshi mined while alpha testing the live chain. Put this up for debate and see if Satoshi surfaces to comment. He could easily have disposed of, or overwritten, the private keys as they were used to create his stash of 980,000 according to http://bitslog.wordpress.com/2013/04/24/satoshi-s-fortune-a-more-accurate-figure/. |
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 03:44:54 AM
Last edit: May 29, 2014, 07:16:37 PM by SlipperySlope |
|
A Bitcoin Super-Peer NetworkAndytoshi, a participant in the bitcoin developers mail list advised me to solve the problem of distributed consensus. While thinking about this problem, advice given to me by others in this forum came to mind. I will attempt to solve Bitcoin proof-of-stake by solving a simpler and larger problem, revisiting the thoughts of Satoshi, in light of how Bitcoin has come to operate. Satoshi quit commenting on this forum about the time that slush started the first mining pool. Satoshi's defining paper had no provision for pools, yet in the recent four-day period, a mere 68 public and private pools mined all the bitcoin . . ..  https://blockchain.info/pools?timespan=4days. . . out of a total 7,650 full nodes, and 2.6 million online wallets reported by Blockchain.info and Coinbase. https://getaddr.bitnodes.io/Today's Bitcoin network is different than what Satoshi may have envisioned in his defining paper, but it works. I believe that the Satoshi Social Contract, between developers and users, accommodates a variety of network topologies and responsibilities. To overcome the problem of how to provide distributed consensus about which version of the blockchain is correct, I propose to build a blockchain that does not fork. The coin-creating responsibility is assigned to one agent, rotated round robin every 10 minutes among the 100 largest trustworthy such agents.  A super-peer network of 100 or less pools use Chord technology to form a robust ring. A mining-permit token is advanced around the ring every 10 minutes. The pool with the token creates the new block and via solicited proof-of-stake shares, distributes the block creation reward to its clients, and to the other super-peers in the ring in proportion to their reported proof-of-stake shares. The proof-of-stake shares are to-myself transactions with a 10 minute age, in which the transaction amount in bitcoin is input into the reward distribution algorithm executed by the super-peer. Proof-of-stake shares are thus analogous to proof-of-work shares submitted to a pool today by client hashers. Here is a diagram of Chord ring topology. These are the closely connected super-peers - the 100 pools - of the proposed Bitcoin proof-of-stake network . . .  I seek two sorts of critiques, (1) if this does not work then how could it be modified to work? (2) what are the likely attacks? I also want to be sure these ideas are clearly stated. If the idea maybe could work then it has these advantages over the current Bitcoin network, beyond the efficiency argument of proof-of-stake vs. existing money-consuming proof-of-work . . .- A single instance of bitcoind is deterministically chosen to create the new block - there are no redundant block creation attempts, no forked blockchains, no orphans and no waste.
- Internet bandwidth usage is greatly reduced in a topology where client blockchain validating and maintaining full-nodes communicate with a single pool, and potentially with a set of backup pools. High bandwidth and high availability channels between pools reflect the status quo with how Bitcoin works today.
- Human judgement of pool trustworthiness removes the need to algorithmically provide it - again this is the status quo.
- Because new transactions can reach a pool in one hop, and reach the pool creating the new block in one more hop, network latency is reduced, potentially allowing a reduction of confirmation times, and reducing the possibility of double-spend versus the current Bitcoin network.
- The reward distribution algorithm does not have to be strictly in proportion to the offered bitcoin stake, rather it could and should be distributed in part to the super peers in return for substantial bandwidth and data security costs that they incur. Full node operators should receive sufficient reward to accommodate their expenses validating and replicating the blockchain, whose transactions grow at 3.2x annually, far in excess of Moore's Law cost reductions. The remaining large portion of the block creation reward, I propose to distribute in a manner which disproportionately rewards smaller stake holders, and perhaps somehow those wallet-owners not running full-nodes. The manner of distribution should should somehow dispel "the rich get richer".
Your thoughts?
|
|
|
|
|
|
clout
|
|
April 27, 2014, 03:54:20 AM |
|
can someone please explain to me why using transactions as proof of stake does not work to solve the problems that you are attempting to address
|
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 04:29:28 AM |
|
can someone please explain to me why using transactions as proof of stake does not work to solve the problems that you are attempting to address
Coin age as I describe it above is a to-myself transaction. If this is not what you mean, then please clarify. |
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 04:51:58 AM |
|
Who chooses the 100 nodes
Somehow they form up and compete. To be fair, pools could have other pools as clients without losing the super-peer topology benefits. The nodes are mining pools that, like today, advertise and solicit clients. The 100 is arbitrary. It is a simple a round number larger than the effective number of nodes that control bitcoin mining today. Slightly more decentralized than today. The idea is to have a high bandwidth Bitcoin network backbone to handle every one of the worlds financial transactions plus all the machine-to-machine transactions coming with the Internet-of-things. |
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 05:49:58 AM |
|
"Somehow" ? I think it's a critical piece you need to figure out.
Well, the first thought that comes to mind is to distribute the open source code, in the Java language, for operating a compliant pool. I would create a reference pool if I cannot sign on at least one existing Bitcoin mining pool. New pools would join the super-peer network In the same manner that Bitcoin Core clients connect to the existing network via a built-in set of IP addresses - I think, Bitcoin pools, and altcoin pools today are advertised by their promoters, and joined by clients on the basis of human judgement. I would retain that working aspect of the status quo. |
|
|
|
|
|
clout
|
|
April 27, 2014, 06:12:03 AM |
|
can someone please explain to me why using transactions as proof of stake does not work to solve the problems that you are attempting to address
Coin age as I describe it above is a to-myself transaction. If this is not what you mean, then please clarify. you destroy coin age through transactions. it doesnt have to be to yourself. peer coin uses the "to-myself transaction" as proof of stake substitute to mining. this however, is a manual process whereas using coin age (or days) from transaction is essentially automatic. |
|
|
|
|
|
clout
|
|
April 27, 2014, 06:16:18 AM |
|
also transactions as proof of stake (tapos) is different than delegated proof of stake (dpos) although dpos uses the same consensus of proof of stake through coin days destroy from transactions.
esssentially using transaction as proof of stake allows you to come to consensus through pos and block production can be determined in any fashion you see fit. the original tapos paper uses mining for block production, but dpos makes block production faster
|
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 06:23:37 AM |
|
also transactions as proof of stake (tapos) is different than delegated proof of stake (dpos) although dpos uses the same consensus of proof of stake through coin days destroy from transactions.
esssentially using transaction as proof of stake allows you to come to consensus through pos and block production can be determined in any fashion you see fit. the original tapos paper uses mining for block production, but dpos makes block production faster
I believe you mean https://bitcointalk.org/index.php?topic=354573.msg3793765#msg3793765, which is the first thread I could find on the topic. I will study the whitepaper. Thanks for the tip. I am open to all improvements. |
|
|
|
|
|
clout
|
|
April 27, 2014, 06:26:05 AM |
|
Who chooses the 100 nodes
each transaction has an implicit proof of stake and therefore an implicit vote towards the security of the network. everyone in the network votes for there own delegates. this is a process that is automated in the client but is easily manually adjusted. essentially the most reliable nodes will be voted to the top 100 and if they ever fail to do their job (fail to produce a block when it is their turn or do not include all confirmed transaction in their produced block) the are immediately fired since the client registers such actions and can switch votes or vote against a delegate. |
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 06:31:08 AM |
|
Who chooses the 100 nodes
each transaction has an implicit proof of stake and therefore an implicit vote towards the security of the network. everyone in the network votes for there own delegates. this is a process that is automated in the client but is easily manually adjusted. essentially the most reliable nodes will be voted to the top 100 and if they ever fail to do their job (fail to produce a block when it is their turn or do not include all confirmed transaction in their produced block) the are immediately fired since the client registers such actions and can switch votes or vote against a delegate. Thanks for an idea how to automate it. I was thinking that clients enroll with a pool, and possibly change to a different pool, manually using their judgement as is the case today with regard to miners and their pools. Perhaps this aspect of trustworthiness does not have to be defined algorithmically. |
|
|
|
|
|
clout
|
|
April 27, 2014, 06:37:42 AM |
|
the manual process is choosing your delegate, although this can be automated so that the client simply choose one of the delegates with the best reputation. the real automation lies in using transaction as proof of stake, because it does not require that someone volunteer their stake and private key.
i think the voting process should be automated within the client, because the job that these delegates have to do is very simple - produce a block when it is your turn, include all confirmed transactions. this is not something that many would be diligent in observing, but is easily detectable by the client.
|
|
|
|
|
|
SlipperySlope (OP)
|
|
April 27, 2014, 06:50:30 AM |
|
the manual process is choosing your delegate, although this can be automated so that the client simply choose one of the delegates with the best reputation. the real automation lies in using transaction as proof of stake, because it does not require that someone volunteer their stake and private key.
i think the voting process should be automated within the client, because the job that these delegates have to do is very simple - produce a block when it is your turn, include all confirmed transactions. this is not something that many would be diligent in observing, but is easily detectable by the client.
Thanks for clarifying your point. |
|
|
|
|
|
LeChatNoir
|
|
April 27, 2014, 07:34:49 AM |
|
I have not the skills to contribute to this discussion but as an investor i'm watching this very closely since i firmly believe that some kind of working PoS is the future of cryptocurrencies.
I also think that bitcoin PoW will show serious weaknesses in the future beside the fact that it is a waste of energy.
SlipperySlope the solution you proposed is very interesting please keep working on it, if you find a strong and efficent way to achieve consensus using PoS i think 99% of the job is done, distribution is not really a problem as many people think.
|
Coinpanion.io - Copy Successful Crypto Traders
|
|
|
|
