Tomorrow and Sunday, the second hackathon in the global BCH Devcon series will take place at Rockstart in Amsterdam. To give an idea of what the second event will hold, and what visiting a hackathon is like, BTC.com wrote-up a review of the first hackathon earlier this month in San Francisco, centring the experiences of attendee Michael Brink, sales head at Rehive. Read it below.
San Francisco’s BCH Hackathon brought together a diverse cross-section of blockchain engineers, fintech entrepreneurs, Bitcoin Cash experts, angel investors, designers, and scrum masters to implement the latest tools released for BCH developers, e.g. opcodes, big blocks, Wormhole tokens and smart contracts.
The judges also brought together a spectrum of deep industry insight with leading core developers from Bitcoin ABC, Wormhole, Coinbase, and Bitbox, and the founders of Moneybutton.com, Yours.org, and  Simple Ledger Protocol (SLP).
For one team of competitors at the event, who called themselves Team Armadillo, San Francisco’s BCH Devcon presented an opportunity to get hands-on experience using software toolkits to build a live demo for the first time.
“We sort of decided last minute” said Michael. “With just one day before the start, we didn’t even have time to find a third or fourth team member.” At the beginning of the first day the teams were given a list of use cases and guidelines as a basis to build from. Michael and colleague Bjorn arrived at the conference and found a room with a whiteboard to brainstorm.
Many participants go to hackathons with their company or a team that is already formed with a strong group of developers, and even implement code they’ve been working on. “While those teams may have a competitive edge, there’s something beautiful in having to start from scratch as you get an end-to-end experience from your first empty github repository to pitching your prototype!” Michael said.
Michael and Bjorn’s idea for the competition was to incentivise the Bitcoin Cash community to drive user adoption by funding a community wallet that issues rebates for goods bought using Bitcoin Cash. Merchants save on transaction fees and service more customers by selling goods at a discounted rate. The increased usage of Bitcoin Cash should in turn run up liquidity for the community wallet to continue issuing rebates.
With limited programming experience, Michael and Bjorn swallowed a five-hours crash course in Javascript to pick up the basics. “There was a serious learning curve, but we managed to hack together 300 lines of code that did the job. Stack overflow was instrumental, and we called a friend when we were stuck debugging”.
They investigated several block explorers that support the BCH testnetbecause they didn’t want to push heaps of test transactions onto the livenet. Michael explained that they chose BTC.com’s Blocktrail SDK because “we were learning, testing on the fly and found it was the most straightforward and well documented.”
Michael describes how they built a live node.js web app, deployed it on Google Cloud, and then set up a webhook directly out of BTC.com to watch incoming transactions on the merchant wallet. They used one of the account balances libraries to check who the transaction came from and initiated an autopay response from the community wallet back to the user.
Michael stressed the importance of working in parallel, “sometimes having two pairs of eyes debugging can help, but when the problem is complex and requires piecewise testing of the code, only one person can operate at a time.” For example, when Michael and Bjorn weren’t getting their web wallet app to deploy after a few hours of testing, Bjorn called a friend to figure out the issue halting the deployment, while Michael started on the pitch deck.
Hackathon judging criteria places a lot of weight on functionality. Michael and Bjorn focused on building the simplest form that worked first, and only then adding features.
At the end of the 24-hour sprint, Michael presented their live demo of a working community wallet, and successfully integrated a field for a user-specific rebate address. While they weren’t able to finish a live merchant checkout page, they presented a mockup that demonstrated what the landing page would have looked like.
Michael’s conclusion was “there’s no need to put too much pressure on yourself, the most important takeaway from the whole experience was the wealth of knowledge from sharing and building together.”