Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: SlipperySlope on April 25, 2014, 09:11:37 PM



Title: AI Coin Development Diary
Post by: SlipperySlope on April 25, 2014, 09:11:37 PM
[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 (https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE) 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 (https://github.com/TexaiCognitiveArchitecture)

https://i.imgur.com/yj2KKFU.png

stephenreed@yahoo.com
LinkedIn: stephenreed (http://www.linkedin.com/in/stephenreed)
mobile: 1-512-791-7860


Descriptive posts . . .

  • A Bitcoin Super-Peer Network (https://bitcointalk.org/index.php?topic=584719.msg6415632#msg6415632)
  • After-the-fact Distributed Consensus and Repair (https://bitcointalk.org/index.php?topic=584719.msg6431769#msg6431769)
  • Bitcoin Proof-of-stake Super Peer Network Diagram (https://bitcointalk.org/index.php?topic=584719.msg6441624#msg6441624)
  • Transitional SHA-256 Mining Multipool (https://bitcointalk.org/index.php?topic=584719.msg6457249#msg6457249)
  • The Satoshi Social Contract (https://bitcointalk.org/index.php?topic=584719.msg6464712#msg6464712)
  • The Hard Fork (https://bitcointalk.org/index.php?topic=584719.msg6496868#msg6496868)
  • Bitcoin Proof-of-Stake Node Roles and Responsibilities, from the Whitepaper being written (https://bitcointalk.org/index.php?topic=584719.msg6563442#msg6563442)
  • CPoS Network Proxy (https://bitcointalk.org/index.php?topic=584719.msg6974028#msg6974028)
  • Bitcoin Cooperating Agent Diagram (https://bitcointalk.org/index.php?topic=584719.msg7024155#msg7024155)
  • Bitcoin Cooperating Agent Design (https://bitcointalk.org/index.php?topic=584719.msg7045701#msg7045701)
  • Communication with the BlackCoin Foundation (https://bitcointalk.org/index.php?topic=584719.msg7092898#msg7092898)
  • Advice on securing a re-engineered Bitcoin network (https://bitcointalk.org/index.php?topic=584719.msg7130896#msg7130896)
  • CPoS To Be Written in the Java programming Language (https://bitcointalk.org/index.php?topic=584719.msg7191760#msg7191760)
  • CPoS To Be Implemented Using the Texai Cognitive Architecture (https://bitcointalk.org/index.php?topic=584719.msg7347081#msg7347081)
  • A Blockchain-Based Exchange Between Proof-of-Work (PoW) Bitcoin and Cooperative Proof-of-Stake (CPoS) Bitcoin (https://bitcointalk.org/index.php?topic=584719.msg7348153#msg7348153)
  • August 18, 2014 Status and Thoughts (https://bitcointalk.org/index.php?topic=584719.msg8419392#msg8419392)
  • TexaiCoin (https://bitcointalk.org/index.php?topic=584719.msg8601276#msg8601276)
  • Self-signed X.509 Certificate Transparency (https://bitcointalk.org/index.php?topic=584719.msg8958941#msg8958941)

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 (http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source) Satoshi Nakamoto, February 11, 2009
  • Bitcoin: A Peer-to-Peer Electronic Cash System (https://bitcoin.org/bitcoin.pdf) Satoshi Nakamoto, 2009
  • Bitcoin Protocol Specification Protocol Version 0.8.6 (http://enetium.com/resources/Bitcoin.pdf) Krzysztof Okupski
  • ASICs and Decentralization FAQ (https://download.wpsoftware.net/bitcoin/asic-faq.pdf) andytoshi
  • A Treatise on Altcoins (https://en.bitcoin.it/wiki/User:Andytoshi/A_Treatise_on_Altcoins) Andytoshi, January 9, 2014
  • Anonymous Byzantine Consensus from
    Moderately-Hard Puzzles: A Model for Bitcoin (https://socrates1024.s3.amazonaws.com/consensus.pdf) Andrew Miller, Joseph J. LaViola, Jr.
  • The Proof-of-Work Concept (http://nakamotoinstitute.org/mempool/the-proof-of-work-concept/) Daniel Krawisz, June 24, 2013
  • What are checkpoints in bitcoin code? (https://bitcointalk.org/index.php?topic=194078.msg2013948#msg2013948)
  • Bitcoin Hurdles: the Public Goods Costs of Securing a Decentralized Seigniorage Network which Incentivizes Alternatives and Centralization (http://www.ofnumbers.com/wp-content/uploads/2014/04/Bitcoins-Public-Goods-hurdles.pdf) Tim Swanson, April 9, 2014
  • Learning from Bitcoin’s past to improve its future (http://www.ofnumbers.com/wp-content/uploads/2014/04/Learning-from-Bitcoins-past.pdf) Tim Swanson, April 27, 2014
  • Satoshi Client Operation: Overview (https://bitcointalk.org/index.php?topic=41718.msg507953#msg507953) bitrick
  • Global Bitcoin Full Nodes Distribution (https://getaddr.bitnodes.io/)
  • DNS Seeds (https://bitcointalk.org/index.php?topic=572510.0)
  • Network Propagation Statistics (http://bitcoinstats.com/network/propagation/)
  • DNS Seeds Availability (http://bitcoinstats.com/network/dns-servers/)
  • Estimating the number of bitcoin miners (http://organofcorti.blogspot.com/2014/05/165-estimating-number-of-bitcoin-miners.html) Organ Ofcorti
  • Wiki - Scalability (https://en.bitcoin.it/wiki/Scalability)
  • Some Thoughts on Bitcoin (http://www.slideshare.net/dakami/bitcoin-8776098) Dan Kaminsky
  • Dan Kaminskys thoughts on scalability (https://bitcointalk.org/index.php?topic=34597.msg430804#msg430804) Mike Hearn
  • PSA: The amount of full Bitcoin nodes is dropping. Please consider running a full node. (http://www.reddit.com/r/Bitcoin/comments/24645i/psa_the_amount_of_full_bitcoin_nodes_is_dropping/)
  • Bitcoin Nodes: How Many is Enough? (http://coinchomp.com/2014/03/19/bitcoin-nodes-many-enough/) Jameson Lopp
  • What Are Bitcoin Nodes and Why Do We Need Them? (http://www.coindesk.com/bitcoin-nodes-need/) Daniel Cawrey, May 9,2014
  • An Order-of-Magnitude Estimate of the Relative Sustainability of the Bitcoin Network (http://www.scribd.com/doc/228253109/The-Relative-Sustainability-of-the-Bitcoin-Network-by-Hass-McCook) Hass McCook, June 5, 2014
  • Transactions Withholding Attack (https://bitcointalk.org/index.php?topic=336350.msg3609690#msg3609690) AnonyMint
  • The Sybil Attack (http://www.few.vu.nl/~mconti/teaching/ATCNS2010/ATCS/Sybil/Sybil.pdf) John R. Douceur
  • Wiki - Common Vulnerabilities and Exposures (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures)
  • Wiki - Weaknesses (https://en.bitcoin.it/wiki/Weaknesses)
  • Deanonymisation of clients in Bitcoin P2P network (http://arxiv.org/pdf/1405.7418v2) Alex Biryukov, Dmitry Khovratovich, Ivan Pustogarov, May 28, 2014
  • On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies (http://cryptome.org/2014/05/bitcoin-suicide.pdf) Nicolas T. Courtois, May 2, 2014
  • Primecoin: Cryptocurrency with Prime Number Proof-of-Work (http://primecoin.org/static/primecoin-paper.pdf) Sunny King, July 7, 2013
  • CryptoNote v 2.0 (https://cryptonote.org/whitepaper.pdf) Nicolas van Saberhagen, October 17, 2013
  • Fullnode (http://fullnode.co) Provision full nodes in a datacenter for $20 per month
  • On Mining (https://blog.ethereum.org/2014/06/19/mining/) Vitalik Buterin
  • The Anatomy of a Money-like Informational Commodity: A Study of Bitcoin [Kindle Edition] (http://www.amazon.com/Anatomy-Money-like-Informational-Commodity-Bitcoin-ebook/dp/B00MEAO7XK) Tim Swanson, August 3, 2014 - also available as a free download
  • An Investor's Investigation Into The Mining Statistics Of Bitcoin Alternatives (http://www.devtome.com/doku.php?id=a_massive_investigation_of_instamines_and_fastmines_for_the_top_alt_coins) Devtome
  • The Math Behind Bitcoin (http://blog.chain.com/post/95218566791/the-math-behind-bitcoin) ericrykwalder

Reading List, suggested improvements to the Bitcoin network . . .

  • Information Propagation in the Bitcoin Network (http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf) Christian Decker, Roger Wattenhofer, 2013
  • On Bitcoin and Red Balloons (http://research.microsoft.com/pubs/156072/bitcoin.pdf) Moshe Babaioff, Shahar Dobzinski, Sigal Oren, and Aviv Zohar, June 2012
  • Accelerating Bitcoin’s Transaction Processing, Fast Money Grows on Trees, Not Chains (https://eprint.iacr.org/2013/881.pdf) Yonatan Sompolinsky, Aviv Zohar, 2013
  • O(1) Block Propagation (https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2) Gavin Andresen, August 2014
  • Bitcoin Improvement Proposals (https://github.com/bitcoin/bips/) GitHub
  • Could Bitcoin Transactions Be 100x Faster? (http://www.nicolascourtois.com/bitcoin/POSTER_100x_Secrypt2014_v1.0.pdf) Nicolas T. Courtois, Pinar Emirdag and Daniel A. Nagy, August 2014
  • A Scalability Roadmap (https://bitcoinfoundation.org/2014/10/a-scalability-roadmap/) Gavin Andresen, October 6 2014
  • Enabling Blockchain Innovations with Pegged Sidechains (http://www.blockstream.com/sidechains.pdf) 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 . . .

  • SWIFT Messaging Services Distributed Architecture Phase 1 (http://www.swift.com/solutions/industry_initiatives/image_doc/DA_Phase_1_white_paper_200912_1_5.pdf) SWIFT, 2009
  • Pricing made easier For new SWIFT customers (http://www.swift.com/solutions/pricing/fs_pricing_easier_200803.pdf) SWIFT
  • VisaNet The technology behind Visa (http://usa.visa.com/download/corporate/_media/visanet-technology/visa-net-booklet.pdf) Visa
  • Inside Visa's Data Center (http://www.networkcomputing.com/networking/inside-visas-data-center/d/d-id/1234221?) Network Computing, May 19, 2013
  • Digital Currency Deep Dive: Is Bitcoin Cheaper and More Efficient than Traditional Payments? (http://www.pymnts.com/news/2014/digital-currency-deep-dive-is-bitcoin-cheaper-and-more-efficient-than-traditional-payments/#.U6sq-h__5k8) David S. Evans

Reading List, proof-of-stake . . .

  • Proof of stake instead of proof of work (https://bitcointalk.org/index.php?topic=27787.msg349645#msg349645) QuantumMechanic, earliest reference - July 10, 2011
  • Proof of Stake (https://bitcointalk.org/index.php?topic=68213.msg795083#msg795083) ripper234, March 11, 2012
  • Proof of Stake (https://en.bitcoin.it/wiki/Proof_of_Stake) (Bitcoin Wiki)
  • Proof of blockchain fair sharing (https://en.bitcoin.it/wiki/Proof_of_blockchain_fair_sharing) Bitcoin Wiki
  • Crypto-Currency Market Capitalizations (https://coinmarketcap.com/)
  • Proof of Stake Coin List (https://bitcointalk.org/index.php?topic=458726.0)
  • What Proof of Stake Is And Why It Matters (http://bitcoinmagazine.com/6528/) Vitalik Buterin, Bitcoin Magazine, August 26, 2013
  • User:Gmaxwell/alt ideas (https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas)
  • Can we have a serious, constructively critical, but respectful discussion about Proof-of-Stake and "nothing at stake"? (http://www.reddit.com/r/peercoin/comments/1wi20p/can_we_have_a_serious_constructively_critical_but/)
  • Proof of Stake (http://download.wpsoftware.net/bitcoin/pos.pdf) Andrew Poelstra, May 28, 2014
  • Peercoin Whitepaper (http://peercoin.net/assets/paper/peercoin-paper.pdf)
  • Decentralised currencies are probably impossible (but let’s at least make them efficient). (http://www.links.org/files/decentralised-currencies.pdf) Ben Laurie, July 5, 2011
  • Delegated Proof-of-Stake (DPOS) (http://107.170.30.182/security/delegated-proof-of-stake.php) Daniel Larimer April 3, 2014
  • What are the pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work? (http://bitcoin.stackexchange.com/questions/10180/what-are-the-pros-and-cons-of-ripples-consensus-as-compared-with-bitcoins-proo) David Schwartz, April 25, 2013
  • Video: How Ripple Works - The Consensus Process (https://www.youtube.com/watch?v=17RtYvWb60o[/url)
  • Slasher: A Punitive Proof-of-Stake Algorithm (http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm) Vitalik Buterin
  • It will cost you nothing to ”kill” a Proof-of-Stake crypto-currency (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCkQFjAA&url=http%3A%2F%2Fpapers.ssrn.com%2Fsol3%2Fpapers.cfm%3Fabstract_id%3D2393940&ei=ZhtjU6zTCtGOyATgiIHIAQ&usg=AFQjCNF5mkzHBGrKX7nLUoiuZwudKB3YqA&sig2=4hSST6-H5AyOIBOdxFJZ3Q&bvm=bv.65788261,d.aWw) Nicolas Houy, 2014
  • POS is MORE vulnerable to 51% attacks than POW (even though wiki says the opposite) (http://www.reddit.com/r/BitcoinSerious/comments/1xpzb8/pos_is_more_vulnerable_to_51_attacks_than_pow/) Reddit /r/BitcoinSerious 2014
  • Proof of Stake Velocity: Building the Social Currency of the Digital Age (http://www.reddcoin.com/papers/PoSV.pdf) Larry Ren, April 2014
  • TenderMint: Consensus without Mining (http://tendermint.com/docs/tendermint_v04.pdf) Jae Kwon
  • Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake (http://eprint.iacr.org/2014/452.pdf) Iddo Bentov, Charles Lee, Alex Mizrahi, Meni Rosenfeld, June 2014
  • Cryptocurrencies without Proof of Work (http://www.cs.technion.ac.il/~idddo/CoA.pdf) Iddo Bentov, Ariel Gabizon, Alex Mizrahi, June 2014
  • Proof of Stake Investment - HBN/PHS/TEK/CAP and more (https://bitcointalk.org/index.php?topic=498739.0) StakeHunter

Reading List, misc altcoin ideas . . .

  • A TorPath to TorCoin: Proof-of-Bandwidth Altcoins for Compensating Relays (https://docs.google.com/file/d/0B7r4osQgWVqKTHdxTlowUVpsVmJRcjF3Y3dtcTVscFhEaW5F) Mainak Ghosh, Miles Richardson, Bryan Ford, and Rob Jansen
  • Cyptocoins List, may be sorted by volume (http://www.cryptocoincharts.info/v2/coins/info) Cryptocharts
  • Decentralized Autonomous Organization (https://en.wikipedia.org/wiki/Distributed_Autonomous_Organization) Wikipedia
  • Factom Whitepaper - Business Processes Secured by Immutable Audit Trails on the Blockchain (http://file:///home/reed/Downloads/Factom_Whitepaper.pdf) Paul Snow, Brian Deery, Jack Lu, David Johnston, Peter Kirby, December 2014

Reading List, global networking . . .

  • Global Networks: Engineering, Operations and Design, G. Keith Cambron

Reading List, super-peer network introduction . . .

  • Designing a super-peer network (http://ilpubs.stanford.edu:8090/594/1/2003-33.pdf) Beverly Yang, Hector Garcia-Molina, 2003
  • Chord: A scalable peer-to-peer lookup service for internet applications (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.663&rep=rep1&type=pdf)

Reading List, super-peer network service discovery . . .

  • One Ring to Rule them All: Service Discovery and Binding in Structured Peer-to-Peer Overlay Networks (http://research.microsoft.com/users/mcastro/publications/ring.pdf) Miguel Castro, Peter Druschel, Anne-Marie Kermarrec, Antony Rowstron, 2002
  • Discovery of Stable Peers in a Self-OrganisingPeer-to-Peer Gradient Topology (http://www.researchgate.net/publication/220973572_Discovery_of_Stable_Peers_in_a_Self-organising_Peer-to-Peer_Gradient_Topology/file/79e4150bdcabb3e279.pdf) Jan Sacha, Jim Dowling, Raymond Cunningham, and Rene Meir, 2006

Reading List, network security and fault tolerance . . .

  • Distributing Authorities and Verifying Their Claims (http://szabo.best.vwh.net/authorities.html) Nick Szabo, 1997
  • The God Protocols (http://szabo.best.vwh.net/msc.html) Nick Szabo, 1999
  • Confidential Auditing (http://szabo.best.vwh.net/confidential.html) Nick Szabo, 1998
  • Advances in Distributed Security (http://szabo.best.vwh.net/distributed.html) Nick Szabo, 2003
  • Trusted Third Parties Are Security Holes (http://nakamotoinstitute.org/literature/18/html/) Nick Szabo, 2005
  • Pacemaker: Fighting selfishness in availability-aware large-scale networks (http://hal.inria.fr/docs/00/35/10/51/PDF/RR-6594.pdf) Fabrice Le Fessant, Gigdem Sengul, Anne-Marie Kermarrec, 2008
  • An Approach to Generalising the Self-Repair of Overlay Networks (http://www.barryfp.com/papers/porter07thesis.pdf) Barry Francis Porter, 2004
  • Byzantine consensus in asynchronous message-passing systems: a survey (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.301.5623&rep=rep1&type=pdf) Miguel Correia, Giuliana Santos Veronese, Nuno Ferreira Neves, Paulo Verissimo, 2011
  • The Byzantine Generals Problem (http://www.drdobbs.com/cpp/the-byzantine-generals-problem/206904396) Mark Nelson, March 18, 2008
  • Practical Byzantine fault-tolerance and proactive recovery (http://research.microsoft.com/users/mcastro/publications/p398-castro-bft-tocs.pdf) M. Castro and B. Liskov, 2002
  • Byzantine fault-tolerant transaction processing for replicated databases (http://www.gsd.inesc-id.pt/~mpc/pubs/luiz_db_replication_nca11_final.pdf) Aldelir Fernando Luiz, Lau Cheuk Lung, Miguel Correia, 2011
  • A Robust Byzantine Fault-Tolerant Replication Technique for Peer-to-Peer Content Distribution (http://thescipub.com/pdf/10.3844/jcssp.2011.159.166) Ayyasamy Sellappan and Sivanandam Natarajan, 2011
  • Secure routing for structured peer-to-peer overlay networks (http://research.microsoft.com/users/mcastro/publications/security-p2p.pdf) M. Castro, P. Druschel, Y. C. Hu and A. Rowstron, 2002
  • Performance and Dependability of structured peer-to-peer overlays (http://research.microsoft.com/users/mcastro/publications/castro04performance.pdf) M. Castro, M. Costa and A. Rowstron, 2004
  • Authenticated Data Structures, Generically (http://www.cs.umd.edu/~mwh/papers/miller14gpads.html) Andrew Miller, Michael Hicks, Jonathan Katz, and Elaine Shi, 2014
  • Byzantine Fault Tolerant Public Key Authentication in Peer-to-Peer Systems (http://www.cs.rutgers.edu/~iftode/byzauth05.pdf) Vivek Pathak, Liviu Iftode
  • Secure History Preservation through Timeline Entanglement (http://www.usenix.org/events/sec02/full_papers/maniatis/maniatis.pdf) Petros Maniatis, Mary Baker, 2002
  • PeerReview: Practical Accountability for Distributed Systems (http://infosec.pku.edu.cn/~p2p/slides/%5BSOSP07%5D%20PeerReview%20---%20Practical%20Accountability%20for%20Distributed%20Systems.pdf) Andreas Haeberlen, Petr Kuznetsov, Peter Druschel, 2007
  • Secure Network Provenance (Technical Report) (http://www.cis.upenn.edu/~ahae/papers/snp-tr2.pdf) Wenchao Zhou, Qiong Fei, Arjun Narayan, Andreas Haeberlen, Boon Thau Loo, and Micah Sherr, 2011
  • Remote Attestation on Program Execution (http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf) Liang G, Xuhua Ding, Robert H. Deng, Bing Xie, Hong Mei, 2008
  • Attested Append-Only Memory: Making Adversaries Stick to their Word (http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf) Byung-Gon Chun, Petros Maniatis, Scott Shenker, John Kubiatowicz, 2007
  • Attestation Turns Crash Tolerance into Byzantine Tolerance (http://www.mitre.org/sites/default/files/pdf/10_0959.pdf‎) 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 (http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-E9B71B85-FBA3-447C-8A60-DEE2AE1A405A.html) VMware
  • Enhanced Cloud Security with HyTrust and VMware (http://www.intel.com/content/dam/doc/reference-architecture/cloud-computing-enhanced-cloud-security-hytrust-vmware-architecture.pdf) Intel
  • Building Trust and Compliance in the Cloud with Intel ® Trusted Execution Technology (http://www.hytrust.com/downloads/casestudy/download.php?file=cloud-computing-txt-xeon-twse-whitepaper.pdf) Intel
  • Ensuring Content Integrity for Untrusted Peer-to-Peer Content Distribution Networks (http://usenix.org/event/nsdi07/tech/full_papers/michalakis/michalakis.pdf) Nikolaos Michalakis, Robert Soule, Robert Grimm, 2007
  • DEFEATING DDOS ATTACKS (http://www.cisco.com/c/en/us/products/collateral/security/traffic-anomaly-detector-xt-5600a/prod_white_paper0900aecd8011e927.pdf) Cisco Systems
  • Closing the Floodgates: DDoS Mitigation Techniques (http://www.symantec.com/connect/articles/closing-floodgates-ddos-mitigation-techniques) Symantec
  • CloudFlare security (https://www.cloudflare.com/features-security) CloudFlare
  • Denial of Service attacks and mitigation techniques: Real time implementation with detailed analysis (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8&ved=0CJoBEBYwCQ&url=http%3A%2F%2Fwww.sans.org%2Freading-room%2Fwhitepapers%2Fdetection%2Fdenial-service-attacks-mitigation-techniques-real-time-implementation-detailed-analysi_33764&ei=jQaJU_PwIoqXqAbBnoHoBw&usg=AFQjCNFHrQDQwSkDqo_EaulsTbqv3vdDjw&sig2=WdLtRtxMJnGSTl9RgqOUmA&bvm=bv.67720277,d.b2k) Subramani rao Sridhar rao
  • Three-Tier Security Model for E-Business: Building Trust and Security for Internet Banking Services (http://www.academypublisher.com/proc/iscsct09/papers/iscsct09p114.pdf) Yu Lasheng, and MUKWENDE Placide, 2009
  • Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.9 (https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_9.pdf) CA/Browser Forum, August 4, 2014
  • NIST SP 800-57 Recommendation for Key Management Part 3: Application-Specific Key Management Guidance (http://csrc.nist.gov/publications/drafts/800-57pt3_r1/sp800_57_pt3_r1_draft.pdf) NIST, May 2014
  • Distributed Systems (http://book.mixu.net/distsys/single-page.html) Mikito Takada
  • In Search of an Understandable Consensus Algorithm (Raft) (https://ramcloud.stanford.edu/raft.pdf) Diego Ongaro and John Ousterhout, May 2014
  • Daily Solar Data (http://www.swpc.noaa.gov/ftpdir/indices/DSD.txt) U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center
  • Latest Solar Radio Flux Report from DRAO, Penticton (http://www.spaceweather.ca/solarflux/sx-4-eng.php) Natural Resources Canada
  • Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees (http://eprint.iacr.org/2013/834.pdf) Ahto Buldas, Andres Kroonmaa and Risto Laanoja, 2013
  • Efficient Data Structures for Tamper-Evident Logging (https://www.usenix.org/legacy/event/sec09/tech/full_papers/crosby.pdf) Scott A. Crosby, Dan S. Wallach, 2009
  • Efficient Data Structures for Tamper-Evident Logging slide presentation (https://www.usenix.org/legacy/event/sec09/tech/slides/crosby.pdf) Scott A. Crosby, Dan S. Wallach, 2009
  • Origin-Bound Certificates (http://www.browserauth.net/origin-bound-certificates) BrowserAuth.net

Texai Cognitive Architecture

  • Natural Language Approach of the Texai Project (https://www.youtube.com/watch?v=aB3px5_75jg) Stephen Reed's Texai project presentation recorded at the 2008 Artificial General Intelligence Conference
  • OpenCyc Commonsense AI Tutorial - part 1 (http://vimeo.com/6579522) Stephen Reed presentation recorded at the 2009 AGI Conference
  • OpenCyc Commonsense AI Tutorial - part 2 (http://vimeo.com/6595854)
  • Bootstrap Dialog: A Conversational English Text Parsing and Generation System (http://agi-conference.org/2009/papers/paper_44.pdf) Stephen L. Reed, Texai.org, presented at the Artificial General Intelligence Conference, 2009.
  • Texai presentation at AGI-2009 recorded video (http://vimeo.com/6343032) Stephen Reed
  • Texai presentation slides at AGI-2009 (http://agi-conference.org/2009/slides/saturday/session_3/2_reed.ppt) Stephen Reed

Developer bookmarks . . .

  • Using Git Support in NetBeans IDE (https://netbeans.org/kb/docs/ide/git.html) NetBeans
  • Configuring Jenkins continuous integration server to work with Git (http://www.uvd.co.uk/blog/labs/configuring-jenkins-continuous-integration-server-to-work-with-git/) uvd
  • Developer Documentation (https://bitcoin.org/en/developer-documentation) bitcoin.org
  • Doxygen generated documentation for the main bitcoin branch (https://dev.visucore.com/bitcoin/doxygen/index.html)
  • Wiki - Running Bitcoin, describes the command line options (https://en.bitcoin.it/wiki/Running_Bitcoin)
  • How to start your own mining pool using bitcoind + eloipool. (https://bitcointalk.org/index.php?topic=495542.msg5457995#msg5457995)
  • Wiki - Protocol specification (https://en.bitcoin.it/wiki/Protocol_specification)
  • Wiki - Protocol rules (https://en.bitcoin.it/wiki/Protocol_rules)
  • Wiki - List of address prefixes (https://en.bitcoin.it/wiki/List_of_address_prefixes)
  • Btcd + getwork + cgminer = profit (https://blog.conformal.com/btcd-getwork-cgminer-profit/) Conformal Systems
  • Announcing Statoshi: Realtime Bitcoin Node Statistics (http://coinchomp.com/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/) Jameson Lopp, May 7, 2014
  • Programming With TrouSerS David Challener, June 13, 2011 (https://www.cylab.cmu.edu/tiw/slides/challener-handout.pdf)
  • PeerReview Downloads (http://peerreview.mpi-sws.org/index.html#downloads)
  • BlockCypher full-nodes API (http://dev.blockcypher.com/)
  • How to set up an IDE for developing Bitcoin Core on Linux (http://coinchomp.com/2014/04/03/set-ide-developing-bitcoin-core-ubuntu-linux/) Jameson Lopp
  • How to create a pull request (https://bitcointalk.org/index.php?topic=4571.0) Gavin Andresen
  • A Hacker’s Guide to Git (http://wildlyinaccurate.com/a-hackers-guide-to-git) Joseph, Wildly Inaccurate
  • Foundation for Intelligent Physical Agents, Specifications (http://www.fipa.org/specifications/index.html) FIPA
  • Howto: PCI-DSS Hardened Ubuntu 14.04LTS (http://systemsoperations.blogspot.com/2014/04/howto-pci-dss-hardened-ubuntu-1404lts.html) Systems Operations
  • Use the Built-in Security Features in Your FOSS Distro (http://www.opensourceforu.com/2013/09/use-the-built-in-security-features-in-your-foss-distro/) OpenSource, September 10, 2013
  • DEFCON 17: More Tricks For Defeating SSL (https://www.youtube.com/watch?v=ibF36Yyeehw) Moxie Marlinspike, January 15, 2011
  • Docker (http://www.docker.com/whatisdocker/)
  • Are LXC containers enough? (http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/) Matt on Cloud
  • Is it safe to run applications in Linux Containers? (http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security) Jerome Petazzoni, Docker, August 20, 2014
  • ExoticVPS.com (http://www.exoticvps.com/) Listing 681 VPS hosts in 97 locations throughout 8 regions.
  • Border Gateway Protocol (http://en.wikipedia.org/wiki/Border_Gateway_Protocol) Wikipedia
  • BGP & Anycast Cloud (http://www.hostvirtual.com/anycast-bgp-cloud/) HostVirtual
  • Fee Schedule (https://www.arin.net/fees/fee_schedule.html) American Registry for Internet Numbers
  • Coinffeine Exchange Algorithm (https://github.com/Coinffeine/coinffeine/wiki/Exchange-algorithm)
  • CoinHook listens to Bitcoin addresses so you don't have to (https://www.coinhook.co/) Pelle Braendgaard
  • Bitcoin Address Shortener for the Blockchain (http://www.reddit.com/r/Bitcoin/comments/28mxl6/bitcoin_address_shortener_for_the_blockchain/) Reddit discussion
  • Transaction fees (https://en.bitcoin.it/wiki/Transaction_fees) Bitcoin Wiki
  • VirWoX MicroPayment API (http://api.virwox.com/api/documentation/MicroPayment_API.pdf) VirWox
  • *** Complete Guide on How to Create a New Alt Coin *** (https://bitcointalk.org/index.php?topic=225690.0) Bitcointalk, June 4, 2013
  • Open Whisper Systems (https://whispersystems.org/) encrypted voice for mobile
  • joget workflow (http://www.joget.org/workflow-management/[/url)
  • Easy Joget v3 for Absolute Beginner (http://www.scribd.com/doc/145790370/Easy-Joget-v3-for-Absolute-Beginner) Madeng
  • WebID (http://www.w3.org/wiki/WebID) W3C
  • How to create scrypt based altcoins?  (http://dogecoin.ga/how_to_create_scrypt_based_altcoins.html)
  • How To Clone Scrypt Based Altcoins for Fun and Profit (http://devtome.com/doku.php?id=scrypt_altcoin_cloning_guide)
  • Introducing Toshi - An Open Source Bitcoin Node For Developers (http://blog.coinbase.com/post/97671295752/introducing-toshi-an-open-source-bitcoin-node-for) Coinbase
  • How to run your own e-mail server with your own domain (http://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/2/) Lee Hutchinson, Ars Technica - Feb 16 2014
  • Java Coding Guidelines - Security (https://www.securecoding.cert.org/confluence/display/jg/1.+Security) Software Engineering Institute
  • Memory Wallet (http://memorywallet.org/) an altcoin JavaScript wallet
  • Why you should build an Immutable Infrastructure (http://blog.codeship.com/immutable-infrastructure/) Florian Motlik
  • Hits-of-Code Instead of SLoC (http://www.yegor256.com/2014/11/14/hits-of-code.html) Yegor Bugayenko, 2014
  • Bitcoin Core version 0.10.0 Release Notes (https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md) December 28, 2014

GitHub & SourceForge Developer bookmarks . . .

  • Texai (https://github.com/StephenLReed/texai) TexaiCognitiveArchitecture GitHub
  • bitcoin-testnet-box, Create a private, difficulty 1 bitcoin testnet (https://github.com/freewil/bitcoin-testnet-box) freewil GitHub
  • Coinpunk open source hosted wallet (https://github.com/kyledrake/coinpunk) kyledrake GitHub
  • Free Java class file shrinker, optimizer, obfuscator, and preverifier (http://proguard.sourceforge.net/) ProGuard SourceForge
  • Copycat - Java implementation of the Raft concensus protocol  (https://github.com/kuujo/copycat) kuujo GitHub
  • Android Bitcoin Wallet App (https://github.com/schildbach/bitcoin-wallet) schildbach GitHub
  • insight block explorer front-end (https://github.com/bitpay/insight) bitpay GitHub
  • insight block explorer API (back-end) (https://github.com/bitpay/insight-api) bitpay GitHub
  • Toshi, An open source Bitcoin node built to power large scale web applications (https://github.com/coinbase/toshi) coinbase GitHub
  • blockpop, Proof-of-publication with the blockchain (https://github.com/petertodd/blockpop) petertodd GitHub
  • Google bitcoinj adapted for A.I. Coin (https://code.google.com/r/stephenlreed-bitcoinj/)
  • Bitcoin Cartographer (https://github.com/mikehearn/httpseed) mikehearn GitHub


Title: Re: [ANNOUNCE] Proof-of-Stake for Bitcoin
Post by: SlipperySlope on April 25, 2014, 09:14:18 PM
The problems to address as viewed by a member of the developers email list . . .

Quote
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.pdf


A 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Proof-of-Stake for Bitcoin
Post by: clout on April 26, 2014, 08:32:08 AM
The problems to address as viewed by a member of the developers email list . . .

Quote
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.pdf


A 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


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: calian on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Peter R on 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?



Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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/ (http://bitslog.wordpress.com/2013/04/24/satoshi-s-fortune-a-more-accurate-figure/).


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 03:44:54 AM
A Bitcoin Super-Peer Network

Andytoshi, 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://i.imgur.com/eTSDj1Qs.png

https://blockchain.info/pools?timespan=4days (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.

http://courses.cse.tamu.edu/caverlee/csce438/hw/super_peer_graph.png

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  . . .

http://upload.wikimedia.org/wikipedia/commons/2/20/Chord_network.png

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?


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on 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


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on 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


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on 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. 


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: LeChatNoir on 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.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 27, 2014, 01:27:15 PM
  • 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".

Why is there a need to inflate the number of currency units by giving them to existing holders?

(I know the question is fundamental but still warrants to be answered.)


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: LeChatNoir on April 27, 2014, 05:45:21 PM
As I said in the other thread, this delegation scheme is the least appealing way to do PoS due to its centralization and reliance on people rather than protocols.

You as a stakeholder are free to choose who trust and you are free to run a super peer so i don't think this kind of centralization is a problem.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on April 27, 2014, 07:12:18 PM
  • 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".

Why is there a need to inflate the number of currency units by giving them to existing holders?

(I know the question is fundamental but still warrants to be answered.)

there isn't, that causes unecessary network bloat. instead you burn the transaction fees, which acts as an implicit dividend or increase of stake for all stakeholders.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on April 27, 2014, 08:38:06 PM
How does that help when the other 100 super nodes are controlling what blocks are formed.  This is not a distributed consensus that I'm satisfied with.

I think you misunderstand that consensus still comes from everyone on the network. The reason there are delegates is because specialization and centralization lead to greater efficiency as we can see given that block production goes from 10min with bitcoin mining (dpow) to 10-30sec with dpos. Think of it through the lens of more traditional governing structures. we could have a fully democratic government in the united states but that would be terribly inefficient since it would take way to long to collect the votes of all citizens on any given issue. not to mention not everyone knows enough or cares enough about each issue, so we would never be able to get 100% of ppl to vote any way. These are the problems that plague peercoin. as the dpos whitepaper elucidates:

Quote
Peercoin is a hybrid coin and is thus partial centralized by the proof of work. Like Bitcoin it also has mining pools. Compared to Bitcoin the Peercoin is certainly more decentralized; however, because proof of stake mining requires users to keep their computers on and wallets unlocked, only a small percentage of the shareholders participate in any kind of mining.

peercoin has the same centralization as bitcoin due to pow mining pools (dpow) and it has low participation rates in pos mining which causes it to be to inefficient to provide security/consensus to the network. this is the underlying reason for this hybrid model, proof of stake mining essentially constitutes a fully democratic governing structure that requires human participation. just as with any democracy the incentives are not there to have 100% participation. furthermore the incentives are even more skewed in this model because people can make disproportionately more with pow mining than with pow stake mining (i believe at the current rate inflation it is something like 9:1) .

the problem with the representative democracy is that we vote every four years so the representatives are not directly accountable to their constituents. of course if you want to get reelected then you will attempt to act in your constituents best interests, but there lies another problem in the fact that the representatives job is so complicated and misunderstood by people that they do not always know if a representative has fully acted in their best interests.

in delegated proof of stake you vote for your own representative (it is important to understand that this still use transactions as proof of stake - you cast your vote through transactions). if your representative is in the top 100 delegates that means that he is one of the top 100 most trusted nodes on the network. the delegates job is simple, he must produce blocks in a timely manner and include all valid transactions in those blocks. if a delegate does not do these things everyone on the network can easily detect that the representatives is not acting in everyones best interest. the client will automatically adjust your vote setting to another more trustworthy delegate. you do not necessarily have to vote ( make a transaction) to change the delegates status. assuming that this is a healthy network and there are several hundred transactions per block if the delegate does not do his job those transactions will automatically have down votes for this delegate so that he is effectively fired on the spot.

dpos puts together the best aspects of decentralization (collectivism) with the best aspects of centralization (specialization). decentralization for the purpose of decentralization is not a way to organize society or a network. the truth is that an organization is most decentralized when there are few if any barriers to access for all positions that govern it. competition decides whether or not someone holds a position. the delegates term in dpos is limited not by arbitrary term limits but by his own conduct and whether or not that conduct serves that better good.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 08:38:17 PM
  • 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".

Why is there a need to inflate the number of currency units by giving them to existing holders?

(I know the question is fundamental but still warrants to be answered.)

There is a need to continue the block reward schedule to preserve the Satoshi Social Contract. The value of bitcoin depends on our belief that what we bought into will not change, especially that it will not get worse. Getting rid of wasteful proof-of-work, which by trend grows to $5 billion sometime in 2015, is the main thing.

Satoshi created the notion of block rewards to motivate miners. In this project, the need for miners to provide wasted work is removed. The motivation to maintain the integrity of the network and blockchain is moved directly to pools who today create new blocks and to their client full nodes that validate and replicate the blockchain.

The Bitcoin network I propose in this project should be secured to financial enterprise class security and performance at a far lower expense than what the existing network is doing buying mining rigs that will certainly be junk in two years and for power.

But what to do with the surplus rewards? I say grant them because Satoshi created a  block reward schedule that this project is held to. I welcome your ideas on how to distribute the awards, in addition to ideas that I have.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 09:03:56 PM
As I said in the other thread, this delegation scheme is the least appealing way to do PoS due to its centralization and reliance on people rather than protocols.

This delegation scheme is close I think to how the existing Bitcoin network actually creates coins. A mere dozen or so greatly centralized entities - the pools - create nearly all the coins.

I rely on people's judgement to select primary and backup pools because that works today. My reference pool implementation will publicly log, in a realtime manner, all the operation details for audit by anyone. Anyone can check the calculations of reward distribution and why-or-why-not particular new transactions were incorporated into the block.

The super peer network, and round robin single mint, are indeed centralized - but no more I argue than the current system.

Experts say that the distributed consensus problem prevents proof-of-stake from ever working. Rather than solve this problem that has stumped better minds than mine, I remove the distributed part. This stretches the Satoshi Social Contract but does not break it I argue, when compared to the pros and cons of the current system.

Here is how I think about the centralization scheme of this project. Could it defend itself against a particular adversarial legal jurisdiction? Yes, because the pools can be located anywhere in the world. If one pool is taken down or subjected to a DDoS attack, the super peer Chord ring automatically heals, and the disconnected full node clients automatically connect to the prearranged backup pool.

At this point I believe Satoshi's fears of government ban or reprisal are overblown, yet they are still possible. What is more likely to attack Bitcoin centralization are patent trolls emboldened by short sighted notions of software intellectual property protection and greedy for the large sums of money flowing now through the network. Suppose my code infringes on someone's patent claims. I am not afraid. Operators of pools and full-nodes have some degree of anonymity and can move around to avoid the trolls.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 09:31:40 PM
Personal communication with andytoshi . . .

Quote
1. As mentioned on -wizards, how do you propose to select the peers?
    How do you propose who mints each block?

2. How do you determine who is "trustworthy"? You suggest human
    judgement is involved — but then how is consensus reached on the
    superpeer list?

3. What if somebody trustworthy mints two blocks and forks the chain?

4. What if peers do not mint a block when they are expected to?

5. What if peers drop off the network temporarily or permanently? How
    would you tell the difference?

My suspicion is that you need a distributed consensus to answer any of
those questions.

(Also, if you modify Bitcoin to require trust anywhere, it will not be
Bitcoin anymore.)

Oh, and some people on bitcointalk are talking about stake based on "proof
of transaction". This is a nonsense idea. Myself and Greg Maxwell figured
out how to completely destroy that system (if it was ever implemented..)
within 10 minutes of reading the whitepaper.

I will ponder your questions a bit. My solution necessitates centralization in order to avoid the distributed consensus problem.

I suppose that with a sufficient audit trail the other super peers and perhaps any validating full node can detect misbehavior after the fact. There is a degree of human trust in today's network. Miners trust pools to fairly deliver the corresponding rewards. Almost all the rewards are distributed in this manner. I argue that the algorithmic portion of the social contract already accommodates human trust. I make it no worse I think.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: bybitcoin on April 27, 2014, 10:49:48 PM
Exactly: the correct departure point to start from.
If peercoin or especially nxt PoS consensus model does lack certain necessary conditions, then please address them mathematically.
This way you'll arrive into a math problem for which you can see what obstacles you have to overcome and pass to solve the problem theoretically first of all. An engineering approach is not always the best one when attacking a problem of fundamental nature.



Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: r0ach on April 27, 2014, 11:39:22 PM
A super-peer network of 100 or less pools use Chord technology to form a robust ring.

I believe using an approach like this in proof of stake sounds more feasible than in PoW.

You could implement a weighted, decentralized checkpoint system for PoS.  As per your example, the top 100 PoS wallets could be referenced for the checkpoint since we're relying on game theory to make any of this stuff work.  It doesn't seem like the majority of the top 100 peercoin/blackcoin/whatever wallets would be interested in destroying their investment.

I'm sure there's dozens of ways to weight checkpoint negotiation without using an arbitrary number like the top 100 wallets online as well.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 11:49:25 PM
Exactly: the correct departure point to start from.
If peercoin or especially nxt PoS consensus model does lack certain necessary conditions, then please address them mathematically.
This way you'll arrive into a math problem for which you can see what obstacles you have to overcome and pass to solve the problem theoretically first of all. An engineering approach is not always the best one when attacking a problem of fundamental nature.

I, for one, am not critiquing other proof-of-stake implementations. The defense of NXT and PPC is up to their respective supporters, which can happen here as we all can learn from the debate.

The super-peer network I've proposed together with a round-robin single mint, is very attractive from a software engineering point of view. Namely 2 hops from transaction origination to blockchain. Only one confirmation is required. No redundant work. No orphans, No forks. Highly scalable with a high performance backbone which is a good thing because transaction growth is 3.2x annually.

Questions are focused on the super peers and the sorts of things that can go wrong with them. Answering these questions is my focus at the moment.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 27, 2014, 11:53:40 PM
A super-peer network of 100 or less pools use Chord technology to form a robust ring.

I believe using an approach like this in proof of stake sounds more feasible than in PoW.

You could implement a weighted, decentralized checkpoint system for PoS.  As per your example, the top 100 PoS wallets could be referenced for the checkpoint since we're relying on game theory to make any of this stuff work.  It doesn't seem like the majority of the top 100 peercoin/blackcoin/whatever wallets would be interested in destroying their investment.

I'm sure there's dozens of ways to weight checkpoint negotiation without using an arbitrary number like the top 100 wallets online as well.


Could you suggest some web pages, documents or discussion threads here that I should study?

I am starting here . . . What are checkpoints in bitcoin code? (https://bitcointalk.org/index.php?topic=194078.msg2013948#msg2013948) and a critque . . .
Bitcoin code has checkpoints, controlled by centralized small group of people. (https://bitcointalk.org/index.php?topic=371635.msg3971466#msg3971466)

[update]

OK, I read a few posts and instantly got it. The Bitcoin Core code has blockchain data information encoded into it as constants, to prevent the full node from processing purported forks from before a developer-consensus date where those developers believe that the blockchain is immutable. This the sort of software engineering pragmatism that skirts the edge of the Satoshi Social Contract and one can understand the idealistic debate around it.

That empty debate is a precedent for what I need to do. The social contract is about certain unchangeable aspects of Satoshi's design. I believe that checkpoints are a great example of how the social contract is maintained while bowing to practical software engineering realities.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 28, 2014, 02:35:33 AM
After-the-fact Distributed Consensus and Repair

I proposed the super-peer, round-robin mint, as a solution to the decentralized consensus problem. Thoughtful critics have questioned the central power of the temporary mint. My initial response was to use a weak analogy with the mining pool situation today in which miners judge which pool is most honest. I think that response satisfactorily covers mining rewards, but says nothing about the risk under my scheme that the temporary mint could misbehave constructing the new block - then what?

I am now revisiting distributed consensus using the notion of checkpoint. Immediately after the new block is created by the temporary mint, there is one chance for collective malfeasance detection and repair. In my scheme, there are 100 well-compensated super peers having at least a total of 8,000 compensated full nodes - the current number - as direct clients. I task each of these with validating the performance of the temporary mint in the 10 minutes before the mint responsibility gets passed along to the next super peer.

Correct block creation should be easy to verify. Only a single new block may be added to the blockchain. All the transactions in the new block have been circulated around the super peer ring. They are well interconnected, so none get lost. The audit trail provided by the temporary mint explains how its algorithm selected or did not select particular transactions. Likewise the audit trail, available for algorithmic inspection, lists the aggregate stake-shares submitted by the temporary mint for its direct client full-nodes, as well as the aggregate stake-shares submitted by each of the super peers. The distributed block reward portions to each super peer can be verified. I mean to ensure that every aspect of the temporary mint's behavior provides justification that is subject to algorithmic verification by thousands of peers.

As a first thought, I suppose that a quorum of super peers and their respective full-node clients verify the actions of the temporary mint. If a certain number of them invalidate the actions of the temporary mint, then the new block is reverted in the same manner as current full nodes deal with a wrong fork. The reverted transactions join the set of those awaiting incorporation into a new block, and the next temporary peer recreates the new block. The misbehaving peer is algorithmically penalized, to an extent not yet designed.

I dub this idea "after-the-fact distributed consensus and repair", provided that it has not already been invented by one of the bright minds around here.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: jonald_fyookball on April 28, 2014, 03:27:58 AM
I like the creativity. Keep exploring and combinations and possibilities.  Maybe you will hit on something good.

The checkpointing that is used in bitcoin, is I think, related to the math probabilities I alluded to earlier.  The PoW scheme is not guaranteed to avoid a split network but diminishes in probability the wider the network is.  This just a hypothesis.  Someone needs to write it out though, and this will illuminate and clarify the possibilities for PoS.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: gacrux on April 28, 2014, 06:21:12 AM
Not directly related to your round-robin rotating single mint idea (which I still haven't fully wrapped my head around), but you may wish to add this to your reading list at the top of the thread:

http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/



Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 28, 2014, 04:36:19 PM
Bitcoin Proof-of-stake Super Peer Network Diagram

Here is a proposed network diagram for how Bitcoin scales to accommodate all the world's financial transactions plus the numerous additional transactions expected from transaction-bots, e.g. the Internet of Things. One of the illustrated super-peers is the temporary mint that creates the new block on the blockchain that contains all the new transactions that efficiently flow inbound from wallets at the spoke endpoints. Transactions reach the mint in at most 3 hops. New blocks efficiently flow in the opposite direction, from the temporary mint super peer out to the full nodes that verify and replicate the blockchain.

Unlike the current Bitcoin network, all connections are SSL/TLS encrypted with X.509 authentication at both endpoints. X.509 certificate management has not yet been designed. Satoshi's network protocol does not need encryption to protect the contents, yet why let anyone even count transactions before they reach the public blockchain?

Note that I have not yet designed the procedure to re-join two such networks after a catastrophic separation - the split brain problem.

https://i.imgur.com/M90ihBv.png


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 28, 2014, 05:53:23 PM
Misbehaving node problem

With a hub and spoke network architecture, what guarantees that information received by the endpoints has not been corrupted by an intermediary? Satoshi solved this problem with proof-of-work embedded into the blockchain which makes forgery difficult.

How does proof of stake prevent forgery?


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: jonald_fyookball on April 28, 2014, 06:02:22 PM
Not sure I get the question?

Transactions cannot be forged because all transactions
are signed using private keys.

A node cannot change that.

PoW or PoS creates consensus at the block level
and every block must cryptographically mesh or link
to the one before it.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 28, 2014, 06:26:25 PM
Not sure I get the question?

Transactions cannot be forged because all transactions
are signed using private keys.

A node cannot change that.

PoW or PoS creates consensus at the block level
and every block must cryptographically mesh or link
to the one before it.

Yes, the question posed on the bitcoin-wizards irc channel was . . .
Quote
how do I sync my node and be sure I actually came to a state of consensus the same as everyone else? in bitcoin the real work done makes figuring out the cost to an attacker of faking that consensus well-defined; I don't see how in your system there is any cost at all

I need to work through the math of proof of stake consequences for blockchain forgery. I also have ideas for full nodes performing queries to several of the super-peers who in response give the current hash - similar to how SPV nodes trust the network, and which I now must study.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 28, 2014, 07:16:16 PM
If you are so interested in these kinds of things, you should study the problem first. You seem to overlook some basics of Bitcoin. The current stakeholders, i.e. ASIC owners, have no interest in giving up their money printing press. To make changes to Bitcoin you need the consensus of those who have mining power and developers ("community consensus"). That community consensus is very clear.  Bitcoin will never move to PoS.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 28, 2014, 07:32:48 PM
If you are so interested in these kinds of things, you should study the problem first. You seem to overlook some basics of Bitcoin. The current stakeholders, i.e. ASIC owners, have no interest in giving up their money printing press. To make changes to Bitcoin you need the consensus of those who have mining power and developers ("community consensus"). That community consensus is very clear.  Bitcoin will never move to PoS.

I am afraid you are mistaken. If the coin creation method is changed, the ASIC owners have nothing to say. Only the economic decision of the coin owners will matter. If after the fork everyone tries to dump the PoS coins, it proves they are worthless. If everyone tries to move to PoS selling their PoW coins, the previous version with ASICs is worthless.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 28, 2014, 07:56:11 PM
If the coin creation method is changed, the ASIC owners have nothing to say.

Bitcoin uses proof-of-work, and therefore the majority of the hashing power decides. Why would the current stake-holders be so stupid to switch to a system which is unproven and where there economic advantages, i.e. their capital investment becomes worthless? That makes no sense whatsoever. Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless. All of this should be obvious to anyone who wants to understand why Bitcoin works. The reason is works is that hashing-power can not possibly become worthless. And those that own the hashing power will not agree to give it up. That's the fundamental limitation as well.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 28, 2014, 08:07:52 PM
If the coin creation method is changed, the ASIC owners have nothing to say.

Bitcoin uses proof-of-work, and therefore the majority of the hashing power decides. Why would the current stake-holders be so stupid to switch to a system which is unproven and where there economic advantages, i.e. their capital investment becomes worthless? That makes no sense whatsoever. Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless. All of this should be obvious to anyone who wants to understand why Bitcoin works.

It is precisely BECAUSE of what you described that if any PoS would ever be implemented by anyone based on Bitcoin blockchain, it will be a fork, or an altcoin, and not Bitcoin. And therefore you and all of the ASIC miners will have no say in the process, because it has new rules.

If people see that the intruder is gaining in value and Bitcoin is losing it, they may try to get extra share of the new coins by selling their Bitcoins, hastening their demise. The original Bitcoin proponents will only lose, though, if they have sold the spinoff, thinking that it is worth nothing.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 28, 2014, 08:48:13 PM
If the coin creation method is changed, the ASIC owners have nothing to say.

Bitcoin uses proof-of-work, and therefore the majority of the hashing power decides. Why would the current stake-holders be so stupid to switch to a system which is unproven and where there economic advantages, i.e. their capital investment becomes worthless? That makes no sense whatsoever. Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless. All of this should be obvious to anyone who wants to understand why Bitcoin works.

It is precisely BECAUSE of what you described that if any PoS would ever be implemented by anyone based on Bitcoin blockchain, it will be a fork, or an altcoin, and not Bitcoin. And therefore you and all of the ASIC miners will have no say in the process, because it has new rules.

If people see that the intruder is gaining in value and Bitcoin is losing it, they may try to get extra share of the new coins by selling their Bitcoins, hastening their demise. The original Bitcoin proponents will only lose, though, if they have sold the spinoff, thinking that it is worth nothing.

With the exception of certain full nodes in the P2Pool, existing ASIC miners do not participate in the Bitcoin network. They provide shares of hashing power to their respective pools in return for daily payouts. My pitch for Bitcoin 1.0 would be to the pools who could retain a lot more of the $500 million passing through their hands each year. There are only 12 or so to persuade. There are about 7300 other full nodes that verify the blockchain and have the power to ban other full nodes who misbehave. Either a majority of existing full nodes must migrate to this project's version, or they must somehow be greatly outnumbered by new paid full nodes on the new version. Other powerful entities in the Bitcoin network include the exchanges and payment processors. Nearly all of these must be on board with the new version. I believe that they would be swayed primarily by popular opinion, and to a lesser extent by the possible zero-confirmation, and lower fee transactions, made possible by the single temporary mint.

I plan a friendly takeover of the blockchain in some possible future world, where I am effectively invited to do so by Bitcoin experts, media, and the public. There will be no doubt those who get spun out on the old blockchain with the old client. But I simply do not see how they could compete with this project.

I want the bitcoin experts to recognize this project as an unimplemented Bitcoin system. That requires passing a very strict test regarding the Satoshi Social Contract. A draft project whitepaper will formally specify how everything is to work. It will no doubt be revised many times, perhaps even after coding and testing reveal glaring errors on my part.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Brangdon on April 28, 2014, 09:05:12 PM
Why would the current stake-holders be so stupid to switch to a system which is unproven
I gather the plan is to spend several years developing the technology, proving it and building consensus. I presume one of the goals is to keep the protocol as compatible with Bitcoin as possible, so authors of wallet software etc will find it relatively easy to support.

I don't know how practical this is. The root post mentions "a sandboxed testnet that periodically forks the Bitcoin blockchain". To me that sounds like I won't be able to buy anything with the testnet coins, and any trading I do will be wiped out when the next fork happens, because the testnet block-chain will be over-written with the latest Bitcoin block-chain. So, nothing will be at stake in the testnet. Those conditions are so unrealistic that I'm not sure any system can be said to have proven itself under them.

After that, although it might be theoretically possible to gradually evolve Bitcoin into Bitcoin-PoS, with both PoW and PoS blocks being accepted as valid by nodes for a while until all nodes upgrade, that isn't what the root post in this thread proposes. Instead it proposes a "big bang", go live with one last snapshot of the Bitcoin block-chain. After which, it will be a fully-fledged altcoin which will coexist alongside the original Bitcoin.

Quote
Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless.
The goal is to preserve Satoshi's social contract. Presumably this includes the rate at which new coins are created.

Quote
And those that own the hashing power will not agree to give it up. That's the fundamental limitation as well.
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old. I think the goal is to make it very easy for them to switch. So the authors of wallet software are important stakeholders, because they can ease the transition for users. It's also important that the new coin is a fork of the old, because basing it on a snapshot of Bitcoin's block-chain means the value of users' holdings in Bitcoin is preserved in the new coin. If the users then prefer to buy the new coins, the value of old Bitcoin will crash and the miners will be in trouble anyway, because the block reward will have less real-world buying power.

A core belief here is that PoS is simply better, and will carry the day on merit. It does seem to me that transaction fees ought to be lower with PoS. That hardly matters today because the block reward is so high. It will matter more in a few years with the block reward halves. Anyone with any foresight can see that after a few halvings, and after a few more years of the PoW hashpower arms race continuing, that Bitcoin transaction fees will have to grow a lot to cover the cost of the miners' hardware. If PoS can offer a similar system with greater efficiency, and that translates into lower transaction fees for users, then it has a real chance of winning users and other stakeholders. Basically, all stakeholders except the miners. And the great thing about PoS is that it doesn't need the miners because it's not computationally expensive. And we don't have to wait for the block reward to happen to make these judgements. The stakeholders - the venture capitalists, the people who make hardware wallets, point-of-sale terminals, Bitcoin ATMs - will place their bets based on which network they consider to have the most long-term future value. And that won't be PoW because PoW is painting itself into a corner.

(All assuming PoS can be made to work. Of which I have yet to be convinced. And as I mentioned above, I also have reservations about whether a currency can really be considered to have proven itself on a testnet.)


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Peter R on April 28, 2014, 10:22:24 PM
What really matters is whether the users want to own the new coins or the old...It's also important that the new coin is a fork of the old, because basing it on a snapshot of Bitcoin's block-chain means the value of users' holdings in Bitcoin is preserved in the new coin.

Whether you create a fork or a spin-off, the end result is the same in this respect: in both cases you have bitcoin (PoW) and bitshares (PoS) running side by side.  If you want bitshares to supersede bitcoin, then you need to legitimize it somehow and the market needs to agree.  

We should also agree on the definition of a "fork" and a "spin-off".  Here are my thoughts:

FORK:
====
A fork preserves the complete chain of digital signatures in the bitcoin blockchain back to the Satoshi genesis block with no missing details.  Bitshares implemented as a fork would mean that new PoS blocks are built forking out from some pre-defined block #X and that client nodes would likely download all new bitshares blocks plus the entire bitcoin blockchain up to the forking point.  

SPIN-OFF:
======
A spin-off preserves the wealth distribution (provable via ECDSA private keys) as specified by the unspent outputs in block #X but does not necessarily preserve the complete chain of digital signatures back to the Satoshi genesis block.  Bitshares implemented as a spin-off would mean that new PoS blocks are built on top of some "nucleus" that represents a snapshot of the blockchain's unspent outputs at block #X.  Client nodes would likely download only the bitshares blocks if the nucleus was hard-coded (the unspent outputs require vastly less disk space than the blockchain transaction history).  


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: jonald_fyookball on April 28, 2014, 11:21:50 PM

A core belief here is that PoS is simply better, and will carry the day on merit.  

I'm not convinced of that necessarily.  And I am not on board
with this delegation scheme for reasons I've stated.  

Provided that distributed consensus can be achieved with PoS, and provided
that it has better defenses against a 51% attack than PoW does,
I would say it MIGHT be superior to PoW if introduced at the
right time, which I think would be premature right now for Bitcoin.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: ahmed_bodi on April 28, 2014, 11:27:16 PM
If this is done and working on a testnet i would be happy to fork bytecoin with your changes.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 29, 2014, 01:48:58 AM
If this is done and working on a testnet i would be happy to fork bytecoin with your changes.

Deal. And thank you so much.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 29, 2014, 05:30:44 AM
What really matters is whether the users want to own the new coins or the old...It's also important that the new coin is a fork of the old, because basing it on a snapshot of Bitcoin's block-chain means the value of users' holdings in Bitcoin is preserved in the new coin.

Whether you create a fork or a spin-off, the end result is the same in this respect: in both cases you have bitcoin (PoW) and bitshares (PoS) running side by side.  If you want bitshares to supersede bitcoin, then you need to legitimize it somehow and the market needs to agree.  

We should also agree on the definition of a "fork" and a "spin-off".  Here are my thoughts:

FORK:
====
A fork preserves the complete chain of digital signatures in the bitcoin blockchain back to the Satoshi genesis block with no missing details.  Bitshares implemented as a fork would mean that new PoS blocks are built forking out from some pre-defined block #X and that client nodes would likely download all new bitshares blocks plus the entire bitcoin blockchain up to the forking point.  

SPIN-OFF:
======
A spin-off preserves the wealth distribution (provable via ECDSA private keys) as specified by the unspent outputs in block #X but does not necessarily preserve the complete chain of digital signatures back to the Satoshi genesis block.  Bitshares implemented as a spin-off would mean that new PoS blocks are built on top of some "nucleus" that represents a snapshot of the blockchain's unspent outputs at block #X.  Client nodes would likely download only the bitshares blocks if the nucleus was hard-coded (the unspent outputs require vastly less disk space than the blockchain transaction history).  


By this definition, this project is intended to be a fork, indeed what bitcoin core developers call a hard fork.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 29, 2014, 08:30:58 AM
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.

Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 29, 2014, 09:25:23 AM
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.

Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.

Nope. A cool part of the crypto universe is that anyone can fork the coin (considering he has the majority of the shares/consensus AFTER the fork against hostile groups) to do whatever, and the markets decide if the fork has any value.

I don't believe miners and core developers would like to support such a change, but unless they have the majority of stake in the fork, they don't count. You can decide the parameters of the fork such that they actively suppress the position of devs and miners. Just like you would be designing an altcoin.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 29, 2014, 09:44:32 AM
Nope. A cool part of the crypto universe is that anyone can fork the coin (considering he has the majority of the shares/consensus AFTER the fork against hostile groups) to do whatever, and the markets decide if the fork has any value.

I don't believe miners and core developers would like to support such a change, but unless they have the majority of stake in the fork, they don't count. You can decide the parameters of the fork such that they actively suppress the position of devs and miners. Just like you would be designing an altcoin.

Yes, you can create a new coin, but this has nothing to do with the consensus in Bitcoin. The difference between a fork and a new chain is that all wealth gets wiped out. Bitcoins don't have value in a new chain. So what OP is talking about is just nonsense - he is explicitly referring to migrating Bitcoin. The people who hold the 5 billion dollars in wealth have no interest in destroying their wealth. The ASIC miners have no interest in moving to another system. The Bitcoin chain is secured by the hashing power. Which means the wealth can't be destroyed by random judgements of people. This economic calculation is the very reason why Bitcoin works in the first place. Essentially those nodes who would want to change the system would be malicious actors in the network. All of this is really required if you want to understand the system, because otherwise bitcoins would be worthless. The value of bitcoins crucially depends on the self-interest of miners and the tie to the hashing-power. Which is not to say there can be better systems. One might imagine a currency where users actually have a say in development, but Bitcoin is not such a system. Any new algorithm will be an Altcoin, not Bitcoin 2.0.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 29, 2014, 10:21:17 AM
Seems that we have the same understanding of the situation.

In the end, the individual users of the currency have the final say, because if many of them decide to migrate, the previous currency network loses value and punishes those who still trust in it. Both PoW and PoS consensuses are helpless if people just abandon the currency en masse.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 29, 2014, 11:02:25 AM
I agree - the market of Alt-Coins will be a kind of meta-consensus system. You vote with your wallet, which network you support. So side-chains, coin issuance within another network and migration are not needed. The market can price the different coins. What is missing is a more fluid exchange, so that payment in BTC and other coins are almost the same.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: jonald_fyookball on April 29, 2014, 11:32:34 AM
didnt mastercoin promise that?


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 29, 2014, 01:56:35 PM
If you are so interested in these kinds of things, you should study the problem first. You seem to overlook some basics of Bitcoin. The current stakeholders, i.e. ASIC owners, have no interest in giving up their money printing press. To make changes to Bitcoin you need the consensus of those who have mining power and developers ("community consensus"). That community consensus is very clear.

I am studying Satoshi's paper in order to extract the terms of the social contract. Then I will author a project whitepaper to describe Bitcoin Proof-of-Stake in an academic format suitable for review. What I have thought about so far assumes well-behaving and bug-free agents operating in an ideal network - abstracted from the real network used by Bitcoin today. The whitepaper must allow for misbehaving and buggy agents operating in a possibly broken network. The new system must be shown to work without any trusted agents. The more convincing math that is in the paper - the better. The developer consensus can be moved by logic and math.

Bitcoin will never move to PoS.

The year 2016 is the last year for awarding 1,314,000 block reward bitcoins, then the block reward halves for the subsequent four years. I would tentatively set January 1, 2016 as the project launch date, because the reallocation of the block rewards is the enticement for switching transactors and holders over to the new version. I will revise a small portion of the Bitcoin Core C++ source code, and create a reference pool Java software program before the end of 2014, and then use all of 2015 for public testing in a sandboxed Bitcoin testnet. At least one altcoin, e.g. bytecoin, could be forked by others to test proof-of-stake in the wild in 2015.

A controversy over the future of Bitcoin can only hurt its price and utility.

All further actions of this project must be non-confrontational to the maximum degree.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: fireinwall on April 29, 2014, 02:18:20 PM
POS is popular for now. Some days later , new feature will come out for most people.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: benjyz on April 29, 2014, 02:39:14 PM
A controversy over the future of Bitcoin can only hurt its price and utility.

All further actions of this project must be non-confrontational to the maximum degree.

What you're trying to do is similar to asking 100 mulit-millionaires to donate all their wealth to charity. it's physically possible, but economically impossible. this is the whole genius of the system. if 51% of the hashing power stays honest, the system works. the reason why people don't destroy the network out of self-interest, is that they can't profitable do so. to move to another algorithm would destroy the system. if you believe it's possible you shouldn't support Bitcoin in the first place  - collusion would be possible to the detriment of all coin holders.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on April 29, 2014, 02:57:29 PM
I believe that these development should be explored. Bitcoin was born as a disruptive innovation, and now/soon it maybe time to consolidate the gains by making incremental improvements.

It is like the earliest automobile was an invention over buggy, but religious sticking to its parameters would seem funny from the perspective of us who use quite different vehicles these days. Similarly I can only lament the fact that any real progress in human transportation ended with jet engine, because of the selfsame religious sticking to certain concepts and stifling of competition of innovation.

I am of the opinion that PoS is inherently fiat, and inherently non-coin, unimplementable, unworkable and undesirable. But I am open to change my opinion if new facts surface. Unwillingness to change opinions with facts is a trait not fitting for a Bitcoin user.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 29, 2014, 02:58:43 PM
Transitional SHA-256 Mining Multipool

What you're trying to do is similar to asking 100 mulit-millionaires to donate all their wealth to charity. it's physically possible, but economically impossible. this is the whole genius of the system. if 51% of the hashing power stays honest, the system works. the reason why people don't destroy the network out of self-interest, is that they can't profitable do so. to move to another algorithm would destroy the system. if you believe it's possible you shouldn't support Bitcoin in the first place  - collusion would be possible to the detriment of all coin holders.

Thanks for the idea about hashing power.

This project will create, or otherwise facilitate, a transitional SHA-256 multipool which pays its participating SHA-256 ASIC hashers in bitcoins free from the taint of inputs dependent upon rewards created by ASIC miners after the fork.

At launch of this project, the Bitcoin Network will regrettably split to some degree as bitcoins mined by the new proof-of-stake version cannot be spent by proof-of-work clients and vice versa. A condition of the launch is that the number of full nodes in the proof-of-stake version greatly outnumber their counterparts in the proof-of-work version, in particular that the major bitcoin exchanges and online wallets support the proof-of-stake version. The ASIC miners who continue to operate their rigs can obtain new-version bitcoins by joining this new multipool, which in addition to mining proof-of-work version Bitcoin, will also mine altcoins sharing the SHA-256 algorithm.





Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on April 29, 2014, 11:12:48 PM
The Satoshi Social Contract

Bitcoin core developers speak of the Satoshi Social Contract as those features of Bitcoin that have been promised by Satoshi, and upon which the integrity of Bitcoin rests. For example, releasing a new version of the Bitcoin Core client that increases the upper limit of mined coins breaks the social contract between the core developers and bitcoin using public.

In this project, proof-of-work will be replaced by proof-of-stake, and a pure decentralized peer-to-peer asynchronous mesh network will be replaced by a hierarchical peer-to-peer synchronous network.

To what degree of severity, does this project break Satoshi's promises, and can the result be called Bitcoin despite claimed advantages?

---------------------------------------------------------------------------------------

Here are the notable promises extracted from the defining whitepaper Bitcoin: A Peer-to-Peer Electronic Cash System (https://bitcoin.org/bitcoin.pdf) by Satoshi Nakamoto.

From the Abstract . . .

*   Bitcoin is a purely peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution. Retained as-is.

*   The Bitcoin network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.  The data structure is retained with a zero-difficulty proof-of-work.

*   Bitcoin messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. Bitcoin messages are routed along fault-tolerant paths from the originating peer to a certain peer having the role of temporary mint, which echos each received transaction back to the network as instant acknowledgment that it will be included according to order received in the ongoing record chain.

From section 1. Introduction . . .

*   Bitcoin is an electronic payment system based upon cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.Retained as-is.

*   Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms protect buyers. Mechanism changed - to be explained.

*   Bitcoin is a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. Retained as-is.

*   The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Mechanism changed - to be explained.

From section 2. Transactions . . .

*   Bitcoin defines an electronic coin as a chain of digital signatures. A payee can verify the signature of a received transaction by computing the transaction payer's digital signature and the payer's public key. Retained as-is.

*   [Because the private key is required by the payer to sign the transaction, if the private key is lost, then the transaction cannot be performed.] Retained as-is.

*   Bitcoin transactions are publicly announced. Retained as-is.

*   In the event of multiple transactions from the same address, the earliest issued transactions counts, and subsequent others are dropped. Retained as-is.

*   Bitcoin is a system whereby the participants agree on a single history of the order in which transactions were received. Retained as-is.

*   The payee has proof that at the time of each transaction, the majority of nodes agreed it was the first received. Retained as-is.

From section 3. Timestamp Server . . .

*   Transaction are gathered into blocks. Retained as-is.

*   The blockchain consists of timestamped blocks whose embedded hash includes the hash of the previous timestamped block, forming a chain. Retained as-is.

From section 4. Proof-of-Work . . .

*   The block contains a SHA-256 hash having a certain number of leading binary zeros, determined by increment a number-used-once until a value is found that gives the block's hash the required zero bits. Retained as-is for backwards compatibility, but the zero-difficulty means the effort is trivial.

*   Proof-of-work difficulty is determined by a moving average targeting an average number blocks per hour. Changed - the difficulty is always one, which is the lowest value.

From section 5. Network . . . Changed - to be explained.

*   The steps to run the network are as follows:
  • New transactions are broadcast to all nodes.
  • Each node collects new transactions into a block.
  • Each node works on finding a proof-of-work [with specified difficulty] for its block
  • When a node finds a proof, it broadcasts the block to all nodes.
  • Nodes accept the block only if all transactions in are valid and not already spent.
  • Nodes express their acceptance of the block by working on creating the next block in the chain using hash of the accepted block as the previous hash.

*   Nodes always consider the longest chain to be the correct one.

*   Nodes receiving two different version of the next block, work on the first version received, but abandon that branch if a longer chain is received from any peer node.

*   Transactions reaching many nodes have a high probability of being included in a block.

*   Nodes missing a broadcast block may subsequently know to ask for it by number when the next block is received the gap recognized.

From section 6. Incentive . . .

*   The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. Retained as-is.

*   The new coin awarded to the block creator is the only way to initially distribute coins into circulation.  Retained as-is.

*   The transaction fee is equal to the transaction's input value minus its output value and is added to the block reward received by the block creator. Retained as-is.

*   The incentive may help encourage nodes to stay honest.  Retained as-is.

From section 7. Reclaiming Disk Space . . .

*   Transactions are stored within the block in the configuration of a Merkle Tree, with only the root included in the block's hash. Retained as-is.

*   Once the latest transactions in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. Retained as-is.

From section 8. Simplified Payment Verification . . .

*   It is possible to verify payments without running a full node. Retained as-is.

*   Verification is performed by querying network full nodes until the SPV node probably has the longest chain of block headers. The transaction timestamp indicates which chronologically ordered block must contain the transaction. The SPV node requests that block's Merkle branch and determines the presence of the transaction to be verified. Retained as-is.

*   The number of following blocks is a measure of confidence that the chain will not be reverted back to before the transaction was accepted into its block. Changed - to be explained.

*   A SPV node is more vulnerable to attack as it depends upon the honesty of its connected full nodes. Retained as-is.

From section 9. Combining and Splitting Value . . .

*   To allow value to split and combined, transactions contain multiple inputs and outputs.  Retained as-is.

*   [The inputs must be unspent to create a valid transaction. When the transaction is accepted by the network, its inputs are regarded as spent, and its outputs are regarded as unspent in the absence of a subsequent transaction having that coin as an input.] Retained as-is.

*   Despite the recursive chain of dependency on a transaction's inputs, there is never the need to extract a complete standalone copy of a transaction's history. Retained as-is.

From section 10. Privacy . . .

*   Privacy can be maintained by keeping public keys anonymous. Retained as-is.

*   New public / private key pairs may be used by the receiver of each transaction to keep them from being linked to common owner. Retained as-is.

*   Multiple inputs to transactions indicate common ownership of the inputs due to the necessity of the owner signing each of them with private key corresponding to the input's contained public key. Retained as-is.

From section 11. Calculations . . .

*   Honest nodes do not accept an invalid transaction as payment. Retained as-is.

*   Honest nodes do not accept a block containing an invalid transaction. Retained as-is.

*   An attack is possible in which the attacker changes one of his own transactions to take back the money he recently spent. Changed - to be explained.

*   In order for the double spend attack to work, the attacker must control a majority of the full node connections, i.e. the 51% attack.  Changed - to be explained.

From section 12. Conclusions . . .

*   Nodes work all at once with little coordination. Changed - to be explained.

*   Nodes do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best-effort basis. Changed - to be explained.

*   Generating full Nodes vote with their hashing power expressing their acceptance of valid blocks by working on them at will, and rejecting invalid blocks by refusing to work on them. Changed - to be explained.

*   Any needed rules and incentives can be enforced with this consensus mechanism. Retained as-is.

From the released Bitcoin Core program, as described by Wiki: Controlled supply (https://en.bitcoin.it/wiki/Controlled_supply) . . .

*   The rate of block creation is approximately constant over time: 6 per hour. Retained as-is.

*   The number of Bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 4 years. Retained as-is.

*   the number of Bitcoins in existence will never exceed 21 million. Retained as-is.

From Satoshi's comment in Bitcoin 0.3.2 released (https://bitcointalk.org/index.php?topic=437.msg3807#msg3807)

*    There are checkpoints to prevent very probably needless verification of the oldest portions of the blockchain. Changed - to be explained.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 01, 2014, 06:56:14 PM
The Hard Fork

Copied from the poll thread . . .

I got a question here.
Can bitcoin really switch to PoS? Wouldn't it just create a hard fork and create a new altcoin?

The Bitcoin brand is not an enforced trademark and the core developers have a policy of neutrality with regard to controversy. My project, to be deployed at the beginning of 2016 after a year of public testing and scrutiny, will use the then-current blockchain as the initial distribution. The new version will exchange transactions with the old version on the existing network. Both versions will reject any transactions tainted by rewards created by the other version after the hard-fork date.

I need at least a three to one advantage with regard to peer full nodes on my version. For proof-of-stake to work I need the cooperation of the largest holders. I need the cooperation of transactors such as third-party wallet providers, hosted wallet providers, and nearly all the major exchanges. One or more transitional SHA-256 multipools will provide untainted bitcoin for its participating ASIC miners. During the year of testing, the project open source will be provided to at least one altcoin already in circulation.

There will be three prices for bitcoin after the hard-fork. The main price will be for untainted coins mined before the hard-fork. The second price will be for coins tainted by proof-of-work rewards issued after the hard-fork. The third price will be for coins tainted by proof-of-stake rewards issued after the hard-fork. I expect selling pressure on the tainted proof-of-work coins as ASIC miners necessarily must sell to buy equipment and purchase power.

The new version will be have the features, to attract the needed majority . . .

  • immediate transaction acknowledgment for incorporation into the blockchain, which is checkpointed every 10 minutes following the new block
  • mining rewards distributed via pools in proportion to provided stakes
  • transactions will be included that have lower fees than present and no-fee transactions will be much more likely to be accepted
  • only one version of the blockchain exists, has broad consensus approval and is widely replicated
  • network cryptographic audit trail

The consensus of users, as designed by Satoshi, will pick the winner. Unless the odds beforehand are very much in this project's favor, the hard-fork will not occur as fragmentation of the system hurts us all. Yet the wastefulness of the current system compels a timely solution.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 05, 2014, 11:05:40 PM
The Whitepaper Final Draft

Bitcoin Cooperative Proof-of-Stake (https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE)


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 06:56:37 AM
The whitepaper is in its final draft. There is no working code yet so the ideas are half-baked so to speak. I want to code everything minimally by year end 2014. I am used to Java and enterprise style regression tests, automated builds and continuous integration servers. I have forked the GitHub repository for Bitcoin and will keep my branch up to date with the main branch.

I like NetBeans for Java, and will first experiment with getting C++ installed there. My development box is Ubuntu and I also run a local Ubuntu server.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Vitalik Buterin on May 20, 2014, 11:42:15 AM
One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: TwinWinNerD on May 20, 2014, 12:28:46 PM
intresting. will take a close look


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: hashman on May 20, 2014, 02:37:28 PM
Very interesting paper!  Thank you for discussion here. 

Two comments:

"In contrast, incumbent credit/debit card payment systems are faster [3] and more certain for consumers. Incumbent bank wire transfer, e.g. Swiftnet [4], is faster and more certain for business-to-business users. Incumbent payment transfer systems have data security policies that Bitcoin lacks [5] with regard to protecting host computers and customer data, e.g. private keys."

I disagree with these statements.  Incumbent systems do have advantages but they are not necessarily faster or more certain (can be reversed up to months later).  As for security policies the incumbent systems are all way behind (pull system, no triple accounting, etc).

Second comment:

Why?  There is no reason to use proof of stake.  Saying that miners use too much energy is simply saying miners are not smart, not that there is a problem with proof of work.  Miners are free to use as much energy as they like.  Proof of stake looks to me like a solution in search of a problem.     








Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 02:42:20 PM
One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.

Yes this is a problem that this design does not handle directly. Rather I consider it the sort of catastrophe that is best dealt with by a network operations center. In the case of current Bitcoin, the lead core developers can issue an alert, and mobilize the community to download a new software version. In constrast, enterprise data networks, especially the incumbent financial data networks have network operations centers that rehearse detection of, and recovery from such faults.

This design provides funding for such a center, run in a decentralized manner by autonomous trustless agents to the greatest possible extent.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 02:49:48 PM
Very interesting paper!  Thank you for discussion here. 
"In contrast, incumbent credit/debit card payment systems are faster [3] and more certain for consumers. Incumbent bank wire transfer, e.g. Swiftnet [4], is faster and more certain for business-to-business users. Incumbent payment transfer systems have data security policies that Bitcoin lacks [5] with regard to protecting host computers and customer data, e.g. private keys."

I disagree with these statements.  Incumbent systems do have advantages but they are not necessarily faster or more certain (can be reversed up to months later).  As for security policies the incumbent systems are all way behind (pull system, no triple accounting, etc).


When I say faster, I mean the typical customer check-out experience at point-of-sale. You verify the payment account at a terminal, swipe a card, and collect the receipt. When I say more certain, I mean to cover the odd case where a bitcoin transaction makes into a block after a certain delay, or the less likely, but worse case when the transaction never gets into a block. The bitcoin network forwards transactions on a best effort basis. There are no guarantees that the transaction will be recorded into the blockchain.

Quote

Why?  There is no reason to use proof of stake.  Saying that miners use too much energy is simply saying miners are not smart, not that there is a problem with proof of work.  Miners are free to use as much energy as they like.  Proof of stake looks to me like a solution in search of a problem.     

Proof-of-stake was immediately recognized as a very attractive idea when first proposed back in 2011. It is the main reason why PeerCoin has the 4th highest market cap. Satoshi admitted that his design would eventually force miners to congregate in locations with the least expensive power, as math shows that competing miners will use all the block reward to support their efforts.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: drawingthesun on May 20, 2014, 03:11:47 PM
I will revise a small portion of the Bitcoin Core C++ source code, and create a reference pool Java software program before the end of 2014

Why Java?

Almost all CryptoCoin's and their associated programs are written in either C, C++ or Python.

Java isn't really seen in a good light in the CryptoCoin community.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 04:20:31 PM
I will revise a small portion of the Bitcoin Core C++ source code, and create a reference pool Java software program before the end of 2014

Why Java?

Almost all CryptoCoin's and their associated programs are written in either C, C++ or Python.

Java isn't really seen in a good light in the CryptoCoin community.

Sorry - that statement is no longer operative. I love Java but after a month of study I realize your point entirely. Everything related to bitcoin core will be C++. There will be no reference pool software, because there are no mining pools in the final design. I will use python to needed testing tools, beyond what has been already contributed to bitcoin at GitHub.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: andytoshi on May 20, 2014, 04:21:47 PM

Hi SlipperySlope,


I see you've updated your whitepaper today (May 20), and I think also every day before that. I have a few comments, though I've got a lot of reading to do so I can't promise I'll follow up on them in a timely fashion.


1. You spend a bunch of the first part of your paper claiming that Bitcoin's proof-of-work system is wasteful and that hashing is "single-purpose". (This is a common meme on here and Reddit, I understand — in general, I'd advise you when learning about Bitcoin to not pick up ideas from this website unless they originate with somebody who is a known expert on Bitcoin.) I recently had a discussion with fenn on ##hplusroadmap about the "single-purpose" claim as well as the "zero-sum" game. Notice that there is no known way to achieve distributed consensus without proof-of-work, so these claims that the entropy production is unnecessary are extraordinary and require significant evidence.

2014-05-11 12:20:10     fenn    it's a zero sum game
2014-05-11 12:20:32     fenn    except for the value of the network of course
2014-05-11 12:20:55     fenn    network value is independent of number of hashes being performed
2014-05-11 12:21:36     kanzure do you know what the hashes are for?
2014-05-11 12:27:58     fenn    "Any block that is created by a malicious user that does not follow this rule (or any other rules) will be rejected by everyone else."
2014-05-11 12:29:18     fenn    "Each block memorializes what took place immediately before it was created."
2014-05-11 12:29:49     fenn    New blocks can't be submitted to the network without the correct answer - the process of "Mining" is essentially the process of competing to be the next to find the answer that "solves" the current block.
2014-05-11 12:30:24     fenn    each hash is a "guess" at the answer
2014-05-11 12:30:59     andytoshi       fenn: you are totally missing the forest for the trees
2014-05-11 12:31:11     andytoshi       like if you said aerobic respiration was a process for binding carbon to oxygen
2014-05-11 12:31:33     fenn    he said "do you know what the hashes are for" and i answered, what do you want
2014-05-11 12:31:40     andytoshi       and when asked what it's for, you started talking about valence electrons and how respiration gets you the right reconfiguration
2014-05-11 12:32:13     andytoshi       fenn: the hashes give a way to translate computational resources into something cryptographically verifiable
2014-05-11 12:32:21     andytoshi       that's what "proof of work" refers to
2014-05-11 12:32:35     fenn    it has nothing to do with computational resources
2014-05-11 12:32:48     andytoshi       it lets you /define/ the system mathematically so that it is hard to rewrite history
2014-05-11 12:33:08     andytoshi       fenn: the correct answer to kanzure's question was "no"
2014-05-11 12:33:24     fenn    it's just the ability to do this particular cryptographic algorithm, which happens to be implemented on something resembling a computer
2014-05-11 12:33:52     -->     drewbug1 (~Adium@c-71-207-76-172.hsd1.pa.comcast.net) has joined ##hplusroadmap
2014-05-11 12:35:21     fenn    you can take all the bitcoin asics in the world and the won't be able to add 2+2
2014-05-11 12:35:52     chris_99        heh
2014-05-11 12:36:14     <--     drewbug (~Adium@fsf/member/drewbug) has quit (Ping timeout: 240 seconds)
2014-05-11 12:36:30     andytoshi       yeah, and you can take all the aerobic biomass in the world and they won't be able to either
2014-05-11 12:36:54     andytoshi       and yet here we are huffing and puffing as we type frantically
2014-05-11 12:37:01     fenn    the difference is you say one is "computational resources" and the other isn't?
2014-05-11 12:38:09     andytoshi       ?? the difference is that respiration is used to provide useful energy to the organism while bitcoin hashing is used to translate a fact of physics to a fact of mathematics
2014-05-11 12:38:22     andytoshi       they are more alike than they are different at the level we are talking
2014-05-11 12:38:42     andytoshi       in both cases they are a mechanism for taking resources from the environment and translating them into a form that the system can use
2014-05-11 12:38:44     fenn    but cells are more general purpose than bitcoin asics
2014-05-11 12:39:06     fenn    even "specialized" cells can do a large number of things
2014-05-11 12:39:16     andytoshi       i'd like a citation that DNA is more expressive than bitcoin script..


You later suggest that checkpoints are an improvement on consensus. This is not true. Checkpoints have nothing to do with consensus. Nada. This has been beaten to death by myself and several others, and is another example of a bitcointroll meme infecting your thought. Above you say that proof-of-stake is the reason that Peercoin is so popular. But Peercoin has been centralized from the start, and has no plan for ever being decentralized. Of course a centralized consensus system is able to be more efficient than a trustless one.

You compare Bitcoin confirmation times to CC transaction approval times. This is nonsense. There is no amount of time after which CC transactions are really irreversible in the sense of Bitcoin, but even the amount of time to eliminate the trivial "call the CC company and dispute the charge" method of reversal is several months. So you should be comparing hours (for Bitcoin) to months (for CC companies). If all you care about is transaction "approval" this is limited only by the speed of the network, just like with CC's, except that the Bitcoin network is more distributed and anyone can verify transactions, so the uptime is better. Again, this has been beaten to death here.

You say that Primecoin is an example of a "useful PoW". But there is no known use for Cunningham chains, and Primecoin has an awful awful "proof" of work which fails pretty-much every point laid out in my ASIC FAQ.

You repeatedly describe the adversarial nature of the Bitcoin network as something Satoshi made up. But adversariality is a fact about the world and not something you can model away when designing a decentralized cryptosystem.


2. I haven't look into your tamper-resistant logs but I worry about how efficient these can be regarding both CPU time and bandwidth, since you have every transaction producing a bunch of these, in some cases from cell-phones or other transaction-producing devices. It looks like at every time you have a single mint who gets to decide what order transactions occur in and which ones are valid or invalid. It's not clear what happens if the node approves conflicting transactions (I guess he gets banned when the next block is produced, but then how do you decide which one was the "correct" one? This does not seem to achieve the "instantly confirmed transaction" scenario I think you are going for.)

Also, don't use Bitcoin addresses for authentication. They can be used to authenticate against "the owner of coins sent to this address" but pretty-much nothing else. Addresses are payment identifiers and confusing this purpose with that of signing keys is only going to cause user error.


3. As we discussed in Austin, this nomadic business makes historic consensus tricky. Suppose the superpeers wind up in being in Vancouver for the summer. After some time they move on to London, so I have an opportunity to buy all the old superpeers' hardware from them for cheap prices. I use them to rewrite some history sufficient that they now pass off to a system in Austin which I control. From there on I'm able to do the usual stake-grinding or whatever tricks to maintain possession of the entire superpeer network forever, just sending it to my hubs around the world. If I were andyfastow rather than andytoshi I'd even set up a bunch of shell corps to disguise that I was doing this.

The point is that if you want to prevent rewriting history, you need to trust everyone with an ability to manipulate history, forever, even long after their incentives to help the network have gone. You need to prevent old hardware from winding up in unsecured dumps, from being stolen, from being hacked, etc., etc. I'd wager most TPM chips out there will expose their keys to (at least one of) the Chinese or Americans.


4. When you talk about trusted computing, what is the actual trust model behind this? I assume you need an authenticated channel to the TPM to verify the machines' software, but when you are only talking to a node through a network it is unclear to me how you can trust that you're talking to a real TPM which is really installed in the system that you're communicating with.


Andrew




Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 04:55:31 PM
Thanks Andrew for your thoughtful comments. I will keep them in mind as I devise the system test plan, that in turn guides the code to be written.

I will attempt to orchestrate public test scenarios that include the bad things you describe, and show whether the system works or not. If the system works, then indeed proof-of-work will be shown to be a wasteful Bitcoin design. If the system handles various byzantine faults and misbehavior, then the algorithm's adopted from Nick Szabo and others I reference will manifestly demonstrate a solution to what up to now has not been solved in Bitcoin.

As the tests proceed next year, I hope first that the simple tests work, and second that you and others propose more difficult challenges.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 04:57:24 PM
Comments from the Bitcoin core developers mail list . . .

  • Referring to the subsidy for miners as "wasting it on miners" isn't going to garner you much favor.

I subsequently removed the word "waste" from the paper and substituted "effort" where needed.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: drawingthesun on May 20, 2014, 05:00:21 PM
Comments from the Bitcoin core developers mail list . . .

  • Referring to the subsidy for miners as "wasting it on miners" isn't going to garner you much favor.

The transactions are moved across the world by the nodes, and then kept secure essentially by the miners.

So it's not wasted! But certainly half wasted!

Nodes are so important and if the transaction volume picks up, eventually the security of the network will be in few hands because only a few people will have the chain.

Even miners do not need the chain anymore. The chain keepers (nodes) have no incentives.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: digitalindustry on May 20, 2014, 06:00:53 PM
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.

Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.

I don' think you are getting it, but this is possibly a political nativity, they are saying they will do the hard sell to other chumps to get them to take this road.

---

I have one question and its of an economic nature, here it is:

If i'm X with 1000 BTC now I have a "Stake" in Bitcoin, agreed?

To get this stake i had to either:

A: Mine it using PoW
 
or

B: Purchase it with fiat money or good or services (essentially packaged energy)
  
of course i might have realized a large profit up until this point (transfered energy) , but>

now to further my Stake, I need to expend more work in some way, (so let me give you an example.)

*lets exclude transfer for the now as its irrelevant to the conversation directly, but lets come back to it.

I might need to buy hardware to mine more PoW currency as per the equilibrium of difficulty.

or

I can directly expend (packaged energy) fiat or goods and services to gain more "stake"


So in summary i can conclude that , Proof of stake is basically a shell game that gives and owner of the stake(energy) an increasing reward(energy) thus centralizing the network and breaking a bunch of fundamental laws of economics.

having said all of that , my question is simple - does more "stake" give more "votes" as per the "one cpu one vote" principal?



** i still believe that you could be able to implement this don't get me wrong, we know the human race is fundamentally docile, however where it will fail is in the execution, you should read over some of my theories on decentralized economics.

This system would fail for the same reasons the current banking system is failing and its centralized media outlets, basically the theory of decentralized multidimensional information flow and how that effects competition.

i will give them to you once i have refined them a little.

sorry for the rant the simple question again:


does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: digitalindustry on May 20, 2014, 06:11:32 PM
a discerning reader could come back to me right now and say "but the equilibrium of difficulty is broken"

difficulty rises but the price has not, well, this comes down to a few aspects , some natural market and others relate to the flaws in the "one cpu one vote"; that; implementation outside of the white paper has proven.

the market is correcting that right now, but unfortunately some will be blinded by the "light" that is "Bitcoin" the brand and not the protocol.

CPoW or whatever you want to call it has gone some way too that , but there will no doubt be further improvements.

people come back and say "there will always be hardware specialization" , and I've always told people "software innovation can easily out-pace hardware specialization".

 


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: digitalindustry on May 20, 2014, 06:19:23 PM
The miners are not the only stakeholders. What really matters is whether the users want to own the new coins or the old.

Nope. The consensus is very clearly defined. Users of coins have absolutely nothing to decide in this decision making process. If you want to understand how Bitcoin works I would suggest to study the whitepaper. If a switch to another algorithm would be possible, bitcoins would be worthless bits. The most important feature of the network is that some elements can't change, first and foremost the money supply and proof-of-work. You can ask some of the miners and core developers how likely such a switch is.

I don' think you are getting it, but this is possibly a political nativity, they are saying they will do the hard sell to other chumps to get them to take this road.

---

I have one question and its of an economic nature, here it is:

If i'm X with 1000 BTC now I have a "Stake" in Bitcoin, agreed?

To get this stake i had to either:

A: Mine it using PoW
 
or

B: Purchase it with fiat money or good or services (essentially packaged energy)
  
of course i might have realized a large profit up until this point (transfered energy) , but>

now to further my Stake, I need to expend more work in some way, (so let me give you an example.)

*lets exclude transfer for the now as its irrelevant to the conversation directly, but lets come back to it.

I might need to buy hardware to mine more PoW currency as per the equilibrium of difficulty.

or

I can directly expend (packaged energy) fiat or goods and services to gain more "stake"


So in summary i can conclude that , Proof of stake is basically a shell game that gives and owner of the stake(energy) an increasing reward(energy) thus centralizing the network and breaking a bunch of fundamental laws of economics.

having said all of that , my question is simple - does more "stake" give more "votes" as per the "one cpu one vote" principal?



** i still believe that you could be able to implement this don't get me wrong, we know the human race is fundamentally docile, however where it will fail is in the execution, you should read over some of my theories on decentralized economics.

This system would fail for the same reasons the current banking system is failing and its centralized media outlets, basically the theory of decentralized multidimensional information flow and how that effects competition.

i will give them to you once i have refined them a little.

sorry for the rant the simple question again:


does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.


ha ha thinking on this more is that why your tag is "SlipperySlope" ha  : D


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 06:20:59 PM
does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.


The answer is Yes. But I do not follow your argument. A better response from me will have to await the availability of code to test.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: cryptomad on May 20, 2014, 06:39:06 PM
Thanks for the info Good read  :o


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: harveyweizhao on May 20, 2014, 06:41:38 PM
I like the idea of super-peer-POS.

POW does cause some problems in current BTC network.
It is always great for the community to get prepared before more critical issues occur on BTC.  


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: digitalindustry on May 20, 2014, 07:03:50 PM
does more "stake" give more "votes" as per the "one cpu one vote" principal?

if your answer is yes,  that's a "double spend"  of  "packaged energy" think about it.

well when i say its a "double spend" it had to come from somewhere, so let me think on this, its transfered from the decentralized network. oh, of course its an implosion.

wow.


The answer is Yes. But I do not follow your argument. A better response from me will have to await the availability of code to test.

the argument is simple :

where does the energy come from?

if Bob has 1000 Bitcoin and wants more how does Bob get them?


lets look:

- Bob buys them.   (Bob expended energy in the form of paper money or good or services)

- Bob Trades them for profit.  (Bob just transfered someone else's energy and made a profit, someone else lost this time)  

- Bob Buys hardware and mines them (Bob expends either Bitcoin (energy tokens) or fiat (energy tokens) and buys hardware and mines them)

or

Proof of stake says Bob gets "interest" on owning something, this breaks the law of energy equilibrium and transfers energy to Bob.


this is not a problem, and it works now because ah, people don't know any better and are stupid, but however why it won't work in the future is because of the same reason Joe goes to work now  and is seeing a declining reward for his work, and why people are turning off the TV.

The reason "interest" exists is for a premium on a risk for Debt (transfer> generally consensual)  or as a shell game to steal wealth (energy) from humans.  (theft) .

only those reasons.



Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 07:35:17 PM
the argument is simple :

where does the energy come from?

if Bob has 1000 Bitcoin and wants more how does Bob get them?


lets look:

- Bob buys them.   (Bob expended energy in the form of paper money or good or services)

- Bob Trades them for profit.  (Bob just transfered someone else's energy and made a profit, someone else lost this time)  

- Bob Buys hardware and mines them (Bob expends either Bitcoin (energy tokens) or fiat (energy tokens) and buys hardware and mines them)

or

Proof of stake says Bob gets "interest" on owning something, this breaks the law of energy equilibrium and transfers energy to Bob.

Ok, I sort of get your chain of reasoning but I think it is faulty. Its not so much about where the purchasing power came from, but to me rather how it is spent. For example dollar bills can be literally burned. That is a form of useless spending. Or dollar bills can be used to buy bitcoins. That is better in my opinion, regardless of how much coal was consumed to create those dollars in the first place. And that is all I have to say on this until the code to be written can speak for itself.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: hashman on May 20, 2014, 08:49:14 PM
Very interesting paper!  Thank you for discussion here. 
"In contrast, incumbent credit/debit card payment systems are faster [3] and more certain for consumers. Incumbent bank wire transfer, e.g. Swiftnet [4], is faster and more certain for business-to-business users. Incumbent payment transfer systems have data security policies that Bitcoin lacks [5] with regard to protecting host computers and customer data, e.g. private keys."

I disagree with these statements.  Incumbent systems do have advantages but they are not necessarily faster or more certain (can be reversed up to months later).  As for security policies the incumbent systems are all way behind (pull system, no triple accounting, etc).


When I say faster, I mean the typical customer check-out experience at point-of-sale. You verify the payment account at a terminal, swipe a card, and collect the receipt. When I say more certain, I mean to cover the odd case where a bitcoin transaction makes into a block after a certain delay, or the less likely, but worse case when the transaction never gets into a block. The bitcoin network forwards transactions on a best effort basis. There are no guarantees that the transaction will be recorded into the blockchain.


Thanks for your reply! 
Funny you should mention that.  I waited in line behind a credit card payer at the sandwich shop yesterday.  Long wait, card didn't go through.    Next in line was me.  I asked for the total in bitcoin, pressed send.  Accepted (at zero confirmations) instantly.  There are no guarantees in life, but bitcoin is pretty damn good.       

Quote
Quote

Why?  There is no reason to use proof of stake.  Saying that miners use too much energy is simply saying miners are not smart, not that there is a problem with proof of work.  Miners are free to use as much energy as they like.  Proof of stake looks to me like a solution in search of a problem.     

Proof-of-stake was immediately recognized as a very attractive idea when first proposed back in 2011. It is the main reason why PeerCoin has the 4th highest market cap. Satoshi admitted that his design would eventually force miners to congregate in locations with the least expensive power, as math shows that competing miners will use all the block reward to support their efforts.

So we need it because other people think we need it?  Peercoin also has a novel reward schedule, both in it's proof of work component with reward linked to difficulty, and of course in the proof of stake portion that appeals to the greedy.  Yes, people will use resources more where they are cheap.  Is that a problem? 


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 20, 2014, 09:38:11 PM
. . . There are no guarantees in life, but bitcoin is pretty damn good.       

Just wondering from your user name if you are a fellow miner?

If so, would you be better off buying dividend paying bitcoins with the money you otherwise set aside to upgrade your rigs? The bitcoin bubble and bust cycles tend to ruin miners. I keep my GPU scrypt rigs leased out for bitcoin on LeaseRigs. I will not sell the cards, I just migrate the mining algorithm away from ASICs.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: hl5460 on May 21, 2014, 12:31:52 AM
Why don't you invite Sunny King to chip in? He is the one that turns PoS into reality through PPC.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Peter R on May 21, 2014, 06:27:41 AM
...Proof of stake says Bob gets "interest" on owning something, this breaks the law of energy equilibrium and transfers energy to Bob.
Ok, I sort of get your chain of reasoning but I think it is faulty. Its not so much about where the purchasing power came from, but to me rather how it is spent. For example dollar bills can be literally burned. That is a form of useless spending.

If you think burning dollar bills represents useless spending, then do you also think printing new dollar bills represents useful savings?  I think you must because your dividend idea essentially prints new bitcoin bills and distributes them, not to those who did work, but to those who held stake.  You seem to think this represents increased wealth (savings).  

The truth is that burning dollars bills is not spending because nothing was consumed.  Similarly, printing more dollar bills is not savings because no consumption was deferred.  

In both cases (burning or printing dollars bills), all you are doing is changing the value of M in the  Quantity Theory of Money (http://en.wikipedia.org/wiki/Quantity_theory_of_money) equation:

   M V = P Q

If you burn dollar bills, then M decreases.  To maintain the economy's real output Q and velocity of money V, the price levels across the economy need to decrease.  So I would argue that you burning your dollar bills is actually a good thing for me because it will very slightly decrease the prices I pay.  It is like a small donation to all the holders of the currency.

In your proposal, you do the opposite: you print new bitcoin bills and distribute them to the stake holders. But this just devalues the money, and assuming all else remains constant, price levels across the economy would tend to rise.  In other words, stake holders may have 10% more money but everything costs 10% more.      


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: Amph on May 21, 2014, 06:59:48 AM
what about a solution to mint with an offline wallet, connected to an online one? it's possible?


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: r0ach on May 21, 2014, 08:36:51 AM
then there still is no incentive not to mine on both in parallel

I always see people quote the Gavin phrase of "nothing at stake" as fact, but it seems like a complete logical fallacy to me.  Don't you need a majority of people holding the proof of stake currency to run non-reference clients to stake multiple chains at once for this to be true?  So you're basically saying the people with the most financial incentive to protect the network are all going to attempt to destroy the network security on purpose, and do it en masse?  How does this not violate game theory?

Bitcoin relies on game theory to exist.  It seems like these same principles should prevent such a thing occurring in proof of stake.

Let's not forget that most people on the planet aren't programmers.  If any crypto coins make it into the mainstream, the majority of people holding proof of stake coins, or using the network at all, will not have any idea how to leverage their stake to attack it.  I feel like many proof of stake attack vectors are done under the assumption that the majority of coin holders are Russian cyber criminals.

Assuming the proof of stake complaints are either dispelled or fixed, the main issue I have with proof of stake is it's attacks are very hard to see coming.  If a vendor like Amazon was taking huge volume of Bitcoin, they would actively monitor network hashrate and have a Defcon 1, red alarm siren go off when the hash rate became too lopsided to accept BTC.  They would then just not accept payments until the hash is distributed better.  Practices like this make the 51% attack almost irrelevant for big business.

Doing something similar to the above with proof of stake seems almost impossible.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: rpietila on May 21, 2014, 08:51:09 AM
...Proof of stake says Bob gets "interest" on owning something, this breaks the law of energy equilibrium and transfers energy to Bob.
Ok, I sort of get your chain of reasoning but I think it is faulty. Its not so much about where the purchasing power came from, but to me rather how it is spent. For example dollar bills can be literally burned. That is a form of useless spending.

If you think burning dollar bills represents useless spending, then do you also think printing new dollar bills represents useful savings?  I think you must because your dividend idea essentially prints new bitcoin bills and distributes them, not to those who did work, but to those who held stake.  You seem to think this represents increased wealth (savings).  

The truth is that burning dollars bills is not spending because nothing was consumed.  Similarly, printing more dollar bills is not savings because no consumption was deferred.  

In both cases (burning or printing dollars bills), all you are doing is changing the value of M in the  Quantity Theory of Money (http://en.wikipedia.org/wiki/Quantity_theory_of_money) equation:

   M V = P Q

If you burn dollar bills, then M decreases.  To maintain the economy's real output Q and velocity of money V, the price levels across the economy need to decrease.  So I would argue that you burning your dollar bills is actually a good thing for me because it will very slightly decrease the prices I pay.  It is like a small donation to all the holders of the currency.

In your proposal, you do the opposite: you print new bitcoin bills and distribute them to the stake holders. But this just devalues the money, and assuming all else remains constant, price levels across the economy would tend to rise.  In other words, stake holders may have 10% more money but everything costs 10% more.      


QFT.

It is surprisingly often good, when a proposal is being discussed, to consider doing the exact opposite. If it is not found pernicious, it is doubtful that the proposal is found beneficial.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on May 21, 2014, 10:42:50 AM
In your proposal, you do the opposite: you print new bitcoin bills and distribute them to the stake holders. But this just devalues the money, and assuming all else remains constant, price levels across the economy would tend to rise.  In other words, stake holders may have 10% more money but everything costs 10% more.      

As a result of writing the whitepaper and listening to constructive comments, e.g. yours, about the proposed Bitcoin system, I am persuaded that paying dividends to stakeholders is a lower priority than investing bitcoin block creation rewards into a network capable of processing all the world's transactions.

This system needs a way to prevent an attacker from establishing numerous puppet nodes, who by acting in concert, could outvote the correct nodes and allow misbehavior. Proof-of-stake provides a means to limit the ability of an attacker to outvote correct nodes. The assumption is that correct nodes will offer sufficient stake in a hot wallet in return for a certain amount of dividends.

The reward allocation policy is most certainly going to be contentious, and increasingly so as the technical barriers are overcome by working code through the end of this year. Core developers are skeptical of my ideas. But if they are won over by working code, then what to do with the $1.6 million daily block creation reward is moved from fantasy conjecture to pressing importance.

The block creation rewards increase with the price of bitcoin, halving in the summer of 2016 to 12.5 bitcoins per block, but staying at that schedule through 2020. Supposing bitcoin indeed reaches $1 million per bitcoin in 2017-2018, then the daily block reward in 2017 might be $1.8 billion per day.

Provided that network infrastructure is generously funded, including just say two hundred paid developers, and that sufficient dividends are paid to support proof-of-stake voting, why not subsidize transaction fees with the block creation reward? I can imagine circumstances in which bitcoin transaction fees could be negative. Visa could not compete with that. The challenge is to prevent abuse, e.g. we could figure out a way for merchants to identify themselves and subsidize transactions paid to them.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: sumantso on May 21, 2014, 11:00:16 AM
So its mostly based on DPoS?

Can't wait for a DPoS coin to come up (I think its close judging by Bytemaster's updates), and then see how it operates in real environment.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 01:50:47 PM
Comment from the Bitcoin-development email list . . .

I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/   But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.

This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things.  But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node.  Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 01:55:23 PM
Relevant chat log from the #bitcoin-wizards IRC channel . . .

<gmaxwell> stephenreed: Yes, bitcoin is ugly in many ways. I spent a decade working for a company building huge routers for internet backbones and working with big providers... I'm well familar with big communications infrastructure.  Bitcoin uses non-scalable mechnimes in a way which "can't work" to achieve an end— an anonymous decenteralized consensus— which "isn't possible" by conventional thinking.  In practice, so far, it does work.  ...
<gmaxwell> ... And I'd love to see something that achieved the same ends, but wishing it doesn't make it so... The uglyness in Bitcoin is not an accident, not a result of ignorance... the problem space truly is hard.
. . .
<gmaxwell> At one point I wrote long winded essays that what bitcoin achieves— a decenteralized consensus— was precluded by physical law. I was wrong, because I didn't consider the right relaxations of the requirements (the the consensus could be eventual and only so under certian economic assumptions, that a vote could be sufficiently sybil resources through the provable expendature of physically finite resources and at the same time ...
<gmaxwell> ... create the incentives the first required). There might be similar alterations of the assumptions or requirements that yield alternative solutions. I certantly hope so.  But I'd expect the presentation any successful attempt to start with a very clear statement of what the assumptions and limitations are, and how it addresses the hard problems that arise in this space.
<gmaxwell> (well to be clear, I'm already aware of some different designs with different assumptions— e.g. there are some proposals which achieve awesome properties— fast, secure, and scalable— that depend on a simple majority of non-anonymous signing registrars being honest. E.g. the compromise decenteralization to get basically every other property you could ask for)
<stephenreed> adam3us: I saw the link to Chris' paper on the dev mail list, read it, and asked him for permission to use it as a reference in my paper. He gave it.
<gmaxwell> adam3us: Amiller, jbonneau and others have been working on a systemizing bitcoin knoweldge paper: https://github.com/citp/bitcoin-sok
. . .
<stephenreed> gmaxwell: this is a key paper that I referenced - http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf    Attested Append-Only Memory: Making Adversaries Stick to their Word, Chun et al. Their math says it is byzantine fault tolerant with respect to relicas less than 50% faulty. Then I use timeline entanglement to make the logs tamper-evident. Also a reference from my paper.
<stephenreed> gmaxwell: Nick Szabo explained the benefit of unforgeable logs as you probably alreadky know.
<gmaxwell> stephenreed: I believe I've read this before? Will check... but generally the problem the clasical approaches have is they do not work in the model of anonymous membership. You have have agreed in advance the identity of the members of the participants in the system. (and have some method to be confident that they are not mostly sybils of a single party)
<stephenreed> gmaxwell: given your network architecture experience, superior to my own, would you say that such a network could indeed handle all the world's transactions?
<stephenreed> gmaxwell: in my system the peers provide a controlled bitcoin address both for identity and for signing their non-transaction messages. That is the audit trail peers can easily verify.
<stephenreed> gmaxwell: Sybils are prevented by the need to sufficient stake them.
<gmaxwell> stephenreed: Bitcoin the payment network? of course not, but it doesn't need to for bitcoin the currency to handle all the worlds transactions (if the world wished it so).  With a sold, throughly secure and decenteralized base we can run additional payment systems on top of bitcoin to achieve additional features and scale.
<stephenreed> gmaxwell: I mean is the super peer network truly capable of handling all the worlds transactions? I think so based on what I read about VisaNet and SwiftNet.
<gmaxwell> stephenreed: If the identity is a propery inside the system how do you prevent simulation?  An example of simulation attacks: past participants leave the system, someone obtains their keys, recovers a snapshot from when they were still a quorum, then plays forward creating a new alternative history.  A new entrant joins the system, he can tell that someone cheated (by the conflicting signatures) but how can he distinguish which state ...
<gmaxwell> ... is the 'real one'?
<stephenreed> gmaxwell: the point is weakened if the peer behaves correctly. A thief to the original owner - but that is same in the current system with regard to hacking a hot wallet.
<andytoshi> stephenreed: the problem is that you have humans determining which transactions go where, so there is no canonical "behaves correctly" in this case
<stephenreed> The orginal history was created by a very carefully single nomadic mint. Did you get that point? All full nodes replicate the single version blockchain.
<gmaxwell> Those thefts happen all the time, even when there is something significant at stake— in my example though they keys could be stolen after the peer has no involvement with bitcoin at all and will lose nothing in an attack (and in fact, may gain handsomly by facilitating an attack)
<stephenreed> gmaxwell: created by a very carefully watched single nomadic mint agent ...
<gmaxwell> stephenreed: I'm not sure I follow your question wrt super peer network. My own prior comment was that I believe the bitcoin ecosystem in total would be able to handle all the worlds transactions, if we wished it to.
<adam3us> gmaxwell: i think the scale question should be with the caveat that to interestingly scale, the main bitcoin properties should still be available to all users (unseizable, unfreezable, user control) for that to be an interesting scaling architecture.  its less interesting if we have a $100k min transaction clearing network with unseizability for them, but trust me for users.  (less but still interesting, viz international banking freezes and spats)
<stephenreed> gmaxwell: Indeed a mesh network could have preferred connections and that is how I intend to modify the core to become a super peer network.
<jgarzik> noooo
<andytoshi> stephenreed: to a newcomer, the original history and a forked history may be indistinguishable as far as legitimacy goes. it's hard to verify things like "carefully watched" even if you are forcing your superpeers to basically be visible economic entities (since they need so much space and bandwidth)
<gmaxwell> stephenreed: There are a great many things you can do if you have a centeral point of trust. And lots of ways to achieve audiability where misconduct of that agent is visible... Thats a viable approach but _very_ philosophically different from Bitcoin, because that agent is still trusted. (I wonder if you've seen the original p2pfoundation announcement of bitcoin? http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source )
<jgarzik> somebody else proposed a super node network at the AMS conference
<jgarzik> how many variants of "but, if we just TRUST these guys over here a little bit more" do we need?
<stephenreed> jgarzik: my ideas are not new. The super peer idea evolved out of the p2p stuff back when Satoshi was looking at napster.
<stephenreed> gmaxwell: My software agents are trustless as Szabo suggests. The unforgeable log enables peers to validate.
<stephenreed> jgarzik: Super peers have superior network/server capability but run the same code base.
<jgarzik> same code base or not is immaterial
<stephenreed> andytoshi: yes visible so that cooperation is assumed but cheating quickly detected. The network reengineering can easily handle the increased traffic - point to point, not mesh.
<andytoshi> detecting cheating is easy, determining who is/isn't cheating is not
<andytoshi> stephenreed: even if you get trustless software agents (e.g. by auditing their behavior or somehow TPM-verifying that they are clean VMs running only your software) you still have (a) random coins, e.g. for peer selection, and (b) user decisions, e.g. transactions, which are inputs from the real world and therefore can be used to introduce distortions and/or forks
<stephenreed> jgarzik: material because tamper-evident logs record every action, inputs and outputs of a peer.
<stephenreed> andytoshi: that point addressed in the paper linked above - less than 50% faulty agents can be tolerated.
<adam3us> stephenreed: how can i audit a network entities tamper-evident logs? TPM remote attestation?
<jgarzik> andytoshi, indeed.  And RE detecting cheating, Sybil'd views can make you particularly vulnerable
<stephenreed> adam3us: yes, but I omitted TPM attestation from the paper because current implementations are too proprietary. I want a TPM enabled stack that says your current release of bitcoind is running and nothing else - no keyloggers etc.
<stephenreed> adam3us: here is the paper on TPM attestation that I studied - http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf
<gmaxwell> stephenreed: These are all neat technologies that we've talked about in here and ought to exist as part of the greater bitcoin ecosystem... but they are really not a replacement for what Bitcoin provides.  E.g. the TPM hardware maker can trivially compromise those systems.
<stephenreed> adam3us: For TPM I was looking at a bare metal implementation not a hypervisor.
<gmaxwell> (I happen to have an IBM cryptocard myself— which is basically the pinnical of remote attest technology right now— ... and I've been playing around with the nexus operating system, which is a hypervisory OS that facilitates remote attest)
<stephenreed> gmaxwell: right about TPM. I understand you need a license to use it in China for example. So remote attestation of unforgeable logs per Szablo works too.
<stephenreed> gmaxwell: They are not a replacement for proof-of-work. They are a replacement that preserves the Satoshi Social Contract between developers and users. My ideas are half-baked now. The code to be written will speak for itself.
<gmaxwell> Traditional reserve currencies are backed by power and authority of natition states— entities with the power to extinguish all life on earth (well, at least all human life)— and yet they do not behave in a way that many people consider trustworthy— they are rules by politics and personalities not by Law.  Some of them have apparently strong social contracts, and yet they do not prevent mission drift.
<gmaxwell> Well I look forward to seeing some neat stuff!
<stephenreed> I wish the Barcelona test harness was done. I need to orchestrate lots of peers to meet your challenges.
<gmaxwell> (don't take my cycnism for dislike)
<stephenreed> gmaxwell: according to Gavin's videos you are the core developer that I need to convince first - Thanks and wait for code.
<stephenreed> Thanks for observing while I write the code of a lifetime.
<adam3us> stephenreed: i would encourage generally to explain algo before coding it because its many orders of magnitude faster to explain an algo than to code it; that way you get feedback early if there are problems that'd need a rewrite
<gmaxwell> Right well in particular make sure the high level objectives of the algorithim are clear before the details.  It's a lot of work to sort out the limitations in the architecture of an idea starting at the 'molecular level'.
<jgarzik> Yes, gmaxwell is the gateway to a new universe ;p
<gmaxwell> Hopefully not in the sense of some volcano-involving rital sacrifice.
<gmaxwell> In other news, the bytecoin-derrived cryptocurrencies ecosystem is now using merged mining, there is now a fork that is merged mined against and of the 3 (or more?) prior bytecoin-derrived cryptocurrencies. (this isn't super news its a few weeks old, but its news to me)
<stephenreed> adam3us: After making or reusing a test harness,  the first bit of work is the tamper evident log, which should be easy to document since I will look closely at the current debug log of bitcoind. The step beyond that would be timeline entanglement which makes the logs tamper-evident. I need to be able to digitally sign a peers log. The functions I need should already be in the core, provided I can capture the key p
<stephenreed> air somehow.
<sipa> "the keypair", which?
<stephenreed> sipa: If you have been following the conversation, then Szabo style unforgeable logs can be created if peers sign  each others logs. I propose for a peer operating a full node to provide a key pair for that purpose, e.g. a bitcoin address public/private key pair.
<sipa> you say "capture the keypair somehow" -> which keypair?
<gmaxwell> stephenreed: in bitcoin the blockchain itself is the unforgable log, but because the system is anonymous (there are no enumerated identities) they are signed via cumulative proof of work instead of a traditional digital signature.  Debug.log is orthorgonal, it's just for software QA, and very little of it is about information which is interesting to other parties.
<stephenreed> sipa: Well the QT wallet securely stores private keys so I suppose I would reuse that method.
<sipa> nodes have nothing to do with wallets
<sipa> it's a historical accident that satoshi's software does both
<gmaxwell> stephenreed: normally bitcoin keys in wallets are intended to be single use, one transaction. As sipa notes we've been slowy working towards seperating the functionality.
<stephenreed> separation is great. My purposes require that a peer sign another peers log to make it tamper-evident. I need for the node operator to provide the private key to bitcoind. The wallet has a method to input and securely store private keys. I may need the wallet in order to received daily dividends from the "reward agent".
<sipa> sounds like you just need something like a host key
<sipa> independent of the wallet
<stephenreed> sipa: how would you store it?
<sipa> oh, you also use it to receive coins?
<stephenreed> sipa: I need to receive bitcoins yes but that may be orthogonal
<sipa> you get rewards for running a full node?
<stephenreed> sipa: I hope that you will read my whitepaper ... https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
<andytoshi> sipa: as i understand it, that is part of stephenreed's proposal because he has mechanisms by which peers enter and leave the system (which include proving some amount of dedicated resources as a sybil prevention)
<stephenreed> sipa: I also have a good set of extended references on the bitcointalk thread OP - https://bitcointalk.org/index.php?topic=584719.0
<andytoshi> stephenreed: you want to separate bitcoin addresses from authentication, you can attach addresses (for receiving funds) to your ID by signing them with your auth key, but because addresses are supposed to be ephemeral they are not well-suited to auth on their own
<stephenreed> sipa:  The whitepaper describes -  a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of paying miners. Subsidized transaction fees are thus lower.
<sipa> sounds like a very different trust model than bitcoin
<sipa> (which is not a bad thing, but suggesting it as a replacement seems strange)
<stephenreed> sipa: a different trustless model yes. Cooperate to save effort, and verify peers to ban cheaters.
<sipa> bitcoin isn't fully trustless, and neither is this :)
<stephenreed> andytoshi: I will  note your comment.
<stephenreed> andytoshi: compared to todays bitcoin, I strongly desire permanent full nodes and would allocate sufficient reward to them to make that happen. SPV nodes can come and go.
<andytoshi> i guess you mean quasi-permanent, like tor, and that's another hard problem (though i don't believe it's impossible) to incentivize in a sybil-resistant way
<stephenreed> andytoshi: You must think that there is a hard problem that I am missing. I appears simple to me to keep track of peer uptime. I would create another agent to perform that duty.
<andytoshi> stephenreed: the hard problem is getting people to stay up when it's costing them resources and maintenance
<stephenreed> andytoshi: the peer would be identified by IP address and offered public bitcoin address. I would pay them to stay up. The current reward is $1.6 million per day divided by say 10000 full nodes!
<andytoshi> right, but it's easy to farm IP addresses and route them to a single box, it's hard to prove that every IP corresponds to disparate physical resources
<stephenreed> andytoshi: That is true of the current system where full nodes are hosted for $19 per month in a data center sharing a portion of some server. Replication of the blockchain is very important.
<andytoshi> it's true but why would anyone bother? it doesn't improve the decentralization or value of the network (which is the only incentive to run a full node today, besides goodwill and geek cred, which are also not helped by standing up sybils)
<stephenreed> andytoshi: Identity is supported by the controlled bitcoin address offered by each full node. The more stake, then more likely they are to be Sybil resistant.
<stephenreed> andytoshi: If there was a way for a software probe to determine, and to ensure, dispersed geographical locations - then I would use that.
<andytoshi> we had a recent discussion on ##crypto (or was it here?) about cryptographic proof of location, and i think we landed on "it's probably impossible" at least on earth since attackers can use fast airborne radio waves while honest parties have to use slow quantum signals in fiber optics
<andytoshi> regarding sybil resistance, if i have a lot of stake i'll get more reward but that still doesn't incentivize me to start more physical nodes. i'll open as many fake ones as my stake allows
<andytoshi> if anything using stake as a gatekeeping mechanism will cause your system to tend to oligarchy
<stephenreed> andytoshi: have to go, but I think online wallet hosting will be the largest stake holders.
<andytoshi> alright, ttyl, but as sipa says this is a large philosophical shift away from bitcoin


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Luckybit on May 21, 2014, 02:03:14 PM
Comment from the Bitcoin-development email list . . .

I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/   But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.

This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things.  But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node.  Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.

Morality is math. As long as it's equally applied throughout a system it's useful.
So as long as everyone follows the same rules no matter how ridiculous it seems it still creates order.

Call it morality or call it algorithm and there is no real difference between the two for a machine. It seems they are more critical of the framing and language you're using than the math behind it.

Overall what you intend to do looks a lot like DPoS. We may know whether or not your CPoS scheme can work from a review of the functioning of DPoS on the Bitshares network. It works on very similar principles except with a different metaphor to explain it. The delegates or the trustee would be fired for misbehavior (which is the same as being banned). I also see some similarities between CPoS and NXT.

Slight difference is that DPoS is deflationary from the beginning. Transaction fees are burned in DPoS, but there are some very good ideas in your whitepaper which it seems DPoS hasn't thought about so CPoS will be a very interesting experiment.

CPoS in my opinion is the right direction to take Bitcoin so you have my vote. Proof of Work is dead and the core devs might be able to save if it they switch from SHA-256 but we all know they cannot for political reasons. The fact that they haven't switched for political reasons is all the proof I need that Bitcoin is centralized. You're attempting to redecentralize Bitcoin and I applaud your effort.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 02:13:44 PM
Comment from the Bitcoin-development email list . . .

I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/   But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.

This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things.  But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node.  Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.

Thanks for commenting on my whitepaper. I linked proof-of-stake and infrastructure incentives because reallocating the block creation rewards yields $1.6 million daily, which pays for a lot of infrastructure, transaction fee subsidies - and just say 200 paid developers.

The banning of misbehaving nodes is an unclear statement on my part which is an attempt to characterize how a bitcoind instance currently disconnects from peers who repeatedly send invalid messages to it. That aspect of bitcoind I would not change. I extend that behavior so that peers actively replay each other's operations to check for consistency. When an inconsistent peer is identified by a quorum of its peers, it is disconnected - for some temporary period. And the reason would be made clear to the disconnected peer owner by an alert.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: clout on May 21, 2014, 02:53:29 PM
...Proof of stake says Bob gets "interest" on owning something, this breaks the law of energy equilibrium and transfers energy to Bob.
Ok, I sort of get your chain of reasoning but I think it is faulty. Its not so much about where the purchasing power came from, but to me rather how it is spent. For example dollar bills can be literally burned. That is a form of useless spending.

If you think burning dollar bills represents useless spending, then do you also think printing new dollar bills represents useful savings?  I think you must because your dividend idea essentially prints new bitcoin bills and distributes them, not to those who did work, but to those who held stake.  You seem to think this represents increased wealth (savings).  

The truth is that burning dollars bills is not spending because nothing was consumed.  Similarly, printing more dollar bills is not savings because no consumption was deferred.  

In both cases (burning or printing dollars bills), all you are doing is changing the value of M in the  Quantity Theory of Money (http://en.wikipedia.org/wiki/Quantity_theory_of_money) equation:

   M V = P Q

If you burn dollar bills, then M decreases.  To maintain the economy's real output Q and velocity of money V, the price levels across the economy need to decrease.  So I would argue that you burning your dollar bills is actually a good thing for me because it will very slightly decrease the prices I pay.  It is like a small donation to all the holders of the currency.

In your proposal, you do the opposite: you print new bitcoin bills and distribute them to the stake holders. But this just devalues the money, and assuming all else remains constant, price levels across the economy would tend to rise.  In other words, stake holders may have 10% more money but everything costs 10% more.      


Dividends should come in the form of burned stake, not in the form of redistributed stake. If you burn transaction fees, for example, that is an implicit dividend to everyone on the network since the money supply increased and purchasing power is transferred from those transacting to those saving.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 03:58:55 PM
A comment from the bitcoin-development email list . . .

I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.

More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 04:05:19 PM
A comment from the bitcoin-development email list . . .

I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.

More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.

The bitcoin core code only has perhaps 30% of Satoshi's code remaining. It can change.

The proposed system takes pains to preserve as much as the Satoshi Social Contract as possible. That is what users see. For them nothing much should change, and what does change should be much better. Full nodes are the foundation of Satoshi's Bitcoin. My proposal pays for upgrades so that they may process all the world's transactions.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 05:07:49 PM
Initial Install of Bitcoin Core and wallet . . .

Following Jameson Lopp's directions http://coinchomp.com/2014/04/03/set-ide-developing-bitcoin-core-ubuntu-linux/ (http://coinchomp.com/2014/04/03/set-ide-developing-bitcoin-core-ubuntu-linux/)

I have the branch from GitHub at https://github.com/StephenLReed/bitcoin (https://github.com/StephenLReed/bitcoin)

I followed the directions in build-unix.md. I have Ubuntu 13.10.
 
I added the bitcoin repository - ppa:bitcoin/bitcoin

Of the options, I chose to install libdb4.8, libboost1.53 and libminiupnpc-dev.

I executed ./autogen.sh
I executed ./configure until no errors
I executed make
OK

I installed NetBeans for C++ and compiled the bitcoin project OK. NetBeans gives hints as to problems it finds in the editor pane and I messaged sipa on #bitcoin-dev about this unresolved forward reference in main.h . . .

Quote
class CCoinsDB;

sipa said it should be . . .

Quote
class CCoinsViewDB;

The change built OK in NetBeans, so the next step is to run the provided regression tests. The regression tests ran OK.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 21, 2014, 06:39:07 PM
A comment from the bitcoin-development email list . . .

I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.

More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.

The bitcoin core code only has perhaps 30% of Satoshi's code remaining. It can change.

The proposed system takes pains to preserve as much as the Satoshi Social Contract as possible. That is what users see. For them nothing much should change, and what does change should be much better. Full nodes are the foundation of Satoshi's Bitcoin. My proposal pays for upgrades so that they may process all the world's transactions.


The response was . . .

Bitcoin is not a democracy. It's a micro-government, but where those with the hashing-power are for ever the rulers of Bitcointopia. There is no necessity to preserve the existing wealth. If the system is superior it will earn it of the market. And so we have a market of competing currencies. The incentives are high enough for people to make a better invention. Starting from scratch in software is often a good thing.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bitcoinbeliever on May 22, 2014, 12:20:37 AM
Enterprise-class would be a major downgrade from bitcoin's current class.  Bitcoin is AT LEAST solar-system-class.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 22, 2014, 02:43:34 AM
Enterprise-class would be a major downgrade from bitcoin's current class.  Bitcoin is AT LEAST solar-system-class.

If we are going to drive Visa and bank wire transfers out of business, then our network needs to be better than theirs. It cannot depend on part-time laptops and ADSL connections. It can be supplemented by those sort of home computers, but the network needs to be non-stop, redundant, and robust in case of power failure and Internet connection outages.

Enterprise class servers and networks are a solved problem. All it takes is money. Each day block creation rewards total about $1.6 million. There is plenty of money to give Bitcoin the hardware it deserves and to pay people around the world to run full nodes - if and when CPoS replaces PoW.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bitcoinbeliever on May 22, 2014, 02:57:20 AM
Enterprise class servers and networks are a solved problem. All it takes is money.

I don't think you quite appreciate the irony of that statement.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 22, 2014, 03:04:14 AM
Enterprise class servers and networks are a solved problem. All it takes is money.

I don't think you quite appreciate the irony of that statement.


Respectfully, I do not understand the irony.

Could you please elaborate on your reasoning that allows an interpretation the opposite of what I perhaps poorly wrote?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bitcoinbeliever on May 22, 2014, 03:51:07 PM
I do not understand the irony.

You are endeavoring to reinvent money.  Money is not an enterprise.  There is no general name for what it actually is, but as just one of its many functions, it mediates interactions between ALL enterprises.  Therefore the solution needs to be far beyond enterprise-class, and far beyond sovereign-class.

Your plan is to explicitly co-opt bitcoin via a blockchain fork, using by your own words, rhetorical as they may be, only a large accumulation of (fiat) money as the tool.  You imply that the global cryptocurrency franchise is something that can be bought.  That is an uninspired enterprise-level business plan.  If it actually worked, you'd better watch out for the next guy's fork.  He might have an even bigger pile of fiat.

Have you considered that even fiat money issuers do not go so far as to pay dividends on cash?

As world-class institutions I offer 2 examples. One is the adversarial legal system.  Is presuming people innocent of criminal charges the most cost-effective approach?  Well, no, but only the adversarial system, where the state must confront and defeat every hare-brained defense, repeatedly ad nauseum, has left society feeling the remotest tinge of justice.

The adversarial system is also what works in nature.  In the open ocean, every creature has to ruthlessly protect and defend its genome.  There is almost no trust across genomes.  And yet, a beautiful, balanced ecosystem emerges.

In this context, I think you underestimate the design of the mining function.

Your project will have its chance in the wild, and I will be disappointed in the universe if you succeed.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 22, 2014, 05:52:51 PM
I do not understand the irony.

You are endeavoring to reinvent money.  Money is not an enterprise.  There is no general name for what it actually is, but as just one of its many functions, it mediates interactions between ALL enterprises.  Therefore the solution needs to be far beyond enterprise-class, and far beyond sovereign-class.

Your plan is to explicitly co-opt bitcoin via a blockchain fork, using by your own words, rhetorical as they may be, only a large accumulation of (fiat) money as the tool.  You imply that the global cryptocurrency franchise is something that can be bought.  That is an uninspired enterprise-level business plan.  If it actually worked, you'd better watch out for the next guy's fork.  He might have an even bigger pile of fiat.

Have you considered that even fiat money issuers do not go so far as to pay dividends on cash?

As world-class institutions I offer 2 examples. One is the adversarial legal system.  Is presuming people innocent of criminal charges the most cost-effective approach?  Well, no, but only the adversarial system, where the state must confront and defeat every hare-brained defense, repeatedly ad nauseum, has left society feeling the remotest tinge of justice.

The adversarial system is also what works in nature.  In the open ocean, every creature has to ruthlessly protect and defend its genome.  There is almost no trust across genomes.  And yet, a beautiful, balanced ecosystem emerges.

In this context, I think you underestimate the design of the mining function.

Your project will have its chance in the wild, and I will be disappointed in the universe if you succeed.



Thanks for responding. I need very much to continue listening if there is any hope of achieving the wide approval this project needs to launch in early 2016. I am now downplaying the payment of dividends to those who offer hot-wallet stakes. I think that needs to happen to the extent required to prevent an attacker creating many controlled puppet full nodes and out-voting the correct nodes when a detected inconsistency requires correction. The bitcoin core developers are skeptical yet awaiting "neat technology".

The daily mining reward has risen to $1.8 million. I suggest that a well funded team of say 200 programmers can easily be paid from this sum to out-compete subsequent forks.

The system I am presenting has a one-time opportunity to re-engineer the network, while preserving the Satoshi Social Contract. 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.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 22, 2014, 06:06:10 PM
Today I am working on my first bitcoin pull request. Following Gavin's instructions How to create a PULL request (https://bitcointalk.org/index.php?topic=4571.msg66945#msg66945).

I am using the NetBeans C++ IDE on Ubuntu, which is not what most core devs use apparently. They use tools from decades ago, and depend on clear thinking, not the intelligent abilities of modern Integrated Development Environments.

The core devs mostly ignore compiler warnings as long as the code builds and tests OK. NetBeans dynamically parses the code in its editor and warnings are highlighted. I messaged sipa on #bitcoin-dev about some cruft in main.h and he is fixing that. Now I want to fix another warning/bug in main.h myself.

I am using Gavin's procedure for a pull request to fix just one line of code that will not really make any difference at all in how Bitcoin works. My plan for the next few days is to fix all the warnings that are easily fixed in the source code as revealed by NetBeans.

Then I need to get a couple of bitcoind instances running in a single machine testnet.

And I will begin to document how to write the tamper-evident log that is a key component of this project. The core devs have been helpful and have encouraged me, as is right, to explore an idea as an easily revised document, rather than as blind-alley coding.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 23, 2014, 03:27:07 PM
GitHub  notes . . .

Bitcoin GitHub repository
=========================
Code:
$ git clone git@github.com:StephenLReed/bitcoin.git
$ cd bitcoin
Synchronizing the my bitcoin branch with the origin bitcoin repository
https://help.github.com/articles/syncing-a-fork (https://help.github.com/articles/syncing-a-fork)

Code:
# initialize my local bitcoin branch repository
$ git clone git@github.com:StephenLReed/bitcoin.git
Cloning into 'bitcoin'...
Warning: Permanently added the RSA host key for IP address '192.30.252.130' to the list of known hosts.
remote: Counting objects: 36043, done.
remote: Compressing objects: 100% (9795/9795), done.
remote: Total 36043 (delta 26003), reused 36043 (delta 26003)
Receiving objects: 100% (36043/36043), 28.65 MiB | 611.00 KiB/s, done.
Resolving deltas: 100% (26003/26003), done.
Checking connectivity... done

$ cd bitcoin

# list the current remotes
$ git remote -v
origin git@github.com:StephenLReed/bitcoin.git (fetch)
origin git@github.com:StephenLReed/bitcoin.git (push)

# add the upstream remote repository
$ git remote add upstream https://github.com/bitcoin/bitcoin.git

# verify the current remotes
origin git@github.com:StephenLReed/bitcoin.git (fetch)
origin git@github.com:StephenLReed/bitcoin.git (push)
upstream https://github.com/bitcoin/bitcoin.git (fetch)
upstream https://github.com/bitcoin/bitcoin.git (push)

# Grab the upstream remote's branches
$ git fetch upstream
remote: Counting objects: 1142, done.
remote: Compressing objects: 100% (587/587), done.
remote: Total 1142 (delta 758), reused 805 (delta 553)
Receiving objects: 100% (1142/1142), 2.70 MiB | 569.00 KiB/s, done.
Resolving deltas: 100% (758/758), done.
From https://github.com/bitcoin/bitcoin
 * [new branch]      0.6.2      -> upstream/0.6.2
 * [new branch]      0.6.3      -> upstream/0.6.3
 * [new branch]      0.7.2      -> upstream/0.7.2
 * [new branch]      0.8.1      -> upstream/0.8.1
 * [new branch]      0.8.3      -> upstream/0.8.3
 * [new branch]      0.8.4      -> upstream/0.8.4
 * [new branch]      0.8.5      -> upstream/0.8.5
 * [new branch]      0.8.6      -> upstream/0.8.6
 * [new branch]      0.9.0      -> upstream/0.9.0
 * [new branch]      0.9.1      -> upstream/0.9.1
 * [new branch]      0.9.2      -> upstream/0.9.2
 * [new branch]      blockheaders -> upstream/blockheaders
 * [new branch]      freenode-verf -> upstream/freenode-verf
 * [new branch]      master     -> upstream/master

# List all local and remote-tracking branches
git branch -va
* master                         4765b8c Merge pull request #4087
  remotes/origin/0.6.2           40fd689 Bump version to 0.6.2.2 for osx-special build
  remotes/origin/0.6.3           6e0c5e3 Revert "Update gitian descriptors to point at stable git repo"
  remotes/origin/0.7.2           32a928e Use github for final 0.7.2 release
  remotes/origin/0.8.1           34d62a8 Set version numbers for 0.8.1 release
  remotes/origin/0.8.3           40809ae Bump version numbers for 0.8.3 release
  remotes/origin/0.8.4           839c7d1 Update the bloom state on the real object, not the temporary one.
  remotes/origin/0.8.5           ef14a26 Bump version numbers for 0.8.5 release
  remotes/origin/0.8.6           03a7d67 Release notes for 0.8.6
  remotes/origin/0.9.0           92d25e4 build: fix explicit --disable-qt-dbus
  remotes/origin/0.9.1           026a939 gitian: Version bump for Qt dependency
  remotes/origin/HEAD            -> origin/master
  remotes/origin/blockheaders    b24aa4a Saving work...
  remotes/origin/freenode-verf   7612e72 FreeNode verification
  remotes/origin/master          4765b8c Merge pull request #4087
  remotes/upstream/0.6.2         40fd689 Bump version to 0.6.2.2 for osx-special build
  remotes/upstream/0.6.3         6e0c5e3 Revert "Update gitian descriptors to point at stable git repo"
  remotes/upstream/0.7.2         32a928e Use github for final 0.7.2 release
  remotes/upstream/0.8.1         34d62a8 Set version numbers for 0.8.1 release
  remotes/upstream/0.8.3         40809ae Bump version numbers for 0.8.3 release
  remotes/upstream/0.8.4         839c7d1 Update the bloom state on the real object, not the temporary one.
  remotes/upstream/0.8.5         ef14a26 Bump version numbers for 0.8.5 release
  remotes/upstream/0.8.6         03a7d67 Release notes for 0.8.6
  remotes/upstream/0.9.0         92d25e4 build: fix explicit --disable-qt-dbus
  remotes/upstream/0.9.1         026a939 gitian: Version bump for Qt dependency
  remotes/upstream/0.9.2         2585310 Add missing LOCK(cs_main)
  remotes/upstream/blockheaders  b24aa4a Saving work...
  remotes/upstream/freenode-verf 7612e72 FreeNode verification
  remotes/upstream/master        97b53b5 Merge pull request #4152

# Check out our local master branch
$ git checkout master
Already on 'master'

# Merge upstream's master into our own
$ git merge upstream/master
Updating 4765b8c..97b53b5
Fast-forward
 .tx/config                                        |    7 +
 Makefile.am                                       |    4 +-
 configure.ac                                      |   47 +-
 contrib/debian/bitcoin-qt.install                 |    2 +-
 contrib/debian/bitcoind.install                   |    3 +-
 contrib/debian/changelog                          |   13 +
 contrib/debian/control                            |    8 +-
 contrib/debian/manpages/bitcoin.conf.5            |    3 -
 contrib/debian/rules                              |   21 +-
 contrib/devtools/README.md                        |   40 +-
 contrib/devtools/symbol-check.py                  |  113 +++
 contrib/devtools/update-translations.py           |   66 ++
 contrib/gitian-descriptors/gitian-linux.yml       |   22 +-
 contrib/gitian-descriptors/gitian-osx-bitcoin.yml |   65 ++
 contrib/gitian-descriptors/gitian-osx-depends.yml |  160 ++++
 contrib/gitian-descriptors/gitian-osx-native.yml  |  179 ++++
 contrib/gitian-descriptors/gitian-osx-qt.yml      |  192 ++++
 contrib/gitian-descriptors/qt-linux.yml           |  263 +++++
 contrib/macdeploy/macdeployqtplus                 |    4 +-
 doc/README_osx.txt                                |   71 ++
 doc/bootstrap.md                                  |    7 +-
 doc/build-unix.md                                 |   43 +-
 doc/release-process.md                            |   54 +-
 doc/translation_process.md                        |   29 +-
 qa/pull-tester/pull-tester.sh                     |    3 +
 qa/rpc-tests/README.md                            |   29 +-
 qa/rpc-tests/netutil.py                           |  134 +++
 qa/rpc-tests/rpcbind_test.py                      |  152 +++
 qa/rpc-tests/util.py                              |   32 +-
 share/genbuild.sh                                 |    2 +-
 share/qt/Info.plist.in                            |    6 +-
 src/Makefile.am                                   |    2 +-
 src/Makefile.include                              |   12 +-
 src/base58.cpp                                    |  183 ++++
 src/base58.h                                      |  259 +----
 src/bignum.h                                      |  595 ------------
 src/bitcoin-cli.cpp                               |    2 +
 src/bitcoind.cpp                                  |    9 +-
 src/chainparams.cpp                               |    6 +-
 src/chainparams.h                                 |    5 +-
 src/compat.h                                      |   10 +-
 src/core.cpp                                      |    4 +-
 src/init.cpp                                      |   26 +-
 src/json/json_spirit_reader_template.h            |   12 +-
 src/json/json_spirit_value.h                      |   32 +-
 src/key.cpp                                       |   72 +-
 src/key.h                                         |    3 +
 src/keystore.cpp                                  |    3 +
 src/leveldb/Makefile                              |   11 +-
 src/leveldb/db/filename.cc                        |    9 +-
 src/leveldb/db/log_reader.cc                      |   23 +-
 src/leveldb/db/log_test.cc                        |   40 +-
 src/leveldb/db/repair.cc                          |    1 -
 src/leveldb/db/version_set.cc                     |   14 -
 src/leveldb/include/leveldb/c.h                   |    1 -
 src/leveldb/include/leveldb/db.h                  |    2 +-
 src/leveldb/include/leveldb/slice.h               |    2 +-
 src/m4/ax_boost_base.m4                           |    5 +-
 src/main.cpp                                      |  453 +++++----
 src/main.h                                        |   51 +-
 src/miner.cpp                                     |   15 +-
 src/net.cpp                                       |   67 +-
 src/net.h                                         |    8 +
 src/netbase.cpp                                   |  198 +++-
 src/netbase.h                                     |   36 +-
 src/protocol.h                                    |    1 +
 src/qt/Makefile.am                                |   11 +-
 src/qt/bitcoin.cpp                                |   24 +-
 src/qt/bitcoin.qrc                                |    1 +
 src/qt/bitcoingui.cpp                             |   17 +-
 src/qt/bitcoingui.h                               |    2 +-
 src/qt/bitcoinstrings.cpp                         |    1 +
 src/qt/clientmodel.cpp                            |   14 +-
 src/qt/clientmodel.h                              |    5 +-
 src/qt/forms/optionsdialog.ui                     |   24 +
 src/qt/forms/rpcconsole.ui                        |   33 +-
 src/qt/locale/bitcoin_ach.ts                      | 1053 ++++----------------
 src/qt/locale/bitcoin_af_ZA.ts                    | 1055 ++++-----------------
 src/qt/locale/bitcoin_ar.ts                       | 1492 ++++++++---------------------
 src/qt/locale/bitcoin_be_BY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_bg.ts                       | 1271 ++++++-------------------
 src/qt/locale/bitcoin_bs.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_ca.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_ca@valencia.ts              | 1096 +++++----------------
 src/qt/locale/bitcoin_ca_ES.ts                    | 1059 ++++-----------------
 src/qt/locale/bitcoin_cmn.ts                      | 1096 +++++----------------
 src/qt/locale/bitcoin_cs.ts                       | 1509 ++++++++---------------------
 src/qt/locale/bitcoin_cy.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_da.ts                       | 1175 +++++------------------
 src/qt/locale/bitcoin_de.ts                       | 1200 +++++------------------
 src/qt/locale/bitcoin_el_GR.ts                    | 1101 ++++-----------------
 src/qt/locale/bitcoin_en.ts                       |  123 ++-
 src/qt/locale/bitcoin_eo.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_es.ts                       | 1082 ++++-----------------
 src/qt/locale/bitcoin_es_CL.ts                    | 1108 +++++-----------------
 src/qt/locale/bitcoin_es_DO.ts                    | 1030 +++-----------------
 src/qt/locale/bitcoin_es_MX.ts                    | 1055 ++++-----------------
 src/qt/locale/bitcoin_es_UY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_et.ts                       | 1057 ++++-----------------
 src/qt/locale/bitcoin_eu_ES.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_fa.ts                       | 1065 ++++-----------------
 src/qt/locale/bitcoin_fa_IR.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_fi.ts                       | 1713 ++++++++++-----------------------
 src/qt/locale/bitcoin_fr.ts                       | 1069 ++++-----------------
 src/qt/locale/bitcoin_fr_CA.ts                    | 1099 ++++-----------------
 src/qt/locale/bitcoin_gl.ts                       | 1120 +++++-----------------
 src/qt/locale/bitcoin_gu_IN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_he.ts                       | 1096 ++++-----------------
 src/qt/locale/bitcoin_hi_IN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_hr.ts                       | 1063 ++++-----------------
 src/qt/locale/bitcoin_hu.ts                       | 1067 ++++-----------------
 src/qt/locale/bitcoin_id_ID.ts                    | 1795 +++++++++++------------------------
 src/qt/locale/bitcoin_it.ts                       | 1468 ++++++++--------------------
 src/qt/locale/bitcoin_ja.ts                       | 1263 ++++++------------------
 src/qt/locale/bitcoin_ka.ts                       | 1122 +++++-----------------
 src/qt/locale/bitcoin_kk_KZ.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_ko_KR.ts                    | 1145 +++++-----------------
 src/qt/locale/bitcoin_ky.ts                       | 1100 +++++----------------
 src/qt/locale/bitcoin_la.ts                       | 1059 ++++-----------------
 src/qt/locale/bitcoin_lt.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_lv_LV.ts                    | 1718 ++++++++++-----------------------
 src/qt/locale/bitcoin_mn.ts                       | 3375 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/qt/locale/bitcoin_ms_MY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_nb.ts                       | 1034 +++-----------------
 src/qt/locale/bitcoin_nl.ts                       | 1216 ++++++------------------
 src/qt/locale/bitcoin_pam.ts                      | 1053 ++++----------------
 src/qt/locale/bitcoin_pl.ts                       | 1042 +++-----------------
 src/qt/locale/bitcoin_pt_BR.ts                    | 1143 +++++-----------------
 src/qt/locale/bitcoin_pt_PT.ts                    | 1564 ++++++++----------------------
 src/qt/locale/bitcoin_ro_RO.ts                    | 1032 +++-----------------
 src/qt/locale/bitcoin_ru.ts                       | 1077 ++++-----------------
 src/qt/locale/bitcoin_sah.ts                      | 1096 +++++----------------
 src/qt/locale/bitcoin_sk.ts                       | 1545 +++++++++---------------------
 src/qt/locale/bitcoin_sl_SI.ts                    | 1073 ++++-----------------
 src/qt/locale/bitcoin_sq.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_sr.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_sv.ts                       | 1489 ++++++++---------------------
 src/qt/locale/bitcoin_th_TH.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_tr.ts                       | 1073 ++++-----------------
 src/qt/locale/bitcoin_uk.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_ur_PK.ts                    | 1096 +++++----------------
 src/qt/locale/bitcoin_uz@Cyrl.ts                  | 1096 +++++----------------
 src/qt/locale/bitcoin_vi.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_vi_VN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_zh_CN.ts                    | 1073 ++++-----------------
 src/qt/locale/bitcoin_zh_HK.ts                    | 1096 +++++----------------
 src/qt/locale/bitcoin_zh_TW.ts                    | 1180 +++++------------------
 src/qt/optionsdialog.cpp                          |    5 +
 src/qt/optionsmodel.cpp                           |   15 +-
 src/qt/optionsmodel.h                             |    3 +
 src/qt/receivecoinsdialog.cpp                     |   19 +-
 src/qt/receivecoinsdialog.h                       |    8 +-
 src/qt/receiverequestdialog.cpp                   |   25 +-
 src/qt/receiverequestdialog.h                     |    7 +
 src/qt/rpcconsole.cpp                             |    8 +-
 src/qt/rpcconsole.h                               |    2 +-
 src/qt/test/test_main.cpp                         |    1 -
 src/qt/transactiontablemodel.cpp                  |    2 +
 src/qt/transactiontablemodel.h                    |    2 +
 src/qt/transactionview.cpp                        |   35 +
 src/qt/transactionview.h                          |    3 +
 src/qt/winshutdownmonitor.cpp                     |   57 ++
 src/qt/winshutdownmonitor.h                       |   29 +
 src/rpcblockchain.cpp                             |   50 +-
 src/rpcclient.cpp                                 |   52 +-
 src/rpcmining.cpp                                 |   10 +-
 src/rpcmisc.cpp                                   |   17 +-
 src/rpcnet.cpp                                    |   69 +-
 src/rpcprotocol.cpp                               |   12 +-
 src/rpcprotocol.h                                 |   24 +-
 src/rpcrawtransaction.cpp                         |   23 +-
 src/rpcserver.cpp                                 |  192 ++--
 src/rpcserver.h                                   |    6 +
 src/rpcwallet.cpp                                 |   18 +-
 src/script.cpp                                    |   72 +-
 src/script.h                                      |  220 ++++-
 src/test/DoS_tests.cpp                            |    5 +-
 src/test/Makefile.am                              |    3 +-
 src/test/{README => README.md}                    |    4 +-
 src/test/base58_tests.cpp                         |    4 +-
 src/test/bignum.h                                 |  180 ++++
 src/test/bignum_tests.cpp                         |  224 -----
 src/test/canonical_tests.cpp                      |   17 +
 src/test/data/script_invalid.json                 |   29 +
 src/test/data/script_valid.json                   |   89 ++
 src/test/data/tx_invalid.json                     |   63 +-
 src/test/data/tx_valid.json                       |   68 +-
 src/test/netbase_tests.cpp                        |   37 +
 src/test/rpc_tests.cpp                            |   16 +
 src/test/script_tests.cpp                         |    6 +-
 src/test/scriptnum_tests.cpp                      |  196 ++++
 src/test/transaction_tests.cpp                    |   50 +-
 src/test/uint256_tests.cpp                        |  210 +++-
 src/test/util_tests.cpp                           |   49 +-
 src/txdb.cpp                                      |   10 +-
 src/txdb.h                                        |    2 -
 src/uint256.h                                     |  528 +++++------
 src/util.cpp                                      |   99 +-
 src/util.h                                        |   39 +-
 src/wallet.cpp                                    |    6 +-
 src/wallet.h                                      |    2 +
 src/walletdb.cpp                                  |    2 +-
 202 files changed, 23277 insertions(+), 66633 deletions(-)
 create mode 100644 .tx/config
 create mode 100755 contrib/devtools/symbol-check.py
 create mode 100755 contrib/devtools/update-translations.py
 create mode 100644 contrib/gitian-descriptors/gitian-osx-bitcoin.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-depends.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-native.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-qt.yml
 create mode 100644 contrib/gitian-descriptors/qt-linux.yml
 create mode 100644 doc/README_osx.txt
 create mode 100644 qa/rpc-tests/netutil.py
 create mode 100755 qa/rpc-tests/rpcbind_test.py
 delete mode 100644 src/bignum.h
 create mode 100644 src/qt/locale/bitcoin_mn.ts
 create mode 100644 src/qt/winshutdownmonitor.cpp
 create mode 100644 src/qt/winshutdownmonitor.h
 rename src/test/{README => README.md} (87%)
 create mode 100644 src/test/bignum.h
 delete mode 100644 src/test/bignum_tests.cpp
 create mode 100644 src/test/scriptnum_tests.cpp

# push my local bitcoin branch to my branch repository at GitHub
$ git push origin master
Counting objects: 1460, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (361/361), done.
Writing objects: 100% (1065/1065), 2.03 MiB | 112.00 KiB/s, done.
Total 1065 (delta 880), reused 887 (delta 702)
To git@github.com:StephenLReed/bitcoin.git
   4765b8c..97b53b5  master -> master

To make a change to the bitcoin repository . . .
How to create a PULL request (https://bitcointalk.org/index.php?topic=4571.msg66945#msg66945)

Code:
$ git checkout -b niftynewfeature # Create a feature branch
 ... edit, test, re-edit, re-test...
$ git commit -a
$ git push git@github.com:StephenLReed/bitcoin.git niftynewfeature:niftynewfeature

Gavin: Submit a PULL request by going to your fork's GitHub page, selecting the branch containing the changes you want pulled ("niftynewfeature" in the above example), and then poking the "Pull Request" button.  Enter a good description of what your changes do and why they're a good idea and how everybody and their brother is already using them to make the world a better place .
















Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bybitcoin on May 23, 2014, 07:50:10 PM
Your idea-work becomes more and more interesting everyday... watching this thread closely!


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 25, 2014, 04:45:21 AM
I presented my whitepaper today and engaged contributors to the Bitshares project on the Beyond Bitcoin podcast . . .

https://bitsharestalk.org/index.php?topic=4713.0 (https://bitsharestalk.org/index.php?topic=4713.0)

I was invited back for a more technical discussion after I have a chance to re-study Dan Larimer's Delegated Proof-of-Stake (DPOS) (http://107.170.30.182/security/delegated-proof-of-stake.php)

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: rpietila on May 25, 2014, 07:58:41 AM
I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 25, 2014, 08:51:46 AM
I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: delulo on May 25, 2014, 10:48:18 AM
I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.
This is an interesting discussion.
The first thing to realize is that money and company shares are not contradictory. Everything can be money. What you maybe meant was currency vs. company shares, that can not be the same thing.

So, are bitcoins currency units or shares in a company? Whether we decide for one or the other here doesn't make it any different from what is and what is possible to do with it. Currency and company shares are just metaphors/analogies and those words have no truth in itself. But it is more or less appropriate to describe bitcoins in one of those ways. I describe Bitcoin as a "payment network" and bitcoins as the tokens necessary to use it. That is the most neutral description I can make. If I had to decide between currency and company shares I would go with company shares because analogous to a company there can be competition (Bitcoin and altcoins) whereas there by definition can not be competition between currencies within the area that the state that issues the currency controls.

Apart from that I am certain that Stephen's interests lie in the success of Bitcoin not matter how it is categorized. It is a great proposal!


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bitbadgerPoS on May 26, 2014, 05:12:48 AM
Hi,

I have come up with what I believe to be at least a partial solution to the PoS problem:

https://bitcointalk.org/index.php?topic=553414.msg6025343#msg6025343

The gist of it is that everybody's Stake is reduced to 0 on a frequent and random basis.  If the node is provably connected to the network at the time that it is randomly called up, it will receive its proportional distribution for its Stake.  If it does not prove itself to be connected to the network at such time, its Stake is still reset to 0, but it does not receive any payment.  For this reason, I call it Proof-of-Connection.

This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate.  Presumably, this would prevent against the "if you have enough Stake, you can cheaply re-write history" attack.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 26, 2014, 08:00:33 AM
Hi,

I have come up with what I believe to be at least a partial solution to the PoS problem:

https://bitcointalk.org/index.php?topic=553414.msg6025343#msg6025343

The gist of it is that everybody's Stake is reduced to 0 on a frequent and random basis.  If the node is provably connected to the network at the time that it is randomly called up, it will receive its proportional distribution for its Stake.  If it does not prove itself to be connected to the network at such time, its Stake is still reset to 0, but it does not receive any payment.  For this reason, I call it Proof-of-Connection.

This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate.  Presumably, this would prevent against the "if you have enough Stake, you can cheaply re-write history" attack.

Interesting,

In CPoS, I would pay full nodes to upgrade to 24/7 dedicated symmetric business class Internet connections. The full nodes would be expected to be permanently connected and executing the current version of the reference Bitcoin Core software. Their share of the block creation reward, paid daily, would be decreased if not always connected.

The daily bitcoin creation reward is now $2,124,360. I would allocate $30 daily to each full-time full node.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: rpietila on May 26, 2014, 12:18:44 PM
I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.

I think "full node owners" is a very flexible entity. Anyone can set up unlimited number of full nodes for voting purposes in the convention, and then scale down after he has voted. This way the outcome of the vote does not necessarily represent the interests of the economic majority of:
a) "actual" full nodes
b) miners
c) bitcoin holders
d) bitcoin users.

I see that the current decision making needs improving, but on the other hand I am very satisfied with the results how we have progressed in this system also (mainly in the relentless rise of BTC price, I mean). This has been possible because the contract is unchangeable, and making it changeable might cause more damage due to the loss in trust, than the changes can make it better.

If things are to be decided by any majority, I believe the only majority that is legitimate is the majority of coin holders, one vote per coin. Everything else represents a power void.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Brangdon on May 26, 2014, 01:23:12 PM
This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate.
So, you're encouraging people to split their stakes between many addresses? Does that help?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: jaekwon on May 27, 2014, 09:04:12 AM
Hi SlipperySlope,

You have two links of mine on the original post, but the first (Venetian Bankers Problem) is deprecated in favor of TenderMint.
Also, the TenderMint link is broken due to a trailing slash.  The link should be: http://tendermint.com/docs/tendermint_v04.pdf



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 27, 2014, 12:38:47 PM
Hi SlipperySlope,

You have two links of mine on the original post, but the first (Venetian Bankers Problem) is deprecated in favor of TenderMint.
Also, the TenderMint link is broken due to a trailing slash.  The link should be: http://tendermint.com/docs/tendermint_v04.pdf


I removed the Venetian Bankers Problem link and fixed the TenderMint link. Thanks for pointing out my errors.

Its interesting that defenders of Bitcoin proof-of-work believe Satoshi's Bitcoin to be the solution to the Byzantine General's Problem, or more generally the only working solution to achieving concensus in a distributed system.

But the academic field of Byzantine Fault Tolerance does not mention bitcoin with the notable exception of Andrew Miller's paper whose only citation is from me. Even when granted that the bulk of such papers were issued before 2009, Satoshi did not reference any in his defining Bitcoin paper nor stimulate much discussion of BFT algorithms when posting to this forum.

Google Scholar search for Byzantine Fault Tolerance (http://scholar.google.com/scholar?q=Byzantine+fault+tolerance+&btnG=&hl=en&as_sdt=5%2C44&sciodt=0%2C44&cites=14268118902810651133&scipsc=)

-Stephen Reed


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 27, 2014, 04:52:17 PM
CPoS Network Proxy

I have been thinking about a way to deploy CPoS in a way that minimally impacts Bitcoin Core, and their pull request regime.

The idea is to have CPoS code execute as a network proxy for bitcoind - the Bitcoin Core program. A paid CPoS full node operator would launch the CPoS program - preferably automatically upon start of the server, The CPoS proxy would configure its bitcoind to have a single peer, namely the collocated proxy. That bitcoind, by default, would have generation turned off. The CPoS proxy would connect to other such proxies forming the super peer network described in my whitepaper. All the agent related code would be implemented in the proxy. The proxy-to-bitcoind communication protocol code would be adapted from bitcoind source code for complete compatibility. The proxy-to-proxy communication protocol would be inspired by FIPA (http://www.fipa.org/specs/fipa00061/SC00061G.html) agent-to-agent protocol.

The single nomadic mint would launch bitcoind every 10 minutes, and configure it to generate the new block. After creating the new block, the mint would shut down its bitcoind. Alternatively if the bitcoind RPC (remote procedure call) interface permits sufficiently robust dynamic control of block generation, then that would be preferable.

Bitcoind would verify transactions received from the proxy and build the blockchain replica with new blocks provided by the single nomadic mint agent via the proxy. The full-node's tamper-evident log would be maintained by the proxy. The bitcoind instance would listen on its standard Internet port for SPV nodes, e.g. mobile wallets, and process their requests. For full nodes desiring local Bitcoin-QT wallets, the proxy would launch the wallet after launching bitcoind. The wallet would communicate with bitcoind directly, and not the proxy.

If and when the blockchain hard fork planned for early 2016 succeeds, the proxy code I write can be merged into the bitcoind code for a single program by willing core developers. This possibility constrains me to write the proxy in the language of bitcoind, which is C++ and the Boost library.

-Stephen Reed


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 29, 2014, 10:43:55 PM
Bitcoin Cooperating Agent

Nothing that the core developers maintain will be touched. The agent code, in this case a Relay Agent, will run the non-generating bitcoind instance. Bitcoind communicates with the reference wallet, bitcoin-qt, and also with the optional command line interface. Simplified Payment Verification wallets communicate with the listening bitcoind.

The notable change is that the bitcoind instance is configured to communicate with other full nodes only via the Relay agent.

https://i.imgur.com/0Q5GuGb.png

-Stephen Reed


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on May 30, 2014, 11:24:09 PM
Bitcoin Cooperating Agent Design

Here is the first portion of the project specifications . . .

Bitcoin Cooperating Agent Design (https://docs.google.com/document/d/1Y-fZSZ7fL7LCKOvAW2niLtuFe7U5QrQ9XUVp3blOlu0)


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 02, 2014, 05:02:32 PM
Communication with the BlackCoin Foundation

BlackCoin is the number 8 cryptocurrency (http://cryptmarketcap.com/) when ranked by market capitalization. Today I corresponded with Adam Krykow, from the BlackCoin Foundation.

Quote
Hi Stephen,
 
I am a member of the BlackCoin Foundation and I had called a week or so ago looking to talk about the article you posted about CPoS. Basically, I am looking to open up some dialogue with you to see if you have any interest in bringing some of your technical expertise to the altcoin realm.
 
Here at BlackCoin we have been attempting to tackle the mining problem of bitcoin with a fast, decentralized, PoS system but it is quite a difficult process. We are still in the early stages of our development, relying on centralized checkpoints currently, but we have been discussing plans for a multinode network within our system. When we stumbled across your whitepaper, it was like reading a fully developed version of our internal discussions.
 
I don’t know how far along you are with your current BitCoin startup, but at BlackCoin we can offer you a community of adopters and a real desire to perfect a system very similar (but not identical there are some differences of opinions to be hashed out) to your CPoS.
 
Thanks for your time and your whitepaper. At the very least I believe we will be citing it frequently as we move forward!
 
Adam Kryskow
Public Relations Director for the Americas
BlackCoin Foundation
a.kryskow@blkfoundation.org
www.blkfoundation.org (http://www.blkfoundation.org)
www.blackcoin.co (http://www.blackcoin.co)

I responded . . .

Quote
Hi Adam,

I am excited about the opportunity to collaborate with your team. Indeed my focus is on Bitcoin, but my plan for 2015 involves demonstrating cooperating proof-of-stake agents with one or more Altcoins, before hard-forking Bitcoin in early 2016. Previously I was informally contacted by a Bytecoin developer who offered to run my code when ready. I have participated in a podcast with Dan Larimer's Delegated Proof-Of-Stake project, and will continue a periodic sharing of ideas.

My design is evolving towards an agent based framework that can support multiple cryptocurrencies. Supposing that altcoins follow the Bitcoin coding convention of deploying an executable similar to bitcoind, then a full node in the CPoS system could operate multiple bitcoind instances, each belonging to a different cryptocurrency. The full node operator would be compensated by each such currency via their respective block creation reward policies. This leads to economies of scale, and significant benefits to lower capitalization altcoins. Message traffic on the CPoS network, e.g. transactions and blocks, would be tagged as to which cryptocurrency they belonged.

See: Bitcoin Cooperating Agent illustration (https://bitcointalk.org/index.php?topic=584719.msg7024155#msg7024155)


I completed the CPoS whitepaper in May. I plan to complete the public high level design in June, and enough of the public message workflow specifications to begin open-source coding in July. I have bitcoind compiling in my C++ NetBeans IDE now. The agent message passing architecture will be adapted from a very similar one that I wrote in Java for my now-postponed AI project. My plan is to have significant elements of the CPoS architecture running in the late fall, with public system testing and altcoin deployment scheduled throughout 2015.

My GitHub repository is currently a Bitcoin clone. I periodically synchronize it with the core developer's repository. For CPoS, I will establish a new public repository. The code that talks to the local bitcoind instances, I will adapt from existing core code. The networking code, the tamper-evident logs, and agent framework will be new code. As I mentioned, the agent framework will be a simplified version of Java code that I wrote some years ago. The agents will each extend a C++ class and provide specialized behavior. Each agent will be simply enough for its peers to easily verify. There may therefore be many agents in total to provide all the required behavior.  A testing framework will be specified and completed that enables robust regression testing of the agent network.

I look forward to continuing discussion with your group, especially regarding our respective development schedules and what components are needed first.

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 04, 2014, 04:45:49 PM
Advice on securing a re-engineered Bitcoin network

This is the email message that I sent to Defense.net, Staminus Communications, Cloudflare, Black Lotus, and Incapsula.

Quote
Hi,

I founded a project to re-engineer the Bitcoin network. This project, if it achieves wide acceptance during a year of system testing in 2015, will launch in early 2016. The whitepaper describing this project is Bitcoin Cooperative Proof-of-Stake (https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE).

The current Bitcoin network contains approximately 8,000 volunteer nodes. My plan would be to use a portion of the daily bitcoin block creation reward to fund an upgrade to robust Virtual Private Server instances, which would be dispersed and hosted at datacenters around the world. Currently the daily block creation rewards amount to $2.4 million.  

I seek your advice about protecting 10,000 or more such dispersed servers against large DDoS attacks. Each server will have at least one public IP address that could be attacked, and each shall use the public Internet for connectivity with other servers and with client software.

Currently the Bitcoin network has no Network Operations Center. My plan provides for nomadic one, but it needs to be highly automated.

How much would it cost to use your services to protect the Bitcoin network that I propose? I desire a scalable solution, and perhaps tiered pricing as the available funding depends upon the volatile price of bitcoin.

As this is an open source and public project, I am posting this query and your response in the project's discussion thread. Because I need to keep a transcript of our conversation, I desire to converse by email if that is OK with your sales staff. I would be delighted to answer your questions, and will thoughtfully consider what you say.

Note that I am sending a similar query to a few other vendors offering DDoS protection.

Thanks!

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860

Quote
Black Lotus

Hello Stephen,

Thank you for reaching out to Black Lotus. I understand you are interested in our Protection for Networks service.

In order to qualify for this service, you must have an ASN, a network capable of BGP sessions, and at least a /24 to allocate for protection. Will you meet these requirements when you launch your project? If not, we have other solutions that will work for your needs as well.

I have attached a PDF with some valuable information about Black Lotus and the protection we provide as well as a PDF with more specific information about Protection for Networks. I am also including a PDF about our Protection for Services that will specifically protect your site.

Please feel free to let me know if you have any questions or would like a custom quote.

Christine Gaylor
Inside Sales Representative, Black Lotus Communications
direct: (678) 608-2575 | mobile: (757) 536-0509 | gtalk: christigaylor@blacklotus.net | skype: christi.gaylor

Quote
Hi Christine,

I believe that the Bitcoin network is not ready for an Autonomous System Network with our own routers. That should come in the years beyond the launch in 2016. In the meantime, I am interested in your Protection for Services product. Am I correct that the customer decides whether a server is under DDoS attack and if so, redirects its IP address to Black Lotus for traffic scrubbing? What are ways to automate this?

Note that I am talking about 10,000 dispersed VPS instances. Can you provide a quote?

Thanks!

-Steve

Quote
Hi Stephen,

Thank you for this information. I am thinking a more custom solution is going to be a better option to meet your specific needs. Would you be open to a call to to discuss this in detail with my lead sales engineer?

I have Friday at 3pm CDT / 1pm PDT available. Let me know, I will be happy to arrange it.

Best Regards,

Christine Gaylor
Inside Sales Representative, Black Lotus Communications
direct: (678) 608-2575 | mobile: (757) 536-0509 | gtalk: christine.gaylor@blacklotus.net | skype: christi.gaylor

Quote
Christine,

I regret that I am travelling that day to open my mountain home in Colorado. It will be great to escape the summer heat of Austin for a week. I can make the call anytime at your convenience from Colorado, Monday June 12 through Friday June 16. I will need to make a transcript of the conversation so that I can publish it on my open source project's discussion site. [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake (https://bitcointalk.org/index.php?topic=584719.0)
 
I look forward to speaking with a sales engineer who can give this project the technical guidance it needs.

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 04, 2014, 08:02:01 PM
Prolexic advice on securing a re-engineered Bitcoin network.

Quote
Prolexic

Dear Stephen,
Thank you for your interest in Prolexic, the global leader in Distributed Denial of Service (DDoS) protection services.  We are processing your request and will contact you within 24 hours.
Prolexic represents the gold standard in DDoS monitoring and mitigation.  We mitigate all attack types no matter how large or complex and we do it fast for one flat monthly fee -regardless of how many times you are attacked or how much bandwidth is consumed.  Even better, this is supported by the industry’s first ever time-to-mitigate Service Level Agreement (SLA).
 If you are currently, or will be, evaluating DDoS protection providers, here are four facts about Prolexic to keep in mind:
More than 10 of the world’s largest banks rely on Prolexic for DDoS protection every day
Prolexic operates the world’s largest and most sophisticated cloud-based mitigation platform with over 1.8 Tbps of bandwidth (3x larger than our biggest competitor)
In 2014, Prolexic mitigated the world’s largest attack (190 Gbps).
Prolexic uses 20 distinct mitigation and analysis technologies where others use 3 or 4
 You may also find the following documents useful:
White Paper: 12 Questions to Ask a DDoS Mitigation Provider (http://ww.prolexic.com/e/9892/rovider-White-Paper-031412-pdf/56v8q/279975440)
Evaluation Worksheet:  DDoS Mitigation Providers (http://ww.prolexic.com/e/9892/itigation-Providers-031412-pdf/56v9d/279975440)
Brochure: Prolexic Overview (http://ww.prolexic.com/e/9892/lexic-corp-brochure-031912-pdf/56vb2/279975440)
If this an emergency call us at + 1 (888) 368 2923 (Toll Free in the U.S.)  or + 1 (207) 608 6213 (Local/International) to be connected with a DDoS mitigation expert.
Best Regards,
Prolexic Sales Operations
http://www.prolexic.com (http://www.prolexic.com)

David from Akami, who acquired Prolexic phoned me to set up an appointment with a sales engineer. Their preferred solution involves an interface with routed network having BGP. This means that each Bitcoin full node would have its own router that guides message traffic to other full nodes. DDoS protection for the entire Bitcoin network would be $20-30K per month.

Akami's other solution, the Proxy Solution, is designed for HTTP traffic, and thus works on ports 80 and 443. Not Bitcoin.

The Bitcoin network would need to acquire a /24 autonomous system (AS) number.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: jubalix on June 07, 2014, 03:12:56 AM
wont NXT do most of this when it implements transparent forgeing?????









Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 07, 2014, 11:56:34 PM
wont NXT do most of this when it implements transparent forgeing?????

Good question. I am quite open to borrowing and sharing ideas with altcoin projects. I of course examined next last month when writing my whitepaper, but I felt at the time that PeerCoin alone was a sufficient example of existing proof-of-stake implementations.

I will revisit transparent forging.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 08, 2014, 12:03:52 AM
Bitcoin Centralization Problem Evolving Into Trusting a Third Party - GHash.io

See: Who cares about the 45% Ghash.io have - will you care when they are at 51%? (https://bitcointalk.org/index.php?topic=643329.0)

I responded . . .

The truth is that proof of work leads inevitably to a single hasher-pleasing dominant mining pool. The hashers have sufficient trust in that pool to permit a 51% attack, that hashers think is not a threat. Hashers have observed that the pools are well behaved, and those pools are efficient due to competition. The dominant pools knows that if there is misbehavior they will be possibly ruined by deserting hashers.

Thus proof-of-work as a means to secure the Bitcoin blockchain now fails Satoshi's design of a system in which there is no trusted third party. .


I claim CPoS will have no trusted third parties. Humans who act as paid agents for the system will themselves create tamper-evident logs justifying their observable actions, which can be checked by a certain number of human agent-peers.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: RSchexnayder on June 08, 2014, 02:36:37 AM

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.
I did this shortly after I became interested in BlackCoin. I came up with the idea of how to implement it after I read the Follow the Coin article at the link below were rat4 and Soepkip are interviewed, and the 10 second transaction time of BlackCoin is prominently mentioned in that article dated April 4th 2014.
http://www.followthecoin.com/interview-creator-blackcoin-bc/
Since BlackCoin has a 1 minute block time, the minimum average transaction time should be 30 seconds.
The methodology that I foresaw is made possible by the fact that all of the nodes are cooperating, which is not possible with a PoW coin like Bitcoin. Therefore, whenever nodes with 51% of the stake at the start of a block have eventually confirmed that a transaction can be in the current block, it can be confirmed to the entire network that it will eventually be in the block. If an attempt at a double spend is occurring in the block, then the first node that subsequently becomes aware of the attempt should immediately ensure that second spend will not be added to the current block by sending an immediate alert that a double spend has been attempted. Each node receiving this alarm should verify that it is accurate. If it is a false claim, the offending node should be blackballed.
I assumed that this method was being programmed by rat4 when it was announced on r/BlackCoin that he was working on PoS 2.0 based on the Peercoin protocol.
It had never been adequately explained to me why Soepkip and others who should have known better had allowed the 10 second fiction to continue after the big pump and dump occurred shortly after the article came out. The 10 second claim was certainly used during that pump. I have tried on several occasions to get an explanation, but I have not tried recently to get one directly from Soepkip because all of my earlier attempts had been brushed aside by him. 
I subsequently found out that that is not what rat4 is working on. That is when Alan told me that your scheme is a more sophisticated version of mine that assumes that the master nodes are sitting astride the backbones of the internet.
With regard to jubalix’s question, it is my understanding that NXT, as it is written now does not incorporate this methodology. However, I could be wrong. Nevertheless, the cat is now out of the bag. IMO it will not be long before the NXT community understands how to modify their protocol and set out to do it. I would think that their first step would be to implement a simplified, bare bones version like my proposed version to determine in practice what kind of actual average transaction times can be achieved. The next step would be your Internet backbone version. 
What Alan refers to as our internal discussions at the Blackcoin Foundation has just been within one relatively small committee where there is much resistance to rocking the Bitcoin boat and a realization that we do not have the ability to properly fund such a project at this time. However, I am sure that NXT does, if the initial investors  think it is worthwhile, which I do not see why they would not.
RSchexnayder   


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 08, 2014, 04:56:34 AM

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.

Right. My main theme is to implement Nick Szabo's idea about agents with non-forgable logs, what an academic paper I cite calls tamper-evident logs. The proof-of-stake is used mainly to deter Sybil attacks, as there is only a certain amount of stake in the post-fork bitcoins that will be thus qualified for dividends.

The single nomadic mint is permitted by the notion of cooperating agents that do not trust the mint, but rather allow it to timestamp the incoming new transactions from clients. The peers verify the mint operations by replaying the operations themselves as they each assemble the blockchain replicant locally in canonical timestamp order. The single mint in turn permits a non-forking blockchain and definite transaction acknowledgment back to the client with sub second response time.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 08, 2014, 05:19:05 AM
CPoS To Be Written in the Java programming Language

I made the big decision a few days ago to write my new Bitcoin system in the Java programming language rather than C++ and the Boost library used by the Bitcoin code contributor team. The Java alternative became possible given the evolution of the design into incorporating bitcoind unchanged but slaved to a new component that contains the agent behavior, but has minimal dependence upon the objects and functions defined in bitcoind.

I will use the bitcoinj client implementation classes as the network adapter to the local bitcoind instance, as well as the adapter for bitcoin data structures.

I have been working with Java for as long as it existed, and I have written over a hundred thousand lines of Java code for my previous artificial intelligence project. There is a thorough suite of unit tests and a continuous integration development environment already in place. My previous project was named Texai. I shall continue using the Java package naming convention "org.texai.bitcoin.*" for the Java source code ported from from the old project.

I concede that Java is slower by 30% or more than the equivalent C++ algorithm. But I do not believe that performance is an issue until very high transaction rates are tested. Aside from a comfort with Java, I believe that its runtime checks reduce the bugginess of production code, Personally I can write code much faster in Java than in C++.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: RSchexnayder on June 08, 2014, 01:20:45 PM

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.

Right. My main theme is to implement Nick Szabo's idea about agents with non-forgable logs, what an academic paper I cite calls tamper-evident logs. The proof-of-stake is used mainly to deter Sybil attacks, as there is only a certain amount of stake in the post-fork bitcoins that will be thus qualified for dividends.

The single nomadic mint is permitted by the notion of cooperating agents that do not trust the mint, but rather allow it to timestamp the incoming new transactions from clients. The peers verify the mint operations by replaying the operations themselves as they each assemble the blockchain replicant locally in canonical timestamp order. The single mint in turn permits a non-forking blockchain and definite transaction acknowledgment back to the client with sub second response time.

I think I can follow what you are saying there, but I am not sure of what exactly you are calling the nomadic mint, the cooperating agent, the client, and peers.

I have enough programming experience and knowledge of data structures that I know that the system that I came up with can work. Furthermore, no one else in the BlackCoin Foundation that I discussed the method with found a problem with it.

My only question at this time concerns the point at which a transaction is initially confirmed in your system. You do no mention waiting until 51% of the nodes with stake at the start of the block have determined that it can be in the block being assembled.

Are you saying that the simple nomadic mint is a part of your program that assembles the master ledger in timestamp order? For it to work this way, it would have to have the sole responsibility to verify that the transaction is legitimate and thus verify it to the network. Thus, it has the responsibility to stop any attempted double spends when presented with the second or subsequent ones.

IMO the two methods accomplish the same thing, but are slightly different in execution

The method that I came up with does not require a centralized mint. I am not trying to argue that one is better than the other, because I have not thought about it. I have no desire to try to start programing either one.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 08, 2014, 07:41:03 PM
Are you saying that the simple nomadic mint is a part of your program that assembles the master ledger in timestamp order? For it to work this way, it would have to have the sole responsibility to verify that the transaction is legitimate and thus verify it to the network. Thus, it has the responsibility to stop any attempted double spends when presented with the second or subsequent ones.

IMO the two methods accomplish the same thing, but are slightly different in execution

The method that I came up with does not require a centralized mint. I am not trying to argue that one is better than the other, because I have not thought about it. I have no desire to try to start programing either one.


Yes I have a single mint which solves many problems that annoy bitcoin users. That mint is nomadic because it's verified object state periodically moves from full node to full node. What i call a nomadic mint agent is isomorphic to the notion that full nodes take turns being the mint. Each other full node, having the role of relay agent, closely verifies the log output of the mint agent.

Because CPoS has a single mint there is immediate acknowlegement by the mint when it queues up a received transaction. There is no chance of a double spend or that an orphan block can be created. CPoS has a single, non-forking blockchain which is simply appended to by the mint's local slave bitcoind instance with trivial Satoshi difficulty effort

My first system test will be two full nodes in a box, cooperating to create new blocks, and quickly exchanging relay and mint roles. Another system test will be three full nodes in a box, performing an exhaustive regression test of  failure modes of one of the three nodes.


Since BlackCoin has a 1 minute block time, the minimum average transaction time should be 30 seconds.

The methodology that I foresaw is made possible by the fact that all of the nodes are cooperating, which is not possible with a PoW coin like Bitcoin.

Therefore, whenever nodes with 51% of the stake at the start of a block have eventually confirmed that a transaction can be in the current block, it can be confirmed to the entire network that it will eventually be in the block.

If an attempt at a double spend is occurring in the block, then the first node that subsequently becomes aware of the attempt should immediately ensure that second spend will not be added to the current block by sending an immediate alert that a double spend has been attempted. Each node receiving this alarm should verify that it is accurate. If it is a false claim, the offending node should be blackballed.

I assumed that this method was being programmed by rat4 when it was announced on r/BlackCoin that he was working on PoS 2.0 based on the Peercoin protocol.

It had never been adequately explained to me why Soepkip and others who should have known better had allowed the 10 second fiction to continue after the big pump and dump occurred shortly after the article came out. The 10 second claim was certainly used during that pump. I have tried on several occasions to get an explanation, but I have not tried recently to get one directly from Soepkip because all of my earlier attempts had been brushed aside by him.  
.

Could you point me to a writeup of your algorithm? Or if this is still exploratory, then could you explain more about how proof-of-stake works in your system to create new blocks? Does your system, like Satoshi's, permit a forking blockchain? Note that any such blockchain forks could confuse the user accessing the minority branch.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: RSchexnayder on June 08, 2014, 08:38:54 PM
.
Could you point me to a writeup of your algorithm? Or if this is still exploratory, then could you explain more about how proof-of-stake works in your system to create new blocks? Does your system, like Satoshi's, permit a forking blockchain? Note that any such blockchain forks could confuse the user accessing the minority branch.
Steve

I have not tried to further define the algorithm, and I do not intend to. I certainly do not want to try to compete with you.

However, I do intend to try to spread the word on the concept. What I have tried to do, and what I think I have accomplished, is to describe an algorithm in such a way that a person familiar with programming techniques can understand how one can get average transaction times much smaller than half of the block time.   


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 08, 2014, 09:54:25 PM

However, I do intend to try to spread the word on the concept. What I have tried to do, and what I think I have accomplished, is to describe an algorithm in such a way that a person familiar with programming techniques can understand how one can get average transaction times much smaller than half of the block time.    


Indeed the CPoS response time has no relationship to the block creation cycle, as the single nomadic mint agent canonically timestamps each received transaction. The round trip number-of-hops is less with CPoS because the mint is the hub of an organized hub-and-spoke, super-peer network. I chose to keep the Satoshi precedence of 10 minute block creation intervals, for the sake of the Satoshi Social Contract - not for any other reason.

I believe that CPoS's optimum network configuration will permit more transactions at lower user fees. This is an indicator that I need to create and test.


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: RSchexnayder on June 09, 2014, 10:45:23 PM
If the coin creation method is changed, the ASIC owners have nothing to say.

Bitcoin uses proof-of-work, and therefore the majority of the hashing power decides. Why would the current stake-holders be so stupid to switch to a system which is unproven and where there economic advantages, i.e. their capital investment becomes worthless? That makes no sense whatsoever. Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless. All of this should be obvious to anyone who wants to understand why Bitcoin works. The reason is works is that hashing-power can not possibly become worthless. And those that own the hashing power will not agree to give it up. That's the fundamental limitation as well.

Steve, I agree the above post that the Bitcoin mining community will not voluntarily give up their printing press. However, I seriously doubt that they will be collectively confronted with that decision on your timeline.

There is already at least one member of the NXT community who at least suspects that this system can be implemented in that coin. It undoubtedly can, if enough devs are charged with the task. The founding 70 odd members certainly have the capital to invest to make that happen,

Furthermore, the BlackCoin community is already aware of its potential, and you have posted your correspondence with their representative letting anyone who reads this thread know about it.

I suspect that you will have to reconsider your plan before the end of this month.   


Title: Re: [ANNOUNCE] Bitcoin Proof-of-Stake
Post by: SlipperySlope on June 09, 2014, 11:20:22 PM
Steve, I agree the above post that the Bitcoin mining community will not voluntarily give up their printing press. However, I seriously doubt that they will be collectively confronted with that decision on your timeline.

There is already at least one member of the NXT community who at least suspects that this system can be implemented in that coin. It undoubtedly can, if enough devs are charged with the task. The founding 70 odd members certainly have the capital to invest to make that happen,

Furthermore, the BlackCoin community is already aware of its potential, and you have posted your correspondence with their representative letting anyone who reads this thread know about it.

I suspect that you will have to reconsider your plan before the end of this month.   


I encourage the spread of CPoS as a technique to altcoins. I expect that public system tests meeting all challenges will sway the Bitcoin community by the time of an early 2016 launch.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on June 12, 2014, 11:31:49 AM
Hello Stephen.

Some problems I found in the OP:

- The linked specifications file doesn't seem to exist.
- The reward policy link requires authentication.
- Your linkedin link requires authentication. There is probably another way to link to it, though I wouldn't be surprised if there isn't, as linkedin has become so aggressive in their spam and tries to make everyone register.

I have read the paper and really liked it. Wouldn't it be good to add a little summary in the OP and insist on reading the paper, as most people tend to skip the links? Because at first sight, for someone who skips the paper, it seems like there aren't even any ideas on the concrete solution yet.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 12, 2014, 01:59:36 PM
Hello Stephen.

Some problems I found in the OP:

- The linked specifications file doesn't seem to exist.
- The reward policy link requires authentication.
- Your linkedin link requires authentication. There is probably another way to link to it, though I wouldn't be surprised if there isn't, as linkedin has become so aggressive in their spam and tries to make everyone register.

I have read the paper and really liked it. Wouldn't it be good to add a little summary in the OP and insist on reading the paper, as most people tend to skip the links? Because at first sight, for someone who skips the paper, it seems like there aren't even any ideas on the concrete solution yet.

Thanks! I fixed the specifications links and permissions on the reward policy link. The LinkedIn profile is probably something I cannot change. I will add the whitepaper abstract to the OP.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: kutaka on June 13, 2014, 06:20:19 PM
Nice idea. With GHASH.IO coming back again and again like a zombie, I think that this hardfork might get more popular soon.

Too bad it is estimated for January 2016. I hope that we will not need that sooner.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Luckybit on June 14, 2014, 01:39:51 PM
I make this post to go on record that I'm in favor of a hard fork of Bitcoin. The core devs and culture surrounding Bitcoin have allowed a 51% attack to occur, MtGox to become centralized, fail, and generate months of bad press, and refuse to switch out of SHA-256 and on to another hashing algorithm or at least Proof of Stake.

Other developers have been warning them, people were warned about MtGox, nothing changes. Instead excuses are constantly being made for increasing centralization. Every month we look and see more signs of centralization.

Either Bitcoin must be hard forked or I'll be using something else like NXT or Bitshares.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on June 14, 2014, 03:54:35 PM
I make this post to go on record that I'm in favor of a hard fork of Bitcoin. The core devs and culture surrounding Bitcoin have allowed a 51% attack to occur, MtGox to become centralized, fail, and generate months of bad press, and refuse to switch out of SHA-256 and on to another hashing algorithm or at least Proof of Stake.

Other developers have been warning them, people were warned about MtGox, nothing changes. Instead excuses are constantly being made for increasing centralization. Every month we look and see more signs of centralization.

Either Bitcoin must be hard forked or I'll be using something else like NXT or Bitshares.



What the hell are you talking about?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: ChuckOne on June 14, 2014, 05:59:59 PM
wont NXT do most of this when it implements transparent forgeing?????

Good question. I am quite open to borrowing and sharing ideas with altcoin projects. I of course examined next last month when writing my whitepaper, but I felt at the time that PeerCoin alone was a sufficient example of existing proof-of-stake implementations.

I will revisit transparent forging.

Good to know. If you have questions or need explanations, PM me.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Luckybit on June 15, 2014, 01:38:37 AM
I make this post to go on record that I'm in favor of a hard fork of Bitcoin. The core devs and culture surrounding Bitcoin have allowed a 51% attack to occur, MtGox to become centralized, fail, and generate months of bad press, and refuse to switch out of SHA-256 and on to another hashing algorithm or at least Proof of Stake.

Other developers have been warning them, people were warned about MtGox, nothing changes. Instead excuses are constantly being made for increasing centralization. Every month we look and see more signs of centralization.

Either Bitcoin must be hard forked or I'll be using something else like NXT or Bitshares.



What the hell are you talking about?

Bitcoin is not sustainable as a decentralized currency. Proof of Work does not and by design cannot scale until a day when each of us can make chips in our basement 3d printers. Since we aren't chip makers, the electric company, or the producers of hashing power, we must continuously buy or borrow hashing power from others. The producers of hashing power control the SHA-256 Proof of Work technology and with it they have obtained the ability to 51% attack. Due to the economics the pyramid can be expected to continue to become more steep over time as control winds up in fewer hands.

The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

They got in their positions because they chose the most advanced technology and I don't see why they should entitled to keep their leadership position if they do not consistently choose the best technology. Progress should be more important than whether or not some miners can get rich. If I were them I would pull some of my money out of Bitcoin and put it into Proof of Stake or I would fund the development of CPoS to support the hard fork of Bitcoin.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on June 15, 2014, 01:47:19 AM
I make this post to go on record that I'm in favor of a hard fork of Bitcoin. The core devs and culture surrounding Bitcoin have allowed a 51% attack to occur, MtGox to become centralized, fail, and generate months of bad press, and refuse to switch out of SHA-256 and on to another hashing algorithm or at least Proof of Stake.

Other developers have been warning them, people were warned about MtGox, nothing changes. Instead excuses are constantly being made for increasing centralization. Every month we look and see more signs of centralization.

Either Bitcoin must be hard forked or I'll be using something else like NXT or Bitshares.



What the hell are you talking about?

Bitcoin is not sustainable as a decentralized currency. Proof of Work does not and by design cannot scale until a day when each of us can make chips in our basement 3d printers. Since we aren't chip makers, the electric company, or the producers of hashing power, we must continuously buy or borrow hashing power from others. The producers of hashing power control the SHA-256 Proof of Work technology and with it they have obtained the ability to 51% attack. Due to the economics the pyramid can be expected to continue to become more steep over time as control winds up in fewer hands.

The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

They got in their positions because they chose the most advanced technology and I don't see why they should entitled to keep their leadership position if they do not consistently choose the best technology. Progress should be more important than whether or not some miners can get rich. If I were them I would pull some of my money out of Bitcoin and put it into Proof of Stake or I would fund the development of CPoS to support the hard fork of Bitcoin.



I'm aware of PoW problems, but you were saying non-sensical things like we allowed "MtGox to become centralized". MtGox was just an exchange, and it was never decentralized. It's just a website! What do you expected Bitcoin developers to do about it?

Also, nothing changed when a pool reached 51%. If you didn't panic at 30% or 40%, why are you panicking now?

CPoS hasn't been proven secure yet, and other alternatives have been proven insecure.

If you are so sure PoS is secure, go ahead and sell your bitcoins for Nxt. But have you considered that a technology might not be "the most advanced" just because someone says so?

This thread is for research, not panicking, fudding, and complaining about the state of Bitcoin or its politics. Please keep it clean.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Luckybit on June 15, 2014, 02:06:02 AM
I'm aware of PoW problems, but you were saying non-sensical things like we allowed "MtGox to become centralized". MtGox was just an exchange, and it was never decentralized. It's just a website! What do you expected Bitcoin developers to do about it?
It was avarice which allowed Mt Gox to grow like that. I'm not usually someone who speaks out against greed because greed can be channeled into good or bad purposes. When greed leads only to centralization without promoting technological progress then can we accept that it's being channeled to a bad cause?

Mt Gox was not producing technological innovation, it wasn't even trying to be the most regulated exchange, it was just a nest of greed heads who were clinging to an obsolete centralized exchange technology. Exchanges were falling left and right yet people still put their money into Mt Gox and many of them were some of the richest early adopters of the Bitcoin community.

Also, nothing changed when a pool reached 51%. If you didn't panic at 30% or 40%, why are you panicking now?
When Mt Gox first started delaying withdraws nothing changed immediately. When Mt Gox first got hacked we heard the same sorta "stay calm" rhetoric. Why should I listen to you now? The security of Proof of Work was based on the premise that a 51% attack is not feasible. It's now proven that a 51% attack is feasible and while you can tell us that it can be patched or prevented it doesn't change the fact that the vulnerability is in the design of the Proof of Work incentive structure itself.

You're going to keep having these sorts of problems until a hard fork switches things over. A hard fork will be necessary because the elites of the PoW Blockchain hierarchy are not going to want to give up their power. Those who would willingly give up their power for the sake of technological progress are truly on the side of technological progress. A transition has to occur and at this point it is clear that Proof of Stake is a better design for long term sustainability both environmental and socially.
CPoS hasn't been proven secure yet, and other alternatives have been proven insecure.
CPoS hasn't been tested yet, I'll give you that. NXT, Peercoin, Blackcoin, all are partially working. Bitshares is in the testing phase right now and DPoS, CPoS, are both similar in a lot of ways. When Bitcoin was being worked on no one was sure it could work but the people who took a chance were rewarded. It resulted in a great technological breakthrough and progress. We have to continue pushing for technological progress in my opinion.

If you are so sure PoS is secure, go ahead and sell your bitcoins for Nxt. But have you considered that a technology might not be "the most advanced" just because someone says so?
I'm not telling anyone to sell all their Bitcoins for any specific technology. I'm saying we should promote technological progress at every opportunity. Bitcoin is proven to have vulnerabilities in the design of Proof of Work and Proof of Stake is an alternative which might be able to solve it. CPoS could work as intended and if it does then there will be no rational reason to stick with PoW except avarice.

This thread is for research, not panicking, fudding, and complaining about the state of Bitcoin or its politics. Please keep it clean.

The whole premise of this thread is that Bitcoin needs to be upgraded. A hard fork is a way to do that if the core developers and entrenched interests wont support the idea. Of course I would rather see the core developers and companies like BitFury get behind the idea. I would like to see these companies begin funding development, where is BitPay? Where is Coinbase?

But I'm skeptical that anything will happen until something dramatic causes people to act. So I'm not posting to promote any FUD, only to share my own stance which you asked me to clarify.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: ChuckOne on June 15, 2014, 09:55:27 AM
The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

Holy crap. Is this true?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: ChuckOne on June 15, 2014, 09:56:30 AM
CPoS hasn't been tested yet, I'll give you that. NXT, Peercoin, Blackcoin, all are partially working. Bitshares is in the testing phase right now and DPoS, CPoS, are both similar in a lot of ways. When Bitcoin was being worked on no one was sure it could work but the people who took a chance were rewarded. It resulted in a great technological breakthrough and progress. We have to continue pushing for technological progress in my opinion.

Why partially?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bybitcoin on June 15, 2014, 11:08:10 AM
Not any 51% attack has happened recently: actually there was a concern about ghash.io total share of btc mining power which was fluctuating at the 40%-50% range recently.. As a result Bitfury dropped 1PH/s of its mining power from the ghash.io pool to cool off the threat and satisfy the concern.

Nxt might not be the most optimum PoS scheme which could be implemented theoretically (but which coin has the optimums so far?), anyway it is the first pure PoS working and that it is doing not partially but as we've seen in the past six months, enough satisfactorily.

Some people just like to speak, and to speak too much.. for proof reference you can have a look at mastercoin thread.
I am passionately following the OP's work and contribution in this thread, hope we could have less noise and nonsense here.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on June 15, 2014, 03:20:38 PM
The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

Holy crap. Is this true?

No. Ignore him, he's just panicking and trying to solve something he's not qualified to solve. And while he's at it he's polluting an otherwise very interesting thread.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: Luckybit on June 16, 2014, 03:57:58 PM
The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

Holy crap. Is this true?

No. Ignore him, he's just panicking and trying to solve something he's not qualified to solve. And while he's at it he's polluting an otherwise very interesting thread.


How do you become qualified to solve something without solving it? Have you solved it? I assume when you talk about qualified you're talking about Peter Todd and Gavin Anddressen?

https://bitcoinfoundation.org/2014/06/13/centralized-mining/
http://www.reddit.com/r/Bitcoin/comments/281ftd/why_i_just_sold_50_of_my_bitcoins_ghashio/

I've made my position on the GHashio and Bitcoin design problems known. If you think I'm unqualified to speak then please ignore everything I've said and continue acting on the information you believe to be correct.

For the record it's true I was involved with Mastercoin from the beginning, am involved with Bitshares too. I'm not panicking, I'm promoting whatever I think the best technological solutions are and to me there is DPoS, CPoS, and Transparent Forging.  If you understand the technology enough then you'll understand why I think that at a later date.

If no one agrees with my opinions I don't really care. I'm putting it out there because the flaws I see in Bitcoin aren't being fixed and I suspect that it needs to be hard forked just to implement CPoS. I wanted to voice my opinion in favor of a hard fork because at this point Bitcoin is promoting a level of centralization which I'm uncomfortable with because it goes against the long term strategic technological principles that I follow.

The 51% attack which happened this week is a warning sign to anyone paying attention. It's a red flag exactly like what we saw when Mt Gox was not processing withdraws. The time to push for a hard fork is right now because Proof of Work as Bitcoin is implementing it is obsolete. It's an incomplete solution compared to a more complete solution such as the Cooperative Proof-of-Stake CPoS or Delegative Proof of Stake DPoS. NXT has a solution as well and the specific challenge we have is to promote the best technologies even when it might not be in the best economic interests of entrenched elites of Proof of Work Blockchain hierarchies.

Holy crap. Is this true?

Don't take it from me, do your own research and form your own opinion. Google is your friend here.

I voiced my concerns because they are genuine concerns. I'm seeing increasing levels of centralization around mining. I'm seeing mining which was once a serious game which anyone had the opportunity to play become something that over time the chip makers will be the only players qualified to profitably participate in.

This is a problem as it removes whatever democratic nature the network could have had. It also has many people claiming that the game is rigged/unfair because the only way to get a Bitcoin now is to buy it with cash. If you have to buy Bitcoins with cash then it has no advantage over Proof of Stake anymore that I can see.

These problems are just the philosophical surface issues I have with how things are playing out, there are some technical problems which are already well addressed by CPoS so I will not go into that.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 16, 2014, 05:32:39 PM
CPoS To Be Implemented Using the Texai Cognitive Architecture

The Texai cognitive architecture will be used to implement the multi-agent network that connects bitcoind, i.e. Bitcoin Core, instances together and enables a single nomadic mint agent that is the core idea of CPoS.

Here are references and videos about my work with Texai . . .

  • Natural Language Approach of the Texai Project (https://www.youtube.com/watch?v=aB3px5_75jg) Stephen Reed's Texai project presentation recorded at the 2008 Artificial General Intelligence Conference
  • OpenCyc Commonsense AI Tutorial - part 1 (http://vimeo.com/6579522) Stephen Reed presentation recorded at the 2009 AGI Conference
  • OpenCyc Commonsense AI Tutorial - part 2 (http://vimeo.com/6595854)
  • Bootstrap Dialog: A Conversational English Text Parsing and Generation System (http://agi-conference.org/2009/papers/paper_44.pdf) Stephen L. Reed, Texai.org, presented at the Artificial General Intelligence Conference, 2009.
  • Texai presentation at AGI-2009 recorded video (http://vimeo.com/6343032) Stephen Reed
  • Texai presentation slides at AGI-2009 (http://agi-conference.org/2009/slides/saturday/session_3/2_reed.ppt) Stephen Reed

Texai is a cognitive architecture to achieve artificial intelligence via a dialog system whereby mentors teach the system skills. For Bitcoin Cooperative Proof-of-Stake, I will remove the demonstration dialog modules, leaving modules that perform . . .

  • X509 certificate server - provides Texai X509 certificates when installing full nodes
  • X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
  • SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints
  • SSL Bittorrent - the torrent protocol is encrypted and used to catch up the blockchain on relaying full nodes as required
  • Webserver - full node statistics and network operations are presented to the operator via HTML pages
  • Albus Hierarchical Control Network - a robotics-inspired multi-agent network consisting of agencies, agents, roles and skills
  • RDF Entity Manager - a Java object persistence framework that uses an RDF quad store as the storage. RDF is a semantic web language for knowledge representation
  • Open Cyc - the open source RDF version of the Cyc commonsense knowledge base, which provides the extensible ontology that structures what Texai agents know and can do

My work plan for the remainder of June is to upload the selected modules to GitHub and begin implementing the first system test case which is a single relay agent full node communicating with a single mint agent full node. The initial version will not perform any peer validation, nor DDoS traffic scrubbing. Note that I need to test whether my approach requires any changes to the Bitcoin Core bitcoind code. I think not.

Here is how I will slave bitcoind to the Texai network . . .

https://i.imgur.com/0Q5GuGb.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 16, 2014, 06:39:48 PM
A Blockchain-Based Exchange Between Proof-of-Work (PoW) Bitcoin and Cooperative Proof-of-Stake (CPoS) Bitcoin

Imagine that in early 2016 there are two versions of the Bitcoin blockchain and network. There is the legacy Satoshi Bitcoin network with proof of work mining. And there is the new fork CPoS Bitcoin blockchain and network. There will be a need to exchange value between the two blockchains as hopefully, the new fork becomes more valuable when users appreciate its benefits.

An nomadic exchange agent in the CPoS system would be connected to the PoW (old fork) network using a suitably configured bitcoind instance. The exchange agent could thus transact on both Bitcoin blockchain forks, i.e. PoW-fork and CPoS-fork simultaneously. Each user of the exchange would have both a PoW Bitcoin wallet and a CPoS wallet, which are two instances of the same program pointed at different networks. The wallets would be used to execute market orders. Multiple signature transactions should permit limit orders, in which the exchange agent provides the second signature when required as the limit condition is met.

There would be a one-hour settlement time on the PoW-fork side of the exchange transaction. The CPoS-fork side of the exchange transaction would occur at the end of the transaction settlement period.

The exchange agent would not have a hot wallet, as all transactions are performed on the respective blockchains. The earned trading commissions would be distributed immediately as microtransactions to the exchange owner. The exchange agent would have an API for charting sites. Trading bots could use that API to determine the market situation, and use their own bitcoind instances, in lieu of wallets, to perform the trades.

Being on-blockchain should allow fees to be lower as the design is simpler and there is no exchange hot wallet to secure. Without any connection to fiat currencies, it should be easy to find jurisdictions to operate the nomadic exchange in which the wallet interface alone is sufficient - without an enrollment that requires certain identification.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 16, 2014, 09:54:10 PM
I pushed, i.e. uploaded, two Java modules to my GitHub project repository at https://github.com/StephenLReed/texai (https://github.com/StephenLReed/texai). The first was the main project Texai which has been pruned down to one maven module - Utilities. I upgraded the Java platform to 1.8 and am using NetBeans version 8.0 as the programming environment.

The Utilities module has 133 unit tests that passed OK. I use three different static bug-finding and style checking tools. Next to adapt and push to GitHub are the RDF Entity Manager and X509Security modules.

Although the Bitcoin core developers have the advantage of portability and performance with their C++ language choice, I for one, am much better off using Java. It will be much, much faster for me to adapt the existing Texai Java source code than to learn C++ well enough to adapt the existing Bitcoin Core source code.

When Bitcoin CPoS is deployed for testing starting this year and for ultimate launch in early 2016, it will only be designed to run on paid-for full nodes, that will get paid only if the full node executes the specified configuration. At the moment I am thinking that the full node operators will be instructed how to run Ubuntu Linux LTS, i.e. the long term stable version, Java 1.8, the CPoS Java components, and the then available Bitcoin Code bitcoind executable. Unlike the Bitcoin core developers who have to design and test code to run on Windows, Linux, MacOS, and other platforms, Bitcoin CPoS will be designed and tested to run on one platform, chosen for optimum security.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 16, 2014, 11:17:39 PM
I added the Texai Java module X509Security to GitHub at https://github.com/StephenLReed/texai (https://github.com/StephenLReed/texai). 41 unit tests passed OK.

X509 certificates are commonly used by websites to authenticate servers in the HTTPS protocol. In Texai, both endpoints of the communication channel authenticate themselves during the TLS/SSL encryption negotiation with X509 certificates issued by the Texai certificate authority server  - which has a certain self-signed certificate as the root certificate. Only full node operators need to be concerned about these certificates when they initially install the software.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 17, 2014, 02:59:14 PM
I configured Jenkins continuous integration software on my local server, and now it rebuilds the project whenever any source code changes on the GitHub Texai project. About 170 unit tests pass OK. There are two downstream projects that are not yet on GitHub. The JavaCV is a computer vision library that I will not be using with Bitcoin CPoS, and the second is the Texai X509 certificate server which I will later add to GitHub as a project.

https://i.imgur.com/Gk58RWF.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 17, 2014, 03:34:22 PM
The X509 certificate server project is now on GitHub (https://github.com/StephenLReed/X509CertificateServer) and is working with my local Jenkins CI (Continuous Integration) software such that whenever I push a source code change to the GitHub project, Jenkins automatically downloads the changes, builds the project, and runs the regression test suite.

Here is the GitHub project page . . .

https://i.imgur.com/oZ5zB5g.png

And here is my local Jenkins CI server page for the X509CertificateServer project . . .

https://i.imgur.com/ySeFppy.png





Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 18, 2014, 01:59:59 AM
I pushed the OpenCyc RDF repository to a new GitHub repository - https://github.com/StephenLReed/texai-rdf-repositories (https://github.com/StephenLReed/texai-rdf-repositories). Also there are a couple of testing repositories, Test and Benchmark.

The OpenCyc repository is used as the commonsense ontology, i.e. vocabulary and taxonomy, for organizing the conversations between Texai agents.

At the moment, some of the unit tests for the RDFEntityManager module are broken. The RDF repository files are comparatively large and so I moved them to a separate GitHub repository to make commits to the Java source code repositories faster.

https://i.imgur.com/BAAt6Uc.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: coinsolidation on June 19, 2014, 10:45:41 PM
Quote
X509 certificate server - provides Texai X509 certificates when installing full nodes
X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints

Do not mix authentication with authorization.

Let each node be named with a URI (URI-A)
Nodes issue their own certificates with URI-A in the subjectAltName part of the x509
As authentication dereference URI-A to find RDF-data, check for the public key from the x509.
If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier.

This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point.

Layer on authorization using ACL, which can also be implemented using RDF.

See webid (formerly foaf-ssl) for more information, see web access control for more on authn.

Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this.

Quote
Webserver - full node statistics and network operations are presented to the operator via HTML pages

I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 20, 2014, 08:34:09 AM
Quote
X509 certificate server - provides Texai X509 certificates when installing full nodes
X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints

Do not mix authentication with authorization.

Let each node be named with a URI (URI-A)
Nodes issue their own certificates with URI-A in the subjectAltName part of the x509
As authentication dereference URI-A to find RDF-data, check for the public key from the x509.
If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier.

This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point.

Layer on authorization using ACL, which can also be implemented using RDF.

See webid (formerly foaf-ssl) for more information, see web access control for more on authn.

Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this.

Quote
Webserver - full node statistics and network operations are presented to the operator via HTML pages

I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf.

I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority.

The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes.

For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai.

An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: coinsolidation on June 20, 2014, 11:11:38 AM
Quote
X509 certificate server - provides Texai X509 certificates when installing full nodes
X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints

Do not mix authentication with authorization.

Let each node be named with a URI (URI-A)
Nodes issue their own certificates with URI-A in the subjectAltName part of the x509
As authentication dereference URI-A to find RDF-data, check for the public key from the x509.
If public key is found, assert that the node "owns" URI-A and thus can use it as an identifier.

This covers authentication and allows each node to revoke and change certificates as it chooses, it also allows nodes to provide more information at the dereferenceable URI and acts as an extension point.

Layer on authorization using ACL, which can also be implemented using RDF.

See webid (formerly foaf-ssl) for more information, see web access control for more on authn.

Consider defining a simple protocol that allows multiple forms of passing keys and establishing identifiers for agents, x509 may need to be replaced, legacy and different networks may need different auth protocols, your suggested approach binds to HTTP+TLS only, when multiple transport level protocol may be required for this.

Quote
Webserver - full node statistics and network operations are presented to the operator via HTML pages

I suggest an RDF data API, it will be far more beneficial if the information is machine readable data (possibly with a default HTML view.. RDFa?), then multiple different UIX can be built on top allowing independent innovation and it'll be readily extensible by using new classes and properties in the rdf.

I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority.

The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes.

For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai.

An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database.

Great to hear.

I believe somebody has already marked up the blockchain as RDF if that would be of use, indeed a few of us have been working on bitcoin+semantic-web for a few years, nothing vastly productive to show for it, but we've certainly prototyped and mapped the architecture out. They are a powerful match!


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 20, 2014, 07:26:05 PM
I completed upgrading the Bouncy Castle cryptographic libraries. I added two more modules from Texai now that their dependencies are in the project. The first is support for bittorrent messages, which is required by the SSLBitTorrent module to be added after the Network module is added. And the second is support for the Albus Hierarchical Control Network - AlbusHCN module, that is the Texai agent framework.

Over 300 unit tests are running OK on my local continuous integration server, which automatically rebuilds the project whenever I push new updates to the GitHub source code repository. Over 32,000 lines of Java source code have been added to the project, not including the regression tests.

I expect that I will add less than 10 more modules from Texai before I am ready to begin coding the first Bitcoin CPoS test case, which simply runs two slave full nodes that take turns hosting the nomadic mint agent which creates new blocks, without yet performing the required verification of the peer tamper-evident logs.

https://i.imgur.com/gWvmNgY.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: coinsolidation on June 20, 2014, 07:58:11 PM
Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 20, 2014, 08:00:42 PM
Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on June 25, 2014, 05:20:56 PM
I have migrated a few more code modules from the Texai system over to the Texai CPoS code repositories on GitHub (https://github.com/StephenLReed). Notably there is an implementation of BitTorrent over TLS/SSL which I will later use for rapid blockchain update of new full nodes.

Texai previously used the Chord distributed hash table to find peers, but I want to replace this mechanism with something else that can connect the CPoS network and be subject to remote verification by peers. Continuing the pattern I set by a single writer to the canonical blockchain, which is then widely replicated, I suppose that the MessageRouter will use a shared dictionary of full node IDs and IP addresses. This shared tamper-evident dictionary would be maintained by a single writer and widely replicated. Changes to the dictionary should be verifiable by peers.

I will think about this feature and also the tamper-evident logs required by the blockchain operations. I believe that there is a Java abstraction that both these use-cases may inherit from.

Here is my contribution activity chart from GitHub. The migrated and tested code from Texai now totals 42,000 lines of Java source code, not including the 450 regression test methods.

https://i.imgur.com/Ny8Dbzj.png



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: kutaka on July 10, 2014, 11:30:57 AM
How can someone contribute? Is the project in a stage where more devs can join?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: mhps on July 12, 2014, 02:15:20 AM
Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.

Why not use the wiki feature on github?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: coinsolidation on July 12, 2014, 02:29:55 PM
Why not use the wiki feature on github?

This is a good idea, and the approach I am taking with Bitmark.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: fran2k on July 13, 2014, 12:54:06 AM
Interesting, reading..


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: coine_smithe on July 22, 2014, 11:06:24 PM
I'm posting this to commit myself to reading everything including all references in this thread some day soon. The work going on here is phenomenal. I want to reach a level where I can comprehend what's going on here and possibly have a part in it. Thanks for making such an awesome topic OP.  8)


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: bubble83 on July 22, 2014, 11:41:18 PM
PoS coin blockchains seem to grow faster than PoW coin blockchains. Will a CPoS bitcoin fork's blockchain grow faster than bitcoin's?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on July 28, 2014, 05:11:28 PM
Can I ask if you could take some time to define a dictionary of terms used in your posts somewhere. I'm familiar with many but only because I have pre existing knowledge. It is hard to distinguish between what is a technology, and innovation, a third party piece of software, a component of the system, and so forth.

Do keep up the good work, I'll be watching this closely.

Another great idea. I will add a glossary to the OP.

Why not use the wiki feature on github?

Thanks for the tip!
-Steve


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on July 28, 2014, 05:19:41 PM
PoS coin blockchains seem to grow faster than PoW coin blockchains. Will a CPoS bitcoin fork's blockchain grow faster than bitcoin's?

CPOS Bitcoin will create a new block exactly every 10 minutes, so on average the CPOS Bitcoin blockchain should be equal in length to the original Satoshi Bitcoin blockchain after the fork. Transaction counts per block will differ because of the relative popularity of the two forks.

Additionally I want CPOS Bitcoin to reliably accept low fee transactions and especially microtransactions to highlight an important advantage of CPOS.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 11, 2014, 10:04:55 PM
After returning from vacation I found that the disk drive on my server crashed. When rebuilding the system I decided to make it identical to my development desktop and use Docker to contain the Jenkins continuous integration application that I used to run on the server. Having a second development computer makes it easier to bring one along on vacation, and also a documented and scripted build for developers that this project will ultimately pay to enhance CPOS Bitcoin.

Docker is a Linux based technology that enables applications to run efficiently in secure containers. I created a Docker container for running Java continuous integration with Jenkins, Maven, Java 8, and Git. This is a generally useful contribution to the Java development community.

The repository for my container is https://registry.hub.docker.com/u/stephenreed/java8-jenkins-maven-git-nano/ (https://registry.hub.docker.com/u/stephenreed/java8-jenkins-maven-git-nano/)

And here is a screenshot . . .

https://i.imgur.com/2kJh0GE.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 11, 2014, 10:16:25 PM
Hashers United Conference

I will be participating in a panel discussion at the Hashers United Conference to be held in Las Vegas, Nevada, USA on October 10-11. The panel topic concerns mining algorithms and my modest role will be to briefly describe Cooperative Proof of Stake for Bitcoin. Sharing the podium will be notable crypto coin designers.

This is a great chance to meet up. If you like, PM me.

http://hashersunited.com/ (http://hashersunited.com/)


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: kutaka on August 13, 2014, 03:00:43 PM
Damn, wish it was in Europe;/


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: ahmed_bodi on August 17, 2014, 07:24:15 PM
Hashers United Conference

I will be participating in a panel discussion at the Hashers United Conference to be held in Las Vegas, Nevada, USA on October 10-11. The panel topic concerns mining algorithms and my modest role will be to briefly describe Cooperative Proof of Stake for Bitcoin. Sharing the podium will be notable crypto coin designers.

This is a great chance to meet up. If you like, PM me.

http://hashersunited.com/ (http://hashersunited.com/)

I'm attending there!


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 18, 2014, 04:13:26 PM
August 18, 2014 Status and Thoughts.

I have about half of the Texai cognitive architecture migrated to GitHub. The knowledge base repositories are larger than GitHub guidelines, so I need to find another more appropriate cloud data server, e.g. Dropbox for those. I configured three separate computers in my lab with the same development environment to ensure redundancy and to document the build recipe. The configuration for developers is . . .

  • Ubuntu 14.04 LTS on bare metal
  • Oracle Java 8 with JCE highest level security policy
  • Netbeans 8.0 Java IDE
  • Maven 3
  • Docker

The Docker platform is currently used to host a Jenkins continuous integration server that I uploaded to the Docker container registry.

My GitHub page is https://github.com/StephenLReed?tab=repositories (https://github.com/StephenLReed?tab=repositories).

My Docker repository page is https://registry.hub.docker.com/u/stephenreed/jenkins-java8-maven-git/ (https://registry.hub.docker.com/u/stephenreed/jenkins-java8-maven-git/).

I would like to have bitcoind in an agent-controlled, non-verifying proxy by early October, 2014, for hallway demonstration at the Hashers United conference in Las Vegas. Consequently, I will upload broken aspects of Texai that have no relationship to Cooperative Proof-of-Stake, as the agents I need to write are dependent upon working code embedded in those otherwise broken dialog modules.

------------

Here are my latest thoughts about how CPOS will work.

I am considering hard-forking the popular Satoshi blockchains: Bitcoin, Litecoin, Dogecoin and Namecoin. They would operate on networks separate from the Satoshi originals and be branded respectively CPOS-B, CPOS-L, CPOS-D and CPOS-N. Users would be required to configure their respective client wallets, payment processors, mixing services, etc., to respective CPOS seed node addresses - that's all. There are no changes required to the client protocols I believe.

The forks could come much earlier than January 2016, depending upon the ambition of the network and the state of system testing.

I would use a portion of block rewards to pay geographically dispersed operators to run full nodes for these plus a Tor relay. Each operator would be required to provision a high-availability enterprise server in a datacenter having redundant high bandwidth Internet connections. Specifications for the server will include protection against DDoS attacks.

As operators will be relatively well compensated, I expect to add new servers only with increased market capitalization and transaction traffic. VisaNet runs the majority of the world's credit card transactions with only two datacenters, so less than ten geographically distributed servers with likewise separate ownership may be adequate to start. Supposing that CPOS grows to the same market capitalization that Bitcoin has currently, then 10,000 distributed paid servers could be justified.

I would choose either CoreOS or Ubuntu LTS for the base operating system, and use Docker containers for the cryptocoin bitcoind software, where each coin gets its own container. Likewise the tor relay gets its own container. Each server would run the latest identical software and as the network grows in size, there are existing softwares to manage the worldwide deployment of Docker containers. Unpaid volunteers could download and run the CPOS agent software to record blockchains and verify peer agent behavior, but would not be permitted to operate agents that mint new blocks or that provide support services to other agents.

Governance of the CPOS network will be performed by the Texai cognitive architecture, in which simple transparent algorithms enforce policies decided at periodic meetings of the node operators. Each operator will be required to purchase a commercial membership in their local Bitcoin Foundation. A portion of the block rewards will fund developers tasked via the Texai cognitive architecture. Each paid person performing a task for the system will have at least two other non-affiliated paid persons check their work. A portion of the block rewards will fund development of the Texai architecture, Bitcoin Core, and relevant altcoin features. Supposing that CPOS coins grow to the current market capitalization of bitcoin, then 300+ developers could be supported. Paid human participants in the CPOS system, e.g. operators and human agents, could be anonymous but would be required to possess X.509 certificates for digital signatures and network authentication. Likewise they must provide verifiable contact information. All communications in the network are digitally signed, TLS/SSL encrypted, and logged. We want the network to be trustless in the sense that Satoshi's Bitcoin is trustless, but paid participants must be held responsible for their behavior via cyrptographic credentials and tamper-evident logs.

I expect the block rewards of the CPOS coins to greatly exceed the transaction revenue with respect to paying for the system. Consequently, I would set transaction fees to the lowest sensible values which I believe are 100x less than what bitcoin charges. Rather than $.05 fee at today's bitcoin price, I would set CPOS transaction fees at the equivalent of $.0005 which encourages the use of microtransactions.

As an example of "eating your own dog food", the Texai software agents will pay each other for services rendered using bitcoin microtransactions. This will encourage software developers to write skills for the system, as they will receive the net earnings of software skill they provide in accordance with a scheme to maximize innovation.

In accordance with the precedent set by Satoshi's Bitcoin, the CPOS network will not be a legal entity in any jurisdiction. The network, despite Tor anonymity capabilities, will not place servers in jurisdictions where their operation would be against the local law. The network will pass through all earnings, e.g. block rewards, transactions fees, and software agent income, to human participants who will pay taxes according to their local jurisdictions.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on August 19, 2014, 05:54:28 AM
Litecoin, Dogecoin

The forks could come much earlier than January 2016

This part makes no sense. Why would you want to do that? Do you realize by 2016, those coins might not even exist anymore? Both of them have been falling in BTC price non-stop as expected from their lack of usefulness, and will probably be displaced by non-Bitcoin clones like Monero for example, which at least adds *something* new (true decentralized anonymity thanks to the use of ring signatures).

http://coinmarketcap.com/currencies/litecoin/

http://coinmarketcap.com/currencies/dogecoin/

If you don't know much about what happened in the dogecoin world you should read this:

http://www.dailydot.com/business/moolah-dogecoin-alex-green/

There's also this leaked video:

http://www.liveleak.com/view?i=e63_1404777061

About Litecoin: The tale that Scrypt made it ASIC resistant is now proven to be false. It's being mined by ASICs, and even the creator of Scrypt himself said "they used it poorly", because it was supposed to use a lot of RAM, but it didn't. So it's basically just another Bitcoin clone with nothing new, less adoption, less investment in mining gear, less security, less brain power working on it, less venture capital, less companies, less network effect, less market capitalization, less everything.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 19, 2014, 11:42:39 AM
Litecoin, Dogecoin

The forks could come much earlier than January 2016

This part makes no sense. Why would you want to do that? Do you realize by 2016, those coins might not even exist anymore? Both of them have been falling in BTC price non-stop as expected from their lack of usefulness, and will probably be displaced by non-Bitcoin clones like Monero for example, which at least adds *something* new (true decentralized anonymity thanks to the use of ring signatures).

http://coinmarketcap.com/currencies/litecoin/

http://coinmarketcap.com/currencies/dogecoin/

If you don't know much about what happened in the dogecoin world you should read this:

http://www.dailydot.com/business/moolah-dogecoin-alex-green/

There's also this leaked video:

http://www.liveleak.com/view?i=e63_1404777061

About Litecoin: The tale that Scrypt made it ASIC resistant is now proven to be false. It's being mined by ASICs, and even the creator of Scrypt himself said "they used it poorly", because it was supposed to use a lot of RAM, but it didn't. So it's basically just another Bitcoin clone with nothing new, less adoption, less investment in mining gear, less security, less brain power working on it, less venture capital, less companies, less network effect, less market capitalization, less everything.


The coins I would fork are currently the highest market capitalization Satoshi proof-of-work coins. Perhaps in a few more months, Dogecoin will fall out of that group. Or on the other hand, a rally in Bitcoin might lift most altcoins as happened November 2013.

I understand your points about the relative merits of coins. But, analogous to current industrial mining, I want to position the CPOS system as an agnostic platform that secures the network for a variety of branded coins without controlling their respective business communities, and thus isolated from their behavior. The CPOS system would drop a coin whose block rewards no longer pay for the storage of their blockchain.

CPOS will enable each supported coin to have lower transaction fees and immediate, certain acknowledgement that accepted transactions will be included in their respective blockchain. CPOS operators, as directed by the software, will contribute a significant portion of respective block rewards to the Litecoin and Dogecoin foundations for use as those communities see fit.

Furthermore, CPOS supported coins will not be subject to 51% attacks. Their transactions will be immutable and thus not subject to double spend attacks. All traffic between paid-for full nodes is TLS/SSL encrypted, and because each such full node is identified by a unique X.509 certificate, there will be no Sybil attacks.

To buoy coin prices and to encourage user migration to the CPOS fork, I would establish a CPOS system policy that allocates a modest portion of block rewards to post-fork unspent transaction outputs in the blockchain as a dividend.

Once the system is up and running, new coins can be enrolled in CPOS during the coin's development process by substituting CPOS for the otherwise required mining pool, on the condition that the developers clone Bitcoin Core, i.e. bitcoind, software. Aside from premining, promoters can pay themselves by owning the foundation that CPOS funds via block rewards, or by accepting payment directly from CPOS to add features - again via block rewards.







Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: pa on August 21, 2014, 12:56:33 AM
I was wondering whether CPoS has been reviewed, or commented on, by any of the Bitcoin core devs.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 21, 2014, 04:15:59 AM
I was wondering whether CPoS has been reviewed, or commented on, by any of the Bitcoin core devs.

Yes, andytoshi personally, and gmaxwell on IRC.

Before writing the whitepaper I met with andytoshi here in Austin, Texas and we discussed the issues of achieving consensus in a distributed system. He believed then that my ideas were not Bitcoin, as I sidestep distributed consensus by not having a Satoshi-style, join-and-leave at will, anonymous, volunteer peer-to-peer system. CPoS has paid-for, authenticated full nodes that are permanently operated by geographically dispersed, non-affiliated system administrators. CPoS is cooperative and achieves trustless behavior via transparent software agents that verify each other's actions. Gmaxwell, I believe, wants to see the working system.

Core developers will likely closely scrutinize the nomadic central mint that enables all CPoS advantages. As I plan to use bitcoind as is, I actually do not need core developer acceptance of a pull request for changes to the Bitcoin Core software. Rather my code encapsulates a slave bitcoind instance and proxies its connections to the secure network CPoS manages.

I plan to explore microtransactions as a route to more general acceptance, as CPoS has benefits for this up-to-now unserved market, namely 100x less transaction fees and immediate acknowledgement  for inclusion in the next block.

Should CPoS prove successful in its forks of the popular PoW coins, then I expect the system to use a portion of the block rewards to hire a relatively large number of developers to join those already working on Bitcoin Core.

I am dropping the idea of paying dividends to existing coin holders, as the system stake is provided by the paid-for full node operators. The block rewards are better spent to improve the coins, and encourage their use in transactions.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: kelsey on August 21, 2014, 05:11:28 AM
I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: hbadger on August 21, 2014, 10:23:12 AM
I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).



Because he wants his initiative to succeed, not to be just another short lived pump and dump scam. He wants to preserve Satoshi's social contract.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 21, 2014, 02:30:39 PM
I'm not upto speed on all of this project ie spent about 2 minutes.

However you wish to hardfork BTC beginning of 2016? you want major holders to follow your fork?

Why not just create a new chain?

What is the point of using BTC when for a start even a bitcoin advocate could hardly consider bitcoins current distribution as ideal?

Also well before you finish there will already be a bitcoin pos on its own blockchain (another project with significant backing far removed from this forum).



Because he wants his initiative to succeed, not to be just another short lived pump and dump scam. He wants to preserve Satoshi's social contract.

That.

Plus the current PoW coins are in a sort of unstable equilibrium, in which their operating situation is locally optimal, even though a hard fork to reallocate the mining reward would be greatly beneficial to the community. As Tim Swanson explains in his recent book, the core developers of Bitcoin do not have the staff nor the consensus to make a great change to how Bitcoin works. Disruption must occur from the outside and start with a market PoW cannot currently address - I will try microtransactions for example.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: othe on August 21, 2014, 02:44:34 PM
But you noticed that the coins you will issue if you hardfork the chains will simply be owned mainly by:

1) Exchanges
2) Destructive idiots like Mark Karpeles
3) Big investors

My guess is, exchanges/investors will just dump them onto the market.

I can´t see how that is in any spirit of what satoshi had in his mind.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 21, 2014, 03:40:33 PM
But you noticed that the coins you will issue if you hardfork the chains will simply be owned mainly by:

1) Exchanges
2) Destructive idiots like Mark Karpeles
3) Big investors

My guess is, exchanges/investors will just dump them onto the market.

That could happen, but I suggest that current holders will simply wait and see what happens to the price of forked coins. The price of a coin, I believe, depends mainly on the quantity of economic transactions its users are willing to make. Metcalfe's Law, as applied to coin prices, says that the price of the coin should be proportional to the square of the number of transactions. My goal therefore is not to get big investors to buy, or even to hold - rather my goal is to get payment processors to accept my forked coins because of their performance - namely immediate acceptance and 100x lower fees. I plan to also use a variety of marketing promotions, allocated from block rewards, to induce users to transact the forked coins.

The first market will be microtransactions, which should lead to high transaction quantity but little in the way of amount.

I can´t see how that is in any spirit of what satoshi had in his mind.

My interpretation of Satoshi's writings are different than yours. He had little to say about the unequal distribution of bitcoin wealth, which is important because he owns so much of it. Obviously, CPoS overturns Satoshi's brilliant solution to the problems of electronic cash, yet I attempt to maintain the Satoshi Social Contract to the greatest extent possible, e.g. no trusted third parties, create a new block every 10 minutes and have a maximum 21 million bitcoins ever.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 23, 2014, 10:20:19 PM
Today I completed the revision, testing and upload of the Texai modules that will provide the foundation for cooperative proof-of-stake for Bitcoin. GitHub has the source code files and I have uploaded the large RDF repositories directory and the large Maven artifacts directory to an account I established at Mega. Shortly I will clean up GitHub by removing those large data directories.

Next steps in CPoS development will be to download and study Bitcoinj which I will use as the adapter to communicate with bitcoind. Bitcoinj is written in Java and bitcoind, which I plan to leave mostly unchanged, is written in C++. Texai is written in Java.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 25, 2014, 06:23:27 PM
Today I removed the very large data repositories from GitHub as they were beyond the size guidelines of GitHub. I have them hosted at Mega instead.

I am now studying the source code of the Bitcoin Core. I am looking in particular at the -regtest option and how in conjunction with the setgenerate Command Line Interface option, the bitcoind program can be made to generate a block with a single hashing attempt. I plan to introduce a new option ...

Code:
-nopowafter=<n>    After block <n> generate and verify proofs of work with trivial difficulty

My plan for the CPoS nomadic mint agent is to slave a running instance of my modified bitcoind program to a supervising agent that runs in the separate local Texai Java process. The agent will configure the slaved bitcoind with the -nopowafter=317439, for example, and then command the bitcoind instance to generate a new block every ten minutes with the setgenerate 1 CLI command.

I had hoped to leave bitcoind completely untouched but the regtest option is tightly coupled to certain permissive testing behavior that I do not want for CPoS production.

Perhaps I can begin a hard fork of the Bitcoin blockchain for alpha testing September 1 GMT. I plan to open the network to the public when I have it migrated to at least one enterprise server, and have the software agents that proxy bitcoind completed. Note that I have not yet developed the tamper-evident logs that are the key network security feature of CPoS.

When open to the public for beta testing, I expect you to find your bitcoin holdings from before September 1 intact, once you configure a separate Bitcoin wallet to connect to certain IP addresses that I will provide.

Note that bitcoins on the CPoS network are an altcoin - they are not bitcoins on the main network.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 26, 2014, 04:02:04 AM
I have two bitcoind instances running in my lab and they tend to utilize excessive upload bandwidth even with one connected only to the other, and with each of them not listening for inbound connections.

On Ubuntu 14.04 LTS I installed trickle which performs network traffic.

Code:
$ cd <directory containing bitcoin-qt>
$ trickle -u 10 -d 20 ./bitcoin-qt -listen=0 -maxconnections=4

These settings allow me to receive updates to my local blockchain replica, while limiting the consumed bandwidth.

https://i.imgur.com/HdgO7SD.png



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 26, 2014, 07:45:43 PM
I completed the modifications to bitcoin core C++ code that allow a new command line option -nopowafter=<n>, where n is the blockchain height, i.e. the blocknumber, at the time of the fork.

My additions and changes can be inspected at my GitHub account for TexaiCognitiveArchitecture https://github.com/TexaiCognitiveArchitecture/bitcoin/tree/no-pow-mods (https://github.com/TexaiCognitiveArchitecture/bitcoin/tree/no-pow-mods) in the branch named no-pow-mods.

Next I need to operate bitcoin-qt in a debugging mode in my NetBeans IDE, i.e. C++ integrated development environment, and use bitcoin-cli to send setgenerate commands and see if the block gets created and that the block reward is subsequently present in the bitcoin-qt wallet with a new address.

https://i.imgur.com/P7WLNrq.png (http://imgur.com/P7WLNrq)


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 27, 2014, 01:45:38 PM
Information Security For Cloud Services - Article Snippets

Catastrophe in the cloud: What the AWS hacks mean for cloud providers (http://www.information-age.com/technology/cloud-and-virtualisation/123458406/catastrophe-cloud-what-aws-hacks-mean-cloud-providers)

Quote
Organisations must ensure they have the rudimentaries in place: role-based access control, two factor authentication, encrypted key stores, and remote, offline back-up.

There must be vigilance, with activity monitored and anomalies reported in line with the incident response plan, and regular security audits performed to ensure sufficient controls are in place.


The 2014 cyber security roadmap (http://www.information-age.com/technology/security/123457584/the-2014-cyber-security-roadmap#sthash.FPRIoTwV.dpuf)

Quote
... moving towards end-to-end automation of network changes should free up time to concentrate on monitoring all areas of the network.

Quote
Controlling the privileged user

Without a doubt, one of the biggest mistakes that organisations make is having insufficient control and oversight of the actions of ‘privileged users’, says Paul Ayers, VP EMEA of security firm Vormetric.

‘In 2014, after the Snowden leaks and other high-profile insider threats and data breaches, I expect organisations to increasingly put in place the security procedures and tools that allow them to audit and control the actions of these users,’ he comments.

Quote
With DDoS tools becoming more advanced and pervasive, Bains warns that all IT operations should work under the premise that they will be attacked, and so plan accordingly.

‘Every stack and layer within their purview should be reviewed, and they should identify cost-effective cloud solutions for their DDoS, which provide much better performance and mitigation than expensive hardware.’

Catherine Pearce, security consultant at mobile security firm Neohapsis, predicts that DDoS attackers will accelerate a move from simple volumetric attacks to those that take advantage of a site's specific performance, with the spread of tools that profile specific targets and attack based upon certain weaknesses in configuration or implementation.

Quote
‘Customers’ expectations for seamless trusted authentication and the continued dominance of smartphones and smart devices will accelerate the move from legacy hardware one-time password tokens to mobile-friendly, embedded security and contextual access controls,’ says SafeNet’s Jason Hart. ‘We can already see early examples such as Apple’s iTouch of biometric authentication, and investments by vendors such as Samsung to bake enterprise-grade security controls into their KNOX platform.’

Quote
Jason Hart of SafeNet reiterates that in the coming year we can expect to see companies move away from the traditional strategy of focusing on breach prevention, and towards a ‘secure breach’ approach.

‘This means accepting that breaches happen and using best practice data protection to guarantee that data is effectively useless when it falls into unauthorized hands,’ he says. ‘So, we can expect to see an increase in the use of encryption that renders any data useless to an unauthorized party.’


3 Critical Best Practices for Encryption Key Management on the IBM i (http://web.townsendsecurity.com/?Tag=Dual%20Control)

Quote
The top 3 critical best practices are:

Separation of Duties - This is widely known control set in place to prevent fraud and other mishandling of information. Separation of duties means that different people control different procedures so that no one person controls multiple procedures. When it comes to encryption key management, the person the person who manages encryption keys should not be the same person who has access to the encrypted data.

Dual Control - Dual control means that at least two or more people control a single process. In encryption key management, this means at least two people should be needed to authenticate the access of an encryption key, so that no one single person has access to an encryption key

Split Knowledge - Split knowledge prevents any one person from knowing the complete value of an encryption key or passcode. Two or more people should know parts of the value, and all must be present to create or re-create the encryption key or passcode. While split knowledge is not needed to create data encryption keys on the IBM i, it is needed for the generation of master keys which are needed to protect data encryption keys. Any encryption keys that are accessed or handled in the clear in any way should be protected using split knowledge.

The three core controls should always be used when storing or transferring encrypted sensitive data. A certified, hardened security module (HSM) designed to secure data encryption keys and key, or master, encryption keys should implement these controls into the administration of the key manager. NIST FIPS 140-2 validation is an important certification to look for in an encryption key manager. This certification ensures that your key manager has been tested against government standards and will stand up to scrutiny in the event of a breach.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 27, 2014, 02:19:09 PM
Young Genius vs Old Master

The New Yorker article (http://www.newyorker.com/magazine/2008/10/20/late-bloomers-2) from 2008 on late bloomers brought to my attention by HackerNews might, if one were generous, analogously apply to 63 year old me, substituting developer for painter/artist, project for painting ...

Quote
... But late bloomers, Galenson says, tend to work the other way around. Their approach is experimental. “Their goals are imprecise, so their procedure is tentative and incremental,” Galenson writes in “Old Masters and Young Geniuses,” and he goes on:

The imprecision of their goals means that these artists rarely feel they have succeeded, and their careers are consequently often dominated by the pursuit of a single objective. These artists repeat themselves, painting the same subject many times, and gradually changing its treatment in an experimental process of trial and error. Each work leads to the next, and none is generally privileged over others, so experimental painters rarely make specific preparatory sketches or plans for a painting. They consider the production of a painting as a process of searching, in which they aim to discover the image in the course of making it; they typically believe that learning is a more important goal than making finished paintings. Experimental artists build their skills gradually over the course of their careers, improving their work slowly over long periods. These artists are perfectionists and are typically plagued by frustration at their inability to achieve their goal.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 27, 2014, 03:34:59 PM
The Elevator Pitch For This Project

The system that I'm developing forks Bitcoin and other major PoW coins into separate networks, I avoid the Byzantine Generals problem by using authenticated cooperating agents rather than anonymous competing nodes. If distributed uncoordinated behavior is designed out of the system, then there is no need for distributed consensus.

I take a conventional high performing global financial network architecture, and adapt it to maximally preserve the Satoshi Social Contract, e.g. the user experience. My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees. How? Because a nomadic mint agent creates new blocks for a widely replicated, non-forking, canonical blockchain with trivial PoW effort. The block reward fees pay qualified full node operators to secure the distributed peer network using conventional data security methods, e.g. TLS/SSL, DDoS filtering, fail-over, digitally signed logs, network operations centers, security intrusion detection and mitigation, customer service, etc.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 27, 2014, 03:46:14 PM
Avoiding the Byzantine Generals problem *doesn't solve it*.

So apart from adding the terms TLS/SSL (that are meaningless in this context) what exactly are you offering as an improvement?

(so far - I don't get it)


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 27, 2014, 05:41:22 PM
Avoiding the Byzantine Generals problem *doesn't solve it*.

So apart from adding the terms TLS/SSL (that are meaningless in this context) what exactly are you offering as an improvement?

(so far - I don't get it)


Indeed, there no need to solve a problem that can be designed out of the system. From my whitepaper (https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE) ...

Quote
This system uses an attestable unforgeable log organization inspired by Nick Szabo. In particular, this system uses attested append-only memory as described by Chun et. al. [36] who provide mathematical arguments for is properties. It remains correct and keeps making progress even when half the replicas, e.g. blockchain replicas, are faulty. This is an improvement over previous Byzantine Fault Tolerant algorithms lacking a tamper-evident log, which allowed only one third faulty replicas

Note that Satoshi's Bitcoin is designed for frequent disagreement among full nodes as to which is the correct blockchain - because all miners are simultaneously attempting to create the next block. In a cooperative system, only one node creates the block according to a pre-arranged schedule. The other nodes verify the actions of the nomadic mint. Disagreement in this system is not designed in, rather it is the result of a fault or an attack.

The primary user improvement I offer is ...

Quote
My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Furthermore,  highly automated network operations management allows this system to react quickly in the face of attack or catastrophe. Customer service is provided to answer user's inquiries.  All of this is paid for by the block rewards at no additional cost to users - who pay 100x lower fees than the Satoshi system.

The Cooperative Bitcoin system is free or low cost to use because it is compatible, given a change in seed IP address, with all existing wallets and services. The source code and non-security-related data are open source and free to download and use. The system, e.g. existing operators, vet new operators according to system administration skills and compliance with the system-specified hardware and software. As block rewards grow in value with increasing adoption by users and subsequent rise in coin price, additional operators can be paid throughout the world. Volunteer full node operators can use the system software to act as blockchain archival nodes, as a last resort disaster recovery of the blockchain and in-flight transactions.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 27, 2014, 06:03:02 PM
How I Explain Cooperative Bitcoin Versus Satoshi's Bitcoin

Suppose, in some possible world, that the gathering of transactions, maintenance of the blockchain, and the hashing calculation is performed by humans with calculators in a Satoshi-style proof-of-work system. Bitcoin today is sort of like these humans working independently in unseen chest-high cubicles and when the solution is found the winning miner stands up and claims the reward.

But alternatively, in a single room, the humans could retain their anonymity by masks or other disguise and cooperate to create a new block with no effort by taking turns, round robin, in order to collect the reward on schedule every 10 minutes. Each cooperating miner would maintain their copy of the canonical blockchain for backup.

Intelligent agents permit efficient, verified, cooperative behavior.

Central to my hypothesis, is the notion that Bitcoin is valuable because some people think it is valuable, not because X effort was consumed to create X value in bitcoin.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 28, 2014, 04:50:26 AM
The primary user improvement I offer is ...

Quote
My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Thus your "primary user improvement" is achieved by adding in a "centralised" (and known to be *broken* CA) system - it seems to me that your idea isn't going to go down very well on this forum but best of luck with it anyway.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 02:23:03 PM
The primary user improvement I offer is ...

Quote
My technique permits instant, certain-to-be-in-the-blockchain transactions with 100x lower fees.

Transport Layer Security using X.509 certificates issued by the system's distributed Texai certificate authority credentials the system's paid full node operators. Each packet within the network is thus encrypted against tampering and tamper-evident logs at each full node permit remote attestation that allows peers to verify each other's good behavior. The trustless behavior of this system is provided by software agents whose algorithms are open source.

Thus your "primary user improvement" is achieved by adding in a "centralized" (and known to be *broken* CA) system - it seems to me that your idea isn't going to go down very well on this forum but best of luck with it anyway.


Would you care to elaborate on the X.509 certificate authority vulnerabilities you mention? For example, I use the Bouncy Castle Java libraries. The routes between super peers of the networks are not public knowledge, only the portal nodes have well known IP addresses.

Here is what Wikipedia has to say ... http://en.wikipedia.org/wiki/X.509#Problems_with_certificate_authorities (http://en.wikipedia.org/wiki/X.509#Problems_with_certificate_authorities).


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 28, 2014, 04:15:12 PM
There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 04:23:00 PM
There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).


Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 28, 2014, 04:31:28 PM
Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.

The issue is not "lost somehow" but "stolen/leaked somehow" - so the system can be "played" if those at the "top" decide to be corrupt (or are cheated).


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 05:47:20 PM
Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.
The issue is not "lost somehow" but "stolen/leaked somehow" - so the system can be "played" if those at the "top" decide to be corrupt (or are cheated).

I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

In contrast to Satoshi's Bitcoin, a cooperative system can use a portion of the block rewards to employ data security firms to perform periodic audits as does the payment card industry. I would have this system at least as secure as the existing payment systems.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 28, 2014, 05:50:26 PM
I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

It won't help - the corruption (or cheating) is not possible to stop with any system (that is why Bitcoin is what it is).

Basically you'd need another Bitcoin blockchain to stop any fault with your CA system which means you are back at square one.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 05:55:49 PM
I suppose then that the root certificate private key should be destroyed immediately after creating a sufficient number of intermediate certificates. The system treats the root certificate as it treats the blockchain. Each is widely replicated and tamper-evident by way of comparing the local copy with what all the other peers have. This notion is resistant to byzantine faults up to 50% invalid peers.

It won't help - the corruption (or cheating) is not possible to stop with any system (that is why Bitcoin is what it is).

Basically you'd need another Bitcoin blockchain to stop any fault with your CA system which means you are back at square one.


Not to quibble, but in my two decades of enterprise billing and payment system experience, I found that reasonable data security practices prevented loss of customer funds. I believe a public trial of cooperative Bitcoin will demonstrate its resistance to hacking - or not.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: CIYAM on August 28, 2014, 06:15:48 PM
Not to quibble, but in my two decades of enterprise billing and payment system experience, I found that reasonable data security practices prevented loss of customer funds. I believe a public trial of cooperative Bitcoin will demonstrate its resistance to hacking - or not.

Sure - you are asking for *trust* so I am just making sure that people are aware of that (if they want to trust your system then that is up to them).

I could mention about my own years of experience (in financial and other fields) but I think it is irrelevant to the discussion.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 07:45:10 PM
Sure - you are asking for *trust* so I am just making sure that people are aware of that (if they want to trust your system then that is up to them).

I claim my cooperative system is trustless in the sense that the source code is open source for inspection, and what few human agents, e.g. developers, network managers, etc., are subject to at least dual control.

The self-signed root X.509 certificate is public except for the private key. Even if the root private key were made public after the issuance of a fixed number of intermediate certificates, I do not see the vulnerability. TLS/SSL traffic is encoded by the end-user (software agent,  not bitcoin user) certificates. Outbound messages from a node are digitally signed using the assigned certificates held by software agent roles hosted by that node.

The chain of trust flows from the root certificate through the intermediate certificate to the end user certificate. The validating endpoint has its own copy of the root certificate which it obtained upon being on-boarded into the network. Sybil attacks, I believe, cannot be accomplished, because both endpoints know each other's certificates in a system in which persistent network connections are managed by distributed, redundant network operation centers.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 28, 2014, 11:32:59 PM
I completed modest modifications to Bitcoin Core that allow the mining of a new block with no effort. The source code branch is named no-pow-mods on my fork of the bitcoin repository at GitHub. My code is here (https://github.com/TexaiCognitiveArchitecture/bitcoin/tree/no-pow-mods).

The new bitcoin configuration option is added to .bitcoin/bitcoin.conf, where the parameter is the height of the blockchain at the moment of the fork...

Quote
. . .
# no proof-of-work after block
nopowafter=317661

The command on Linux to create a new block and then return is ...

Quote
$ bitcoin-cli setgenerate true

And here is the block reward added to my test wallet ...

https://i.imgur.com/iTdi0We.png

Next step is to write a simple Java software agent to send the generate command to the running bitcoin-qt instance every 10 minutes.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 29, 2014, 08:47:26 PM
Here is an organization chart design for the nodes within a particular server in the Texai cognitive architecture. Each node contains roles, which are the software agents that collectively perform the node's mission. Roles, in turn, have skills which are Java objects that provide perception and action behavior. Arrows depict the asynchronous task message passing from superior to subordinate roles. Likewise, perceptions, e.g status reports flow upwards from subordinate to superior.
https://i.imgur.com/q1AX6Nr.png
Each node has the following essential roles ...
  • GovernanceRole
  • HeartbeatRole
  • NodeLifeCycleRole
  • NodeLoggerRole

The TopFriendshipNode is the topmost node in this hierarchical control network. It's mission is governance, moreover ensuring that the system is friendly.

The NetworkConfigurationNode contains the NetworkConfigurationRole which performs the node's mission of scheduling the nomadic software agents such as the MintRole.

The NetworkOperationsNode contains the NetworkConfigurationRole which performs the node's mission of network operations management. It contains the BootstrapRole which has the skills to on-board a new server into the Texai network. It contains the RecoveryManagementRole which supervises recovery from a fault. It contains the SoftwareProvisioningManagementRole which supervises software provisioning, e.g. version upgrades.

Cryptocoin operation nodes may contain the following roles ...
  • CoinSeedRole - Uses the Texai encrypted torrent library to seed new servers with the cryptocoin's blockchain
  • BlockchainArchiveRole - replicates the canonical blockchain with new blocks created by the nomadic mint agent
  • MintRole - The nomadic cryptocoin minting agent
  • RewardAllocationRole - The nomadic cryptocoin block reward allocation agent
  • FinancialAccountingAndControlRole - The nomadic agent which balances the blockchain against processed transactions, and provides traffic statistics to network operations
  • PrimaryAuditRole - the nomadic agent which has primary responsibility for verifying the behavior of the MintRole and RewardAllocationRole
  • SecondaryAuditRole - has secondary audit responsibility
  • SoftwareProvisioningRole - performs software provisioning for a particular cryptocoin's Docker container
  • RecoveryRole - has the responsibility for a particular cryptocoin's recovery from a fault
  • CoinPortalRole - has the responsibility of public communication with a cyptocoin's native protocol to client wallets and transaction processors.
The TorRelayNode contains the TorRelayRole which has the simple skill of running a Tor relay instance that encrypts and obfuscates network traffic for those cryptocoin clients that wish additional anonymity by using Tor.



Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on August 29, 2014, 09:41:20 PM
Here is an illustration of how a server in the Texai network will be configured with Docker containers that provide isolation between cryptocoin daemons, e.g. bitcoind, and the Texai software agents that control them ...

https://i.imgur.com/b3VTUCE.png


Title: Re: TexaiCoin
Post by: SlipperySlope on August 30, 2014, 08:00:13 PM
TexaiCoin

After completing the minimal required changes to my fork of the Bitcoin Core code for creating new blocks with trivial effort, I have been reflecting on how best to demonstrate the technology. Today I am re-branding this thread accordingly as TexaiCoin.

Note that the May 2013 whitepaper (https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE) describes a hard fork of bitcoin. That cannot possibly happen unless Coopcoin 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 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.

I would like to demonstrate TexaiCoin at the Hashers United Conference in early October. It will not then have all the features needed for a public release but I can say that when released, TexaiCoin will have the same parameters as Bitcoin and will launch with a genesis block and no premine. This coin is to be marketed as a cryptocurrency especially suited for microtransactions and immediate acknowledgement that the accepted transactions will appear in the next block.



Title: Re: TexaiCoin
Post by: SlipperySlope on August 30, 2014, 08:04:10 PM
TexaiCoin is designed to run within a Docker container on the Linux operating system. If you want to run this but have only Windows or a Mac, then the VirtualBox software environment can be installed to allow Linux to run on your computer.

https://i.imgur.com/XSNHObt.png


Title: Re: TexaiCoin
Post by: SlipperySlope on August 30, 2014, 08:54:05 PM
This diagram supersedes the one posted earlier. Note that I do not plan to fork any existing proof-of-work coins, rather I am demonstrating an alternative approach that I hope will one day be adopted by Bitcoin, Litecoin, Dogecoin, Namecoin ect. developers.

https://i.imgur.com/O5ko61c.png


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: flipperfish on September 04, 2014, 09:38:32 AM
There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).


Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.

How do you plan to detect bad nodes?


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on September 04, 2014, 03:49:31 PM
There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).


Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.

How do you plan to detect bad nodes?

Peer agents perform remote attestation of each other's behavior. Tamper-evident logs record context, inputs, actions, and outputs, which when replayed by a validating peer, confirm good behavior or detect bad behavior, e.g. a byzantine fault. The research that I referenced in the May whitepaper for this technique gives the math proving overall good behavior with up to 50% of the nodes faulty. In contrast, Satoshi's Bitcoin can be corrupted by a single mining node with 51% of the network hashing power.

In addition to remote attestation of peer behavior, TexaiCoin will include a distributed network operations center equipped with a suite of open source information security tools that will detect intrusion and unauthorized changes to the host operating system and the Docker containers in which TexaiCoin full nodes execute. As funding from block reward permits, TexaiCoin network portals, that connect to wallets and external processors, will be protected against DDoS attacks by a traffic filtering service.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: CIYAM on September 04, 2014, 04:01:35 PM
Again - you trust the CA system which has been *proven* to be flawed.

We just have to somehow *trust you*?

Let's see your papers and how they are reviewed before you ask for any funds please.

BTW - this:

-   Does not permit double-spending, whereas Satoshi's Bitcoin sometimes does.

is *wrong* (if you want to be taken seriously then I'd suggest that you remove it).


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 04, 2014, 04:44:09 PM
Again - you trust the CA system which has been *proven* to be flawed.

We just have to somehow *trust you*?

Let's see your papers and how they are reviewed before you ask for any funds please.

BTW - this:

-   Does not permit double-spending, whereas Satoshi's Bitcoin sometimes does.

is *wrong* (if you want to be taken seriously then I'd suggest that you remove it).


Respectfully, I ask you to elaborate a bit on both your points.

I use the X.509 v3 certificate generation facilities provided by the well known Bouncy Castle Java library. I use the optional high encryption strength encryption policy settings provided by Oracle java. I use a self-signed root certificate that each node receives, and do not check for revocation when verifying certificate paths because in my system the certificate serves to digitally sign messages, to encrypt traffic, and to identify the full node. The subject item in the certificate is a UUID, not a real name to preserve the anonymity of the node's owner yet retain identity to preclude Sybil attacks.

Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Code:
-rpcssl                                  Use OpenSSL (https) for JSON-RPC connections
 -rpcsslcertificatechainfile=<file.cert>  Server certificate file (default: server.cert)
 -rpcsslprivatekeyfile=<file.pem>         Server private key (default: server.pem)
 -rpcsslciphers=<ciphers>                 Acceptable ciphers (default: TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH)

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Regrading the peer review of my May 2013, whitepaper (http://arxiv.org/abs/1405.5741), the Bitcoin developers that I have contacted prefer to see working code and the test suite. All are skeptical that my cooperative ideas solve the distributed consensus problem.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: CIYAM on September 04, 2014, 04:48:56 PM
Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Bitcoin does not use X.509 for anything important (it was added for merchants and has nothing to do with the core operations).

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Your statement about "sometimes allowing double-spends" is *completely false* - please show me 1 example of a *double spend* in the Bitcoin blockchain to back up your claim (and yes I know *you can't because there is no such thing*).


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 04, 2014, 05:10:20 PM
Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.

Bitcoin does not use X.509 for anything important (it was added for merchants and has nothing to do with the core operations).

Might I beg some more clarification on the X.509 attack surface given the details I provided?

Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Your statement about "sometimes allowing double-spends" is *completely false* - please show me 1 example of a *double spend* in the Bitcoin blockchain to back up your claim (and yes I know *you can't because there is no such thing*).


Thanks for your clarification. I will amend my claim accordingly to "double-spending fraud attacks, e.g. BitUndo".

Double-spending (https://en.bitcoin.it/wiki/Double-spending)
Quote
Bitcoin has some exposure to fraudulent double-spending when a transaction is first made, with less and less risk as a transaction gains confirmations.

Here is the well known example of the Finney attack which is based upon double spending. To be clear, what I mean by double spending is the issuance of two or more bitcoin transactions such that at the time of issuance each receiver believes the transaction to be good, yet because the longest blockchain will only contain one copy of the transaction, there is the opportunity for fraud. The appearance of this service caused a great deal of consternation on the Bitcoin core developers mail list ...

BitUndo (http://www.bitundo.com/)

Quote
Contrary to popular belief, your mistakes might not be forever. Until a transaction appears in the blockchain (aka is confirmed) no demonstrable work has been done, or needs to be undone in order to change it. Bitundo incentivizes miners to undo your mistake transaction, by including a transaction that would conflict with it (aka having a conflicting input).





Title: Re: TexaiCoin Pre-Release Development Diary
Post by: CIYAM on September 04, 2014, 05:17:28 PM
As I have stated the CA system is *flawed* because of *trust* (just search for "ca certificates hacked") to get a start (do I really need to post the links?).

The Finney attack is nothing new and so I don't see why it is relevant especially as you have shown no way to avoid it (apart from relying upon the CA system which is flawed).


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 04, 2014, 07:06:58 PM
As I have stated the CA system is *flawed* because of *trust* (just search for "ca certificates hacked") to get a start (do I really need to post the links?).

Thanks for the search tip. You are awesome CIYAM!

I spent the last 50 minutes watching an informative video on certificate man-in-the-middle attacks that linked in the OP. Fortunately, I can use SSLSniff to attack the network and trace the certificate validation through the Bouncy Castle source code to ensure that this particular attack vector is closed. I already set the X.509 Basic Constraints properly for the root, intermediate and end-user certificates. An additional hurdle for an attacker is that my system has client as well as server certificates, which I will test with the SSLSniff tool. I searched the Docker registry for a container with this already built, but it should be easy given these instructions (http://www.thoughtcrime.org/software/sslsniff/).

SSLSniff works on a LAN, e.g. public WiFi network. This design somewhat protected by virtue of white-listed IP addresses for known full nodes.

I suppose the best defense against man-in-the-middle attacks is to use the same techniques as does the bitcoin protocol in which transaction messages are signed by the sender with their private key. I can modify the expected node heartbeat messages to include a signed hash of the inbound and outbound traffic which a network operations agent can check for omitted or extraneous messages performed by a man-in-the-middle attacker.

A goal now is to accumulate a suite of attack tools such as SSLSniff, Metasploit, etc., and record TexaiCoin responses to those attacks to back up my claim that a cooperative coin network is as secure , if not more secure, than Satoshi's Bitcoin.




Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: flipperfish on September 05, 2014, 09:52:47 AM
There have already been documented cases of private keys being compromised (not sure if that led to the shutting down of any CA but it might have).

The fundamental problem is that CA is *not decentralised* therefore it is a weakness and not something that can possibly *improve* the idea of Bitcoin (in terms of the Byzantine Generals problem and its solution).


Ok. In this system each full node has a copy of the root certificate. The distributed certificate servers use an intermediate X.509 certificate. Validation by TLS/SSL endpoints at the full nodes perform validation of the chain from root --> intermediate --> end-user, which is a software agent role.

Suppose the root key is lost somehow. The chain validation still works. The software does not check for certificate revocation. Bad nodes are simply banned.

How do you plan to detect bad nodes?

Peer agents perform remote attestation of each other's behavior. Tamper-evident logs record context, inputs, actions, and outputs, which when replayed by a validating peer, confirm good behavior or detect bad behavior, e.g. a byzantine fault.

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.


The research that I referenced in the May whitepaper for this technique gives the math proving overall good behavior with up to 50% of the nodes faulty. In contrast, Satoshi's Bitcoin can be corrupted by a single mining node with 51% of the network hashing power.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: SlipperySlope on September 11, 2014, 08:23:49 PM
Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ (http://trousers.sourceforge.net/faq.html)

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

The Texai system works as you describe it as each node has an X.509 certificate. The system has a self-signed root certificate and is its own certificate authority. De-centralized Intermediate certificates are used to create the end-entity certificates for the nodes/roles. These intermediate certificates are widely distributed in the system. Each node has a copy of the root certificate, but not its private key.


Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

When generating x509 version 3 certificates I use RSA with a key length of 3072 bits and SHA256 with RSA as the signature algorithm. This works on Java 1.8 with the high encryption strength policy enabled, and also works to encrypt websocket traffic to Android and IOS clients. As certificate validation is entirely in my control, e.g at both endpoints of a TLS version 1.2 connection and with all the entries of the certificate available, I believe that the Texai network is resistant to Sybil attacks.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 12, 2014, 09:22:27 PM
I am working on the minimal set of Texai software agents that will operate a bitcoind instance on my Ubuntu laptop for hallway demonstration at the Hashers United Conference to be held in Las Vegas in October.

Meanwhile, I learned about the Raft distributed consensus algorithm that provides an off-the-shelf solution to how to robustly select the mint agent from among the set of candidate peers. There is an implementation in Java at GitHub that I linked in the OP. And here is an animated illustration of the algorithm as prepared by Ben Johnson ...

http://thesecretlivesofdata.com/raft/ (http://thesecretlivesofdata.com/raft/)

This algorithm is robust against failing nodes and partitioned networks, but not against byzantime, e.g. malicious peers. I will handle the latter using Nick Szabo's method of remote attestation of peer behavior by inspecting their respective tamper-evident log files.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: prophetx on September 14, 2014, 04:12:47 AM
interesting  ;D


Title: Re: [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake - CPoS
Post by: flipperfish on September 14, 2014, 12:17:52 PM
Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ (http://trousers.sourceforge.net/faq.html)

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?


What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: mr_random on September 14, 2014, 01:12:51 PM
Nice selection of links in the OP! Bookmarked!


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 14, 2014, 04:00:47 PM
Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ (http://trousers.sourceforge.net/faq.html)

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?


Here is the link to the academic reference used in my white paper: Remote Attestation on Program Execution  (http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf). Essentially, the idea is to embed digital signatures of the log's hash to that point by attesting remote peers into a given peer's own log. The researchers call this technique entanglement, but I understood it more readily as peer-notarized logs that prove whether or not a particular log has been tampered with.

What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?

As a result of my rewarding conversation with CIYAM above, I recently decided to have each node operator be their own certificate authority. My scheme does not rely on a chain of trust from a central certificate authority, indeed I want to preserve that part of the Satoshi Social Contract which says there are no trusted third parties in Bitcoin. I need X.509 certificates to identify a peer solely by their published public key, and to encrypt traffic between nodes via TLS 1.2.  I do not need a chain of trust to tie a real name and address to the system nor to the certificate holder.

There is a security concept called Trust On First Use (TOFU), which allows peers to record received self-signed certificates and trust them from that point forward. That is a relatively weak method which I plan to eventually augment by providing an easy to use method of emailing peer self-signed certificates from the peer to an archiving Texai software agent before first use. To identify a peer in the Texai network, I would  use the certificate, which cannot be forged due to the public/private key math, together with the IP address of the peer and to use encrypted email for out-of-band communication with the peer. For example a peer operator should receive a periodic digitally signed email from the system detailing their fair share of the  mining reward paid to their supplied address. This manual oversight by the operator precludes man-in-the-middle attacks that would divert the reward to another address.

Sybil attacks may occur in Satoshi's Bitcoin . . .

Weaknesses (https://en.bitcoin.it/wiki/Weaknesses)

Quote
Sybil attack
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the second one.

Full nodes in Satoshi's bitcoin identify themselves only by IP address. In the Texai network, that weak identity is strongly augmented by X.509 certificates. Software agents keep track of the uptime and verified good behavior of the network nodes.

Satoshi's proof-of-work method makes it hard for an attacker to obtain 51% of the hashing power to attack the network. I plan for the occasional voting among Texai peers to be weighted according to respective peer stakes and each such vote shall be paid for by the system in proportion to the stake. Thus an attacker would have to obtain 51% of the aggregate stake, which has been proven to be more expensive for the attacker than obtaining 51% of the hashing power in a proof-of-work coin. To my knowledge, no proof-of-stake coin has been compromised in a 51% attack, in comparison ...

List of Historical 51% Attacks on Altcoins (https://bitcointalk.org/index.php?topic=332584.0)




Title: Re: TexaiCoin Pre-Release Development Diary
Post by: hbadger on September 21, 2014, 01:44:40 AM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on September 21, 2014, 02:16:41 AM
[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 21, 2014, 04:58:28 AM
[Lurker decloak]
This thread has reached the point where it could use an injection of keyless signature infrastructure, as invented by Ahto Buldas of Guardtime (I am not associated with them):

http://en.wikipedia.org/wiki/Linked_timestamping

Some forms of global coordination, such as a stochastic cooperative signal that is widely observable, are compatible with decentralized paranoia.  Just ask neurons and ants.

Perhaps Mr. Reed might reconsider his resignation to PKI and central servers with this information.
[/Decloak]

Thanks for the help, Scumby!

I wanted to offer a document timestamping API which would not necessarily be evidence in a court of law but would provide a distributed, robust service implemented with micropayments. This is an excellent implementation suggestion for this skill, which is required by the nomadic mint which timestamps incoming transactions. I would then be easy to expose this skill as a money-making microservice API. Apparently the Bouncy Castle cryptography library I use has a time stamp protocol server that I will evaluate.

Keyless Signature Infrastructure is interesting. I understand Merkle trees and this is similar. I will stay with self-signed X.509 certificates for identification, digital signatures for messages, and message channel encryption.



Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on September 21, 2014, 04:21:59 PM
I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

******

I think of KSI as envisioned above as a skip list of Merkle trees, with the skip list built around hashing that is one-way not only in calculation, but also in time.  It does this in a way that is far more bandwidth-efficient than replicating massive blockchains around like Bitcoin.  Guardtime markets this to governments as a way of signing documents and Linux OS log entries with keys that can't be tampered with, in order to defeat future Edward Snowdens from modifying system logs.  I think this same concept could be used for ledger integrity for micropayments as you note, or just about any kind of ledger for that matter.

The implementation envisions a newspaper or central service that would broadcast a top level hash, and providing this service (or enabling a central government agency to provide it, as is done in Estonia) is how Guardtime thinks it will make money.  A nomadic mint performing this function would seem to be preferable to a fixed commercial or government source. 

What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting). 


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 21, 2014, 08:56:32 PM
I have only a basic understanding of Bitcoin's internals, so if there is nonsense here due to my own ignorance I apologize.  I think you are doing a tour-de-force job of assimilating a wide cross-disciplinary breadth of ideas here, but I am concerned that the TexAI/Cyc ontology stuff is so alien to most developers that it could torpedo your adoption if you make it too front-and-center.  The AI integration into the CPOS "stew" feels a bit forced; it's evidently a treasured ingredient in your own intellectual "refrigerator" and provides you continuity with your AI work, but you're going to have a hard enough time getting mindshare without having to also persuade engineers that symbolic programming with ontologies is worthwhile for cryptocurrencies.  My .02.

Indeed.

For reason you mention, I have stripped out the work-in-progress, natural language dialog and face-recognition aspects of Texai from the code that I am committing to GitHub for TexaiCoin. When I talk with coin developers at the Hasher's United conference in Las Vegas next month, I will be talking about a multi-agent software system which can cooperate to mine coins with no effort and still be as secure as Bitcoin.

My approach to artificial general intelligence is to follow Alan Turing's advice back in 1950, which is to create a system capable of being taught skills and then to teach it. My implementation uses the robotic-inspired architecture described by James Albus, in which his hierarchical control network of software agents has been elaborated by me to model a human organization. For TexaiCoin, I have 27 simple agents which cooperate and will check each other to operate an altcoin network with no trusted third parties.

I could have implemented these agents for TexaiCoin using any one of several agent frameworks, but it was the security aspects that motivated me to repurpose my existing AI code. Concerned about the need to ensure Friendly AI in a distributed network operated by anyone downloading the code, I designed the AI code years ago to be secure against intruders and hackers. I incorporated X.509 certificates for that purpose. Currently, I plan to use tamper-evident logs and remote attestation to strengthen Texai against attackers.

I will be able to market TexaiCoin as having genuine artificial intelligence, thus helping this altcoin and its innovations to be distinguished from other thousand-plus altcoins. I do not plan to say much initially about the OpenCyc knowledge base that is part of each deployed container.

TexaiCoin ideally will become a platform upon which third-party developers can add vetted skilled agents, and receive payment in TexaiCoin for the benefits gained by the collective infrastructure, or from the proceeds of services for sale, e.g. an API. I will start with the document timestamp service as a demonstration.

I will add a high level goal to the system to pursue self-improvement, e.g. to increase revenue and coin value via tasks performed by paid developers. Humans will be able to perform tasks specified in the same manner as for software agents, but with a secure web form or secure email as the communication channel. I think that the system paying one person to perform the task, and paying two non-affiliated others to check the work should be safe.





Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 21, 2014, 09:21:26 PM
What has not been explored AFAIK, is what if the nomadic mint's KSI calculation had a publicly visible component that could be cross-checked by any client?  I.e. if the hash function had to mix in a widely observable source of chaos, such as the S&P 500 index closing price or solar flux index.  People might relax about cooperation if the public could "trust, but verify" the calculations of the population of nomadic mints subject to attack by a powerful adversary.  KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  


Scumby,

What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.

Quote
KSI + chaos could be immutable in the past (cannot reconstruct a historical hash with KSI) and the future (chaotic processes are immune to time series forecasting).  

This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain. I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Even if not, your mentioning of a public chaos value is a good idea for convincing observers that the blockchain was not constructed prior to the timestamp associated with the public chaos value. I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on September 22, 2014, 03:06:31 AM
Let's go back to Satoshi's original paper (https://bitcoin.org/bitcoin.pdf):

Quote from: Satoshi
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

You have already shown Satoshi's counterfactual assumptions here were wrong.  You have solved the problem of a central company controlling the mint with your nomadic mint.  The payee gets proof by cooperating in electing a dynamic superpeer hierarchy and trusting it to prevent double-spend, without seeing every transaction.  Instead of mining independently, the nodes can cross-check the calculations of their superpeer and shoot him if a majority discover he's a turncoat.  The superpeer can in turn try to identify bad nodes to be shunned by the network, and broadcasts intermediate signature hashes for consumption by end nodes.  Superpeers could be spontaneously elected for a term of office.  You are inspired by what mining pools are already doing in practice, but now are incorporating it into a self-organizing cooperative system.  Cool stuff!

Quote from: satoshi
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

We now know that one-CPU-one-vote didn't work out too well once ASICs got into the action.  CPOS solves the majority decision making representation problem by spontaneous election of trusted nodes/mints, and then all the other nodes watch them for misbehavior.  The superpeers, in turn, need to watch out for Sybil attacks and rally honest nodes against them.  This is a more biologically-supported approach than Santoshi's competitive gold mining, if you think about it (think bees and neurons).

Quote from: SlipperySlope
What you say is very interesting. Satoshi designed the current Bitcoin proof-of-work system to prevent an adversary from presenting a forged blockchain as legitimate. My approach makes that difficult by having only one canonical version of the blockchain, in which the current hash is widely known, in which participants are identified by certificates, and in which misbehavior is detected by verifying peers.
...
This is a desirable property for the blockchain or agent logs. I want to understand the circumstances allowing an adversary to forge such a blockchain.

I seem to comprehend how a KSI + chaos blockchain could be tamper-evident, but the forgery attack is one in which the adversary replays transactions from some point in the history, with some change in their own favor, recalculating the merkle trees and block hashes at each step. The forged block chain is thus internally consistent with no evidence of tampering unless compared with the final block hash of the legitimate blockchain.

Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

Quote from: Satoshi
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

Quote
I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 22, 2014, 03:47:32 AM
Quote from: SlipperySlope
Does KSI as you understand it somehow make replaying of the blockchain building process impossible - as I described that process above?

Here's what Satoshi says:

Quote from: Satoshi
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

The cryptographic proof-of-work blockchain approach used in Bitcoin inherently suffers from replayability and being determinate, which Satoshi solved by starting a computing arms race chasing an exponential function.  POS has the same weaknesses from what I can tell.  In KSI, the blockchain is one-way in time, and cannot be replayed by an adversary, because the complete ledger is not visible to all nodes.  That's a feature, originally designed to enforce a centralized signature upon a single node's transaction, for integrity purposes.  There is a hierarchical summarization by special nodes (like CPOS superpeers and nomadic mints) that broadcast digest hashes, which each end node has to sign onto its own transactions.  Superpeers can be nomadic and elected (that would be an extension of KSI), and are responsible for supervising the nodes within their hash space and time.  The system is still dependent upon 51% honest nodes.

By adding a chaotic parameter into the blockchain hash, I think it would be harder to "surpass the work of honest nodes" in Satoshi's parlance, because it would increase the dimensionality of the precalculation necessary, and hopefully make it harder to design an ASIC around.

Quote
I could use the daily radio flux at 10.7 cm as reported by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center, or can anyone suggest something published and archived by a more international source?

My own research indicates that the DRAO at Penticton, BC Canada is the gold standard for 10.7 cm flux, and has been tracking it since the 1950s.  You could define the chaos broadcast as an average of several world observatories.  I think it would be neato if the nomadic mint published the summary Merkle hash, the solar flux value that can be cross-checked, and the resulting hash value.  Not even the NSA can control the Sun.  I don't know how much additional security solar chaos really adds, but it just feels good, doesn't it?

Thanks Scumby for your articulate understanding of my work.

I examined the DRAO website and have written a message to their webmaster asking about why the displayed solar flux index is months old instead of current. Another potential micro-revenue service for TexaiCoin would be to wrap an API around the daily solar flux measurement and its recent archived values.

I am constrained to keep the blockchain structure unchanged so as to maximise the opportunity that my changes will someday be incorporated into Bitcoin Core. But that does not keep me from creating a parallel data structure as you describe for KSI, which I now somewhat comprehend because of your explanation. The blockchain must remain a public ledger in its entirety, but I can envision a KSI process as you describe to irreversibly record blockchain hashes at each new block.

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees (http://eprint.iacr.org/2013/834.pdf)

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?

I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on September 22, 2014, 02:45:10 PM

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees (http://eprint.iacr.org/2013/834.pdf)

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?
I think in this scheme, the issue is that the 51% adversary could rig the elections of superpeers.  It's no longer about protecting the historical blockchain from rewriting.  Buldas essentially encodes time into the blockchain in a way that he says is provably resistant to backdating *and* independently verifiable by third parties that do not have access to the full ledger.  For the application he had in mind (signing every syslog entry of every Linux machine in the world) it would have been impractical to distribute every single transaction around.  Here is the summary in the paper you linked to:

Quote from: Ahto Buldas
Underlying data structures guarantee that it is not possible to issue fake, backdated or otherwise mis- leading signature tokens—even where rogue client and rogue service provider collaborate. Committing into globally unique and public Hash Calendar makes tampering with the system, especially with the clock value, highly visible to all users. The system security does not depend on the long-term secrecy of the private keys as it is not possible to prove that the keys were not actually leaked. Underlying cryptographic primitives may be easily changed, e.g. in case of apparent weakening of the algorithms. There may be occassions when the infrastructure must be stopped—if the system integrity or clock accuracy is in doubt. The signature token itself is independently verifiable by third parties using only public information and algorithms; verification must be possible even after the service provider ceases the operations.
In order to provide highly available service single points of failure are eliminated. The requirements on system reliability are different: a globally unique core cluster must be operated by the best trust authority practices, but the service delivery network may use commodity virtual servers without much requirements on operating environment, like a reliable “wall clock” or persistent storage. Privacy and confidentiality risks are minimal, because the infrastructure handles only aggregate hashes.

I'm rejecting Buldas' statement in bold, which  I believe to be motivated by his commercial ambitions, and substituting your nomadic mint.

Quote from: SlipperySlope
I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.

It may not have been clear that I was rejecting a central newspaper authority like Buldas designed and Satoshi rejected, and glomming onto your nomadic mint to publish the public top-level hash automatically.  Term limits!

*********

Re: Bitcoin Core, I think where this could lead is partitioning the cryptocoin hash space amongst superpeer-led mining pools, and federating/mixing their respective blockchains up the hierarchy.  That would encourage people to start mining pools instead of scamcoins and scamexchanges.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Brangdon on September 23, 2014, 07:07:11 PM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).
Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: hbadger on September 23, 2014, 07:13:14 PM
To my knowledge, no proof-of-stake coin has been compromised in a 51% attack

Peercoin has been successfully attacked. The reason these PoS coins are still up and running today is because they either use checkpoints (which makes them 100% centralized and pointless, which is the case of Peercoin), or they are continually making changes which makes attacking them annoying or hard, but is just another form of centralization (they depend on the continuous updates that everyone must accept blindly, as opposed to a stable protocol that rarely changes. Someone compared this to the whack-a-mole game).
Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.

So you have already forgotten that one time when a hacker stole 5% of all the coins, and with that, 5% of all the hashing power?

And I don't see what's so "implausible" about buying half of the coins when the market cap is so small. Did you know that you don't even need to own the coins to perform the attack? You just need to have owned them at some point, and begin your forks there. With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete. With PoS that cost doesn't exist. The attacker can sell all his coins and then start the attack.

See what Gregory Maxwell (nullc) thinks about PoS:

https://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek8epc?context=2

https://news.ycombinator.com/item?id=6798997


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Brangdon on September 23, 2014, 08:37:09 PM
Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.

So you have already forgotten that one time when a hacker stole 5% of all the coins, and with that, 5% of all the hashing power?
A hack of an exchange is not a 51% attack. 5% is not enough coin to mount an attack. The hack had no effect on block-chain security; the hacker couldn't do anything that Bter couldn't have done.

Quote
And I don't see what's so "implausible" about buying half of the coins when the market cap is so small.
If you try to buy so many, the price will rise. If you succeed, you will find you are attacking yourself.

Quote
Did you know that you don't even need to own the coins to perform the attack? You just need to have owned them at some point, and begin your forks there.
You have to have owned them within the last 12 hours or so, because although Nxt doesn't have checkpoints, it does disallow block-chain reorganisations past 720 blocks. This means to do what you suggest you have to acquire 51% of Nxt and then sell them all off within 12 hours. Dumping in such volume would crash the price, and you'd lose a lot of money.

Quote
With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete.
The mining gear can be used for other PoW coins that use the same ASICs.

Quote
See what Gregory Maxwell (nullc) thinks about PoS:
He's talking about Peercoin. It's a different algorithm. His comments don't apply to Nxt.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: hbadger on September 23, 2014, 09:34:11 PM
Nxt doesn't use checkpoints. Although it adds features fairly often, its core model doesn't change often and new features don't make it harder to attack. Even if they did, I don't see how that would affect mounting a 51% attack. Getting to control 51% of Nxt would be implausibly difficult because of the difficulty in acquiring that many coins.

So you have already forgotten that one time when a hacker stole 5% of all the coins, and with that, 5% of all the hashing power?
A hack of an exchange is not a 51% attack. 5% is not enough coin to mount an attack. The hack had no effect on block-chain security; the hacker couldn't do anything that Bter couldn't have done.

Quote
And I don't see what's so "implausible" about buying half of the coins when the market cap is so small.
If you try to buy so many, the price will rise. If you succeed, you will find you are attacking yourself.

Quote
Did you know that you don't even need to own the coins to perform the attack? You just need to have owned them at some point, and begin your forks there.
You have to have owned them within the last 12 hours or so, because although Nxt doesn't have checkpoints, it does disallow block-chain reorganisations past 720 blocks. This means to do what you suggest you have to acquire 51% of Nxt and then sell them all off within 12 hours. Dumping in such volume would crash the price, and you'd lose a lot of money.

Quote
With PoW at least the attacker will have trouble recovering the costs of his mining gear which will become obsolete.
The mining gear can be used for other PoW coins that use the same ASICs.

Quote
See what Gregory Maxwell (nullc) thinks about PoS:
He's talking about Peercoin. It's a different algorithm. His comments don't apply to Nxt.

No, he's talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 23, 2014, 10:21:31 PM
[Gregory Maxwell] talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.

I briefly chatted with Gregory Maxwell on #bitcoin-wizards last spring as I was publishing my whitepaper on Bitcoin Cooperative Proof-of-Stake (http://arxiv.org/abs/1405.5741). Certainly the Bitcoin core developers are skeptical that anything other than proof-of-work can solve the distributed consensus problem. He graciously wished me well with regard to my approach, and I believe that the core developers, e.g. those chatting in #bitcoin-wizards IRC channel, will have more pointed questions and comments when this project's working code is deployed into production, vs commenting on a whitepaper.

Satoshi designed bitcoin, I think, by adapting a napster style peer-to-peer network, e.g. omitting the central index server, to support an anonymous digital currency. His envisioned users were also operators who mined bitcoins using their laptops, from residential internet connections, while joining and leaving the network at will. This is the context of how core developers view distributed consensus.

In contrast, this design fits the Satoshi Social Contract into a conventional distributed enterprise-style financial network, e.g. omitting central control. Its envisioned users are wallet owners and payment processors. Its envisioned operators are non-affiliated paid system administrators who securely provision identical software containers on bare metal dedicated servers in geographically disparate datacenters. The system is innovatively managed by peer-verified software agents having no single point of failure. The nomadic mint agent builds a canonical non-forking blockchain, which is widely copied, and allows immediate transaction processing without confirmations.

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint. Rather he was interested in the vulnerabilities my scheme might have with regard to attacks and network faults in which the system must come to agreement on the correct or optimal version of system state, e.g. who gets to be the mint, and what happens if there are forged blockchains. That is why this project needs to reach production for such fault scenarios to be designed, tested and reported.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: hbadger on September 23, 2014, 11:00:19 PM
[Gregory Maxwell] talking about PoS too. If you have any doubts go ask him yourself. He's always in the #bitcoin-wizards IRC channel. PoS is not considered a viable alternative to PoW yet. There will have to be another breakthrough to make it workable.

I briefly chatted with Gregory Maxwell on #bitcoin-wizards last spring as I was publishing my whitepaper on Bitcoin Cooperative Proof-of-Stake (http://arxiv.org/abs/1405.5741). Certainly the Bitcoin core developers are skeptical that anything other than proof-of-work can solve the distributed consensus problem. He graciously wished me well with regard to my approach, and I believe that the core developers, e.g. those chatting in #bitcoin-wizards IRC channel, will have more pointed questions and comments when this project's working code is deployed into production, vs commenting on a whitepaper.

Satoshi designed bitcoin, I think, by adapting a napster style peer-to-peer network, e.g. omitting the central index server, to support an anonymous digital currency. His envisioned users were also operators who mined bitcoins using their laptops, from residential internet connections, while joining and leaving the network at will. This is the context of how core developers view distributed consensus.

In contrast, this design fits the Satoshi Social Contract into a conventional distributed enterprise-style financial network, e.g. omitting central control. Its envisioned users are wallet owners and payment processors. Its envisioned operators are non-affiliated paid system administrators who securely provision identical software containers on bare metal dedicated servers in geographically disparate datacenters. The system is innovatively managed by peer-verified software agents having no single point of failure. The nomadic mint agent builds a canonical non-forking blockchain, which is widely copied, and allows immediate transaction processing without confirmations.

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint. Rather he was interested in the vulnerabilities my scheme might have with regard to attacks and network faults in which the system must come to agreement on the correct or optimal version of system state, e.g. who gets to be the mint, and what happens if there are forged blockchains. That is why this project needs to reach production for such fault scenarios to be designed, tested and reported.


I agree and have high expectations for what you are doing. You seem to know your crypto and at the same time you are one of the few who actually uses professional development techniques.

I was just pointing out a few false statements that I have seen here, like "Peercoin has never been attacked", "Nxt is [cryptographically] secure", "Gregory Maxwell was only talking about Peercoin", etc.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on September 23, 2014, 11:54:05 PM
Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint.

My intent in introducing KSI is it is an example of a design along the same lines where

a) a central "mint" can be trusted but verified by peers
b) peers can be trusted because their transactions must signed by the central mint, so you can have a canonical blockchain (blocktree?)
c) there's no replaying of the blockchain possible thanks to information partitioning, but integrity can still be checked by everyone by verifying the hierarchical hash tree calculations. 

If you make the mint nomadic, and you add public chaos to handicap anyone who somehow could forecast the blockchain, I think you would have something better than Bitcoin. 


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on September 24, 2014, 09:05:14 PM
Self-signed X.509 Certificate Transparency

In this project I need a tamper-evident log-store of X.509 certificates replicated in, or otherwise available to, each container. I could simply trust a remote peer's certificate upon first use, but that method does not prevent a man-in-the-middle attack. A better alternative is a replicated tamper-evident log-store that is checked by the sender for correct listing of its IP address and certificate. The message recipient verifies the message signature of the message using the certificate looked up, or previously cached, for the sender's qualified role name: container-name.agent-name.role-name.

Each peer agent/role that communicates beyond its container to a remote agent/role will generate its own self-signed X.509 certificate and safeguard the private key in the local container encrypted keystore. I am thinking about following the keyless signature infrastructure (KSI) design suggested by Scumby in which a growable binary merkle hash tree timestamps and stores the certificates along with a Solar Flux Index chaos value. An index over the log-store records keys consisting of the qualified role name, and values consisting of the IP address and certificate of a peer agent/role. A later-dated entry for a peer supersedes an earlier-dated entry in the log-store, which permits container operators to occasionally migrate from one IP address to another. I expect paid super peers to have static, seldom changing IP addresses. Lesser-paid, blockchain archiving nodes, may execute using a residential internet connection having a dynamic IP address, which would not be recorded in the certificate log-store.

 The tamper-evident log for the certificates would be part of the downloaded container for a new installation, and would be updated securely by polling a sufficient number of peers once connected to the network.

The previous version of Texai used a Chord distributed hash table to contain the certificates. But for TexaiCoin I have removed the Chord library as it was another moderately complex attack surface that could be avoided by using a simple tamper-evident distributed data structure.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: ASIC-8Tile on September 25, 2014, 07:24:26 PM
We looked at Chord as well.
Have you looked into Whānau DHT?
What is Whānau? It means "extended family".
http://en.wikipedia.org/wiki/Whānau

These are some of the techniques described by Chris Lesniewski-Laas and M. Frans Kaashoek from the MIT: Computer Science and Artificial Intelligence Laboratory.

http://pdos.csail.mit.edu/papers/ton:chord/paper-ton.pdf (http://pdos.csail.mit.edu/papers/ton:chord/paper-ton.pdf)

Regards,


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Brangdon on September 27, 2014, 02:55:48 PM
I was just pointing out a few false statements that I have seen here, like "Peercoin has never been attacked", "Nxt is [cryptographically] secure", "Gregory Maxwell was only talking about Peercoin", etc.
Nothing I wrote was false. Nxt is secure; no-one has successfully attacked it (as opposed to attacking exchanges or individuals). If you read the quote you linked to, here (https://news.ycombinator.com/item?id=6798997), Gregory Maxwell was very clearly being specific to Peercoin and Peercoin's flaws. He may have written other things elsewhere; I just commented on the bit you linked.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: beitris.dwlul on October 01, 2014, 02:23:01 PM
Java isn't really seen in a good light in the CryptoCoin community.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: hbadger on October 01, 2014, 03:03:38 PM
Java isn't really seen in a good light in the CryptoCoin community.

Because the CryptoCoin community is mostly composed by geeks (who can't tell the difference between Java, Java plugin, and Javascript), and not professional developers. There are also many C and Python fanboys who fall into the "heroic programming" category (hint: this isn't something desirable).


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on October 01, 2014, 03:11:09 PM
Java isn't really seen in a good light in the CryptoCoin community.

Perhaps I can change that opinion. I suppose that because Bitcoin Core was written by Satoshi in C++, that language is the traditional approach in cryptocurrency. C++ is arguably more performant than Java, but the latter's many security and productivity advantages are well known.

For example ....

1. Java has a number of excellent Integrated Development Environments which enable the faster design, writing, debugging and regression testing of applications. In contrast, Bitcoin Core developers often use command line tools.

2. Java is inherently safer than C++ in that security is provided by a runtime environment which abstracts the underlying operating system and hardware.

3. Java encourages reuse. Notably, I use the Bouncy Castle cryptography library in this project.

4. Java source code is easier to read and understand than the same behavior written in C++. Please look at the source for BitcoinJ on GitHub vs the Bitcoin Core source on GitHub. More programmers have been taught Java than C++. Unfortunately, I believe that Satoshi received a Computer Science degree before Java was popularized in the late 1990's.

5. The community you speak of probably does not develop applications for Android, the world's dominant mobile device operating system, which because of the reasons I mention, strongly favors their rebranded Java language.

Bitcoin Core developers are stuck with the messy C++ code Satoshi left them, and have been forced to rewrite half of it, according to Gavin Andressen. In this project I have made very modest changes to C++ Bitcoin Core to repurpose its testing behavior, allowing the creation of a new block every 10 minutes with a trivial proof-of-work. I treat bitcoind as a slave process entirely controlled and proxied on the network by Java software agents. Thus this project retains full feature and bug fidelity with the Bitcoin protocol, and compatibility with existing wallets and processors via a set of TexaiCoin seed IP addresses and port.

Writing in Java, i.e the NetBeans IDE on Ubuntu, enables me to swiftly explore alternative implementations of new features.

As suggested in a prior post by Scumby, I am currently working on keyless signature infrastructure as part of the tamper-evident log module. I am using SHA-512 hashing as provided by Bouncy Castle. Each full node's logs will be temporally salted with the current Solar Flux indicator and hashed into a network-wide, timestamped merkle tree whose root value is widely known and archived, e.g. into an operators' mail list. This prevents equivocation misbehavior by a peer which cannot undetectably report an incorrect version of its state to an attesting peer, who verifies the target peer's version state hash in the distributed provenance merkle hash tree.

I am so glad to be using Java.




Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on October 12, 2014, 03:47:26 PM
I was reading up on IPv6 and thought of this project when I read this:

http://datatracker.ietf.org/doc/rfc4941/

RFC4941 Privacy Extentions allows for nodes to randomly shift their IPv6 addresses in order to foil MAC and IP tracking.  I intuit that there are some positive implications for using IP addresses to sign hashes, especially in a KSI regime.

Scumby


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: delulo on October 18, 2014, 08:59:58 AM
Hello Stephen,

I went through your whitepaper. Thanks for your contributions to move this technology forward! I have a few questions.

How does a case look like where stake weighted voting is required? Isn't it "node-stake" weighted voting (as indicated at the end of 6.9)?

How is the mint (s)elected or is the mint role being passed around among all super peer nodes? For how long does one node host the mint?

To estimate how secure a system is it makes sense to describe the weakest link and estimate what the costs are to exploit it. (assuming: there is no perfect system; every system has attack vectors). What would you say is the cheapest / easiest way to attack[attack meaning a) a political attack (destroy the system to people loose the trust in it) or b) an economically motivated attack like a double spend attack] a CPOS system?

What are the ad- and disadvantages of CPOS compared to DPOS (http://wiki.bitshares.org/index.php/DPOS_or_Delegated_Proof_of_Stake)?



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on November 04, 2014, 07:00:09 PM
At the Hasher's United Conference, I spoke about Cooperative Mining. The conference was recorded, and Kris Stinson has uploaded my talk to YouTube.

What is Cooperative Mining Bitcoin? Stephen Reed. Filmed at Hashers United Oct. 10/14 (https://www.youtube.com/watch?v=1ycTL9BTaE8&feature=youtu.be)

The corresponding six slides (PDF) are here (http://texai.org/files/cooperative-mining.pdf).

At the conference after my talk, Drew Hingorani and I decided to co-found A.I. Coin for launch in March 2015.

My current short term A.I. Coin development goal is to get three Docker containers running A.I. Coin, accepting transactions and creating new blocks.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on November 04, 2014, 07:32:31 PM
I was reading up on IPv6 and thought of this project when I read this:

http://datatracker.ietf.org/doc/rfc4941/

RFC4941 Privacy Extentions allows for nodes to randomly shift their IPv6 addresses in order to foil MAC and IP tracking.  I intuit that there are some positive implications for using IP addresses to sign hashes, especially in a KSI regime.

Scumby

Thanks for thinking about this project when reading about related tech!

Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (https://tools.ietf.org/html/rfc4941)

The A.I. Coin network is connected via known TCP IP addresses. A client joining the network uses a built-in list of seed IP addresses to reach one or more full-nodes which provide configuration information that includes more IP addresses.

Could you elaborate on the positive implications?




Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on November 04, 2014, 07:56:25 PM
Hello Stephen,

I went through your whitepaper. Thanks for your contributions to move this technology forward! I have a few questions.

How does a case look like where stake weighted voting is required? Isn't it "node-stake" weighted voting (as indicated at the end of 6.9)?

Yes, each full node votes the stake of its operator, which may be offline in a cold wallet. The stake is composed of the unspent transaction outputs that are controlled by the full node operator.

Quote
How is the mint (s)elected or is the mint role being passed around among all super peer nodes? For how long does one node host the mint?

The peer that hosts the mint is selected by the configuration agent from among the super-peers. The simplest method is to take-turns round-robin. The duration of the mint responsibility is a parameter that can be adjusted. Given that the mint hosting schedule can be efficiently published in advance to all peers, then the mint hosting duration could be anywhere from 10 minutes to perhaps one week.

Quote
To estimate how secure a system is it makes sense to describe the weakest link and estimate what the costs are to exploit it. (assuming: there is no perfect system; every system has attack vectors). What would you say is the cheapest / easiest way to attack[attack meaning a) a political attack (destroy the system to people loose the trust in it) or b) an economically motivated attack like a double spend attack] a CPOS system?

CPOS is designed similar to a conventional financial network, except that hardware and operations are provided by unrelated parties. The direct attack would be to compromise 51% of the stake-weighted peers.

The least expensive and perhaps least effective attack is a DDoS attack on certain network IP addresses. The super peers will be located in datacenters which have DDoS protection services. The ordinary peers should be too numerous to effectively attack, which is the defense that Bitcoin uses.

Quote
What are the ad- and disadvantages of CPOS compared to DPOS (http://wiki.bitshares.org/index.php/DPOS_or_Delegated_Proof_of_Stake)?

The main advantage of CPOS is that there is single mint and one version of the blockchain, leading to immediate transaction settlement.
The main disadvantage of CPOS is that its design has not yet been tested in production.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on November 05, 2014, 07:55:41 AM
Could you elaborate on the positive implications?

A design where IP addresses are transient and used to sign hashes, wherein the next IP to be assigned to a given node is random, would seem to be harder for an adversary with unlimited computing power to precompute and attack.  This extremely-dynamic IP assignment is built into IPv6.  That was the thought.


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: SlipperySlope on November 07, 2014, 03:42:59 AM
Could you elaborate on the positive implications?

A design where IP addresses are transient and used to sign hashes, wherein the next IP to be assigned to a given node is random, would seem to be harder for an adversary with unlimited computing power to precompute and attack.  This extremely-dynamic IP assignment is built into IPv6.  That was the thought.

Each distributed agent/role has a self-signed X.509 certificates for digital signatures and for SSL/TLS communication channel encryption. The tamper-evident data structures, e.g. agent logs, are signed by X.509 certificates. I plan to use the solar flux chaos value as you suggested in the KSI scheme which ties together all the distributed tamper-evident data structures into a temporal merkel tree whose root hash value is widely known.

Could you help me understand how transient IPv6 addresses can be used to sign hashes? The system needs the X.509 certificates to establish unique agent/role identity that persists over time.

I really appreciate the thought that you have given to this project.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: delulo on November 07, 2014, 03:10:58 PM
Thanks for your reply.

Quote
The peer that hosts the mint is selected by the configuration agent from among the super-peers. The simplest method is to take-turns round-robin. The duration of the mint responsibility is a parameter that can be adjusted. Given that the mint hosting schedule can be efficiently published in advance to all peers, then the mint hosting duration could be anywhere from 10 minutes to perhaps one week.
But what are the (objective) criteria by which the mint role is assigned? My worry is that there is no valuable/scarce resource necessary to become the mint and therefore control the network...

The most valuable ressources (for an attacker) seem to be "node-stake" and the quantity of nodes since everyone seems to be able to become a super peer no matter of his stake size (correct?). Isn't this much easier to achieve than pure stake?


Title: Re: TexaiCoin Pre-Release Development Diary
Post by: Scumby on November 08, 2014, 07:44:27 AM
The system needs the X.509 certificates to establish unique agent/role identity that persists over time.

I didn't realize such persistence was a requirement of your design.  I was thinking about certificates that are regenerated by a node every time its IP changes, enhancing anonymity and reducing the ability of an adversary to recreate a historical network state.   It may not have been relevant after all. 


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on December 09, 2014, 03:54:52 AM
Thanks for your reply.

Quote
The peer that hosts the mint is selected by the configuration agent from among the super-peers. The simplest method is to take-turns round-robin. The duration of the mint responsibility is a parameter that can be adjusted. Given that the mint hosting schedule can be efficiently published in advance to all peers, then the mint hosting duration could be anywhere from 10 minutes to perhaps one week.

But what are the (objective) criteria by which the mint role is assigned? My worry is that there is no valuable/scarce resource necessary to become the mint and therefore control the network...

The most valuable resources (for an attacker) seem to be "node-stake" and the quantity of nodes since everyone seems to be able to become a super peer no matter of his stake size (correct?). Isn't this much easier to achieve than pure stake?

A.I. Coin will launch with a minimum of five super peers, located in geographically dispersed datacenters.  The founding super peer operators will vet candidates that become new super peers when needed due to growing transaction volume.

A joining node cannot become a super peer otherwise.



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: leathan on December 09, 2014, 08:27:46 AM
Wish I had time to follow this, seems very interesting.. good luck. I already learned alot just reading through this post.

P.S. C programmers are heros*


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: emdje on December 13, 2014, 09:39:11 PM
Interesting ideas, and difficult to read ;D even when read twice, learning a lot here.

Any thoughts already about what algorithm to use?
You are talking about hardforking Bitcoin (when/if A.I. Coin is succesfull and accepted by the community), does that mean it will most likely be a sha265 algorithm?


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: LeChatNoir on February 27, 2015, 08:27:26 PM
What's happened to this project?


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: biggus dickus on February 27, 2015, 10:00:35 PM
What's happened to this project?

This project is not a rush job. According to the OP is a multi-year effort. He is trying to create a new innovation instead of the usual cut and paste job.

...........

The A.I. Coin project is a multi-year effort to achieve a no-proof-of-work mining implementation in an cryptocurrency that ...

............



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: The Chainmaker on February 28, 2015, 06:12:41 AM
What's happened to this project?

This project is not a rush job. According to the OP is a multi-year effort. He is trying to create a new innovation instead of the usual cut and paste job.

...........

The A.I. Coin project is a multi-year effort to achieve a no-proof-of-work mining implementation in an cryptocurrency that ...

............


anybody with the name biggus dickus is a person that I'm guessing wouldn't lie, no?


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: The Chainmaker on February 28, 2015, 06:14:10 AM
Thanks for your reply.

Quote
The peer that hosts the mint is selected by the configuration agent from among the super-peers. The simplest method is to take-turns round-robin. The duration of the mint responsibility is a parameter that can be adjusted. Given that the mint hosting schedule can be efficiently published in advance to all peers, then the mint hosting duration could be anywhere from 10 minutes to perhaps one week.

But what are the (objective) criteria by which the mint role is assigned? My worry is that there is no valuable/scarce resource necessary to become the mint and therefore control the network...

The most valuable resources (for an attacker) seem to be "node-stake" and the quantity of nodes since everyone seems to be able to become a super peer no matter of his stake size (correct?). Isn't this much easier to achieve than pure stake?

A.I. Coin will launch with a minimum of five super peers, located in geographically dispersed datacenters.  The founding super peer operators will vet candidates that become new super peers when needed due to growing transaction volume.

A joining node cannot become a super peer otherwise.



and anyone with a name "slipper slope" should be somebody I can totally trust to give my money to, no?

just saying....


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: The Chainmaker on February 28, 2015, 06:16:00 AM
I'm sure you are a legit guy.... but that name is terrible.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: rpietila on February 28, 2015, 10:12:16 AM
I would not go against established members with 3 months / 100 posts experience.  :P

Do you realize the guy is 45 years older than you, and changing the name in the forum costs $2,500? He's had 1000x gains from Bitcoin and in the old days, stupid names were ok.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: CIYAM on February 28, 2015, 03:14:09 PM
...and changing the name in the forum costs $2,500?

Sorry but in what forum does it cost $2,500 to change your user name?


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Cablez on February 28, 2015, 03:18:34 PM
He is talking about being a donator in order to change your username.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: CIYAM on February 28, 2015, 03:20:19 PM
He is talking about being a donator in order to change your username.

I changed my user name - and it cost me nothing (just a request to @theymos).

So I am not sure exactly the point (apart from that you can change your username without requesting a mod to do so if you have that status).


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Cablez on February 28, 2015, 03:21:01 PM
Well then I am not sure what he is referencing in that bit, lol.  :)


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: rpietila on February 28, 2015, 06:37:09 PM
He is talking about being a donator in order to change your username.

I changed my user name - and it cost me nothing (just a request to @theymos).

@theymos is a good guy but it does not mean he would change the usernames for random newbies, so consider yourselves a part of old guard  ;D


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: biggus dickus on February 28, 2015, 06:50:34 PM
What's happened to this project?

This project is not a rush job. According to the OP is a multi-year effort. He is trying to create a new innovation instead of the usual cut and paste job.

...........

The A.I. Coin project is a multi-year effort to achieve a no-proof-of-work mining implementation in an cryptocurrency that ...

............


anybody with the name biggus dickus is a person that I'm guessing wouldn't lie, no?

I take offence at that remark, biggus dickus is my real name.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: biggus dickus on February 28, 2015, 07:02:12 PM
He is talking about being a donator in order to change your username.

I changed my user name - and it cost me nothing (just a request to @theymos).

@theymos is a good guy but it does not mean he would change the usernames for random newbies, so consider yourselves a part of old guard  ;D

Here is what the staff member Eal F. Skillz has to say about whether it's possible to have your username changed.


I don't think theymos have time for this anymore. Just create a new account if you don't like this username or be a donator.

PM theymos and ask him very nicely.

The forum is too big for this now.  Staff, donators, and VIP can do it... so my suggestion is donate 10 BTC or create a new account.
Contact theymos he will change it for you.
No he won't, stop bothering the admin with rubbish like this or are you just posting for the sake of your prime dice payouts?

OP, name changes are only available to donators, vip and staff members.

Here's what the administrator BadBear has to say about getting theymos to change a username.

Just make the new account, nobody cares if you have more than one. Go nuts.

I agree with rpietila, theymos might do an old timer a favor and change his name, but his time is too limited to do it for the rest of us.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: CIYAM on March 01, 2015, 02:47:33 AM
I agree with rpietila, theymos might do an old timer a favor and change his name, but his time is too limited to do it for the rest of us.

It probably has got far too big for that now - but at least newbies won't really lose anything by creating a new account.

You can also buy senior accounts (assuming one for sale has a name you like) for well under 1 BTC.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on March 02, 2015, 09:26:51 PM
Hi everyone.

Drew Hingorani, myself, and our active community plan to launch AI Coin at the Inside Bitcoins Conference New York, April 27-29 (http://insidebitcoins.com/new-york). I have been silent the past few months here as we worked on the first provisional patent covering our solution to what we characterize as certain Bitcoin problems.

We now have a dedicated modern forum where you can see technical information, as well as our pre-launch activities. The super peer demonstration network has been minting 50 test aicoins every 10 minutes for over 60 days. We have branded a MultiBit wallet for AI Coin, which you can download for Windows. We have a branded QT wallet for the Mac. You can see our minting and transaction activity on our branded Insight Blockchain explorer.

Our chief innovation vs Bitcoin for customers is that AI Coin has immediate settlement - sub second response time. The QT and MultiBit wallets have been modified to permit immediate spending of received transactions. Our chief innovation for the business is that our cooperative mining secures the blockchain with network-wide algorithmic trustworthiness, and without conventional mining expense.

AI Coin, the company, will initially own the aicoins minted each day, and will transparently pay expenses with them, or with fiat obtained from daily sold aicoins. Our expenses are planned to optimally promote the value of aicoin, and to benefit our community. We will hold a substantial reserve in fiat to cover customer losses that are our fault. We will pursue both a Bit License for New York State operation, and Money Services Business licenses in the 50 US States, as well as similar licensing in other jurisdictions that are important to our customers.

Customers can buy aicoins from an exchange after launch, or can perform specified tasks as contractors for us and be paid in aicoins. The company will subsidize certain customer, payment processor and merchant activities to give aicoin a comparative advantage over other crytptocurrencies with regard to transaction friction. Our transaction fees will be 100x lower relative to Bitcoin and we will likewise accommodate microtransactions.

Important among our contractors are the operators of our network. We plan to pay $1000 per month to super peer operators which host their servers in DDoS-protected secure datacenters. We anticipate having enough of these in the network backbone to claim that AI Coin is more decentralized than Bitcoin with regard to the geographical locations in which new blocks are added to the blockchain. Likewise we plan to pay $50 per month to operators of ordinary computers that dedicate home or office computers 24/7 for the purpose of archiving the AI Coin blockchain. We need between 50 - 100 of the archiving peers to assure redundancy, and to have plenty of network gateways for customer wallets.

We have a growing, active community who contribute ideas, artwork, programming, social networking and so on. They enthusiastically want to bring AI Coin to the mainstream.

Our forum:  ai-cointalk.org (http://ai-cointalk.org) .
Website: ai-coin.org (http://ai-coin.org)
Demonstration blockchain explorer: texai.dyndns.org:3000 (http://texai.dyndns.org:3000)

Join Us

-Stephen Reed


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: emdje on March 10, 2015, 02:28:09 PM
Would I be able to mine AI coin? Or just buy on exchange?
And are there already uses for it when it launches?


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on March 11, 2015, 03:10:08 AM
Would I be able to mine AI coin? Or just buy on exchange?
And are there already uses for it when it launches?

The company is the sole miner of AI Coin. The 7,200 aicoins created each day will be sold on an exchange or otherwise directly paid for expenses.

AI Coin, the company, will initially own the aicoins minted each day, and will transparently pay expenses with them, or with fiat obtained from daily sold aicoins. Our expenses are planned to optimally promote the value of aicoin, and to benefit our community. We will hold a substantial reserve in fiat to cover customer losses that are our fault. We will pursue both a Bit License for New York State operation, and Money Services Business licenses in the 50 US States, as well as similar licensing in other jurisdictions that are important to our customers.

We are seeking integration with at least one payment processor before launch, and that depends on obtaining an exchange before launch.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: bybitcoin on March 15, 2015, 06:20:16 AM
Your business development model resembles Ripple.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Melbustus on March 22, 2015, 03:30:16 AM

The company is the sole miner of AI Coin. The 7,200 aicoins created each day will be sold on an exchange or otherwise directly paid for expenses.
...


Wait... What happened to:


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....


Edit: cuz I'll support a project which preserves the effective scarcity of bitcoin (if the tech, etc, is good), thereby supporting the idea that cryptocurrency can be scarce and therefore valuable.

But if you are creating an alt-coin that doesn't tie into bitcoin's ledger (ie, the utxo-set), you are directly attacking the notion of crypto-scarcity, and therefore the idea that crypto-currency can be good money. In which case I will vocally not support this project. And FWIW, I've been approached in the real-world by your representatives.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Joshuar on March 22, 2015, 03:42:34 AM

The company is the sole miner of AI Coin. The 7,200 aicoins created each day will be sold on an exchange or otherwise directly paid for expenses.
...


Wait... What happened to:


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....


Edit: cuz I'll support a project which preserves the effective scarcity of bitcoin (if the tech, etc, is good), thereby supporting the idea that cryptocurrency can be scarce and therefore valuable.

But if you are creating an alt-coin that doesn't tie into bitcoin's ledger (ie, the utxo-set), you are directly attacking the notion of crypto-scarcity, and therefore the idea that crypto-currency can be good money. In which case I will vocally not support this project. And FWIW, I've been approached in the real-world by your representatives.


Lost coins would have to be accounted for wouldn't they? Be too scarce and you risk losing the title of "currency"(Lack of liquidity). I find it odd that many people here use the word currency, but through their arguments, instead, support the notion of commodity. I know that the "too scarce" aspect would be eliminated if we used the term "bits" instead of "bitcoin"(denominations), but just talking in terms of full bit/coins.

I don't believe following bitcoin's distribution model is the best idea if you want to create a "currency". Odd I know, haha.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Melbustus on March 22, 2015, 04:22:28 AM
...
I don't believe following bitcoin's distribution model is the best idea if you want to create a "currency". Odd I know, haha.


This is mostly a separate discussion, but either complete-information monetary policies are best, or human-controlled ones are. The idea that one tweak of some complete-info algorithmic policy is better than another tweak of a complete-info algorithmic monetary policy is ridiculous and fundamentally misunderstands what monetary policy does.

Specifically, monetary policy in the central banking era seeks to attenuate peaks and troughs of natural economic activity through explicit human action. The overarching assumption, which is probably correct, is that the instantaneous supply optimum for some future date cannot be known with much certainty beforehand. So the solution the world has come to today is to give control over that supply number to a studious committee of economic custodians. The idea is that they'll be better able to determine today's optimal supply than some pre-set policy.

Bitcoin changes the question entirely and simply posits that maybe perfect knowledge of future supply, by all economic participants, will allow for more optimal allocation (by businesses/humans) today, and that perhaps this will more naturally attenuate the tendency of economies to generate large peaks and troughs. Whether you have a monetary policy with a fixed supply, 2% inflationary forever, or something else, shouldn't matter in this context so long as all economic participants have complete knowledge of the dynamics. So trying to tweak the alg doesn't matter.

But adding alt-coins that don't support the dominant monetary policy (bitcoin's) does matter, because that action implicitly erodes the perfect-information base of this entire experiment.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Joshuar on March 22, 2015, 04:27:14 AM
...
I don't believe following bitcoin's distribution model is the best idea if you want to create a "currency". Odd I know, haha.


This is mostly a separate discussion, but either complete-information monetary policies are best, or human-controlled ones are. The idea that one tweak of some complete-info algorithmic policy is better than another tweak of a complete-info algorithmic monetary policy is ridiculous and fundamentally misunderstands what monetary policy does.

Specifically, monetary policy in the central banking era seeks to attenuate peaks and troughs of natural economic activity through explicit human action. The overarching assumption, which is probably correct, is that the instantaneous supply optimum for some future date cannot be known with much certainty beforehand. So the solution the world has come to today is to give control over that supply number to a studious committee of economic custodians. The idea is that they'll be better able to determine today's optimal supply than some pre-set policy.

Bitcoin changes the question entirely and simply posits that maybe perfect knowledge of future supply, by all economic participants, will allow for more optimal allocation (by businesses/humans) today, and that perhaps this will more naturally attenuate the tendency of economies to generate large peaks and troughs. Whether you have a monetary policy with a fixed supply, 2% inflationary forever, or something else, shouldn't matter in this context so long as all economic participants have complete knowledge of the dynamics. So trying to tweak the alg doesn't matter.

But adding alt-coins that don't support the dominant monetary policy (bitcoin's) does matter, because that action implicitly erodes the perfect-information base of this entire experiment.

Is there a alt-coin that is a clone of Bitcoin, but finished it's mining period already? It would be interesting to look at. But, yes, I get your argument and agree with it. I  think we may be on the same page though. You're talking about knowing the total supply beforehand(Unlike Fiat), that I agree with. What I originally referred to was the exact copying of Bitcoin's distribution(from satoshi's mining close to 1million xbt to now) onto an altcoin 1:1 so that all the altcoin's addresses and coins were proportional to that of Bitcoin. Basically the altcoin would have bitcoin's entire distribution from release to now, "cloned" onto it.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on March 22, 2015, 07:50:01 AM

The company is the sole miner of AI Coin. The 7,200 aicoins created each day will be sold on an exchange or otherwise directly paid for expenses.
...


Wait... What happened to:


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....


Edit: cuz I'll support a project which preserves the effective scarcity of bitcoin (if the tech, etc, is good), thereby supporting the idea that cryptocurrency can be scarce and therefore valuable.

But if you are creating an alt-coin that doesn't tie into bitcoin's ledger (ie, the utxo-set), you are directly attacking the notion of crypto-scarcity, and therefore the idea that crypto-currency can be good money. In which case I will vocally not support this project. And FWIW, I've been approached in the real-world by your representatives.


In my May 2014 whitepaper, I proposed a dramatic change to the way that the Bitcoin blockchain is secured. I changed my approach due to the prevailing wisdom among core developers that radical innovation should take place in altcoins first. AI Coin would have to be very successful in order to grow to the point of diluting Bitcoin's market cap.

Sorry to lose your vocal support, but happy that our community has reached out to you already.

We are attending the Texas Bitcoin Conference, and will launch at Inside Bitcoins New York, April 27-29. I would be glad to meetup and discuss cryptocurrency.

http://ai-coin.org (http://ai-coin.org)


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: coine_smithe on April 03, 2015, 10:10:29 AM
Wow I can't believe you're finally making this! I commented in this thread before but my comment is gone... Do you have a thread in the announcements page? Also, I feel like the website and the logo on the Twitter page could use some work. The logo on the Twitter page looks very poor. I can recommend some people who do graphic and web design for alts if you want.

The logo needs to be more modern and professional. The current gold one looks very cheesy like many of the scam coins.

The website is too convoluted with flash animations. It should be straightforward and graphically professional for a coin of this caliber.

If you want to contact me on Twitter my name is @check__it__out. I check bitcointalk.org less frequently and I don't get notifications on my phone either.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: coinmaster222 on April 04, 2015, 04:55:50 AM
Thought that myself get a graphic/web dev and get a more professional logo and website it looks pretty shitty just now for a really good coin


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 05, 2015, 03:18:14 AM
Wow I can't believe you're finally making this! I commented in this thread before but my comment is gone... Do you have a thread in the announcements page? Also, I feel like the website and the logo on the Twitter page could use some work. The logo on the Twitter page looks very poor. I can recommend some people who do graphic and web design for alts if you want.

The logo needs to be more modern and professional. The current gold one looks very cheesy like many of the scam coins.

The website is too convoluted with flash animations. It should be straightforward and graphically professional for a coin of this caliber.

If you want to contact me on Twitter my name is @check__it__out. I check bitcointalk.org less frequently and I don't get notifications on my phone either.

Quote
Thought that myself get a graphic/web dev and get a more professional logo and website it looks pretty shitty just now for a really good coin

AI Coin's forum has our old blue logo. Do you like that one better?  I plan to post your constructive comments on our forum where they can be discussed by our most enthusiastic supporters, one of whom is a web designer and branded our website. AI Coin Inc has a rather transparent management style and I thank you for helping us to be better.

We have a modest budget for advertising before launch. Do readers have an opinion of where to advertise? CoinDesk has a relatively large number of visitors for example.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: coine_smithe on April 07, 2015, 01:02:42 AM
Wow I can't believe you're finally making this! I commented in this thread before but my comment is gone... Do you have a thread in the announcements page? Also, I feel like the website and the logo on the Twitter page could use some work. The logo on the Twitter page looks very poor. I can recommend some people who do graphic and web design for alts if you want.

The logo needs to be more modern and professional. The current gold one looks very cheesy like many of the scam coins.

The website is too convoluted with flash animations. It should be straightforward and graphically professional for a coin of this caliber.

If you want to contact me on Twitter my name is @check__it__out. I check bitcointalk.org less frequently and I don't get notifications on my phone either.

Quote
Thought that myself get a graphic/web dev and get a more professional logo and website it looks pretty shitty just now for a really good coin

AI Coin's forum has our old blue logo. Do you like that one better?  I plan to post your constructive comments on our forum where they can be discussed by our most enthusiastic supporters, one of whom is a web designer and branded our website. AI Coin Inc has a rather transparent management style and I thank you for helping us to be better.

We have a modest budget for advertising before launch. Do readers have an opinion of where to advertise? CoinDesk has a relatively large number of visitors for example.

Dash's logo is the type of logo that is very popular not only in crypto but in general in graphic design in world corperations.
http://coinmarketcap.com/static/img/coins/16x16/darkcoin.png

Or Microsoft's logo is not letter based but a shape.
http://www.google.com/imgres?imgurl=http://3.bp.blogspot.com/-X9lWxWlQO9g/UDZklbBZSfI/AAAAAAAAI1o/8J1ZDMUMlI8/s1600/microsoft%252Bnew%252Blogo.png&imgrefurl=http://www.techpinas.com/2012/08/new-logo-of-microsoft-corporation.html&h=130&w=387&tbnid=GSBxIHi2vDOthM:&zoom=1&tbnh=50&tbnw=151&usg=__goTFDX3QVtIyKLtgreZTw1CpWN0=&docid=kpTyvfWMExeHsM&itg=1

Overall you need to distance yourself from the "coin" shape. It's a cheesy altcoin meme that devalues your image. It should be a simple shape or two letters "AI" floating on a white background.

As far as the site, look at Monero's:
https://getmonero.org/home

It has a menu bar up top and a simple, clean, professional interface. It should be a quick and simple reference for people to learn about your product. You current site is convoluted and requires people to scroll through flash animations that look cheesy and waste their time. A lot of people have mobile devices that will struggle to even load that. I will give you some references for someone who can do the work for you.

As far as promotion Coindesk is great. I would go with them first if you have to choose one. Also posting in /r/bitcoin yourself as the lead dev isn't a bad idea. They are receptive to legitimate projects such as this. It's a great promotional vehicle. Storjcoin and Monero are well received there and I think your project will be as well.

I'll add more later as I get it.

EDIT: Just got a referral for you from my team: http://www.cryptodesign.net/
He did Mintpal's logo etc. Look at his website for an idea of simple and effective design.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 07, 2015, 01:52:51 AM
Dash's logo is the type of logo that is very popular not only in crypto but in general in graphic design in world corperations.
http://coinmarketcap.com/static/img/coins/16x16/darkcoin.png

Or Microsoft's logo is not letter based but a shape.
http://www.google.com/imgres?imgurl=http://3.bp.blogspot.com/-X9lWxWlQO9g/UDZklbBZSfI/AAAAAAAAI1o/8J1ZDMUMlI8/s1600/microsoft%252Bnew%252Blogo.png&imgrefurl=http://www.techpinas.com/2012/08/new-logo-of-microsoft-corporation.html&h=130&w=387&tbnid=GSBxIHi2vDOthM:&zoom=1&tbnh=50&tbnw=151&usg=__goTFDX3QVtIyKLtgreZTw1CpWN0=&docid=kpTyvfWMExeHsM&itg=1

Overall you need to distance yourself from the "coin" shape. It's a cheesy altcoin meme that devalues your image. It should be a simple shape or two letters "AI" floating on a white background.

As far as the site, look at Monero's:
https://getmonero.org/home

It has a menu bar up top and a simple, clean, professional interface. It should be a quick and simple reference for people to learn about your product. You current site is convoluted and requires people to scroll through flash animations that look cheesy and waste their time. A lot of people have mobile devices that will struggle to even load that. I will give you some references for someone who can do the work for you.

As far as promotion Coindesk is great. I would go with them first if you have to choose one. Also posting in /r/bitcoin yourself as the lead dev isn't a bad idea. They are receptive to legitimate projects such as this. It's a great promotional vehicle. Storjcoin and Monero are well received there and I think your project will be as well.

I'll add more later as I get it.

EDIT: Just got a referral for you from my team: http://www.cryptodesign.net/
He did Mintpal's logo etc. Look at his website for an idea of simple and effective design.

Thanks for your awesome contribution! It is emotionally difficult this close to launch to go back over work we thought was accomplished, but as our advisors tell us - branding is very important. I am taking this up with my co-founder before mentioning it on our dedicated forum.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 08, 2015, 03:14:19 AM
Thanks a lot for your constructive feedback!

Our team agree today to remove the animated robot graphic and make the ai-coin.org website better with respect to an audience beyond gamers. Plus we will do a better job for mobile.

Our inspiration sites that look great on large screen and on mobile too ...

Monero - https://getmonero.org/home (https://getmonero.org/home) (one page without vertical scrolling)

Ripple - https://ripple.com/ (https://ripple.com/) (aimed at financial institutions, good use of customer recommendations which highlight Ripple benefits, my favorite but obviously expensive)

Dash - https://www.dashpay.io/ (https://www.dashpay.io/) (scrolling with menu tabs, significant rebranding of privacy-centric Darkcoin)


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: biggus dickus on April 08, 2015, 11:21:38 AM

The company is the sole miner of AI Coin. The 7,200 aicoins created each day will be sold on an exchange or otherwise directly paid for expenses.
...


Wait... What happened to:


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....


Edit: cuz I'll support a project which preserves the effective scarcity of bitcoin (if the tech, etc, is good), thereby supporting the idea that cryptocurrency can be scarce and therefore valuable.

But if you are creating an alt-coin that doesn't tie into bitcoin's ledger (ie, the utxo-set), you are directly attacking the notion of crypto-scarcity, and therefore the idea that crypto-currency can be good money. In which case I will vocally not support this project. And FWIW, I've been approached in the real-world by your representatives.


I also read it that A.I. Coin would tie into bitcoin's ledger (ie, the utxo-set). I'm disappointed its turned into another IPO. Another IPO/ICO is the last thing most people want considering all the rip offs over the previous 12 months.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: drawingthesun on April 08, 2015, 11:59:11 AM
Sorry if this has already been answered.

Three questions:

1) Was there any consideration to create the coin with eternal inflation of <1%? To keep future generations in hundreds of years interested?

2) Are there any anonymous capabilities built into this coin?

3) Will this coin have side chains enabled? (I feel this is important to compete with Bitcoin, if Bitcoin does one day gain side chains)


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: drawingthesun on April 08, 2015, 12:02:18 PM
I also read it that A.I. Coin would tie into bitcoin's ledger (ie, the utxo-set). I'm disappointed its turned into another IPO. Another IPO/ICO is the last thing most people want considering all the rip offs over the previous 12 months.

Most coins end up turning into IPO/ICO due to the developers wanting instant riches.

My suggestion:

Copy the bitcoin coin release so far 1:1 and IPO/ICO the leftover coins from the ones that haven't been mined yet.
This keeps all the current Bitcoin players in the game and creates a larger community incentive.

You still have 7 million coins to sell at IPO/ICO .


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: bybitcoin on April 08, 2015, 07:26:34 PM
No cap, the total coins created each day will be owned and then distributed or sold by a company that plans to get bitlicence and follow its upcoming regulation rules as soon as it becomes available.
By this plan, even Ripple would look more decentralized and user-driven than this one!


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: TheReaper on April 09, 2015, 03:54:08 PM
No cap, the total coins created each day will be owned and then distributed or sold by a company that plans to get bitlicence and follow its upcoming regulation rules as soon as it becomes available.
By this plan, even Ripple would look more decentralized and user-driven than this one!
Sorry, but that is wrong:

there is a cap of 21 millions coin
50 coins created every 10 minutes
www.ai-coin.org
minting peers are not owned by company and are spread out globally over many continents.
a percentage of coins are sent back to company and the rest kept by peer nodes not owned by ai coin inc.
basically, a new type of mining.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 09, 2015, 05:58:48 PM
No cap, the total coins created each day will be owned and then distributed or sold by a company that plans to get bitlicence and follow its upcoming regulation rules as soon as it becomes available.
By this plan, even Ripple would look more decentralized and user-driven than this one!
Sorry, but that is wrong:

there is a cap of 21 millions coin
50 coins created every 10 minutes
www.ai-coin.org
minting peers are not owned by company and are spread out globally over many continents.
a percentage of coins are sent back to company and the rest kept by peer nodes not owned by ai coin inc.
basically, a new type of mining.

It turns out that if the company owns all the coins, even for just the day they are created, it would be an "administrator" of a central repository from which tokens are issued and redeemed according to FinCEN guidance published last October. We knew this and assumed that we could obtain the money services business licences in the 48 US States where they are required as we progressed after launch. Our legal advice now is that we cannot launch under the previous business plan as that entails a legal risk in the USA.

Reaper mentions the new plan, which is to have a conventional altcoin minting method whereby independent operators create the new aicoins each day and pay a software licence fee to the company, which in turn promotes and develops AI Coin for the benefit of operators, current and future holders. Even this business plan is subject to tweaking, as the software license may create an situation in which the deal between the company and its independent operators creates what the US SEC views as a security, which is subject to onerous regulation. As a lay person, my reading of the regulation and court decisions is that because the company is not the *sole* provider of effort which makes the deal valuable, then the deal is not a security. Instead I believe it is similar to retail store franchise agreements in the USA in which a share of store revenues is sent back to the franchisor. The analogy is that aicoin mining operators, its super peers, must perform effort too in order for the deal to be valuable. AI Coin Inc is seeking the advice of attorneys who know this sort of law. Fortunately, our president works in New York City, and networks conveniently with such law firms. If the software license becomes a poor choice due to SEC regulations, then another method to try for the desired revenue split would be to have a distinguished super peer owned by the company that gets more turns to create aicoins than the other super peers.



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: drawingthesun on April 10, 2015, 02:23:45 AM
... pay a software licence fee to the company...

This coin will not take off under that model.
What will happen, is that all of your technology will be copied and used in a clone that will take off.

Of course, you can get around this by making the coin closed source, in which case I doubt you'll ever sell one license fee.



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 10, 2015, 02:53:38 AM
... pay a software licence fee to the company...

This coin will not take off under that model.
What will happen, is that all of your technology will be copied and used in a clone that will take off.

Of course, you can get around this by making the coin closed source, in which case I doubt you'll ever sell one license fee.


Well, what is worse from your point of view is that the intelligent agent software has a provisional patent application pending. Most of the source code will be available for inspection, and could be copied and used in jurisdictions that do not permit nor honor software patents. Each of our peers wraps a branded recent version of Bitcoin Core, which will always be open source.

AI Coin's technology allows for instant spending of received aicoins. This is zero confirmations. No Finney attacks, no undoing transactions, nor double spend fraud. The network has a rationally designed topology. In only two hops, a transaction from a wallet reaches the super peer whose turn it is to create the next new block. That gives worldwide subsecond response time.

AI Coin Inc, the company behind its cryptocurrency, optimally spends its majority share of issued aicoins for promotion and development. There is no substantial expense for electricity nor specialized mining equipment. Proof-of-Stake, although mentioned in our May 2014 whitepaper, is actually not necessary for the current implementation, which does not routinely have disagreement. Instead we will have a human-in-the-loop to oversee the distributed intelligent software agents that operate the network. Super peer operators on several continents will take turns monitoring the network and each other.

What will make this coin take off, if indeed it does, is simply that a single company, engaging its enthusiastic community, spending most of the issued aicoins with the single goal of optimising the benefits for current and future users, succeeds in executing its mission.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: ethought on April 10, 2015, 04:29:02 AM
... pay a software licence fee to the company...

This coin will not take off under that model.
What will happen, is that all of your technology will be copied and used in a clone that will take off.

Of course, you can get around this by making the coin closed source, in which case I doubt you'll ever sell one license fee.



I have to agree with drawingthesun. Mining is hard enough as it is without having to pay the devs / parent company / whoever for the privilege. That might make it a hard sell.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 10, 2015, 05:58:44 AM
... pay a software licence fee to the company...

This coin will not take off under that model.
What will happen, is that all of your technology will be copied and used in a clone that will take off.

Of course, you can get around this by making the coin closed source, in which case I doubt you'll ever sell one license fee.



I have to agree with drawingthesun. Mining is hard enough as it is without having to pay the devs / parent company / whoever for the privilege. That might make it a hard sell.


Interesting that you should say that. I would guess that you are a proof of work miner.

AI Coin super peers will be limited in number to avoid over investing in network infrastructure. If we limit the super peers to 20, I see no problem achieving that given the number already on our demo system. Ordinary, non-mining peers will split a pool of aicoins contributed to by the mining super peers. There will be no limit on the number of ordinary peers, but they must have high availability in order to share from the pool. The software license will need to cap the dollar equivalent amount of aicoins shared by all peers. It does not make sense to overpay for network infrastructure when promotion, features and partnerships would do more to attract new users.

AI Coin has intelligent software agents that will automate software distribution and network restarts, thus making it rather easy to keep a super peer running. We use Docker containers to assure an immutable deployed application. The persistent data volume is mapped to the host.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 10, 2015, 06:19:12 AM
Sorry if this has already been answered.

Three questions:

1) Was there any consideration to create the coin with eternal inflation of <1%? To keep future generations in hundreds of years interested?

2) Are there any anonymous capabilities built into this coin?

3) Will this coin have side chains enabled? (I feel this is important to compete with Bitcoin, if Bitcoin does one day gain side chains)

1. The whitepaper theme was to convince Bitcoin to adopt this technology, therefore it will be as close to Satoshi's specifications as possible. We start at 50 aicoins created every 10 minutes, the rate halving every four years for a total of 21 million aicoins.

2. We want to take AI Coin mainstream and that means whatever privacy is built into the latest Bitcoin Core version we will have too. In addition, AI Coin encrypts all message traffic between its peers, and has gateways for client access, so a service like blockchain.info for aicoin would not be able to assign IP addresses to transaction endpoints.

3. Regarding sidechains, when Bitcoin Core supports them, AI Coin will also because we stay current with Bitcoin Core. We are launching on version 0.9.3, and after the network is proven stable we will migrate to Bitcoin Core version 0.10.0 or 0.10.1 if that gets released in time. Part of the motivation for sidechains is the notion that Bitcoin is not suitable for all the world's transactions. Gavin famously said, "why would I want my coffee purchase on the blockchain". But AI Coin actually wants to handle all the world's transactions. AI Coin has a rationally designed network - a super peer well connected ring, and spokes out to ordinary peers. We will not overbuild the infrastructure. Where Bitcoin replicates its blockchain on 10000 plus full nodes, AI Coin needs only about 50 blockchain archiving peers with suitable geographical and jurisdictional diversity. Given such redundancy in peers, AI Coin peers can each use inexpensive disk drives in non-redundant configurations. The cost per stored byte is such that AI Coin can store transactions indefinitely for 100x lower transaction fees relative to Bitcoin. The AI Coin dust level is correspondingly lower relative to Bitcoin - i.e. if an aicoin had the same price as a bitcoin, then the aicoin transaction fee would be 100x lower in fiat value. Furthermore, because the AI Coin network is so much less expensive to run, the transaction fees should cover the expense when the mining reward diminishes in the fullness of time.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: bybitcoin on April 10, 2015, 07:50:55 AM
No cap, the total coins created each day will be owned and then distributed or sold by a company that plans to get bitlicence and follow its upcoming regulation rules as soon as it becomes available.
By this plan, even Ripple would look more decentralized and user-driven than this one!
Sorry, but that is wrong:

there is a cap of 21 millions coin
50 coins created every 10 minutes
www.ai-coin.org
minting peers are not owned by company and are spread out globally over many continents.
a percentage of coins are sent back to company and the rest kept by peer nodes not owned by ai coin inc.
basically, a new type of mining.

It turns out that if the company owns all the coins, even for just the day they are created, it would be an "administrator" of a central repository from which tokens are issued and redeemed according to FinCEN guidance published last October. We knew this and assumed that we could obtain the money services business licences in the 48 US States where they are required as we progressed after launch. Our legal advice now is that we cannot launch under the previous business plan as that entails a legal risk in the USA.

Reaper mentions the new plan, which is to have a conventional altcoin minting method whereby independent operators create the new aicoins each day and pay a software licence fee to the company, which in turn promotes and develops AI Coin for the benefit of operators, current and future holders. Even this business plan is subject to tweaking, as the software license may create an situation in which the deal between the company and its independent operators creates what the US SEC views as a security, which is subject to onerous regulation. As a lay person, my reading of the regulation and court decisions is that because the company is not the *sole* provider of effort which makes the deal valuable, then the deal is not a security. Instead I believe it is similar to retail store franchise agreements in the USA in which a share of store revenues is sent back to the franchisor. The analogy is that aicoin mining operators, its super peers, must perform effort too in order for the deal to be valuable. AI Coin Inc is seeking the advice of attorneys who know this sort of law. Fortunately, our president works in New York City, and networks conveniently with such law firms. If the software license becomes a poor choice due to SEC regulations, then another method to try for the desired revenue split would be to have a distinguished super peer owned by the company that gets more turns to create aicoins than the other super peers.


I was referring to the plan mentioned in a previous page, before this new one being informed here (I just follow this btctalk thread).

Your new plan looks much better, and unless you put a harsh percentage to be paid for the software fee (>%5), paying the fee won't be a huge minus for this POS model.


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: SlipperySlope on April 10, 2015, 01:53:09 PM
I was referring to the plan mentioned in a previous page, before this new one being informed here (I just follow this btctalk thread).

Your new plan looks much better, and unless you put a harsh percentage to be paid for the software fee (>%5), paying the fee won't be a huge minus for this POS model.

I will create the launch announcement thread next week, and retire this one.

The software license fee will be large, and furthermore the dollar share provided to the fixed number of super peer miners will be capped so that they earn a maximum of $1500 per month. From the viewpoint of the 20 or so super peers that may seem unfair, but it is a really good deal compared to operating a modest bitcoin or scrypt mining operation. Firstly, the equipment is rented from a datacenter at less than $500 per month, and the operator is not responsible for what the datacenter provides: site security, provisioning, DDoS protection, electricity and bandwidth. AI Coin software uses its intelligent agents to be relatively self-administering. We do not need to attract any more super peer operators beyond those already expressing interest and operating super peers on our demo network. We will have super peers in the USA, Iceland, Belgium, Italy, India, and Australia. At launch, AI Coin will create its new blocks in more places than Bitcoin's top six mining pools.

Our business plan entails the spending of the new aicoins, 7,200 each day, to optimally benefit the current and future users. A goal is to grow the aicoin price along the trajectory followed by Bitcoin over its six year history. We are not novel as Bitcoin was at the time of introduction, but we can spend aicoins for marketing, advertising, promotion, education, customer service, etc. in ways that the Bitcoin Foundation simply cannot. Metrics to measure the results of our plan execution include aicoin price relative to bitcoin and litecoin, number of ai-cointalk.org members, social media mentions, number of transactions, value of transactions, number of unspent transaction outputs, and so forth. Discovering customers and optimising the advertising expenditures is a solved problem. We will simply follow best practices.

In order to have funds to pay for the promotion and other means to bring AI Coin to the mainstream, it is necessary not to overspend for network infrastructure as does Bitcoin, nor overspend to make the rich richer, as does the typical proof-of-stake altcoin.

The best way to acquire aicoins will be to either buy them at Bittrex, or to earn them as a part-time contractor by performing tasks that benefit our system or our community. Note that US residents contractors will have to give the company bookkeeper (herself a part-time contractor) their name, address and SSN for our 1099-MISC federal tax reporting.



Title: Re: A.I. Coin Pre-Release Development Diary
Post by: coine_smithe on April 13, 2015, 12:28:26 PM
Thanks a lot for your constructive feedback!

Our team agree today to remove the animated robot graphic and make the ai-coin.org website better with respect to an audience beyond gamers. Plus we will do a better job for mobile.

Our inspiration sites that look great on large screen and on mobile too ...

Monero - https://getmonero.org/home (https://getmonero.org/home) (one page without vertical scrolling)

Ripple - https://ripple.com/ (https://ripple.com/) (aimed at financial institutions, good use of customer recommendations which highlight Ripple benefits, my favorite but obviously expensive)

Dash - https://www.dashpay.io/ (https://www.dashpay.io/) (scrolling with menu tabs, significant rebranding of privacy-centric Darkcoin)

I just saw the new site which looks a lot better. The toolbar up top is great and I assume you'll be adding more to it. I didn't see a Twitter or forum link on the site however. The new logo on the site looks good as well. The new one on the Twitter account looks kinda goofy though, you should match the banner and logo from the site to the Twitter account for continuity. Looking forward to launch!


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: Bitcoinmeister on April 13, 2015, 04:19:09 PM
Hello

I can't download the wallet on http://www.ai-coin.org/

when is the pre-sale planed?


Title: Re: AI Coin Development Diary
Post by: SlipperySlope on April 13, 2015, 05:23:31 PM
Launch Postponed

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.

Development continues.


Title: Re: AI Coin Development Diary
Post by: Hazard on April 13, 2015, 06:49:13 PM
Launch Postponed

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.

Development continues.
Good call.


Title: Re: AI Coin Development Diary
Post by: bybitcoin on April 16, 2015, 06:23:07 AM
Launch Postponed

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.

Development continues.
And you got back again to the previous temptatation?!
Everyone interested in buying into this should ask himself once and only once:
Why should a decentralized consensus ledger need to be fully licenced before it getting any traction at all?
Whose benefit could be legally at risk?
Not hard to see..!
Good luck.


Title: Re: AI Coin Development Diary
Post by: coinmaster222 on April 16, 2015, 06:29:23 AM
Launch Postponed

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.

Development continues.
And you got back again to the previous temptatation?!
Everyone interested in buying into this should ask himself once and only once: why should a decentralized consensus ledger need to be fully licenced before it getting any traction at all?
Whose benefit could be legally at risk?
Not hard to see..!
Good luck.

My thoughts exactly


Title: Re: AI Coin Development Diary
Post by: wowwow1 on April 16, 2015, 02:52:14 PM
Launch Postponed

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.

Development continues.
And you got back again to the previous temptatation?!
Everyone interested in buying into this should ask himself once and only once: why should a decentralized consensus ledger need to be fully licenced before it getting any traction at all?
Whose benefit could be legally at risk?
Not hard to see..!
Good luck.

My thoughts exactly
Its because they are selling the coins.
 There not giving them to everybody for free
Money Service Businesses
The term Money Service Business has a special meaning under the Money Laundering Regulations 2007. Your business is a Money Service Business under these regulations if it:

acts as a bureau de change - even if this is on a ship that isn’t always in UK territorial waters
transmits money, or any representation of money, in any way (just collecting and delivering money as a ‘cash courier’ isn’t transmitting money)
cashes cheques that are payable to your customers
Even if your business only does one of these things, it is still classed as a Money Service Business.

HMRC is the supervisory body for most Money Service Businesses under the Money Laundering Regulations. If you run a Money Service Business it’s your responsibility to register with HMRC unless you’re already supervised by the Financial Conduct Authority (FCA) for the purposes of the Money Laundering Regulations. You mustn’t act as a Money Service Business until you’re either registered with HMRC or supervised by the FCA.

Pawnbrokers who act as Money Service Businesses must register with HMRC, who will supervise both the pawnbroking and the money service aspects of their business.


When you don’t need to register as a Money Service Business
Occasional money service activities
If you exchange currency or cash cheques only occasionally, or only on a limited basis, then you don’t have to register as a Money Service Business if:

your total turnover from these money service activities is no more than £64,000 a year
turnover from money service activities is no more than 5 per cent of your total annual turnover
currency exchange or cheque cashing transactions worth more than €1,000 must be limited to one per customer - this could be one single transaction or a series of smaller transactions that seem to be linked
the money service activities must be secondary to your main business activity and directly related to it
the currency exchange or cheque cashing service must only be available to customers of the main business - it mustn’t be available to the public
your business isn’t operating as a Trust or Company Service Provider or an Accountancy Service Provider
You’ll need to meet all of these conditions, otherwise you have to have  licence.

I could imagine its almost the same for the U.S.A
UK and U.S.A are partners when it comes to money and war ;)

Plus can you tell me if someone sends coins to my wallet will they get to my wallet in a second
you say it does

And how much do you plan on selling your first batch of coins for












Title: Re: AI Coin Development Diary
Post by: freigeist on April 16, 2015, 05:22:24 PM
So to avoid this legal shit there could be several solutions maybe

1) if you still want deal with FIAT then register a company in Panama, Belize or any similar state
2) organize a lottery sell lottery tickets and the winners will get pries in your crypto coin
3) best option would not have anything to do with FIAT money just
distribute the crypto coin to the people ;)



Title: Re: AI Coin Development Diary
Post by: wowwow1 on April 16, 2015, 06:57:41 PM
So to avoid this legal shit there could be several solutions maybe

1) if you still want deal with FIAT then register a company in Panama, Belize or any similar state
2) organize a lottery sell lottery tickets and the winners will get pries in your crypto coin
3) best option would not have anything to do with FIAT money just
distribute the crypto coin to the people ;)


YES deal with every fiat on the planet earth.
 And deal fiat on every planet in the universe. ;)

If you want success in AIcoin government need to approve
best to do it by the book like they are doing ;)

so be keeping my eye on this 1

plus well done DEVS looking good





Title: Re: AI Coin Development Diary
Post by: SlipperySlope on April 20, 2015, 02:51:50 AM
AI Coin cannot sell the coins created without requiring a MSB license. We were in the process of obtaining a FinCEN license, which is a US Federal License that specifies what sort of reporting is required to FinCEN. That agency routine accepts registrations. Our would-have-been partner exchange Bittrex is already registered with FinCEN, but not licensed in the 48 US States as an MSB.

Our attorneys said that all US cryptocurrency exchanges are categorized as MSBs as they interpret the FinCEN guidance issued last year. Although that requirement is not being enforced currently, AI Coin would have no available means of exchange in the USA should it have launched without the licenses, and a crackdown by the States shut down all the altcoin exchanges in the USA.



Title: Re: AI Coin Development Diary
Post by: coinmaster222 on April 21, 2015, 02:21:45 AM
Just stay clear of the US dollar,if you want to use Fiat use UK Pound or Euro


Title: Re: AI Coin Development Diary
Post by: pa on April 27, 2015, 07:15:57 PM
AI Coin cannot sell the coins created without requiring a MSB license. We were in the process of obtaining a FinCEN license, which is a US Federal License that specifies what sort of reporting is required to FinCEN. That agency routine accepts registrations. Our would-have-been partner exchange Bittrex is already registered with FinCEN, but not licensed in the 48 US States as an MSB.

Our attorneys said that all US cryptocurrency exchanges are categorized as MSBs as they interpret the FinCEN guidance issued last year. Although that requirement is not being enforced currently, AI Coin would have no available means of exchange in the USA should it have launched without the licenses, and a crackdown by the States shut down all the altcoin exchanges in the USA.



I'm sorry if this has already been asked and answered. I haven't been following your project closely. Why not distribute AI Coin as a "spin off" of Bitcoin's blockchain, so that everyone who owns btc can claim a corresponding amount of AI Coin?


Title: Re: AI Coin Development Diary
Post by: wowwow1 on April 28, 2015, 02:36:55 PM
AI Coin cannot sell the coins created without requiring a MSB license. We were in the process of obtaining a FinCEN license, which is a US Federal License that specifies what sort of reporting is required to FinCEN. That agency routine accepts registrations. Our would-have-been partner exchange Bittrex is already registered with FinCEN, but not licensed in the 48 US States as an MSB.

Our attorneys said that all US cryptocurrency exchanges are categorized as MSBs as they interpret the FinCEN guidance issued last year. Although that requirement is not being enforced currently, AI Coin would have no available means of exchange in the USA should it have launched without the licenses, and a crackdown by the States shut down all the altcoin exchanges in the USA.



I'm sorry if this has already been asked and answered. I haven't been following your project closely. Why not distribute AI Coin as a "spin off" of Bitcoin's blockchain, so that everyone who owns btc can claim a corresponding amount of AI Coin?
So how do aicoin make any money.
there not going to do all that work for nothing come on would you they need to make a living..

Plus there trying to get a patent it will never happen NO CHANCE ..
J.P MORGAN could not get 1 and they tried over 100 times always rejected ..


Title: Re: AI Coin Development Diary
Post by: 4x13 on June 01, 2015, 04:17:08 PM
OK, so when is the tentative release??


Title: Re: AI Coin Development Diary
Post by: coine_smithe on September 24, 2015, 04:11:01 PM
http://www.tenebrousmagazine.com/sitebuildercontent/sitebuilderpictures/skeleton-computer.jpg


Title: Re: AI Coin Development Diary
Post by: bubbaj on December 29, 2016, 02:07:22 AM
Another dead idea


Title: Re: AI Coin Development Diary
Post by: BitDreams on October 22, 2019, 05:29:10 AM
OK, so when is the tentative release??

SlipperySlope has lost control of his username in one of the past breaches and I asked him if I could post an update to this thread so here it is:

https://medium.com/@stephen_17820/the-birth-of-self-improving-artificial-intelligence-60df743b2505

My Brothers Twitter Profile:  https://twitter.com/stephenlreed (SlipperySlope)


Title: Re: A.I. Coin Pre-Release Development Diary
Post by: BitDreams on October 22, 2019, 06:36:08 AM
... pay a software licence fee to the company...

This coin will not take off under that model.
What will happen, is that all of your technology will be copied and used in a clone that will take off.

Of course, you can get around this by making the coin closed source, in which case I doubt you'll ever sell one license fee.



I have to agree with drawingthesun. Mining is hard enough as it is without having to pay the devs / parent company / whoever for the privilege. That might make it a hard sell.


https://github.com/ai-coin/KafkaBlockchain


Title: Re: AI Coin Development Diary
Post by: BitDreams on October 23, 2019, 11:48:00 PM
Another dead idea

We are back. https://medium.com/@stephen_17820/online-combined-opencyc-wordnet-and-wiktionary-a06757531cbe