nChain Completes Workshop with Bitcoin Unlimited and ...

My response to recent concerns

Hey all,
I’ve spent some time during my flight back home to discuss in detail the experience in Singapore, what talked about, things the mods and team are working on, improvements that can be made and some other things too. This post has also had input from the other moderators too.
I don’t think any of the mods were massively pleased with the outcome of how we portrayed our time in Singapore during the last update and it certainly didn’t put across all the fantastic things we learnt or discussed while we were there. There was a quick turnaround with the update and with some of us were travelling and heading to other countries for various reasons it wasn’t ideal – anyway let’s begin. P.s. I apologise in advance for the lengthy post.

Education

As most of you are aware there is a rebranding process going on for Request currently, it was really exciting to hear Robbins experience and to see the scope of the project. Request are working with an industry leading full-service digital agency to improve the understandability of Request through educational content.
The current Request website is mainly catered towards ICO investors and hasn’t really changed much since the token sale – when visiting the site, it’s extremely difficult to understand what Request is, how it works and who can it benefit from the platform. One of the goals of the project is to revamp the website to cater for developers, businesses, users, community members, early adopters and investors.
The concept of the blockchain, Request, and its products is daunting for the non-technical audience. While the team know it’s important to cater for developers and other industry professionals having an easy to understand project with easy to consume information is an important step towards adoption.
The Request Hub will also play a critical part in the growth of the Request Network. The new website will have a focus on developers and businesses and pushing them towards the hub and how they can use the funding to help create their projects. Most of you will probably be aware that the dApps + the core protocol are different projects entirely. Internally, this is also the case.
You can see an visual image of the structure here: https://imgur.com/pXF1gEK
The core platform team is responsible for protocol development, things like scaling solutions, data encryption, extensions, features like cross-currency etc. Whereas the dApp teams focus on creating applications built on the Request platform, crowdfunding, invoicing, payments etc. Although this isn’t new information it’s important for sections later in the write-up.

FIAT

