How could the bitcoin protocol be changed? Has this ever ...

It's time for a break: About the recent mess & temporary new rules

Unfortunately, I was on vacation this weekend, so I was unable to prevent /Bitcoin from becoming messy. Sorry about that. I and other moderators more-or-less cleaned it up. Report anything that we missed.
Because people are still probably in a "troll-happy" mood from the lack of moderation, moderation will be increased for a while. Everyone needs some time to calm down. In particular, posts about anything especially emotionally-charged will be deleted unless they introduce some very substantial new ideas about the subject. This includes the max block size debate (any side) and /Bitcoin moderation. Also, people are continuously spamming links to inferior clones of /Bitcoin and the XT subreddit -- these links will be removed and the posters banned unless the links are remarkably appropriate for the given situation. When this sticky is removed, the rules will return to what they were previously.
It is possible that some people have been or will be banned too readily due to the increased moderation. If this happens to you, mail /Bitcoin with a justification of your actions, then wait 2 days and mail again if there's no satisfactory response, then wait 4 days, then 8, 16, 32, etc. If your mail to /Bitcoin is too high-volume, we may block all further mail from you, which will make it impossible for your to appeal your ban.

About XT

/Bitcoin exists to serve Bitcoin. XT will, if/when its hardfork is activated, diverge from Bitcoin and create a separate network/currency. Therefore, it and services that support it should not be allowed on /Bitcoin. In the extremely unlikely event that the vast majority of the Bitcoin economy switches to XT and there is a strong perception that XT is the true Bitcoin, then the situation will flip and we should allow only submissions related to XT. In that case, the definition of "Bitcoin" will have changed. It doesn't make sense to support two incompatible networks/currencies -- there's only one Bitcoin, and /Bitcoin serves only Bitcoin.
If a hardfork has near-unanimous agreement from Bitcoin experts and it's also supported by the vast majority of Bitcoin users and companies, we can predict with high accuracy that this new network/currency will take over the economy and become the new definition of Bitcoin. (Miners don't matter in this, and it's not any sort of vote.) This sort of hardfork can probably be adopted on /Bitcoin as soon as it has been determined that the hardfork is not absolutely against the spirit of Bitcoin (inflating out-of-schedule, for example). For right now, there will always be too much controversy around any hardfork that increases the max block size, but this will probably change as there's more debate and research, and as block space actually becomes more scarce. I could see some kind of increase gaining consensus in as soon as 6 months, though it would have to be much smaller than the increase in XT for ~everyone to agree on it so soon.
There's a substantial difference between discussion of a proposed Bitcoin hardfork (which was previously always allowed here, even though I strongly disagree with many things posted) and promoting software that is programmed to diverge into a competing network/currency. The latter is clearly against the established rules of /Bitcoin, and while Bitcoin's technology will continue working fine no matter what people do, even the attempt at splitting Bitcoin up like this will harm the Bitcoin ecosystem and economy.

Why is XT considered an altcoin even though it hasn't broken away from Bitcoin yet?