This is an excerpt from the 8th June AMA special project update (https://blog.request.network/request-network-project-update-june-8th-2018-ama-special-request-network-now-available-for-5da85547d933) which covers the teams thoughts on FIAT.
Fiat integration is vital for the success of the Request Network for medium to long-term. What we focus on today is making sure the protocol has enough features and a solid developer experience to attract developers to build reliable financial tools on top of the Request Network. The foundation prioritizes its own development goals based on direct feedback coming from the developer community. We receive requests for features that are needed by developers, as their product depends on it.
Today, the main feedback coming from the developer community is to make it easier to use the library, implementation of encryption, cross currency support and adding more cryptocurrencies. Apart from these requests, scalability of the protocol itself and developing extensions such as escrow are also prioritized as it is crucial for adoption of the protocol by developers. The above are our current priorities in development, while we in parallel are researching several fiat integration options mentioned in an update last December.
All of the above bullet points are things the team are actively researching and looking into, we discussed how the Singapore government is looking at tokenizing the Singaporean Dollar and how many more governments in the future will look at taking this route, however this is a long way off.
A decentralised Oracle with Chainlink would be ideal but it’s not ready yet.
Integrations by partnerships with banks / partnering with credit card companies or processors (like Stripe) is incredibly difficult (especially being decentralised) but it’s something the team will actively work on / towards.
Oracle and bank APIs – we discussed several projects here like StellarX, OmiseGo and more – each have their own pros and cons but nothing in the space is really ready for FIAT, some options are close and the team are keeping a close eye on several projects in this space.
There are tonnes of regulatory issues surrounding FIAT and the blockchain, governments are dubious about the blockchain technology and banks are having a tough time getting involved too – even big companies like Binance, Coinbase and Circle still can’t obtain a banking license after many years of trying. The regulatory situation will change, crypto is still a young industry and it will take time for governments to catch up.
Instead of spending time trying to achieve FIAT which wasn’t viable, their time has been spent on far more productive things such as scaling solutions, data encryption, working on various dApps, working with partners, hiring and much more. The better the platform the more impact having FIAT will have when it comes. Yes, not being able to stick to the roadmap isn’t ideal, but the team have realised there are limitations and made the best of the situation.
Would it have been good if the team have been more transparent about FIAT and the issues they faced? Absolutely. Detailed articles about subjects like this do take time, and raise further questions which also take up the team’s time. We want to find a good balance going forward of keeping the team on track and keeping the community informed. We will also work with the team to improve communication for things like this (if they ever arise in the future) and how the mods can alleviate some of the time-pressure if possible.
The team do realise the importance of FIAT, it hasn’t been forgotten and will be something the team will keep on the roadmap – in the future when FIAT is possible we will have a much more mature platform and many use cases live and ready to integrate FIAT.

Marketing

One of the most discussed things over the past months is marketing, this is a very important topic and it’s something that can make or break a project.
As per the ‘Rebranding + Restructure’ section, marketing will be broken down into two different groups, dApps and the core Request platform. The marketing for each of these aspects is very different.
So, why aren’t the team marketing right now? Quite simply – the platform just isn’t ready yet, there isn’t enough value to risk marketing at this stage. This is the same with some of the dApps, they are close, but they still aren’t quite there yet.
In my case if we take a look at the WooCommerce + Shopify plugins, if I go ahead and run a PPC (pay-per-click) campaign before BTC is integrated, then users may leave the site and never return. In this instance I will have lost money as well as a potential customer. This is just one example but it’s the same for other dApps too.
Right now, The team are making active steps towards marking when the platform and dApps are, as well as hiring dedicated marketers.
I do want to say that the team truly understand the importance of marketing, they will market the project and the dApps– it’s critical they do so.
To break it down there are entirely separate game-plans to consider when marketing, the core platform and dApps.
Core Platform (Foundation)
Marketing for the core platform will focus on; educating the community about the platform, educating developers / businesses / potential partners about the Request protocol and how it can be used by / integrated into business workflows.
The rebrand will have a big focus on education and driving adoption of the Request Hub + Fund. In the meantime, we are discussing ways to improve the Request Hub and how we can get more developers involved at this stage, I have covered this in more detail in the ‘Request Hub’ section.
dApps
Each dApp will in essence be its own entity (business) and will act independently of the foundation. Each dApp will have a dedicated team, individual aims and goals, potentially a custom roadmap, a proprietary marketing strategy and much more (everything you expect from a typical business).
Marketing for individual dApps will vary greatly depending on what the dApp is, some will be focussed on B2B, some B2C, some dApps might be a combination of both.

Hiring + strategies to find new devs

The foundation growing at a quick rate and one of the things we discussed in Singapore was hiring and strategies to find new devs.
There are several strategies that the Request team can adopt alongside job advertisements to help entice developers, not only to the foundation but also to the Request Hub. We discussed potentially using freelancers and then hiring if they are a good fit, more engagement from the team with people that contribute to the Request Hub and how the team can help (financially via the fund + time set aside for devs), hackathons with prize incentives, speaking at developer conferences (very important). Some ways of engaging with developers do require the platform / ecosystem to be more mature but we are actively working on making these things a reality. Also, improving the community sentiment will also drive hype which in turn hopefully attracts more developers.

Request Hub + Request Fund

In my opinion one of the best selling points of Request is the Request Hub + Fund. Although there is activity in the hub and some projects have receiving funding it is nowhere near as widely used as it could be. As I’ve discussed in the marketing section, the renewed website will have a big focus on pushing the Hub + Fund.
Aside from the marketing aspect I have also been speaking to teams in the Hub for a while about how the flow for funding can be improved, we have discussed the barrier to entry for the fund (MVP limitations), the turnaround time for responding to funding applications (needs to be quicker), having the team engage more with the Request Hub devs as well as actively helping them with their business needs.
In the future I will also look at creating a suite of tutorials, and potentially workshops, for the Request Hub to help get developers up and running.

Bi-weekly updates

One of the hot topics since returning from Singapore has been the bi-weekly updates, we have been discussing with the team how they can be improved without taking up too much time for the team. There are several things which are actively being discussed:
This will be an ongoing discussion with the foundation, it will take time to refine the bi-weeklys and we also need to find a happy medium that suits both the foundation and the community too.

The Community Managers and our role

The goal as community managers is to firstly ensure that the social channels e.g. Reddit, Discord, Slack and Telegram are a good place for investors, the team and developers – we want to ensure it’s good for open discussions (both positive and negative) and a place where we can educate people about Request too.
As community managers we want to try and stay as impartial as possible, we will help to educate when we can, we’ll shut down any false information and we’ll help alleviate any concerns where possible. We don’t want to take sides, we are simply there to be a bridge between the team and the community.
We want the Request community to be an open place where anyone can discuss what they want, we want to see discussions about good things and bad – we don’t want Request to be a place where negativity is censored. We (the mods) are just normal guys, we love technology, we love the blockchain, we are just investors like all of you, and we want the best for the Request Network.
We are continually improving how we and the team deliver information, but things can still be improved massively – we are already actioning some things to improve communication between the community and the team and we have plenty of other things lined up too.

Roadmap

During the rebrand the website will rework the dynamic roadmap to something potentially similar to Ark (https://ark.io/roadmap), with percentages (or something similar) and a breakdown of each goal on the roadmap. This will help with transparency and also allow the community to track progress more easily.
I’ll cover my perspective on the dynamic roadmap looking from a developers point of view, as a lot of people are still unsure as to why the roadmap has changed and in turn it raises lots of questions.
From a developers point of view.
As a dev it can be incredibly difficult to hit deadlines that are more than a few weeks / over a month or two away, the further away the date the harder it is to estimate + hit deadlines. This is the case for a normal business, but as crypto is insanely fast paced and such a new industry this is even more prevalent.
In the normal development world you typically work in weekly / bi-weekly sprints to produce features in small iterations which contributes to the overall project, at the end of each sprint you re-evaluate the previous weeks and re-adjust timings / resources if necessary – estimating deadlines months in advance is almost impossible.
The biggest issue about committing to a firm date is that crypto adoption is moving at a fast rate, non-blockchain businesses are getting involved with cryptocurrencies and a great platform like Request is an attractive option for them. On-boarding these businesses takes money, expertise and most importantly team resources. The team is growing but for now the time spent with these partners needs to come from somewhere, and unfortunately features can sometimes get affected.
Let's take BTC support - if the team was fully focused on BTC I would have no doubt there would have been no delay. But PwC came along, which took up development resources and, unfortunately, impacted the deadline. Long-term, having PwC onboard will have a more positive effect on the overall Request Network ecosystem. Partnerships won't wait around, Bitcoin support will.
With these partnerships there will be a push for features they want to see. PwC for example, would be focused on the accounting so they would likely be pushing for accountancy related dApps (http://accounting.request.network/) - when the roadmap was first created the team could never predict such a huge entity like PwC would come onboard, so changing focus is sometimes required from a project. Once again, long-term this will benefit Request massively.
From a development perspective changing the roadmap is a fantastic move in my opinion, the team never know what is around the corner and being able to quickly adapt to new opportunities, on-boarding companies are critical for the long-term viability of the network. As the team grow there will be more development resource available to focus on the core platform and partners which will allow the team to better predict features in the future. Once again, I’d like to reiterate things do need improving here, the team can be more transparent, and the roadmap can, and will, be improved.

Summary

The Singapore trip was fantastic, and it was an incredible experience working closely with the team and it was great to see their passion and talent while working away through the week, it’s an excellent work environment too.
Every bit of feedback is incredibly important, please don’t hesitate to get in touch at any time to me or any of the mods, either by Reddit, Discord, Slack or Telegram.
There is a lot of work ahead for the mods and the team, but rest assured we have every single one of your concerns in our scope; the community and the perception you guys have is so important to the team and the project. There are a lot of great things going on that we will continue to improve and lots of things that need changing – it won’t be something that happens overnight but something that will be continuously improving for the entirety of the project – we are dedicated to working hard and improving Request and the community every day.
At the end of all this, actions speak louder than words, and we will take everything into consideration to help ensure Request thrives, we are already in the process of actively making changes.
Apologies for the lengthy post but hopefully this clears some bits up and helps to put across some of the great things we saw in Singapore, if you have any other questions feel free to leave a comment or get in touch privately. Cheers.
submitted by AdmREQ to RequestNetwork [link] [comments]

IEEE Security & Privacy on the Blockchain (IEEE S&B 2019) - CALL FOR PAPERS! Submission deadline: Feb. 18.

IEEE Security & Privacy on the Blockchain (IEEE S&B)
An IEEE EuroS&P affiliated Workshop
20th June 2019, in Stockholm, Sweden
https://blockchain.kcl.ac.uk/ieee-sb2019/

Important Dates
- Submission deadline: 18th February 2019 - Notification of acceptance: 28th March 2019 - Camera-ready deadline: April 18th 2019 - Workshop: 20th June 2019

Call for Papers
The emergence of Bitcoin and decentralized cryptocurrencies, and their fundamental innovation -- blockchains -- have allowed for entities to trade and interact without a central trusted third party. This has led to a captivating research activity in multiple domains and across different venues, such as top security and distributed systems conferences and journals, as well as a vibrant startup rush on this new technology.
The third IEEE Security and Privacy on the Blockchain workshop aims to unite interested scholars as well as industrial members from all relevant disciplines who study and work in the space of blockchains. We solicit previously unpublished papers offering novel contributions in both cryptocurrencies and wider blockchain research. Papers may present advances in the theory, design, implementation, analysis, verification, or empirical evaluation and measurement of existing systems. Papers that shed new light on past or informally known results by means of sound formal theory or through empirical analysis are welcome. Suggested contribution topics include (but are not limited to) empirical and theoretical studies of:
- Anonymity and privacy issues and measures to enhance them - Applications using or built on top of blockchains - Atomic Swapping - Big Data and blockchain technology - Bitcoin, Ethereum, Monero, ZCash protocol, other coins and extensions (cryptography, scripting/smart contract language etc.) - Case studies (e.g., of adoption, attacks, forks, scams etc.) - Censorship - Consensus protocols for blockchains - Cryptocurrency adoption and economic impact - Cryptocurrency adoption and transition dynamics - Decentralized Applications (Exchanges, Mining Pools, Trading Platforms) - Adoption of blockchains in developing countries - Economic and monetary aspects - Economics and game theory of mining - Forensics and monitoring - Formal verification of Blockchain protocols and Smart Contracts - Fraud detection and financial crime prevention - Governance - Identity, Identification and trust in blockchain systems - Implications for existing business models - Interfacing fiat and cryptocurrencies - Intermediates in different industries and their future - Internet of things (IoT) and blockchains - Legal and policy implications of Smart Contracts - Legal status of ICO/TGE - Legal, ethical and societal aspects of (decentralized) virtual currencies - New applications of the blockchain - New business models for permissioned and permissionless blockchains - Off-chain payment channels - Peer-to-peer broadcast networks/topologies - Permissioned (e.g. Hyperledger) and permissionless (e.g. Bitcoin) blockchains - Privacy and anonymity-enhancing technologies - Proof-of-work, and its alternatives (e.g., proof-of-stake, proof-of-burn, and virtual mining) - Real-world measurements and metrics - Regulation and law enforcement - Relation to other payment systems - Scalability and scalable services for blockchain systems - Security of blockchains - Smart Contract Programming Languages and VMs - Transaction graph analysis - Usability and user studies
This topic list is not meant to be exhaustive. S&B is interested in all aspects of the blockchain research relating to security and privacy. Papers that are considered out of scope may be rejected without full review. We encourage submissions that are "far-reaching" and "risky."

Submission
All submissions must be original work and should be submitted for blind review. Short position papers may not exceed 4 pages total and full papers may not exceed 10 pages, including references and appendices. Authors should use the IEEE conference proceedings templates.
Please find more information about the workshop, including further submission instructions, on the website: https://blockchain.kcl.ac.uk/ieee-sb2019/

📷ReplyReply allForward
submitted by truja to truebit [link] [comments]

RightMesh AMA Answers

Thank you for your interest in our project and for submitting questions over the past week for our first AMA!
 
Please see below for our answers. Question thread available here. If you would like further clarification on any of the below, please join our Telegram channel to speak directly with the team.
 
The RightMesh Team
 
 
 

I like you guys the most because you're a BCORP with a great purpose, but what does your organization do better than the competition? Thank you.

 
Thank you for your kind words about our B Corp status, it’s something we pride ourselves on at Left and RightMesh! For those who are not familiar, Left, the parent company of RightMesh, is a certified B-Corp and has won numerous awards for community engagement and corporate culture. B Corps are for-profit companies certified by the non-profit B Lab to meet rigorous standards of social and environmental performance, accountability, and transparency. As a certified B Corp, Left is committed to doing business “right” – for the good of all. There are over 2,400 B Corps in over 50 countries, covering 130 industries. Some notable B Corps include Ben & Jerry’s, Warby Parker, Patagonia, Etsy, Plum Organics, and of course, Left!
 
We believe there are several differentiating factors about RightMesh, spanning from our organization to our technology. These include:
 
 

Culture & Values:

 
Left’s founders, Chris Jensen and John Lyotier, had a dream to create a company built on core values and an anything-is-possible attitude that can make this planet a better place. We have been recognized as the “Best Employer in BC (British Columbia, Canada)” by Small Business BC, and we are a two-time winner of the BC Tech Community Engagement Award. All employees get to participate in our “Dream Program” in which the company supports us to fulfil our personal dreams and ambitions, and we are given unlimited work hours for volunteering in our community.
 

Team Expertise:

 
The RightMesh team consists of over 100 PhDs, Scientists, Developers, Entrepreneurs, Business Strategists and other experts who have in-depth expertise in Mesh technologies, blockchain and building successful businesses.
 
RightMesh has offices in Vancouver, Canada and Khulna, Bangladesh. We also have project contributors and partners working from Zug, Switzerland and Los Angeles, United States.
 
A key differentiating factor is the fact that our team has strong experience in scaling teams which will be extremely important to the success of RightMesh in the future following our TGE.
 

Executive Team Overview

 
John Lyotier, Co-founder and CEO  
Co-Founder & CEO, RightMesh. John is one of the co-founders and is a key contributor to the global strategy, vision, and technology roadmap for RightMesh, its parent company Left, and all its subsidiary brands. John is an entrepreneur and a successful marketer with more than 20 years of experience in promoting, launching, designing, and jumpstarting new businesses and products through innovative marketing concepts. Under his leadership, the parent company, Left, has gained a national reputation as being a “Best Workplace” award winner while being the first back-to-back recipient of the BC Tech Association’s Tech Impact Award for Community Engagement, recognizing the best company in BC for balancing “Work, Life, and Play”. With RightMesh, he is focused on bringing connectivity to the next billion.
 
Chris Jensen, Co-founder and COO  
Chris began his career in the UK working for multinationals and banks and continued in the banking and brokerage industry upon moving to Canada. He has a strong understanding of the finance markets and has lived the pain of raising capital for early stage companies during the beginning stages of growth, from 25 to 80+ employees. He has founded several start-up companies in his career. In his role as CEO for Left and COO at RightMesh, Chris thrives on understanding the big picture and on moving the levers that drive the company forward. This includes financing, strategic partnerships, and corporate development. Chris holds a BSc (Honours) in Economics and History from Queen Mary University of London.
 
Dr. Jason Ernst, CTO and Chief Networking Scientist  
Jason holds a PhD in the field of Mesh Networking and Heterogeneous Wireless Networks as well as a M.Sc. on Scheduling Techniques for Wireless Mesh Networks, both from the Applied Computing faculty at the University of Guelph. An adjunct professor at the University of Guelph, Jason has more than 30 published papers on wireless networks, cognitive agents, FPGAs, and soft-computing topics and has presented his research at international conferences around the world. Jason is the only Canadian member of the ACM Future of Computing Academy and a member of their executive committee. Prior to joining Left, Jason was the CTO of Redtree Robotics, which designed robots that made use of multiple radio technologies to ensure pervasive connectivity to each other and their operators.
 
Dr. David Wang, Applied Research Engineering Scientist  
Dr. Zehua Wang is the Chief Micropayment Scientist at RightMesh. He received Ph.D. degree from the University of British Columbia (UBC), Vancouver, Canada. He received his master and bachelor degrees in Computer Engineering and Software Engineering, respectively. He holds a research fellow position in UBC. He has published more than 30 peer-reviewed book chapters and papers in topics of mobile ad-hoc networks, blockchain technology, the Internet of Things, and the fifth-generation wireless networks. He has expertise of using optimization and game theories to solve economic problems. He was a recipient of Four-Year-Fellowship and awarded the Graduate Support Initiative Award at UBC. In industry, he has about 10 years experiences of software development. In academia, he served as the technical program committee (TPC) Co-chair of IEEE International Workshop in Smart Multimedia and TPC members in many international conferences, including IEEE ICC, IEEE Globecom, and IEEE VTC, etc. He is a member of IEEE.
 
Saju Abraham, Chief Product Officer  
Saju is a seasoned professional in the realm of mobile and wireless technologies having worked with customers, partners and teams across 19 countries in organizations such as Lucent Technologies, Movius, NEC, OnMobile and Telefónica. His passion for building great products stemmed from his multifaceted experience as a software engineer, architect and product manager, and he currently thrives in bringing multiple cross-functional and cross-cultural teams together to cohesively execute the product strategy for RightMesh. His credentials include a Bachelor’s degree in Computer Science and Engineering and a Postgraduate degree in Management from the Indian Institute of Management, Bangalore.
 
Melissa Quinn, Corporate Development Manager  
Melissa’s passion to empower people to be their best selves is why she has immersed herself in the blockchain, cryptocurrency, and mesh technology world. Heading up Corporate Development for RightMesh, Melissa works closely with the team while constantly seeking Partners, Advisors, and other game changers who are aligned with our vision. She has a BBA from SFU, a background in HR, and a strong desire to put innovative technology at the forefront of doing business as a force for good.
 
Rakib Islam, Co-Founder and CTO of Left  
In his role as CTO, Rakib sets the pace for Left’s application development initiatives, including key recruitment of engineering and mobile technologists. Rakib leads Left Technologies Pty Ltd, Left’s ISO-9000 certified subsidiary in Bangladesh. An active member of BASIS (Bangladesh Association for Software and Information Services), he frequently travels abroad to present an example of the ‘new’ Bangladesh and speak about economic empowerment. Rakib’s credentials include a Master’s Degree in Computer Science and Applications from Pune University, India, as well as being a participant in the US Department of State Professional Fellows Program for Young Entrepreneurs at the University of Oklahoma.
 
Tracy McDonald, Director, Talent & Culture  
With over 10 years working with people to grow their potential, Tracy is passionate about creating dynamic teams that facilitate business growth and positive culture. As an early Lefty, she was instrumental in scaling up the team to over 80 people, without losing the culture that makes Left special and unique. Tracy’s coaching and development work with the Lefties has been recognized with many awards including “Best Workplace in BC” and Community Engagement Winner from the BC Tech Association. Her dedication to making Left a premier workplace, was further recognized when Left became a certified B Corporation. Tracy’s belief in the potential of people allows her to lead with compassion, integrity, and trust. She earned her Bachelor of Science from Simon Fraser University.
 
Dana Harvey, Chief Communications Officer  
Dana harnesses the power of words and technology to engage audiences and compel them to action. As a communications professional with 25+ years’ experience in global markets, Dana combines strong strategic skills with out-of-the-box thinking and the unique ability to craft omnichannel content that resonates and inspires. She has helped large corporations like Nortel, Motorola and IBM develop new markets, managed an international advertising agency, and guided multiple businesses to success through her own communications consultancy. Dana is also an experienced public speaker, passionate about sharing her knowledge and motivating audiences. As an advocate for the full participation of women in all communities, she is especially interested in exploring the positive social and economic impacts RightMesh will bring to women in developing nations and around the world. Dana is co-founder of the Women’s Collaborative Hub, an organization that empowers youth and women from diverse backgrounds. Her credentials include a BA (Honours) in Communications and a Post Baccalaureate Masters (Dean’s List) in Asian Management.
 
Alyse Killeen, Executive Strategist  
Alyse is Managing Partner of StillMark Co. and StillMark Capital, and is one of the very first traditional venture investors to participate as an investor and advisor in the blockchain and cryptocurrency ecosystems. In 2015, the UN Foundation named her a Top 70 Bay Area Digital Leader, and in 2016, Singapore University of Social Sciences (SUSS), a university under the ambit of Singapore’s national Ministry of Education, appointed Alyse as a Fintech Fellow. In 2017, International Business Times (IBT) recognized Alyse’s contribution to the development of the blockchain ecosystem by including her in the 4th position of IBT’s “VCs Powering the Blockchain Boom” List, following Tim Draper, Mark Cuban, and Naval Ravikant of AngelList and MetaStable. Alyse has presented internationally, been featured in many reputable publications, authored a book chapter in the award-winning Handbook of Digital Currency titled “The Confluence of Bitcoin and the Global Sharing Economy”, and in 2017 contributed to the next book in the series, Handbook of Blockchain, Digital Finance, and Inclusion (2017), co-authoring “Global Financial Institutions 2.0” with Dr. R. Chan of the World Bank. In her role as Executive Strategist, Alyse consults with the executive team, including on the development of the team’s network within the blockchain community and introduction to ecosystem leaders.
 

Our Advisors:

 
Our advisory team consists of advisors who believe in the long lasting success of the project. They have been carefully selected to help built RightMesh over multiple years of operation and are not involved solely for the token generation event.
 
Our advisors include:
 
 

Academic Research:

 
Academic research has been core to the design and development of RightMesh thus far, and will continue to be a key driver for us in the future. RightMesh works closely with Universities on academic research on mesh networks, blockchain technology, and payment channels. We are working on research with the University of British Columbia on density simulation and payment channel development. Since early 2017, we’ve been conducting research on mesh networks and connectivity in Arctic / remote regions with:
 
 
We've received grants from NSERC, MITACS and CIRA to support pilot programs thus far and are submitting a MITACS cluster grant to support over 100 graduate student units over the next 3-5 years. This research covers everything from how to design relevant mesh apps in the communities the mesh is operating in, to performance evaluation of the network protocols, to scalability of micropayment channels.
 

Technology:

 
It is also important how the mesh is designed for scalability reasons. Most mesh networking solutions are built around a store and forward and broadcast mechanism. This mechanism is not scalable and congests the network causing complete breakdown of the network. Even a small amount of devices can quickly cause exponential traffic resulting in extremely high delay and low effective throughput for apps running on broadcast protocols. In the RightMesh network, devices directly communicate with another device, and make smart routing decisions along the way.
 
RightMesh implements autonomous role topology/mesh creation layer - which means devices in the RightMesh network will autonomously detect each other and connect - user intervention in the network role is minimized .
 

Other key tech differentiators include:

 
We don't broadcast data. We compute a route between devices. Our protocol was built to use multiple paths (most use a single path and have long recovery times on a broken connection). The RightMesh network protocols can failover, or use multiple paths at the same time. RightMesh doesn't require the phone to be rooted. RightMesh doesn't require extra hardware. RightMesh can share existing Wi-Fi or Cellular Data, many others can only share Cellular Data.
 
 

Partners & Affiliations:

 
 
Answer provided by the RightMesh Team
 
 

Hello, First, congratulations on the big idea! I'm definitely a supporter. (1/2) My question is how far are you into testing your mesh network?

 
Thank you! We’ve spent the last 1.5 years or so building the protocol stack from the ground up, and so most of the testing that has been done has been around testing the functionality of the stack - including node discovery, single-hop and multi-hop communication, multi-path routing, forming mesh networks with heterogeneous wireless links, and app integration.
 
And over time, we steadily have been improving our end-to-end reliable communications protocol. The protocol originally achieved somewhere on the order of a few kbps when we first started because we did e2e acks on every packet. We have since moved to sliding window and selective ack mechanism which has allowed the performance to climb closer to the Mbps range. However, we still have more work to do in order to achieve the theoretical maximums of the individual links (and even faster if combining links).
 
In terms of testing of the scale of a RightMesh network, we've tested with up to 10 hops on a single path, but can likely support more. Right now the largest offline mesh we've had is 30 devices, limited only by the number of devices we had available at that moment in time.
 
Building a performance evaluation framework is one of our next immediate and important tasks, where we can evaluate the performance of the network under various test conditions - for example how the network behaves based on density, and how does the number of hops impact the response time and data that flows through the network.
 

(2/2) Can I assume I'll only be able to participate if I'm in the surrounding locations? For example: Someone in Indonesia is using RightMesh to try and connect to the internet. Is there a possibility for me to help them if I live in a different country? Thank you and keep up the good work.

 
To be a participant in a RightMesh network, you will have to be in close vicinity with another RightMesh powered node (smartphone) in order to be connected to a network. However, it will be possible for community members to operate devices that provide a “superpeer” layer. These would be fixed nodes with stable, reliable, and ideally fast internet connections. They would provide relaying between different geographically separate meshes - for instance between two neighbourhoods that are too far apart for one mesh to cover them both. They would be required to provide tokens in order to facilitate the channels that need to be made between the buyers and sellers. This would allow them to charge a fee for having their tokens locked up in the channels.
 
We will also open source the superpeer, so people will be able to work off our reference superpeer implementation and build their own custom superpeers. This would let them control the strategy the superpeer uses to allocate tokens into channels. We expect to have a release of the superpeer which supports payment channels by next week. At this point in time the solution is proof-of-concept stage, but some testing has been done to support two meshes communicating with each other through a superpeer where the data seller in each mesh is compensated by buyers in each mesh.
 
Answers provided by Dr. Jason Ernst, CTO and Chief Networking Scientist & Saju Abraham, Chief Product Officer
 
 

What do you see as the biggest challenge with taking your technology to market and hitting your usegrowth targets?

 
Density is the biggest challenge of mesh technologies, and one of the reasons why token economies are required to incentivize users to share their signal when it is available.
 
We are looking to bring in users into the RightMesh ecosystem through the work they do in the network, and provide them economic incentives that will encourage further action. What defines work? Being a part of a relay node in the network for instance - that reduces barriers to entry. Or incentivizing users for taking actions in the app or to consume content such as ads. The more opportunities there are for users to earn, the more people that will join, the more developers that will join the ecosystem, leading to more opportunities, and the network effects loop should grow stronger.
 
Answer provided by Saju Abraham, Chief Product Officer & Aldrin D’souza, Product Manager
 
 

(1/3) What is the theoretical maximum mesh size?

 
There isn't really a theoretical limit. We don't have any hard caps on devices in our code, however locally there may be limitations from individual phones. For instance, I've seen some phones in hotspot mode which only support 6 clients connected to it. On other phones sometimes, as few as 3-4 BT connections. So there are some constraints on the topology and the maximum number of connections one device may have, but it is limited more by the devices, the chipset and Android, rather than our software. We can also get around some of these limitations still using our switching technology, however, this will have a noticeable impact on delay.
 

(2/3) Does the transfer rate for users slow as the mesh size increases?

 
This is less a function of the number of users, or devices, and more a function of the demand on the network. A network with many devices and few users actually requesting traffic may perform better than a small network where all of the users are requesting lots of traffic. There is some overhead in the protocol to maintain the connectivity of devices, however this will be minimal in impact compared to the load of traffic from all of the devices. It also depends on where the traffic is going. If it internal to the mesh it may be possible with a dense mesh that RightMesh could support high throughput internally. The bottlenecks would likely occur in cases where there is lots of traffic which requires the Internet, and there are too few people willing to sell or donate Internet data into the network. Compared to other meshes howevever because RightMesh can support multiple paths, we can split the load across all available Internet connections rather than doing something more naiive like rely only on the closest one, for example.
 

(3/3) How do you plan to test a large scale mesh prior to launch?

 
There is lots that we can do with simulation, or combining simulations with some real devices. We also have a large team in Bangladesh that can help support field tests in some very different environment that we are used to in Vancouver.
 
Further, we are working with researchers at UBC and Guelph so that graduate students can apply some of the latest research methods in simulation and performance evaluation to RightMesh. (I myself have a PhD that relied heavily in this area, and we have several other PhDs on the team who can provide expertise to graduate students in this area. We are also working with some other top researchers in this area who will help in ensure we are straining and breaking the network as much as possible before launch).
 
To be more specific, it will be a combination of stressing various components of the system one at a time, along with tests that stress all of the components at once. We are also building software that can automate various scenarios to test how the phones and the library can handle different topologies and connectivity. Before we consider it ready for launch however, we'll need some wide scale tests with real devices and real traffic. This will likely happen by working with friendly partners who believe in the benefits of what the mesh can provide in very localized applications (think a train schedule app in a crowded city for example). This will inevetiably result in parts of the protocol breaking, which will iteratively repair.
 
Once we are satisfied that the network as a whole can maintain stability, tokens properly account for the data being used (verified on the public testnets), and that users of these early partner apps are having a good user experience, we will deploy to the public network.
 
Answers provided by Dr. Jason Ernst, CTO and Chief Networking Scientist
 
 

Have you had direct interest from large enterprise clients wishing to use the mesh technology in their apps/content strategy as yet, or are you having to reach out to them to generate interest?

 
Yes, RightMesh has been receiving direct inquiries from major corporations and organizations every day. These companies are largely interested in reaching emerging markets and regions where connectivity is an issue, and has been inaccessible until now. Mesh technology, being so new, will enable new types of applications to emerge that have not previously been possible, so proof of concepts for both RightMesh and partners will be a key focus. We’re actively in discussion with companies who are interested in integrating RightMesh into mobile applications, dApps, IoT devices and other hardware products to develop pilot projects.
 
In addition to these inbound inquiries, we have an outbound strategy as well, where we’ve identified key verticals that would benefit from mesh enabled applications. In the near term, over the next year while we harden the RightMesh protocol, we plan to focus on working with partners who provide services like emergency communications, distance education, medical services, and messaging applications, to name a few.
 
We see the need to work with a variety of different types of partners from international NGOs to brand names in order to test various use cases (ex. emergency medical alerts or content distribution from content providers). Our partnership strategy will evolve over time as our protocol matures.
 
We will publish announcements as per our effective disclosure policy once anything is material.
 
If your organization is interested in discussing a partnership or collaboration with RightMesh, we'd love to hear from you! Please email us at [email protected].
 
Answer provided by Brianna MacNeil, Product Manager, Blockchain
 
 

First let me say this product is revolutionary, I know if availability is solved there is no reason not to use this. My question is regarding your choice of an erc20 token, wasn't it more suitable to choose something like IOTA for constant payment of internet access? Are you planning for the payments to be made every second per MB consumed or something like that? Thanks

 

Related question: How exactly to you intend to use microtransactions considering high Tx fees from the Ethereum network?

 
Thank you very much for your feedback!
 
First, for context, let’s explain why and how RightMesh is using blockchain technology. Firstly, the protocol is integrated with Ethereum to uniquely identify each node (smartphone/device) in the mesh network by assigning it a MeshID in a similar way that a MAC address is assigned an IP address. Secondly, participation in the network is incentivized through an ERC20 token, called RMESH, and the network uses a custom implementation of µRaiden to allow for micropayments of micro amounts of data in the network.
 
We are supporters of Ethereum and its strong development community. Scalability and reducing transaction fees are two of the biggest challenges that the Ethereum community is working on now. But, while that is happening, we have also been looking at our own protocol design to minimize the need of Ethereum transactions and tackle the problem of scalability.
 
Every microtransaction that occurs on a RightMesh network does not need to be secured on the blockchain - that is vastly inefficient. That’s why we’ve been relying on a payment channel design based on µRaiden that allow micro transactions to occur in the network between nodes without transaction fees, and not being dependant on the blockchain for every transaction. We think this has to be a joint community effort, and so we’ve published the work we’ve done in porting the µRaiden libraries to Java to be used in our Android libraries.
 
We also believe that being a part of the Ethereum community also means contributing to it and helping it to move forward.
 
We hope that the work we have been doing on µRaiden and porting the libraries to other languages - specifically Java so it could be used in Android applications - will benefit other projects who plan to use the Ethereum network for microtransactions: https://github.com/RightMesh/microraiden-java
 
Answer provided by Saju Abraham, Chief Product Officer
 
 

If Google/Alphabet succeed with Project Loon, will this damage RightMesh's market?

 
If Google’s Project Loon succeeds, it would be a win for everyone and the planet. The same goes for the SpaceX satellite initiatives, the OneWeb project, Facebook’s global internet initiatives, 5G networks, and the success of other mesh networking technologies in the blockchain space.
 
We each share the goal of bringing connectivity to the nearly 4 billion people who do not have access to internet and connectivity. At the end of the day, we, RightMesh, aim to lift millions out of poverty by providing them with access to the societal and economic benefits afforded by the internet and access to information. This is not something that can be solved by one entity. It will take the combination of different solutions and approaches to make this a reality.
 
One major strength of RightMesh is that we can solve last mile connectivity, which is incidentally complementary to many other projects in the space. There is a good opportunity for us to potentially collaborate with some forward-thinking wireless companies, MVNOs, and corporations working on global connectivity projects, to provide last mile delivery.
 
Answer provided by John Lyotier, CEO & Brianna MacNeil, Product Manager, Blockchain
submitted by BreezyZebra to RightMesh [link] [comments]

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

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

Link to Paper


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

References
[1] Bitcoin cash. https://www.bitcoincash.org/.
[2] Litecoin. https://litecoin.org/.
[3] Ethash. https://github.com/ethereum/wiki/wiki/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. https://en.wikipedia.org/wiki/Natural_bobtail.
[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. http://eprint.iacr.org/2016/871.
[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. http://ethdocs.org/en/latest/.
[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. https://eprint.iacr.org/2016/555, 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. https://arxiv.org/pdf/1507.06183.pdf, 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]

Merged Mining: Analysis of Effects and Implications

Date: 2017-08-24
Author(s): Alexei Zamyatin, Edgar Weippl

Link to Paper


Abstract
Merged mining refers to the concept of mining more than one cryptocurrency without necessitating additional proof-of-work effort. Merged mining was introduced in 2011 as a boostrapping mechanism for new cryptocurrencies and countermeasures against the fragmentation of mining power across competing systems. Although merged mining has already been adopted by a number of cryptocurrencies, to this date little is known about the effects and implications.
In this thesis, we shed light on this topic area by performing a comprehensive analysis of merged mining in practice. As part of this analysis, we present a block attribution scheme for mining pools to assist in the evaluation of mining centralization. Our findings disclose that mining pools in merge-mined cryptocurrencies have operated at the edge of, and even beyond, the security guarantees offered by the underlying Nakamoto consensus for extended periods. We discuss the implications and security considerations for these cryptocurrencies and the mining ecosystem as a whole, and link our findings to the intended effects of merged mining.

Bibliography
[1] Coinmarketcap. http://coinmarketcap.com/. Accessed 2017-09-28.
[2] P2pool. http://p2pool.org/. Accessed: 2017-05-10.
[3] M. Ali, J. Nelson, R. Shea, and M. J. Freedman. Blockstack: Design and implementation of a global naming system with blockchains. http://www.the-blockchain.com/docs/BlockstackDesignandImplementationofaGlobalNamingSystem.pdf, 2016. Accessed: 2016-03-29.
[4] G. Andersen. Comment in "faster blocks vs bigger blocks". https://bitcointalk.org/index.php?topic=673415.msg7658481#msg7658481, 2014. Accessed: 2017-05-10.
[5] G. Andersen. [bitcoin-dev] weak block thoughts... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011157.html, 2015. Accessed: 2017-05-10.
[6] L. Anderson, R. Holz, A. Ponomarev, P. Rimba, and I. Weber. New kids on the block: an analysis of modern blockchains. http://arxiv.org/pdf/1606.06530.pdf, 2016. Accessed: 2016-07-04.
[7] E. Androulaki, S. Capkun, and G. O. Karame. Two bitcoins at the price of one? double-spending attacks on fast payments in bitcoin. In CCS, 2012.
[8] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille. Enabling blockchain innovations with pegged sidechains. http://newspaper23.com/ripped/2014/11/http-_____-___-_www___-blockstream___-com__-_sidechains.pdf, 2014. Accessed: 2017-09-28.
[9] A. Back et al. Hashcash - a denial of service counter-measure. http://www.hashcash.org/papers/hashcash.pdf, 2002. Accessed: 2017-09-28.
[10] S. Barber, X. Boyen, E. Shi, and E. Uzun. Bitter to better - how to make bitcoin a better currency. In Financial cryptography and data security, pages 399–414. Springer, 2012.
[11] J. Becker, D. Breuker, T. Heide, J. Holler, H. P. Rauer, and R. Böhme. Can we afford integrity by proof-of-work? scenarios inspired by the bitcoin currency. In WEIS. Springer, 2012.
[12] I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. https://eprint.iacr.org/2016/919.pdf, 2016. Accessed: 2017-09-28.
[13] Bitcoin Community. Bitcoin developer guide- transaction data. https://bitcoin.org/en/developer-guide#term-merkle-tree. Accessed: 2017-06-05.
[14] Bitcoin Community. Bitcoin protocol documentation - merkle trees. https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees. Accessed: 2017-06-05.
[15] Bitcoin community. Bitcoin protocol rules. https://en.bitcoin.it/wiki/Protocol_rules. Accessed: 2017-08-22.
[16] V. Buterin. Chain interoperability. Technical report, Tech. rep. 1. R3CEV, 2016.
[17] W. Dai. bmoney. http://www.weidai.com/bmoney.txt, 1998. Accessed: 2017-09-28.
[18] C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on, pages 1–10. IEEE, 2013.
[19] C. Decker and R. Wattenhofer. Bitcoin transaction malleability and mtgox. In Computer Security-ESORICS 2014, pages 313–326. Springer, 2014.
[20] Dogecoin community. Dogecoin reference implementation. https://github.com/dogecoin/
[27] A. Gervais, G. Karame, S. Capkun, and V. Capkun. Is bitcoin a decentralized currency? volume 12, pages 54–60, 2014.
[28] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 3–16. ACM, 2016.
[29] I. Giechaskiel, C. Cremers, and K. B. Rasmussen. On bitcoin security in the presence of broken cryptographic primitives. In European Symposium on Research in Computer Security (ESORICS), September 2016.
[30] J. Göbel, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor. Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay. Performance Evaluation, 104:23–41, 2016.
[31] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, 2015.
[32] Huntercoin developers. Huntercoin reference implementation. https://github.com/chronokings/huntercoin. Accessed: 2017-06-05.
[33] B. Jakobsson and A. Juels. Proofs of work and bread pudding protocols, Apr. 8 2008. US Patent 7,356,696; Accessed: 2017-06-05.
[34] M. Jakobsson and A. Juels. Proofs of work and bread pudding protocols. In Secure Information Networks, pages 258–272. Springer, 1999.
[35] A. Judmayer, N. Stifter, K. Krombholz, and E. Weippl. Blocks and chains: Introduction to bitcoin, cryptocurrencies, and their consensus mechanisms. Synthesis Lectures on Information Security, Privacy, & Trust, 9(1):1–123, 2017.
[36] A. Juels and J. G. Brainard. Client puzzles: A cryptographic countermeasure against connection depletion attacks. In NDSS, volume 99, pages 151–165, 1999.
[37] A. Juels and B. S. Kaliski Jr. Pors: Proofs of retrievability for large files. In Proceedings of the 14th ACM conference on Computer and communications security, pages 584–597. Acm, 2007.
[38] H. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau, and A. Narayanan. An empirical study of namecoin and lessons for decentralized namespace design. In WEIS, 2015.
[39] G. O. Karame, E. Androulaki, and S. Capkun. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 906–917. ACM, 2012.
[40] G. O. Karame, E. Androulaki, M. Roeschlin, A. Gervais, and S. Čapkun. Misbehavior in bitcoin: A study of double-spending and accountability. volume 18, page 2. ACM, 2015.
[41] A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.
[42] S. King. Primecoin: Cryptocurrency with prime number proof-of-work. July 7th, 2013.
[43] T. Kluyver, B. Ragan-Kelley, F. Pérez, B. E. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. B. Hamrick, J. Grout, S. Corlay, et al. Jupyter notebooks-a publishing format for reproducible computational workflows. In ELPUB, pages 87–90, 2016.
[44] Lerner, Sergio D. Rootstock plattform. http://www.the-blockchain.com/docs/Rootstock-WhitePaper-Overview.pdf. Accessed: 2017-06-05.
[45] Y. Lewenberg, Y. Bachrach, Y. Sompolinsky, A. Zohar, and J. S. Rosenschein. Bitcoin mining pools: A cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pages 919–927. International Foundation for Autonomous Agents and Multiagent Systems, 2015.
[46] Litecoin community. Litecoin reference implementation. https://github.com/litecoin-project/litecoin. Accessed: 2017-09-28.
[47] I. Maven. Apache maven project, 2011.
[48] G. Maxwell. Comment in "[bitcoin-dev] weak block thoughts...". https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011198.html, 2016. Accessed: 2017-05-10.
[49] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. Voelker, and S. Savage. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference, pages 127–140. ACM, 2013.
[50] S. Micali. Algorand: The efficient and democratic ledger. http://arxiv.org/abs/1607.01341, 2016. Accessed: 2017-02-09.
[51] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz. Permacoin: Repurposing bitcoin work for data preservation. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 475–490. IEEE, 2014.
[52] A. Miller, A. Kosba, J. Katz, and E. Shi. Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 680–691. ACM, 2015.
[53] B. Momjian. PostgreSQL: introduction and concepts, volume 192. Addison-Wesley New York, 2001.
[54] Myriad core developers. Myriadcoin reference implementation. https://github.com/myriadcoin/myriadcoin. Accessed: 2017-06-05.
[55] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, Dec 2008. Accessed: 2017-09-28.
[56] S. Nakamoto. Merged mining specification. https://en.bitcoin.it/wiki/Merged_mining_specification, Apr 2011. Accessed: 2017-09-28.
[57] Namecoin Community. Merged mining. https://github.com/namecoin/wiki/blob/masteMerged-Mining.mediawiki#Goal_of_this_namecoin_change. Accessed: 2017-08-20.
[58] Namecoin community. Namecoin reference implementation. https://github.com/namecoin/namecoin. Accessed: 2017-09-28.
[59] A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.
[60] K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016.
[61] K. J. O’Dwyer and D. Malone. Bitcoin mining and its energy footprint. 2014.
[62] R. Pass, L. Seeman, and A. Shelat. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 643–673. Springer, 2017.
[63] D. Pointcheval and J. Stern. Security arguments for digital signatures and blind signatures. Journal of cryptology, 13(3):361–396, 2000.
[64] Pseudonymous("TierNolan"). Decoupling transactions and pow. https://bitcointalk.org/index.php?topic=179598.0, 2013. Accessed: 2017-05-10.
[65] P. R. Rizun. Subchains: A technique to scale bitcoin and improve the user experience. Ledger, 1:38–52, 2016.
[66] K. Rosenbaum. Weak blocks - the good and the bad. http://popeller.io/index.php/2016/01/19/weak-blocks-the-good-and-the-bad/, 2016. Accessed: 2017-05-10.
[67] K. Rosenbaum and R. Russell. Iblt and weak block propagation performance. Scaling Bitcoin Hong Kong (6 December 2015), 2015.
[68] M. Rosenfeld. Analysis of bitcoin pooled mining reward systems. arXiv preprint arXiv:1112.4980, 2011.
[69] M. Rosenfeld. Analysis of hashrate-based double spending. http://arxiv.org/abs/1402.2009, 2014. Accessed: 2016-03-09.
[70] R. Russel. Weak block simulator for bitcoin. https://github.com/rustyrussell/weak-blocks, 2014. Accessed: 2017-05-10.
[71] A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 515–532. Springer, 2016.
[72] Sathoshi Nakamoto. Comment in "bitdns and generalizing bitcoin" bitcointalk thread. https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696. Accessed: 2017-06-05.
[73] O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive compatibility of bitcoin mining pool reward functions. In FC ’16: Proceedings of the the 20th International Conference on Financial Cryptography, February 2016.
[74] B. Sengupta, S. Bag, S. Ruj, and K. Sakurai. Retricoin: Bitcoin based on compact proofs of retrievability. In Proceedings of the 17th International Conference on Distributed Computing and Networking, page 14. ACM, 2016.
[75] N. Szabo. Bit gold. http://unenumerated.blogspot.co.at/2005/12/bit-gold.html, 2005. Accessed: 2017-09-28.
[76] M. B. Taylor. Bitcoin and the age of bespoke silicon. In Proceedings of the 2013 International Conference on Compilers, Architectures and Synthesis for Embedded Systems, page 16. IEEE Press, 2013.
[77] Unitus developers. Unitus reference implementation. https://github.com/unitusdev/unitus. Accessed: 2017-08-22.
[78] M. Vukolić. The quest for scalable blockchain fabric: Proof-of-work vs. bft replication. In International Workshop on Open Problems in Network Security, pages 112–125. Springer, 2015.
[79] P. Webb, D. Syer, J. Long, S. Nicoll, R. Winch, A. Wilkinson, M. Overdijk, C. Dupuis, and S. Deleuze. Spring boot reference guide. Technical report, 2013-2016.
[80] A. Zamyatin. Name-squatting in namecoin. (unpublished BSc thesis, Vienna University of Technology), 2015.
submitted by dj-gutz to myrXiv [link] [comments]

An Analysis of Attacks on Blockchain Consensus

arXiv:1610.07985
Date: 2016-11-20
Author(s): George Bissias, Brian Neil Levine, A. Pinar Ozisik, Gavin Andresen

Link to Paper


Abstract
We present and validate a novel mathematical model of the blockchain mining process and use it to conduct an economic evaluation of the double-spend attack, which is fundamental to all blockchain systems. Our analysis focuses on the value of transactions that can be secured under a conventional double-spend attack, both with and without a concurrent eclipse attack. Our model quantifies the importance of several factors that determine the attack's success, including confirmation depth, attacker mining power, and any confirmation deadline set by the merchant. In general, the security of a transaction against a double-spend attack increases roughly logarithmically with the depth of the block, made easier by the increasing sum of coin turned-over (between individuals) in the blocks, but more difficult by the increasing proof of work required. In recent blockchain data, we observed a median block turnover value of 6 BTC. Based on this value, a merchant requiring a single confirmation is protected against only attackers that can increase the current mining power by 1% or less. However, similar analysis shows that a merchant that requires a much longer 72 confirmations (~12 hours) will eliminate all potential profit for any double-spend attacker adding mining power less than 40% of the current mining power.

References
  1. Back, A., Corallo, M., Dashjr, L., Mark, F., Maxwell, G., Miller, A., Poelstra, A., Timón, J., Wuille, P.: Enabling Blockchain Innovations with Pegged Sidechains. http://www.opensciencereview.com/papers/123/enablingblockchain-innovations-with-pegged-sidechains (October 2014)
  2. Bissias, G., Ozisik, A.P., Levine, B.N., Liberatore, M.: Sybil-Resistant Mixing for Bitcoin. In: Proc. ACM Workshop on Privacy in the Electronic Society (November 2014), http://forensics.umass.edu/pubs/bissias.wpes.2014.pdf
  3. Confirmation. https://en.bitcoin.it/wiki/Confirmation (February 2015)
  4. Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J., Felten, E.: Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In: IEEE S&P. pp. 104–121 (May 2015), http://doi.org/10.1109/SP.2015.14
  5. Bonneau, J.: How long does it take for a bitcoin transaction to be confirmed? https://coincenter.org/2015/11/what-does-it-mean-for-a-bitcoin-transactionto-be-confirmed/ (November 2015)
  6. Croman, K., et al.: On Scaling Decentralized Blockchains . In: Workshop on Bitcoin and Blockchain Research (Feb 2016)
  7. Douceur, J.: The Sybil Attack. In: Proc. Intl Wkshp on Peer-to-Peer Systems (IPTPS) (Mar 2002)
  8. Ethereum Homestead Documentation. http://ethdocs.org/en/latest/
  9. Eyal, I., Sirer, E.G.: Majority Is Not Enough: Bitcoin Mining Is Vulnerable. Financial Cryptography pp. 436–454 (2014), http://doi.org/10.1007/978-3-662-45472-5_28
  10. Fischer, M., Lynch, N., Paterson, M.: Impossibility of distributed consensus with one faulty process. JACM 32(2), 374–382 (1985)
  11. Gervais, A., O. Karame, G., Wust, K., Glykantzis, V., Ritzdorf, H., Capkun, S.: On the Security and Performance of Proof of Work Blockchains. https://eprint.iacr.org/2016/555 (2016)
  12. Heilman, E., Alshenibr, L., Baldimtsi, F., Scafuro, A., Goldberg, S.: Tumblebit: An untrusted bitcoin-compatible anonymous payment hub. Cryptology ePrint Archive, Report 2016/575 (2016), http://eprint.iacr.org/2016/575
  13. Heilman, E., Kendler, A., Zohar, A., Goldberg, S.: Eclipse Attacks on Bitcoin’s Peer-to-peer Network. In: USENIX Security (2015)
  14. Litecoin. http://litecoin.org/
  15. Meiklejohn, S., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker, G., Savage, S.: A Fistful of Bitcoins: Characterizing Payments Among Men with No Names. In: Proc. ACM IMC. pp. 127–140 (2013), http://doi.acm.org/10.1145/2504730.2504747
  16. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf (May 2009)
  17. Pagnia, H., Vogt, H., Gaertner, F.: Fair Exchange. The Computer Journal, vol. 46, num. 1, p. 55, 2003. 46(1), 55–78 (2003)
  18. Poon, J., Dryja, T.: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. http://www.lightning.network/lightning-network-paper.pdf (November 2015)
  19. Ron, D., Shamir, A.: Quantitative analysis of the full bitcoin transaction graph. In: Proc. Financial Crypto. pp. 6–24 (Apr 2013), http://doi.org/10.1007/978-3-642-39884-1_2
  20. Rosenfeld, M.: Analysis of hashrate-based double-spending. https://bitcoil.co.il/Doublespend.pdf (December 2012)
  21. Sapirshtein, A., Sompolinsky, Y., Zohar, A.: Optimal Selfish Mining Strategies in Bitcoin. https://arxiv.org/pdf/1507.06183.pdf (July 2015)
  22. Sasson, E.B., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza, M.: Zerocash: Decentralized anonymous payments from bitcoin. In: IEEE S&P. pp. 459–474 (2014), http://dx.doi.org/10.1109/SP.2014.36
  23. Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in Bitcoin. Financial Cryptography and Data Security (2015), http://doi.org/10.1007/978-3-662-47854-7_32
  24. Sompolinsky, Y., Zohar, A.: Bitcoin’s Security Model Revisited. https://arxiv.org/abs/1605.09193 (May 2016)
  25. Tschorsch, F., Scheuermann, B.: Bitcoin and beyond: A technical survey on decentralized digital currencies. IEEE Communications Surveys Tutorials PP(99), 1–1 (2016)
submitted by dj-gutz to myrXiv [link] [comments]

Frequently Asked Questions (FAQ)

Frequently Asked Questions (FAQ)
1. What is Helix?
Helix Cognitive Computing GmbH is a Berlin-based strategic tech company, dedicated to creating a cutting-edge digital ecosystem for interconnecting Everyone and Everything. Helix aims to challenge the status quo by eliminating the need for intermediaries and central authorities, at virtually no cost. For more information, you can visit our website at www.hlx.ai.
2. What problem is Helix solving?
Helix solves problems associated with centralized systems and management. Rather than blindly relying on third-party promises, Helix builds trust by adopting public consensus mechanisms. Thus, it fosters the creation of endless new relationships and businesses that are more ‚direct‘ in nature. Helix enables the use of end-to-end encryption to emit secured data streams, implying that you can fully control which parties are authorized to access your messages or data.
By eliminating intermediaries, Helix enables trustless transactions. It is no longer required to blindly trust any intermediary, whether it is a storage or financial service provider, such as banks. An example includes the creation of Decentralized Autonomous Organizations (DAOs) that are direct, peer-to-peer and organize their company through digital voting systems. This could be achieved for any organization using the HelixFramework involving no payment fees to Helix. The Helix Consensus Protocol is leveraged to achieve data integrity instead of that (for more information about the HelixTangle, please refer to the Whitepaper on our website: https://www.hlx.ai/whitepaper), i.e., transactions that have reached agreement are serialized to the ledger and are immutable.
3. What makes Helix different to others?
  • The Helix Consensus Protocol (HCP) enables efficient and secure transaction processing at virtually no cost, opposed to legacy blockchains.
  • We are building an application by the name of HelixComposer. Helix assigns great importance to usability and accessibility by providing an interface for people who do not have prior knowledge in cryptocurrencies or computer sciences. The HelixComposer and its graphical user interface provide the middle layer or rather the "interaction layer" between users and the network infrastructure. It enables interactive guidance and tools for designing own decentralized applications and defining smart contracts.
  • We have community service, the HelixFoundation. The HelixFoundation assures the sustainability of the HelixNetwork. The HelixNetwork consists of Nodes (Computers) executing HCP and overlay networks (such as Flash and MAM), that are leveraged to achieve greater scalability and privacy. Further, the HelixFoundation is dedicated to creating educational workshops in the realm of Distributed Ledger Technologies, as we feel a great need of educating interested people and promote young talents.
4. Is Helix an active player in the Blockchain space?
Helix is active in the Distributed Ledger Technologies DLT space with its own Peer-to-Peer (P2P) network protocol – not based on Blockchain principles. The Helix Distributed Ledger is modeled as a Directed Acyclic Graph (DAG), a well-known data structure with excellent properties in terms of scalability.
5. What does decentralization mean?
Decentralization is a term used in network topology to describe the relations between different node types. Centralized systems typically consist of a client-server architecture or slave nodes listening to a coordinator.
https://i.redd.it/8pue5gmq1fg11.png
Decentralization promotes the elimination of unnecessary intermediaries, from the transfer of value between persons and things.
6. What is Distributed Ledger Technology (DLT)?
Distributed Ledger Technology encompasses an extensive database consisting of synchronized digital records. Examples of records maintained by DLTs include monetary transactions (e.g., Bitcoin Blockchain), titles and rights to intellectual property, creative content, music, votes, healthcare records, and other sensitive or confidential material.
7. What is a Directed Acyclic Graph (DAG)?
A Directed Acyclic Graph is a particular type of graph consisting of nodes connected to each other by directed edges. The term ‘Directed’ refers to the idea that edges have directions (like a street map), while ‘Acyclic’ implies that it is not possible to walk from a node X and return to X without going back on a previously used edge (for example no U-turns!).
8. What is a P2P Network?
The architecture of most computer applications on the internet is two-tiered. In a two-tiered architecture, there is a clear division between clients and servers. For example, a typical banking application allows a client to prepare transactions on his/her local machine, and upload the transaction to the bank's centralized server or database. In contrast to the two-tiered architecture of centralized applications, P2P systems equally distribute all aspects of the application across participants, which enables workloads, resources, and values to be shared, and additionally, eliminates the need for peers to trust central authorities.
9. What is “cognition”?
The word cognition derives from the Latin term cognosco which means 'to conceptualize'. Cognition can be defined as the mental act of acquiring and understanding knowledge through senses, experience, and thought.
10. What does “cognitive computing” mean?
Cognitive computers imitate human intelligence by processing data with a set of rules and procedures that can be updated iteratively, based on the value of the incoming data on an asneeded basis. Cognitive computing systems can provide highly accurate descriptions of visual and linguistic data, just like humans. A developing cognitive computer system relies on machine learning strategies, and the scientific study of biological systems, including their cognitive abilities that sustain autonomous, self-driven learning.
11. How is Helix funded today and do you plan an ICO – when?
Currently, Helix is funded by global private and institutional investors. In order to optimize its strategy and operations to the interest of both public (i.e. community) and professional investors, Helix decides to defer its ICO until a better perception in the markets evolves. Helix also intends to evaluate other forms of global coin distribution models where the public audience would be involved in schemes similar to Bounty Programs or Air Drops rather than an ICO. For more detailed information about ICO and Coins, please refer to the Helix ICO & Coins Quick Facts on our website: https://hlx.ai/whitepaper.
12. What is a cryptocurrency after all?
A cryptocurrency is a digital means of payment created and transferred using cryptographic principles, to enable a decentralized and secure payment system.
13. What is HLX?
HLX is the cryptocurrency developed by Helix Cognitive Computing.
14. Why is HLX called "Cognitive Cryptocurrency"?
Every transaction initiated in the HelixTangle results from the process of cognition. Helix uses cognitive scientific methods for purposes of security and validation in the network. For example, in order to approve or validate a transaction, Helix introduces the first ever transaction ledger in the crypto world, which secures transactions using artificial intelligence techniques such as decentralized deep learning, a unique ability to understand, reason and learn about cyber-attacks and threats.
15. Who can use HLX?
HLX is for everyone and everything. You do not need to create a large valued transaction to use the HelixTangle. And since there is no fee, both people and machines can attach their micro-valued transactions to the HelixTangle. Thus, the HelixTangle can be used for machineto-machine settlement, person-to-machine, or machine-to-person payments.
16. Who needs HLX?
The HLX coin is the means of digital exchange in the HelixTangle.
17. How I can mine HLX and how expensive are the transaction fees?
You cannot "mine" the HelixTangle because the Helix protocol does not require intermediaries like miners. The upshot is that the HelixTangle does not waste valuable resources like energy or natural space. Regarding transaction fees, there are none!
18. How are HLX created?
The HLX amount was set in advance by a human council. The sum is set in advance in the code and implemented in the HelixTangle. The Total Coin Supply is calculated from (244 * 244).
19. What is the maximum number of HLX Coins that can be in circulation?
Our maximum amount will be 4,292,493,394,837,504 HLX or 4,292,493,394 mHLX. We also tend to say, in short, but imprecisely: "The total supply is approximately 4,3 petaHLX".
20. What is the difference between mHLX and HLX?
Because the number 4,292,493,394,837,504 HLX is rather inconvenient to use, we count in millions of HLX, calling that unit mHLX (“Mega Helix”).
So the integer of the total coin supply divided by a million results in the total mHLX supply of 4,292,493,394 mHLX.
21. Is the HLX supply infinite?
The HLX coin supply is finite, not infinite. In other words, there are a limited number of HLX coins. In contrast to the Keynesian economic models of most states, the HLX coin supply is not inflationary because no one can “print money” as they need it, and arbitrary coins are never generated.
22. On which exchange platforms for trading HLX will be available?
To be announced after the ICO.
23. Where can I store my HLX?
Once the HLX coins are prepared for transfer to third parties, you can store your HLX inside the HelixWallet software that will be provided in time for the coin transfers.
24. Is Helix' focus on the HLX coin or the Tangle?
First and foremost, Helix is not about the cryptocurrency but rather a protocol for introducing next-generation technology in decentralized distributed computing. It can be said that the cryptocurrency HLX is a necessity to our peer-to-peer network. To be able to tap the full potential of the HelixTangle you need currency. It is not possible to pay with fiat money on the Tangle, and this is not a plan.
25. Is the HelixNetwork better than a Blockchain P2P network?
Yes. Advantages of the HelixNetwork over traditional Blockchain P2P networks include:
  • Cost – Transactions in the Tangle are free of charge and occur at a far higher speed
  • Scalability - Transaction confirmation speed increases linearly with the numbers of tips
  • Decentralization – The Helix Tangle eliminates the need for mining or miners
  • Environmentally Friendly – e.g., No waste of electrical energy
  • Can be used by the emerging machine economy (=IoT and sensors).
26. Why is the Tangle faster than a Blockchain?
New transactions in the Tangle confirm two previous transactions. This makes the Tangle infinitely scalable. Blockchain, on the other hand, sees several transactions packed into one block and these blocks are charged every ten minutes.
27. What is unique about the Tangle?
The HLX coin can be used like any other cryptocurrency. The network protocol was specially designed to connect devices. Companies and people gather data every day with a myriad of devices such as weather sensors or sensors in machinery and healthcare. But almost every piece of information is not used or recycled. The HelixNetwork can tackle it in two ways: It can save data in a way, such that no one other than yourself has access to the data. Moreover, it allows a free transaction between the owner and the one who wants to acquire the data. While we already realize how relevant data is at present, in the future, data will play an even more significant role.
28. How is data stored in the Tangle?
Suppose you want to send a JPG file to someone. First, your picture will be split into several parts and stored in a special field of various Helix transactions.
To send data or communicate with someone on the HelixTangle, you store data in the shared, public version of the Tangle for a limited amount of time. When you, or someone else you authorize, retrieve the data, you are reading the data directly from the HelixTangle in its most current state. The transactions containing your data will not be removed until a snapshot, which is like sending data off into oblivion. After the data has been forgotten, all transaction objects valued at 0 are deleted from the shared, public HelixTangle. If someone would want to read your data from the HelixTangle, that would mean that they must take the precisely same walk through the graph you already did, and only then they would recover the original walk, or message, or data. To simplify this process and stay up to certain privacy requirements, we use a module called Masked Authenticated Messaging. It enables a private, public or restricted encrypted data stream, wherein the restricted scheme, for instance, a channel identifier key and a private key would be required to access the data stream.
29. Is the data stored in the Tangle or does the data only pass through the Tangle?
To be certain of the correctness of your data, in other words, to achieve data integrity, it is mandatory that data is stored in the Tangle. Due to Proof of Work requirements and confirmation times, this could lead to problems in a scenario like a messaging app, where remotely instant data transfer is required. In these cases, it is recommended to use an overlay network like Flash. Flash enables the creation of a multi-signature wallet (that holds a balance predefined by the parties) by two or more parties that trust each other. Transactions in a flash channel are almost instant, with delays only associated to network propagation. When the channel is closed by the parties, the last state of the balances of the parties is synchronized to the Tangle. This procedure eliminates a lot of overhead, supports scalability of the overall system, i.e., the HelixNetwork and enables a tremendous throughput of transactions.
30. How is the data sent?
You can use the interface provided in the official HelixWallet. Using the Interface, you will be able to publish data into the Tangle and restrict access to your needs.
31. What are possible use cases for the HelixTangle?
To give a few examples:
  • Bio data platform - BEAMS (Helix' first spin-off, more information at www.beams.ai)
  • Recording diagnostics
  • Supply Chain Transparency (Manufacturing)
  • Aircraft Maintenance, Repair, and Operations (MRO) Energy & Utilities (The era of microgrids)
  • Public transport (Train, bus)
  • Licensing (Music, movies)
  • Votes (Government)
  • Post-shipping companies (UPS, DHL)
  • Food Industry (Food tracking)
32. Do I need HLX to use the Tangle?
It is not entirely necessary to own HLX to use the Tangle. In the future, you will be able to use the Helix Tangle to store and send your data to other people securely.
33. When will the HelixTangle / Network be available?
The MainNet should be launched in Q1 of 2019.
34. How can I synchronize with Helix' progress?
To keep up to date, you can follow our Social Media Accounts, or get informed through our website and Discord server.
Helix is active on the following Social Media Platforms:
Discord: https://discordapp.com/invite/WztYaYP
Telegram: https://t.me/helixfoundation
Twitter: https://twitter.com/FoundationHelix
Facebook: https://www.facebook.com/Helix-Foundation-874464419427146/
LinkedIn: https://www.linkedin.com/company/hcc-gmbh/
Medium: https://medium.com/helix-foundation
YouTube: https://www.youtube.com/channel/UCTC_SlcpU4V9juYkIN87rKA
Bitcointalk: https://bitcointalk.org/index.php?topic=4794230.0
35. What are Helix' intentions regarding Post-Quantum-Cryptography?
Helix’ proof of work is minimal which means the difference of performance between a quantum computer (QC) and a normal computer is minimal (~QC would be roughly 100 times more efficient than an average everyday computer, in blockchain a QC would be 14 billion times more efficient than a high-end mining pool). The difference is great.
Helix uses Schnorr signatures, which are based on the discrete logarithm problem. It achieves high performance and privacy standards and is widely studied and accepted in the industry. The problem is it’s susceptibility to quantum computations (to be more specific Shor’s algorithm implementation on QCS). Although we see the quantum era as a massive threat to existing cryptographic methods, we are sure of the fact that certain attacks, which are currently only theoretically modeled, will need a few more years to become practical enough for sufficient incentive of an adversary. While Helix is determined to come up with solutions for the quantum era, we decide to take a route quite different from our predecessor. Instead of publishing “quantum proof” algorithms (that the scientific community hasn’t had a chance to study yet), now in a time where there is no practical QC attack, seems kind of premature. In a realm, where trust is the highest good, seems premature.
The general idea is to use, what achieves the best performance and security standards today, while initiating the research needed to sustain all of the computing eras that lie ahead.
36. What Helix areas and brands are worth to know?
  • HelixEcosystem - All systems, users, community associated with the HelixTangle
  • HelixTangle - Helix’ initiated P2P network protocol (a next-generation internet)
  • HelixPlatform - The place for developers and community to interact with the HelixTangle
  • HelixWallet - Interface to manage participation in the HelixEcosystem
  • HelixVirtualMachine - Provides secure access to the computing power of the HelixTangle
  • HelixComposer - Toolkit to build your dApps (decentralized use cases)
  • HelixWetware - Helix’ future initiative for a DNA-based molecular storage system
  • HelixFoundation - the Non-Profit arm of Helix to foster HelixEcosystem and R&D
  • HelixCognitiveComputing - the Commercial legal entity of HelixGroup
  • HLX - Helix Cognitive Cryptocurrency
  • BEAMS - A bio data platform powered by the HelixTangle
submitted by HelixFoundation to helixfoundation [link] [comments]

Community management response to recent concerns.

Hey all,
I’ve spent some time during my flight back home to discuss in detail the experience in Singapore, what talked about, things the mods and team are working on, improvements that can be made and some other things too.
I don’t think any of the mods were massively pleased with the outcome of how we portrayed our time in Singapore during the last update and it certainly didn’t put across all the fantastic things we learnt or discussed while we were there. There was a quick turnaround with the update and with some of us were travelling and heading to other countries for various reasons it wasn’t ideal – anyway let’s begin. P.s. I apologise in advance for the lengthy post.

Rebrand + the Request structure

As most of you are aware there is a rebrand going on for Request currently, it was really exciting to hear Robbins experience and to see the scope of the rebrand. Request are working with an industry leading full-service digital agency to improve Request not only as a brand but as an organisation too.
The current Request website is mainly catered towards ICO investors and hasn’t really changed much since the token sale – when visiting the site, it’s extremely difficult to understand what Request is, how it works and who can it benefit from the platform. One of the goals of the rebrand is to completely revamp the website to cater for developers, businesses, users, community members, early adopters and investors.
The concept of the blockchain, Request, and its products is daunting for the non-technical audience. While the team know it’s important to cater for developers and other industry professionals having an easy to understand project with easy to consume information is an important step towards adoption.
The Request Hub will also play a critical part in the growth of the Request Network, the new rebrand + website will have a focus on developers and businesses and pushing them towards the hub and how they can use the funding to help create their projects. Alongside the rebrand the foundation will undergo a restructure (which ties into the new rebrand). Most of you will probably be aware that the dApps + the core protocol are different projects entirely, although the dApps leverage the Request platform they are treated and handled differently internally at Request.
You can see an visual image of the structure here: https://imgur.com/pXF1gEK
The core platform team are responsible for protocol development, things like scaling solutions, data encryption, extensions, features like cross-currency etc. Whereas the dApp team focus on creating applications built on the Request platform, crowdfunding, invoicing, payments etc. Although this isn’t new information it’s important for sections later in the write-up.

FIAT

This is an excerpt from the 8th June AMA special project update (https://blog.request.network/request-network-project-update-june-8th-2018-ama-special-request-network-now-available-for-5da85547d933) which covers the teams thoughts on FIAT.
Fiat integration is vital for the success of the Request Network for medium to long-term. What we focus on today is making sure the protocol has enough features and a solid developer experience to attract developers to build reliable financial tools on top of the Request Network. The foundation prioritizes its own development goals based on direct feedback coming from the developer community. We receive requests for features that are needed by developers, as their product depends on it.
Today, the main feedback coming from the developer community is to make it easier to use the library, implementation of encryption, cross currency support and adding more cryptocurrencies. Apart from these requests, scalability of the protocol itself and developing extensions such as escrow are also prioritized as it is crucial for adoption of the protocol by developers. The above are our current priorities in development, while we in parallel are researching several fiat integration options mentioned in an update last December.
All of the above bullet points are things the team are actively researching and looking into, we discussed how the Singapore government is looking at tokenizing the Singaporean Dollar and how many more governments in the future will look at taking this route, however this is a long way off.
A decentralised Oracle with Chainlink would be ideal but it’s not ready yet – hopefully we will see Chainlink launch on the main-net soon.
Integrations by partnerships with banks / partnering with credit card companies or processors (like Stripe) is incredibly difficult (especially being decentralised) but it’s something the team will actively work on / towards.
Oracle and bank APIs – we discussed several projects here like StellarX, OmiseGo and more – each have their own pros and cons but nothing in the space is really ready for FIAT, some options are close and the team are keeping a close eye on several projects in this space.
There are tonnes of regulatory issues surrounding FIAT and the blockchain, governments are dubious about the blockchain technology and banks are having a tough time getting involved too – even big companies like Binance, Coinbase and Circle still can’t obtain a banking license after many years of trying. The regulatory situation will change, crypto is still a young industry and it will take time for governments to catch up.
Instead of spending time trying to achieve FIAT which wasn’t viable, their time has been spent on far more productive things such as scaling solutions, data encryption, working on various dApps, working with partners, hiring and much more. The better the platform the more impact having FIAT will have when it comes. Yes, not being able to stick to the roadmap isn’t ideal, but the team have realised there are limitations and made the best of the situation.
Would it have been good if the team have been more transparent about FIAT and the issues they faced? Absolutely. Detailed articles about subjects like this do take time, and raise further questions which also take up the team’s time. We want to find a good balance going forward of keeping the team on track and keeping the community informed. We will also work with the team to improve communication for things like this (if they ever arise in the future) and how the mods can alleviate some of the time-pressure if possible.
The team do realise the importance of FIAT, it hasn’t been forgotten and will be something the team will keep on the roadmap – in the future when FIAT is possible we will have a much more mature platform and many use cases live and ready to integrate FIAT.

Marketing

One of the most discussed things over the past months is marketing, this is a very important topic and it’s something that can make or break a project.
As per the ‘Rebranding + Restructure’ section, marketing will be broken down into two different groups, dApps and the core Request platform. The marketing for each of these aspects is very different.
So, why aren’t the team marketing right now? Quite simply – the platform just isn’t ready yet, there isn’t enough value to risk marketing at this stage. This is the same with some of the dApps, they are close, but they still aren’t quite there yet.
In my case if we take a look at the WooCommerce + Shopify plugins, if I go ahead and run a PPC (pay-per-click) campaign before BTC is integrated, then users may leave the site and never return. In this instance I will have lost money as well as a potential customer. This is just one example but it’s the same for other dApps too.
Right now, The team are making active steps towards marking when the platform and dApps are, as well as hiring dedicated marketers.
I do want to say that the team truly understand the importance of marketing, they will market the project and the dApps– it’s critical they do so.
To break it down there are entirely separate game-plans to consider when marketing, the core platform and dApps.
Core Platform (Foundation)
Marketing for the core platform will focus on; educating the community about the platform, educating developers / businesses / potential partners about the Request protocol and how it can be used by / integrated into business workflows. They will also be marketing the Request Hub and the Request Fund to the devs and businesses.
The rebrand will have a big focus on education and driving adoption of the Request Hub + Fund. In the meantime, we are discussing ways to improve the Request Hub and how we can get more developers involved at this stage, I have covered this in more detail in the ‘Request Hub’ section.
dApps
Each dApp will in essence be its own entity (business) and will act independently of the foundation. Each dApp will have a dedicated team, individual aims and goals, potentially a custom roadmap, a propriety marketing strategy and much more (everything you expect from a typical business).
Marketing for individual dApps will vary greatly depending on what the dApp is, some will be focussed on B2B, some B2C, some dApps might be a combination of both.

Hiring + strategies to find new devs

The foundation growing at a quick rate and one of the things we discussed in Singapore was hiring and strategies to find new devs.
There are several strategies that the Request team can adopt alongside job advertisements to help entice developers, not only to the foundation but also to the Request Hub. We discussed potentially using freelancers and then hiring if they are a good fit, more engagement from the team with people that contribute to the Request Hub and how the team can help (financially via the fund + time set aside for devs), hackathons with prize incentives, speaking at developer conferences (very important). Some ways of engaging with developers do require the platform / ecosystem to be more mature but we are actively working on making these things a reality. Also, improving the community sentiment will also drive hype which in turn hopefully attracts more developers.

Request Hub + Request Fund

In my opinion one of the best selling points of Request is the Request Hub + Fund. Although there is activity in the hub and some projects have receiving funding it is nowhere near as widely used as it could be. As I’ve discussed in the marketing section, the rebrand will have a big focus on pushing the Hub + Fund.
Aside from the marketing aspect I have also been speaking to teams in the Hub for a while about how the flow for funding can be improved, we have discussed the barrier to entry for the fund (MVP limitations), the turnaround time for responding to funding applications (needs to be quicker), having the team engage more with the Request Hub devs as well as actively helping them with their business needs.
In the future I will also look at creating a suite of tutorials, and potentially workshops, for the Request Hub to help get developers up and running.

Bi-weekly updates

One of the hot topics since returning from Singapore has been the bi-weekly updates, we have been discussing with the team how they can be improved without taking up too much time for the team. There are several things which are actively being discussed:
This will be an ongoing discussion with the foundation, it will take time to refine the bi-weeklys and we also need to find a happy medium that suits both the foundation and the community too.

The Community Managers and our role

The goal as community managers is to firstly ensure that the social channels e.g. Reddit, Discord, Slack and Telegram are a good place for investors, the team and developers – we want to ensure it’s good for open discussions (both positive and negative) and a place where we can educate people about Request too.
As community managers we want to try and stay as impartial as possible, we will help to educate when we can, we’ll shut down any false information and we’ll help alleviate any concerns where possible. We don’t want to take sides, we are simply there to be a bridge between the team and the community.
We want the Request community to be an open place where anyone can discuss what they want, we want to see discussions about good things and bad – we don’t want Request to be a place where negativity is censored. We (the mods) are just normal guys, we love technology, we love the blockchain, we are just investors like all of you, and we want the best for the Request Network.
We are continually improving how we and the team deliver information, but things can still be improved massively – we are already actioning some things to improve communication between the community and the team and we have plenty of other things lined up too.

Roadmap

During the rebrand the website will rework the dynamic roadmap to something potentially similar to Ark (https://ark.io/roadmap), with percentages (or something similar) and a breakdown of each goal on the roadmap. This will help with transparency and also allow the community to track progress more easily.
I’ll cover my perspective on the dynamic roadmap looking from a developers point of view, as a lot of people are still unsure as to why the roadmap has changed and in turn it raises lots of questions.
From a developers point of view.
As a dev it can be incredibly difficult to hit deadlines that are more than a few weeks / over a month or two away, the further away the date the harder it is to estimate + hit deadlines. This is the case for a normal business, but as crypto is insanely fast paced and such a new industry this is even more prevalent.
In the normal development world you typically work in weekly / bi-weekly sprints to produce features in small iterations which contributes to the overall project, at the end of each sprint you re-evaluate the previous weeks and re-adjust timings / resources if necessary – estimating deadlines months in advance is almost impossible.
The biggest issue about committing to a firm date is that crypto adoption is moving at a fast rate, non-blockchain businesses are getting involved with cryptocurrencies and a great platform like Request is an attractive option for them. On-boarding these businesses takes money, expertise and most importantly team resources. The team is growing but for now the time spent with these partners needs to come from somewhere, and unfortunately features can sometimes get affected.
Let's take BTC support - if the team was fully focused on BTC I would have no doubt there would have been no delay. But PwC came along, which took up development resources and, unfortunately, impacted the deadline. Long-term, having PwC onboard will have a more positive effect on the overall Request Network ecosystem. Partnerships won't wait around, Bitcoin support will.
With these partnerships there will be a push for features they want to see. PwC for example, would be focused on the accounting so they would likely be pushing for accountancy related dApps (http://accounting.request.network/) - when the roadmap was first created the team could never predict such a huge entity like PwC would come onboard, so changing focus is sometimes required from a project. Once again, long-term this will benefit Request massively.
From a development perspective changing the roadmap is a fantastic move in my opinion, the team never know what is around the corner and being able to quickly adapt to new opportunities, on-boarding companies are critical for the long-term viability of the network. As the team grow there will be more development resource available to focus on the core platform and partners which will allow the team to better predict features in the future. Once again, I’d like to reiterate things do need improving here, the team can be more transparent, and the roadmap can, and will, be improved.

Summary

The Singapore trip was fantastic, and it was an incredible experience working closely with the team and it was great to see their passion and talent while working away through the week, it’s an excellent work environment too.
Every bit of feedback is incredibly important, please don’t hesitate to get in touch at any time to me or any of the mods, either by Reddit, Discord, Slack or Telegram.
There is a lot of work ahead for the mods and the team, but rest assured we have every single one of your concerns in our scope; the community and the perception you guys have is so important to the team and the project. There are a lot of great things going on that we will continue to improve and lots of things that need changing – it won’t be something that happens overnight but something that will be continuously improving for the entirety of the project – we are dedicated to working hard and improving Request and the community every day.
At the end of all this, actions speak louder than words, and we will action take everything into consideration to help ensure Request thrives.
Apologies for the lengthy post but hopefully this clears some bits up and helps to put across some of the great things we saw in Singapore, if you have any other questions feel free to leave a comment or get in touch privately. Cheers.
submitted by DontBlinkETH to RequestNetworkCss [link] [comments]

CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada | Pindar Wong | Aug 11 2015

Pindar Wong on Aug 11 2015:
Bitcoin Scalability Workshops
In recent months the Bitcoin development community has faced difficult
discussions of how to safely improve the scalability and decentralized
nature of the Bitcoin network. To aid the technical consensus building
process we are organizing a pair of workshops to collect technical
criteria, present proposals and evaluate technical materials and data with
academic discipline and analysis that fully considers the complex tradeoffs
between decentralization, utility, security and operational realities. This
may be considered as similar in intent and process to the NIST-SHA3 design
process where performance and security were in a tradeoff for a security
critical application.
Since Bitcoin is a P2P currency with many stakeholders, it is important to
collect requirements as broadly as possible, and through the process
enhance everyone’s understanding of the technical properties of Bitcoin to
help foster an inclusive, transparent, and informed process.
Those with technical interest are invited to participate in this pair of
workshops with the following intent:
Phase 1: Scene setting, evaluation criteria, and tradeoff analysis.
Montreal, Canada: September 12th-13th, 2015
Scalability is not a single parameter; there are many opportunities to make
the Bitcoin protocol more efficient and better able to service the needs of
its growing userbase. Each approach to further scaling the Bitcoin
blockchain involves implicit trade offs of desired properties of the whole
system. As a community we need to raise awareness of the complex and subtle
issues involved, facilitate deeper research and testing of existing
proposals, and motivate future work in this area.
The purpose of this workshop is to discuss the general tradeoffs and
requirements of any proposal to scale Bitcoin beyond its present limits.
Session topics are to include the presentation of experimental data
relating to known bottlenecks of Bitcoin’s continued growth and analysis of
implicit tradeoffs involved in general strategies for enabling future
growth.
This event will not host sessions on the topic of any specific proposals
involving changes to the Bitcoin protocol. Such proposals would be the
topic of a 2nd, follow-on Phase 2 workshop described below; this event is
intended to “set the stage” for work on and evaluation of specific
proposals in the time between the workshops.
Phase 2 will be planned out further as part of Phase 1 with input from the
participants.
Phase 2: Presentation and review of technical proposals, with simulation,
benchmark results.
Hong Kong, SAR, China: TBD Nov/Dec 2015
Hopefully to be easier for the Chinese miners to attend, the second
workshop pertaining to actual block size proposals is to be planned for
Hong Kong roughly in the late November to December timeframe.
The purpose of this workshop is to present and review actual proposals for
scaling Bitcoin against the requirements gathered in Phase 1. Multiple
competing proposals will be presented, with experimental data, and compared
against each other. The goal is to raise awareness of scalability issues
and build a pathway toward consensus for increasing Bitcoin’s transaction
processing capacity or, barring that, identify key areas of further
required research and next steps for moving forward.
Preliminarily, Phase 2 will be a time to share results from experiments
performed as a result of Phase 1 and an opportunity to discuss new
developments.
How do the Workshops work?
-
Both events will be live-streamed with remote participation facilitated
via IRC for parallel online discussion and passing questions to the event.
-
These workshops aim to facilitate the existing Bitcoin Improvement
Proposals (BIP)[1] process. Most work will be done outside of the workshops
in the intervening months. The workshops serve to be additive to the design
and review process by raising awareness of diverse points of view, studies,
simulations, and proposals.
-
Travel, venue details, and accommodation recommendation are available at
scalingbitcoin.org. Registration begins August 12th at an early-bird
ticket price of $150 USD until September 3rd. The ticket prices do not come
close to covering the venue expense and travel subsidies, hence the need
for corporate sponsors.
-
Please see the FAQ at scalingbitcoin.org which should answer most other
questions.
Travel Subsidies for Independent/Academic Researchers
There will be an application process for independent or academic
researchers to apply for travel assistance to help cover the expense of
airfare and hotel fees up to $1,000 per qualified presenter who intends to
give a presentation. The four underwriters of this event have agreed to
jointly review applications and cover the travel subsidies for qualified
presenters. See scalingbitcoin.org for details.
Sponsors of the Montreal Workshop
The first workshop is hosted and with logistics handled by the Montreal
consultancy CryptoMechanics <http://cryptomechanics.com>.
The Underwriters jointly responsible for venue expenses and researcher
travel subsidies are currently the MIT Digital Currency Initiative,
Chaincode Labs, Blockstream, and Chain.com.
Current sponsors include: Cryptsy, BitcoinTalk, Final Hash, Blockstream,
MIT DCI, Chaincode Labs, IDEO Futures, Kraken, and Chain.com.
Additional sponsors are needed. Please see scalingbitcoin.org for
sponsorship details or contact me directly via < pindar dot wong at
gmail.com >
Online Workshop Resources
-
Bitcoin-Workshops-Announce list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-workshops-announce
-
Bitcoin-Workshops discussion list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-workshops
-
#bitcoin-workshops chat on the Freenode IRC network
http://webchat.freenode.net/?channels=bitcoin-workshops
Call for Proposals/Papers/Presentations
If you have any research relevant to issues surrounding Bitcoin
scalability, your proposal for a presentation at the Montreal workshop
would be most welcome. Please see scalingbitcoin.org for submission
details.
Pindar Wong
Chair, Montreal Workshop Planning Committee
Chairman, VeriFi (Hong Kong) Ltd.
[1] https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/af220cea/attachment-0001.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010135.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

[2015/09/01] An Open Letter to the Bitcoin Community

An Open Letter to the Bitcoin Community
As active contributors to Bitcoin, we share this letter to communicate our plan of action related to technical consensus and Bitcoin scalability.
Bitcoin is many things to many people. However, the development and maintenance of Bitcoin is a human endeavor. Satoshi sought review and cooperation, and the subsequent work by Bitcoin’s developers has made the system more secure and orders of magnitude faster. The Bitcoin developer community is dedicated to the future of Bitcoin, looks after the health of the network, strives for the highest standards of performance, and works to keep Bitcoin secure on behalf of everyone.
We’re committed to Bitcoin and responsive to the needs of the community. For the past five years, we’ve written code and managed over 50 Bitcoin releases and reviewed more than 45 formal proposals to improve Bitcoin’s performance, security, and scalability. Technical discussions, while heated at times, are always focused on improving Bitcoin.
Much work has already been done in this area, from substantial improvements in CPU bottlenecks, memory usage, network efficiency, and initial block download times, to algorithmic scaling in general. However, a number of key challenges still remain, each with many significant considerations and tradeoffs to evaluate. We have worked on Bitcoin scaling for years while safeguarding the network’s core features of decentralization, security, and permissionless innovation. We’re committed to ensuring the largest possible number of users benefit from Bitcoin, without eroding these fundamental values.
There will be controversy from time to time, but Bitcoin is a security-critical system with billions of dollars of users’ assets that a mistake could compromise. To mitigate potential existential risks, it behooves us all to take the time to evaluate proposals that have been put forward and agree on the best solutions via the consensus-building process.
In the upcoming months, two open workshops will bring the community together to explore these issues. The first Scaling Bitcoin workshop will be in Montreal on September 12-13. The second workshop is planned for December 6-7 and will be hosted in Hong Kong to be more inclusive of Bitcoin’s global user base.
We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops. It’s great to already see broad excitement for the event and the high concentration of technical participants attending.
We’re confident that by working together we can agree on the best course of action. We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date.
We welcome your participation as we continue our efforts to bring Bitcoin into the future.
Signed,
(List of Technical contributors who support this letter)
Wladimir J. van der Laan
Pieter Wuille
Cory Fields
Luke Dashjr
Jonas Schnelli
Jorge Timón
Greg Maxwell
Eric Voskuil
Amir Taaki
Dave Collins
Michael Ford
Peter Todd
Phillip Mienk
Suhas Daftuar
R E Broadley
Eric Lombrozo
Daniel Kraft
Chris Moore
Alex Morcos
dexX7
Warren Togami
Mark Friedenbach
Ross Nicoll
Pavel Janík
Josh Lehan
Andrew Poelstra
Christian Decker
Bryan Bishop
Benedict Chan
฿tcDrak
William Swanson
Charlie Lee
Jeremy Rubin
Esteban Ordano
Manuel Araoz
Ruben de Vries
source: https://bitcoincore.org/en/2015/09/01/open-lette
submitted by linktype to Bitcoin [link] [comments]

Bitcoin Scalability Workshops - Scaling Bitcoin 2019 ... Bitcoin Scalability Workshops - Scaling Bitcoin 2019 Bitcoin 2019: Scaling to the Masses Scaling Bitcoin  Nervos Meetup Bitcoin Scalability Workshops - Scaling Bitcoin 2019

For example, Bitcoin can only deal with 7 transactions per second averagely. Obviously, it cannot meet the requirement of current digital payment scenarios, nor can it be carried in other applications such as distributed storage and credit service. What's more, different blockchain systems carry different business and requirements, so scalability is the core issue of the current development of ... The current Scaling Bitcoin Workshop will take place October 8 th -9 th at the Politecnico di Milano Piazza Leonardo da Vinci, 32 20133 Milano - Italy. We are accepting technical proposals for improving Bitcoin performance including designs, experimental results, and comparisons against other proposals. The goals are twofold: 1) to present potential solutions to scalability challenges while ... Andrew Poelstra (Director of research Blockstream) Workshop on scriptless scripts SB5-24. play_circle_filled. ... Mark Erhardt Simulation-based Evaluation of Coin Selection Strategies SB3-16. play_circle_filled . Arthur Gervais On the Security and Performance of Proof of Work Blockchains SB3-17. play_circle_filled. Emin Gun Sirer Bitcoin Covenants -- Opportunities and Challenges SB3-18. play ... Bitcoin is a distributed, worldwide, decentralized digital money … Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts. r/Bitcoin. log in sign up. User account menu. 49. CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada. Close. 49. Posted by. u/pindarhk. 4 years ago. Archived. CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada ... keyboard_arrow_leftBack Scaling Bitcoin workshop : Tel Aviv 2019 Anonymous atomic locks. A2L: Anonymous atomic locks for scalability and interoperability in payment-channel hubs

[index] [46593] [2719] [28261] [31069] [42271] [42100] [29832] [21371] [34742] [7629]

Bitcoin Scalability Workshops - Scaling Bitcoin 2019 ...

Bitcoin Scalability Workshops - Scaling Bitcoin 2019 "Yesod" - Day 1 - Morning - Duration: 3:44:52. Scaling Bitcoin 1,400 views. 3:44:52. Saifedean Ammous vs Peter Schiff on Sound Banking, Gold & ... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Scaling Bitcoin is an annual international nonprofit engineering conference focused on Bitcoin and Blockchain scalability approaches and related technologies... Try watching this video on www.youtube.com, or enable JavaScript if it is disabled in your browser. Bitcoin Scalability Workshops - Scaling Bitcoin 2019 "Yesod" - Day 1 - Afternoon - Duration: 4:46:13. Scaling Bitcoin Recommended for you. 4:46:13.

#