Because it is intentionally programmed to diverge from Bitcoin, I don't consider it to be important that XT is not distinct from Bitcoin quite yet. If someone created a fork of Bitcoin Core that allowed miners to continue mining 25 BTC per block forever, would that be "Bitcoin" even though it doesn't split from the Bitcoin currency/network quite yet? (I'd say no.)

Can I still talk about hard fork proposals on /Bitcoin?

Right now, not unless you have something really new and substantial to say.
After this sticky is removed, it will be OK to discuss any hardfork to Bitcoin, but not any software that hardforks without consensus, since that software is not Bitcoin.

If XT is an altcoin then why aren't sidechains or Lightning altcoins?

/Bitcoin is about the Bitcoin currency and network. Lightning allows you to move the Bitcoin currency. Sidechains are on-topic in general because they are a possibly-useful addition to the Bitcoin network. It is possible that some specific sidechains might not be on-topic -- this isn't clear to me yet.
XT is programmed to create a separate currency and network, so it is not Bitcoin.

How do you know that there is no consensus?

Consensus is a high bar. It is not the same as a majority. In general, consensus means that there is near-unanimity. In the very particular case of a hardfork, "consensus" means "there is no noticeable probability that the hardfork will cause the Bitcoin economy to split into two or more non-negligible pieces".
I know almost for certain that there is no consensus to the change in XT because Bitcoin core developers Wladamir, Greg, and Pieter are opposed to it. That's enough to block consensus. And it works both ways: if Gavin and Mike are strongly opposed to Pieter's BIP, then this will also block consensus on that BIP.
Other than the core devs, big Bitcoin companies (especially Coinbase, BitPay, and exchanges) could block consensus, as could large groups of average users who are collectively capable of making reasonable arguments and exerting economic force (probably not just random unknown people complaining about nothing).
Even though consensus is such a high bar, I think that in practice any hardfork that gets consensus among the Bitcoin Core devs and makes it into Bitcoin Core has a good chance of succeeding. But again, the developers would just be spearheading the effort, and many others could block them if necessary.

But with such a high bar, 8 MB blocks will be impossible!

If consensus can never be reached on one particular hardfork proposal, then the hardfork should never occur. Just because you want something doesn't mean that it's ever reasonable for you to hijack Bitcoin from the people who don't want it, even if your side is the majority (which it isn't in this case). This isn't some democratic country where you can always get your way with sufficient politicking. Get consensus, live without the change, or create your own altcoin.
Hard forks are supposed to be hard. While some hard forks will probably be necessary in the long run, these hard forks will need to have consensus and be done properly or Bitcoin will die due to the economy being constantly shattered into several pieces, or as a side-effect of forcing through technically unsound changes that the majority of experts disagree with (like XT's 8MB block size).

Don't most experts want 8 MB blocks soon?

Not by any reasonable idea of "most experts" I can think of. For example, among people with expert flair on /Bitcoin, AFAIK any large near-term increase is opposed by nullc, petertodd, TheBlueMatt, luke-jr, pwuille, adam3us, maaku7, and laanwj. A large near-term increase is supported by gavinandresen, jgarzik, mike_hearn, and MeniRosenfeld. (Those 12 people are everyone with expert flair.)
I've heard concerns that some experts who oppose any large near-term increase have conflicts of interest. But many of them have been expressing the same concerns for years, so it's unlikely that any recent possible conflict of interest is influencing them. Also, if they believed that increasing the max block size would help Bitcoin as a whole, what reason would they have to prevent this? I don't see the incentive.
We don't need to trust the above list of experts, of course. But I for one have found the conservative position's arguments to be much more convincing than the huge-increase position's arguments. It's not reasonable to say, "You know a lot more than I do, and I don't see any fault in your arguments, but you must be trying to trick me due to this potential conflict of interest, so I'm going to ignore you."

Who are you working for?

I am not an employee of anyone but myself. As far as I know my only incentives for engaging in this policy are to make Bitcoin as strong as possible for ideological reasons, and in the long-term to increase the Bitcoin price. When I make policies, I do so because I believe that they are right. I am not being paid for my work on /Bitcoin or for creating certain policies.
It would have been far easier for me to simply allow XT. If I was a politician or a business, I probably would have bowed to community demands already. And on several occasions I have very seriously considered the possibility that I could be wrong here and the community right. But in the end I just don't see any way to both reasonably and consistently deal with XT and cases similar to XT except to ban them on /Bitcoin. Additionally, I am further motivated by my knowledge that a "hostile hardfork" like the one in XT is very harmful for Bitcoin no matter what the change entails, and that the change in XT is in fact amazingly bad.

See also

See my previous posts on this subject and the discussion in their child comments. Keep in mind that my comments are often downvoted to the point of being hidden by default.
Also, someone who could be Satoshi posted here. This email address was actually used by Satoshi before he left, and the email apparently did come from that email address legitimately (not a spoof). Whether he's actually Satoshi or not, I agree with what he's saying.

About majoritarianism

Just because many people want something doesn't make it right. There is example after example of this in history. You might reasonably believe that democracy is the best we can do in government (though I disagree), but it's not the best we can do with private and independent forums on the free market.
If you disagree with /Bitcoin policy, you can do one of these things:
Do not violate our rules just because you disagree with them. This will get you banned from /Bitcoin, and evading this ban will get you (and maybe your IP) banned from Reddit entirely.
If 90% of /Bitcoin users find these policies to be intolerable, then I want these 90% of /Bitcoin users to leave. Both /Bitcoin and these people will be happier for it. I do not want these people to make threads breaking the rules, demanding change, asking for upvotes, making personal attacks against moderators, etc. Without some real argument, you're not going to convince anyone with any brains -- you're just wasting your time and ours. The temporary rules against blocksize and moderation discussion are in part designed to encourage people who should leave /Bitcoin to actually do so so that /Bitcoin can get back to the business of discussing Bitcoin news in peace.
The purpose of moderation is to make the community a good one, which sometimes includes causing people to leave.

This thread

You can post comments about moderation policy here, but nowhere else.
submitted by theymos to Bitcoin [link] [comments]

Bobtail: A Proof-of-Work Target that Minimizes Blockchain Mining Variance

Date: 2017-10-19
Author(s): George Bissias, Brian Neil Levine

Link to Paper

Blockchain systems are designed to produce blocks at a constant average rate. The most popular systems currently employ a Proof of Work (PoW) algorithm as a means of creating these blocks. Bitcoin produces, on average, one block every 10 minutes. An unfortunate limitation of all deployed PoW blockchain systems is that the time between blocks has high variance. For example, 5% of the time, Bitcoin's inter-block time is at least 40 minutes. This variance impedes the consistent flow of validated transactions through the system. We propose an alternative process for PoW-based block discovery that results in an inter-block time with significantly lower variance. Our algorithm, called Bobtail, generalizes the current algorithm by comparing the mean of the k lowest order statistics to a target. We show that the variance of inter-block times decreases as k increases. If our approach were applied to Bitcoin, about 80% of blocks would be found within 7 to 12 minutes, and nearly every block would be found within 5 to 18 minutes; the average inter-block time would remain at 10 minutes. Further, we show that low-variance mining significantly thwarts doublespend and selfish mining attacks. For Bitcoin and Ethereum currently (k=1), an attacker with 40% of the mining power will succeed with 30% probability when the merchant sets up an embargo of 8 blocks; however, when k>=20, the probability of success falls to less than 1%. Similarly, for Bitcoin and Ethereum currently, a selfish miner with 40% of the mining power will claim about 66% of blocks; however, when k>=5, the same miner will find that selfish mining is less successful than honest mining. The cost of our approach is a larger block header.

[1] Bitcoin cash.
[2] Litecoin.
[3] Ethash., Aug 3 2017.
[4] Martin Abadi, Mike Burrows, Mark Manasse, and Ted Wobber. Moderately hard, memory-bound functions. ACM Trans. Internet Technol., 5(2):299–327, May 2005.
[5] Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo. Dos-resistant authentication with client puzzles. In Revised Papers from the 8th International Workshop on Security Protocols, pages 170–177, 2001.
[6] Adam Back. Hashcash - Amortizable Publicly Auditable CostFunctions, 2002.
[7] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. Cryptocurrencies without proof of work. In International Conference on Financial Cryptography and Data Security, pages 142–157. Springer, 2016.
[8] Iddo Bentov, Charles Lee, Alex Mizrahi, and Meni Rosenfeld. Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake [Extended Abstract] y. ACM SIGMETRICS Performance Evaluation Review, 42(3):34–37, 2014.
[9] Bobtails.
[10] Xavier Boyen, Christopher Carr, and Thomas Haines. BlockchainFree Cryptocurrencies: A Framework for Truly Decentralised Fast Transactions. Cryptology ePrint Archive, Report 2016/871, Sept 2016.
[11] George Casella and Roger L. Berger. Statistical inference. Brooks Cole, Pacific Grove, CA, 2002.
[12] Liqun Chen and Wenbo Mao. An auditable metering scheme for web advertisement applications. Information Security, pages 475–485, 2001.
[13] F. Coelho. An (Almost) Constant-Effort Solution- Verification Proofof-Work Protocol Based on Merkle Trees. In Progress in Cryptology – AFRICACRYPT, pages 80–93, June 2008.
[14] Drew Dean and Adam Stubblefield. Using client puzzles to protect tls. In Proceedings of the 10th Conference on USENIX Security Symposium - Volume 10, SSYM’01, Berkeley, CA, USA, 2001. USENIX Association.
[15] J. Douceur. The Sybil Attack. In Proc. Intl Wkshp on Peer-to-Peer Systems (IPTPS), March 2002.
[16] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In In 12th Annual International Cryptology Conference, pages 139–147, 1992.
[17] Ethereum Homestead Documentation.
[18] Ittay Eyal, Adem Efe Gencer, Emin Gun Sirer, and Robbert Van Renesse. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 45–59, Santa Clara, CA, 2016. USENIX Association.
[19] Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining is vulnerable. In International conference on financial cryptography and data security, pages 436–454. Springer, 2014.
[20] M. Franklin and D. Malkhi. Auditable metering with ligthweigth security. In Proc. Financial Cryptography, pages 151–160, 1997.
[21] Arthur Gervais, Ghassan O. Karame, Karl Wust, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. On the Security and Performance of Proof of Work Blockchains., 2016.
[22] Bogdan Groza and Bogdan Warinschi. Cryptographic puzzles and dos resilience, revisited. Des. Codes Cryptography, 73(1):177–207, October 2014.
[23] Markus Jakobsson and Ari Juels. Proofs of Work and Bread Pudding Protocols. In Proc. Conference on Secure Information Networks: Communications and Multimedia Security, pages 258–272, 1999.
[24] A. Juels and J. Brainard. Client puzzles: A cryptographic countermeasure against connection depletion attacks. In Proc. Networks and Distributed Security Systems, pages 151–165, 1999.
[25] Ben Laurie and Richard Clayton. “Proof-of-work" proves not to work; version 0.2. In Proc. Workshop on Economics and Information Security, 2004.
[26] Andrew Miller, Ari Juels, Elaine Shi, Bryan Parno, and Jonathan Katz. Permacoin: Repurposing bitcoin work for data preservation. In Proc. IEEE Security and Privacy, pages 475–490, 2014.
[27] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, May 2009.
[28] A. Pinar Ozisik and Brian Neil Levine. An Explanation of Nakamoto’s Analysis of Double-spend Attacks. Technical Report arXiv:1701.03977, University of Massachusetts, Amherst, MA, January 2017.
[29] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal Selfish Mining Strategies in Bitcoin., July 2015.
[30] XiaoFeng Wang and Michael K. Reiter. Defending against denial-ofservice attacks with puzzle auctions. In Proceedings of the 2003 IEEE Symposium on Security and Privacy, SP ’03, pages 78–, Washington, DC, USA, 2003. IEEE Computer Society
submitted by dj-gutz to myrXiv [link] [comments]

We are the Global Bitcoin Alliance, Ask Us Anything

Hello /bitcoin!
We are the Global Bitcoin Alliance, a decentralized network of non-profit organizations that promote and protect Bitcoin around the world. We have been promoting Bitcoin for some time, providing information, encouraging business and individual adoption, locally in our respective regions, and globally.
If you have questions for us on any topic, please post them here.
Unfortunately not everyone could make it, but we have with us today:
We will be here for at least next hour taking your questions, but the post will be live longer than that - we'll be sure to direct your questions to the right people even after this time window.
submitted by ripper2345 to Bitcoin [link] [comments]

Estimation of Miner Hash Rates and Consensus on Blockchains

Date: 2017-07-01
Author(s): A. Pinar Ozisik, George Bissias, Brian Levine

Link to Paper

We make several contributions that quantify the real-time hash rate and therefore the consensus of a blockchain. We show that by using only the hash value of blocks, we can estimate and measure the hash rate of all miners or individual miners, with quanti able accuracy. We apply our techniques to the Ethereum and Bitcoin blockchains; our solution applies to any proof-of-work-based blockchain that relies on a numeric target for the validation of blocks. We also show that if miners regularly broadcast status reports of their partial proof-of- work, the hash rate estimates are signi cantly more accurate at a cost of slightly higher bandwidth. Whether using only the blockchain, or the additional information in status reports, merchants can use our techniques to quantify in real-time the threat of double-spend attacks.

[1] 2015. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. (July 2015).
[2] 2016. Gnosis. (November 2016).
[3] Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. 2016. "MedRec: Using Blockchain for Medical Data Access and Permission Management. In Proc. Intl. Conf. on Open and Big Data. 25–30.
[4] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille. 2014. Enabling Blockchain Innovations with Pegged Sidechains. Technical report. (Oct 22 2014).
[5] Simon Barber, Xavier Boyen, Elaine Shi, and Ersin Uzun. 2012. Bitter to better—how to make bitcoin a better currency. In International Conference on Financial Cryptography and Data Security. Springer, 399–414.
[6] Bryan Bishop. 2015. bitcoin-dev mailling list: Weak block thoughts... (Sep 2015).
[7] bitcoin 2015. Confirmation. (February 2015).
[8] Joseph Bonneau. 2015. How long does it take for a Bitcoin transaction to be confirmed? (November 2015).
[9] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J.A. Kroll, and E.W. Felten. 2015. SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. In IEEE S&P. 104–121. SP.2015.14
[10] George Casella and Roger L. Berger. 2002. Statistical inference. Brooks Cole, Pacific Grove, CA. http://opac.inria.frecord=b1134456
[11] Kyle Croman et al. 2016. On Scaling Decentralized Blockchains . In Workshop on Bitcoin and Blockchain Research.
[12] Digix. 2017. (Last retrieved June 2017).
[13] DigixDAO. 2017. (Last retrieved June 2017).
[14] J. Douceur. 2002. The Sybil Attack. In Proc. Intl Wkshp on Peer-to-Peer Systems (IPTPS).
[15] Bradley Efron. 1982. The jackknife, the bootstrap and other resampling plans. Society for industrial and applied mathematics (SIAM).
[16] Ethash. 2017. (Last retrieved June 2017).
[17] ethereum. Ethereum Homestead Documentation. (????).
[18] Etheria. 2017. (Last retrieved June 2017).
[19] Ittay Eyal and Emin Gün Sirer. 2014. Majority is not enough: Bitcoin mining is vulnerable. Financial Cryptography (2014), 436–454.
[20] William Feller. 1968. An Introduction to Probability Theory and its Applications: Volume I. Vol. 3. John Wiley & Sons London-New YorkSydney-Toronto.
[21] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. 2015. The bitcoin backbone protocol: Analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 281–310.
[22] Arthur Gervais, Ghassan O. Karame, Karl Wust, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. 2016. On the Security and Performance of Proof of Work Blockchains. (2016).
[23] Hashcash. 2017. (Last retrieved June 2017).
[24] Ethan Heilman, Leen Alshenibr, Foteini Baldimtsi, Alessandra Scafuro, and Sharon Goldberg. 2017. TumbleBit: An untrusted Bitcoincompatible anonymous payment hub. In Proc. ISOC Network and Distributed System Security Symposium (NDSS).
[25] Svante Janson. 2014. Tail Bounds for Sums of Geometric and Exponential Variable. Technical Report. Uppsala University.
[26] Litecoin. 2017. (Last retrieved June 2017).
[27] Satoshi Nakamoto. 2009. Bitcoin: A Peer-to-Peer Electronic Cash System. (May 2009).
[28] A. Pinar Ozisik, Gavin Andresen, George Bissias, Amir Houmansadr, and Brian Neil Levine. 2016. A Secure, Efficient, and Transparent Network Architecture for Bitcoin. Technical Report UM-CS-2016-006. University of Massachusetts, Amherst, MA.
[29] Meni Rosenfeld. 2012. Analysis of hashrate-based double-spending. (December 2012).
[30] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. 2015. Optimal Selfish Mining Strategies in Bitcoin. (July 2015).
[31] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized Anonymous Payments from Bitcoin. In IEEE S&P. 459–474.
[32] Yonatan Sompolinsky and Aviv Zohar. 2015. Secure high-rate transaction processing in Bitcoin. Financial Cryptography and Data Security (2015).
[33] Yonatan Sompolinsky and Aviv Zohar. 2016. Bitcoin’s Security Model Revisited. (May 2016).
[34] F. Tschorsch and B. Scheuermann. 2016. Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies. IEEE Communications Surveys Tutorials PP, 99 (2016), 1–1. 2016.2535718
[35] Marko Vukolić. 2015. The quest for scalable blockchain fabric: Proof-ofwork vs. BFT replication. In International Workshop on Open Problems in Network Security. Springer, 112–125.
submitted by dj-gutz to myrXiv [link] [comments]

Personalized Difficulty Adjustment for Countering the Double-Spending Attack in Proof-of-Work Consensus Protocols

Date: 2018-07-09
Author(s): Chi-Ning Chou, Yu-Jing Lin, Ren Chen, Hsiu-Yao Chang, I-Ping Tu, Shih-wei Liao

Link to Paper

Bitcoin is the first secure decentralized electronic currency system. However, it is known to be inefficient due to its proof-of-work (PoW) consensus algorithm and has the potential hazard of double spending. In this paper, we aim to reduce the probability of double spending by decreasing the probability of consecutive winning. We first formalize a PoW-based decentralized secure network model in order to present a quantitative analysis. Next, to resolve the risk of double spending, we propose the personalized difficulty adjustment (PDA) mechanism which modifies the difficulty of each participant such that those who win more blocks in the past few rounds have a smaller probability to win in the next round. To analyze the performance of the PDA mechanism, we observe that the system can be modeled by a high-order Markov chain. Finally, we show that PDA effectively decreases the probability of consecutive winning and results in a more trustworthy PoW-based system.

[1] Satoshi Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Consulted, vol. 1, no. 2012.
[2] Ephraim Feig, “A framework for blockchain-based applications,” arXiv preprint arXiv:1803.00892, 2018.
[3] Marta Piekarska Harry Halpin, “Introduction to security and privacy on the blockchain,” in Symposium on Security and Privacy Workshops, 2017 IEEE European Symposium on. IEEE, 2017.
[4] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar, “Optimal selfish mining strategies in bitcoin,” in Financial Cryptography and Data Security. 2017, pp. 515–532, Springer.
[5] Ghassan Karame, Elli Androulaki, and Srdjan Capkun, “Two bitcoins at the price of one? double-spending attacks on fast payments in bitcoin.,” IACR Cryptology ePrint Archive, vol. 2012.
[6] Ghassan O Karame, Elli Androulaki, Marc Roeschlin, Arthur Gervais, and Srdjan Capkun, “Misbehavior in bitcoin: A study ˇ of double-spending and accountability,” ACM Transactions on Information and System Security (TISSEC), vol. 18, no. 1.
[7] Tobias Bamert, Christian Decker, Lennart Elsen, Roger Wattenhofer, and Samuel Welten, “Have a snack, pay with bitcoins,” in Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on. IEEE, 2013, pp. 1–5.
[8] Chrysoula Stathakopoulou, “A faster bitcoin network,” 2015.
[9] Adrian E Raftery, “A model for high-order markov chains,” Journal of the Royal Statistical Society. Series B (Methodological), pp. 528–539, 1985.
[10] Andre Berchtold and Adrian E Raftery, “The mixture tran- ´sition distribution model for high-order markov chains and non-gaussian time series,” Statistical Science, pp. 328–356, 2002.
[11] Waiki Ching, Michael K Ng, and Shuqin Zhang, “On computation with higher-order markov chains,” in Current Trends in High Performance Computing and Its Applications, pp. 15–24. Springer, 2005.
[12] Michael K Ng and WK Ching, Markov Chains: Models, Algorithms and Applications, Springer, 2006.
[13] Wen Li and Michael K Ng, “On the limiting probability distribution of a transition probability tensor,” Linear and Multilinear Algebra, vol. 62, no. 3.
[14] Jen-Hung Tseng, Yen-Chih Liao, Bin Chong, and Shih-Wei Liao, “Governance on the drug supply chain via gcoin blockchain,” International Journal of Environmental Research and Public Health, 2018.
[15] Shih-Wei Liao, Boyu Lin, and En-Ran Zhou, “Gcoin:wiki, code and whitepaper,” and, 2014.
[16] Meni Rosenfeld, “Analysis of hashrate-based double spending,” arXiv preprint arXiv:1402.2009, 2014.
[17] Joshua A Kroll, Ian C Davey, and Edward W Felten, “The economics of bitcoin mining, or bitcoin in the presence of adversaries,” in Proceedings of WEIS, 2013, vol. 2013.
submitted by dj-gutz to myrXiv [link] [comments]

Why do I believe it was BCN destiny to be born in 2012?

Why do I believe it was BCN destiny to be born in 2012? Just look at this and see yourself:
1983 - Blind signatures were invented by David Chaum link 1997 - HashCash (proof of work system) was invented by Adam Back link
2001 - Ring signatures were invented by Ron Rivest, Adi Shamir, and Yael Tauman link
2003 - Mart n Abadi, Michael Burrows, and Ted Wobber presented "Moderately hard, memory-bound functions"link
2004 - Patrick P. Tsang and Victor K. Wei presented their paper "Short linkable ring signatures for e-voting, e-cash and attestation" link
2005 - Matthew Franklin and Haibin Zhang with "Unique Group Signatures" study link
2005 - Exponential memory-bound functions for proof of work protocols by Fabien Coelho link +2006 - "Traceable Ring Signature" by Fujisaki and Suzuki link
2008 - Bitcoin whitepaper by Satoshi Nakamoto link
2009 - Stronger key derivation via sequential memory-hard functions by Colin Percival link
2009 - First Bitcoin block was generated
2010 -2012 - Bitcoin Anonymity Problem Discussions link
2011 - An Analysis of Anonymity in the Bitcoin System, Fergal Reid and Martin Harrigwere link
5/15/2012 - Dorit Ron and Adi Shamir made Quantitative Analysis of the Full Bitcoin Transaction Graph link
6/8/2012 - Bytecoin Wiki started link
6/30/2012 - Bytecoin launch announcement link- first news
7/4/2012 - First BCN block was generated link
8/6/2012 - Destination Address Anonymization in Bitcoin (one-time addresses in BCN) link
10/19/2012 - Evaluating User Privacy in Bitcoin by Elli Androulaki, Ghassan O. Karame, Marc Roeschlin, Tobias Scherer, Srdjan Capkun. link
12/12/2012 -CryptoNote whitepaper v 1.0 link
12/13/2012 - Analysis of hashrate-based double-spending, Meni Rosenfeld link
10/17/2013 - CryptoNote whitepaper v 2.0 link
Here we see how the technology logically came to the advent of cryptocurrencies with ring signature and memory-bound function PoW implementation. Soon after Bitcoin's release the community started to raise concerns about its anonymity with multiple solutions and propositions. High concentration of theoretical papers on these topics in 2009-2011 most probably spurred the brightest minds to make attempts of practical e-cash with ring signatures realization. Therefore, BCN couldn't but appear in 2012.
Based on
submitted by joethejudge77 to BytecoinBCN [link] [comments]

Decred - An Overview

Decred is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. At its core is a hybridized proof-of-work proof-of-stake (PoW/PoS) consensus system that aims to strike a balance between PoW miners and PoS voters to create a more robust notion of consensus. The project is a result of the theoretical proposals brought by proof-of-activity (PoA) and MC2 in 2013. Decred development started in April, 2014 with a single developer and expanded to include developers from btcsuite shortly thereafter.
Decred is built in the spirit of open participation and we have provided below a full disclosure of the technical features of the system, wallets and mining, initial funding and distribution, project governance and development, and a group contribution timeline. We hope to launch mainnet on January 18th, 2016, and will provide additional details in this thread. Everyone is welcome to participate, and you are certainly welcome to join the development and project groups if you have interest in contributing to our efforts!
i. Technical Features
The features below are implemented in Decred and will be available in full at launch. For a deeper description, please consult the Decred Technical Brief (DTB001).
•Novel hybridized proof-of-work/proof-of-stake (PoW/PoS) consensus system - A decentralized lottery is used to select PoS miners to vote on PoW blocks. The PoW and PoS subsidies account for 60% and 30% of each total block subsidy, respectively. This system is based on that of MC2, which is very similar to, but developed independently from, Proof-of-Activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld. •Cold staking and decentralized stake pooling - The ability to generate new coins without the risk of having your coins online when PoS mining. The PoS mining system has also been engineered with distributed, decentralized stake pooling in mind, so that even those with small amounts of stake can participate in network validation. •Internal voting system for the addition of new features and hard or soft fork selection - Both PoW and PoS miners can vote for features and issues through bit flags, providing a sensible mechanism for resolving disputes about the features of the blockchain. •Immutable transaction hashes ("transaction IDs") by separating transaction signatures from the rest of the transaction data - A permanent fix for transaction hash malleability has been implemented that prevents mutability of the transaction hash by separating it from its input signatures. This allows more efficient SPV validation. Fraud proofs have also been added. •Elliptic curve cryptography over secp256k1 with optional Curve25519 support - The Bitcoin scripting system has been modified to allow for simple, drop-in addition of new elliptical curve digital signature algorithms. •Schnorr signatures with threshold n-of-n support - In addition to supporting Schnorr signatures, groups of signers can now jointly sign transactions off-chain in constant size signatures, ensuring higher privacy and less blockchain bloat. •Script enhancements and new OP codes - New OP codes have been added to the existing Bitcoin scripting engine, and extensions for the plug-in use of future scripting engines have been added. •PoW mining using BLAKE256 hash algorithm - Inspired by Bernstein's Chacha stream cipher, SHA3 finalist BLAKE256 offers speed as well as high security. •Compatibility with Bitcoin transaction scripting system - Decred's scripting system has been derived from Bitcoin's with care in ensuring that all future updates to the Bitcoin transaction script will be easily extensible to Decred. Further, any newly created functionalities will also be devised with backwards compatibility with Bitcoin in mind. •Modularized, easy-to-use Golang btcsuite codebase - Thanks the to the codebase inherited from btcsuite, adding new features to the daemon or wallet will be facile. Decred will episodically sync updates from btcsuite, so that it benefits from the latest developments in Bitcoin. •Hierarchical deterministic (HD) wallets - Wallets use a seed to deterministically generate addresses, so your wallet can be restored from a single BIP0032 seed. •Transaction expiration - Transactions have a new expiration field to prevent inclusion into the blockchain after a certain height. •Patches for intrinsic Bitcoin bugs - Extra push for multisignature scripts has been removed, SIGHASH_SINGLE behavior has been corrected. •Approximately 21 million coins - Exponential decay in subsidy or the number of coins generated per year. •Self-funded development via block subsidy - In order to have an ongoing source of funding for development work, a consensus rule has been added to allocate 10% of each block subsidy to a development organization. This entity is transparent and responsible for funding development work performed by current and new developers so that the project remains sustainable without a funding dependence on outside forces in the future. Decred therefore improves with growth in a sustainable way and is accountable only to its users.
ii. Wallets and Mining
•Web wallet service - In order for users to have access to a GUI on all platforms, we have created a web wallet service forked from BitPay's Copay wallet and its dependencies. This wallet allows users to access all the basics with Decred: sending and receiving coins, multisig transactions. •Command-line wallet - For more advanced users, we have a command-line wallet, dcrwallet. dcrwallet allows users to mine PoS and collect rewards by participating in the PoW/PoS consensus system. •Simple GPU miner - A simple AMD GPU miner that connects to a local daemon will be available before launch. In the future, proper getblocktemplate functionality will be enabled and pool software will be made available.
iii. Initial Funding and Airdrop
Decred opted for a different funding model in an attempt to shift the risk carried by supporters to the developers of the project. Instead of asking interested parties to fund the development of the software, the developers decided to pool funds together and carry the project to completion before making it public. The consensus was that this is an ethical path given the realities of funding software development, due to the fact that the developers alone carry the risk of the project failing, whereas in the past potential users were expected to pay for coins before any code was written. We felt this was unjust.
The development of Decred was funded by Company 0 and from the pockets of its developers individually. The cost of developing the project, in terms of developer pay, totals to approximately USD 250,000, which Company 0 paid to developers. An additional amount of approximately USD 165,000 has been allocated for unpaid work and individual purchases by developers. We felt that the most equitable way to handle compensation for these expenses was to perform a small premine as part of the project launch. The model is unusual in that no developer received any amount of coins for free - all coins owned by developers will either be purchased at a rate of USD 0.49 per coin from their own pockets or exchanged for work performed at the same rate.
The premine consists of 8% of the total supply of 21 million coins, meaning the premine consists of 1.68 million coins. Rather than allocating the entire premine to the bring-up costs, we decided to split the premine equally between compensation for bring-up and an "airdrop", where we freely give an equal amount of coins to a number of airdrop participants. This means Company 0 and its developers will have put roughly USD 415,000 into the bring-up since April, 2014 and receive 4% of the total supply, 840,000 coins (at USD 0.49 per coin). The remaining 4% will be spread evenly across a list of airdrop participants as part of an effort to build the Decred network and decentralize its distribution. Coins held by Company 0 will be used to fund its ongoing work on open-source projects, such as Decred and btcsuite.
Giving away these coins in an airdrop allows us to accomplish several things at once for the project: enlarge the Decred network, further help decentralize the distribution of coins, and allow us to get coins into the hands of people who are interested in participating in the project. Decred is fundamentally about technological progress, so the airdrop will target individuals that have made contributions to advance technology in its various forms. The maximum number of airdrop participants is capped at 5,000 individuals, so we recommend registering sooner rather than later. These coins will be given away unconditionally and there is zero expectation of Decred receiving anything from you in return for these coins.
Sign up for the airdrop is currently open, but the airdrop registration will commence on January 4th, 2016. People who have been selected to participate in the airdrop will receive an email that contains a link to a web registration form. This form will require airdrop participants to enter an address to which their coins can be sent. Binaries and source code will be made available so that you can generate a wallet seed and an address for your airdrop coins. Once you have entered your receiving address into the airdrop webform and submitted it, you will receive your coins on the projected launch date of January, 18th, 2016.
iv. Project Governance and Development
In addition to the technical features that make up the technology, Decred as a project introduces several development and governance features and proposals to ensure and steer long-term growth. We encourage participants to discuss these topics earnestly, as we want to ensure the system of development and governance is built on a solid foundation.
•A multi-stakeholder development ecosystem that welcomes and empowers participants who want to build new functionality and improve on existing features. •Any party can submit feature proposals and developers are paid for work to fulfill requirements. This is done in full view of the community in a system designed to fight against ingroup-outgroup dynamics. •The initial contributors are the developers responsible for btcsuite (est. early 2013 - present). •A proposal for a layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community. •A proposal for bottom-up decision-making through the Decred Assembly, an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort. •The project is bound by the Decred Constitution on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together.
v. Group Contribution Timeline
Below are key points of free and open-source contributions made by the Decred developers to the digital currency ecosystem since 2013. The largest of which is the btcsuite package, which comprises a suite of packages and tools for working with Bitcoin in Golang, and includes btcd, a full node, mining capable, Bitcoin implementation. To date, the total contribution across btcsuite represents 98,046 lines of code, 44,576 of which are test coverage.
vi. Additional Information
Website: Forum: Wiki: Reddit: Twitter: IRC: #decred on
submitted by ocnios to decred [link] [comments]

Bitcoin TLV `14, #33 - Meni Rosenfeld - Multi-PPS LessWrong - Bitcoin, Chess AI and the Solstice (Hebrew, 19.12.2017) Meni Rosenfeld - Early Days of Bitcoin Mining EB49 – Meni Rosenfeld: Mining Pool Reward Systems, Bitcoin Economics, Bitcoin in Israel 45. BITCOIN 2013 - Day 3 - Mining Pool Reward Methods, part 1of3

limit my search to r/Bitcoin. use the following search parameters to narrow your results: subreddit:subreddit find submissions in "subreddit" author:username find submissions by "username" find submissions from "" url:text search for "text" in url selftext:text search for "text" in self post contents self:yes (or self:no) include (or exclude) self posts nsfw:yes (or ... Meni Rosenfeld: We went with “foundation” previously, but now we usually use “association”; first, it’s a more accurate translation for the name which it has in Hebrew, and second we originally started to work as part of the global Bitcoin Foundation in the US, but right now it doesn’t look so good about our cooperation with them, because they have some very problematic terms for ... From Bitcoin Wiki. Jump to: navigation, search. A term coined by Meni Rosenfeld for the following miner policy: Ignore alternate chains if they contradict more than N blocks of history known to this miner. This proposal is a possible way to combat double spends. If honest miners cement each block N blocks after it is received, an attacker has a deadline of N blocks for the release of his ... On the Bitcoin Stack Exchange a user Sean Chapman asks “Are there any studies into the size of the blockchain scaling over time?”. Meni Rosenfeld, writer of the top answer, explains that although he isn't aware of any studies that meet Chapman's request, he can outline 5 reasons why we needn't be concerned about blockchain scalability [7]: 1. Not every user needs to run a full network node ... Posted in r/Bitcoin by u/101111 • 201 points and 36 comments

[index] [31450] [32595] [10651] [40498] [26478] [33166] [12070] [17767] [49553] [8247]

Bitcoin TLV `14, #33 - Meni Rosenfeld - Multi-PPS

Meni Rosenfeld is Founder of Bitcoil and Chairman of the Israeli Bitcoin Association. Having organized several meetups and conferences in Israel, he is a very active member of the Israeli Bitcoin ... Mining Pool Reward Methods by Meni Rosenfeld, Chairman of Israel Bitcoin Association. The lecture was presented at the 6th Technion Summer School on Cyber and Computer Security held Sept. 10 ... 00:00 - Opening words and intro to LessWrong (Joshua Fox) 02:40 - Prehistory and governance of Bitcoin (Meni Rosenfeld) 37:07 - How traditional Chess engines work (Meni Rosenfeld) 1:33:39 - Notes ... OnChain Scaling Conference presentation June 24/16 "A Fork in the Road: Must we Choose a Path?" [email protected] The lecture took place in the Inside Bitcoins Tel Aviv 2014 conference, organized by the Israeli Bitcoin Association and Buzz Productions, on October 19-20, 2014. Slides (for the entire conference ...