Receive all Cointelegraph news immediately in Telegram.
If bitcoin is meant to be the perfect money for the internet, one important property seems to be lacking: instant, secure, and trustless transactions. But the winning team of the first ever Amsterdam Bitcoin Hackathon – organized by Bitcoin API provider Blocktrail – may just have found the solution to this problem.
If bitcoin is meant to be the perfect money for the internet, one important property seems to be lacking: instant transactions that are secure and trustless. But the winning team of the first ever Blocktrail-sponsored Amsterdam Bitcoin Hackathon may just have found a way to circumvent confirmations when transacting bitcoins.
Sure, bitcoin-as-is provides a payments solution that is far superior to competitors in several ways. Transactions are often many times faster and more secure than wire transfers, credit cards or payment providers, eliminating the need for a trusted middle man.
Even with bitcoin, however, secure and trustless payments are not instant, since the possibility of double spending requires the need for at least one confirmation - which, of course, takes ten minutes on average, and could take more than an hour if you're unlucky. This is less than ideal, especially for some kinds of digital products – a Netflix-type of service that sells movies on demand, for instance.
This Saturday, in a stylish canal side house in the center of Amsterdam, a team of four hackers who had never met each other before, including two who were using bitcoin for the first time, might have constructed the theoretical groundwork to solve this problem. And even though some 12 hours of coding at the Amsterdam Bitcoin Hackathon was a little too short to finish a fully functional implementation, the concept itself and its visualization convinced the day's judges to award them the first prize of 5 bitcoins, a Trezor hardware wallet, and a ticket to the upcoming The Next Web conference in Amsterdam.
“It's far from a finished commercial product,” NoRiskWallet team member, Sebastian Lobato, emphasized. “It's a relatively clunky process, the fees are four times that of a normal transaction, and I suspect that the transaction malleability could even break this as long as that's not fixed. So it's far from ideal in its current form. But I think it's also something that has never existed in bitcoin before. And who knows? It’s possible that services such as Blocktrail or GreenAddress implement solutions like this one in the future.”
So how does the NoRiskWallet work? Essentially, the software makes use of a couple of Bitcoin's funky features, most importantly multisig capability - where several keys are needed in order to spend bitcoin – and lock time – which automates bitcoin transactions at some preset time in the future.
If a customer wants to make use of a NoRiskWallet service, he’d need to fund it by sending bitcoin to a two-out-of-two multisig address. As a key feature, this multisig address must contain a lock time transaction to himself, signed with one key held by the NoRiskWallet service, while the other key remains in the possession of the user. As such, the funds will automatically be sent back to the user at some point in the future, unless both parties overwrite the transaction before that time.
Meanwhile, the NoRiskWallet service would need to create an identical two-of-two multisig transaction with the merchant, funding this address with the same amount of bitcoin as collateral. Much like the first set-up, this address contains a transaction back to the NoRiskWallet service that will be triggered later on, unless both the NoRiskWallet service and the merchant agree to overwrite this transaction earlier than that.
Now, when the user decides to buy something from the merchant, he signs his part of the multisig transaction, and has the merchant contact the NoRiskWallet service in order to sign the other end of the transaction. But instead of sending the money to himself, both the user and the NoRiskWallet service send this money to the second multisig address. Subsequently, both the NoRiskWallet service and the merchant sign their end of this multisig wallet in order to forward the money to the merchant, while simultaneously signing a lock time transaction to the merchant as well, using the collateral.
NoRiskWallet team member Sebastian Lobato explains:
“In this way, no one is at risk of losing their money, even if the other two parties collude. The worst that could happen is that you'd have to wait a little while until the lock time is set. The user will have to wait in order to get his money back if the NoRiskWallet service doesn't uphold it's part of the deal, the NoRiskWallet service will have to wait to get its collateral back, and the merchant might have to wait for the collateral to be send in case the initial transaction gets double spend. But the amount of time they'd have to wait is determined by themselves, so it'd be a minor inconvenience at worst.”
Even though the software was not running at the end of the day, the hackathon judging panel as well as organizer and Blocktrail CEO, Boaz Bechar, regarded the NoRiskWallet the well deserved winner of the day. “The NoRiskWallet team took on a big challenge, especially for a one-day hackathon, and they made excellent progress throughout. It’s even more impressive that this team, which included both advanced and new users, all met that very morning! While we didn't get to see the final product in action, I think the crowd agreed with the judges that it was a very promising start”, Bechar said.
The No Trust Wallet code can be found on their GitHub page, which includes an elaborate explanation of the software in the Readme.
Full disclosure: The author of this article was on the hackathon judging panel but did not get paid except for free pizza and drinks.
Did you enjoy this article? You may also be interested in reading these ones:
Follow us on Facebook
For updates and exclusive offers, enter your e-mail below.
Thank you for contacting us! We will reply to you as soon as possible.
Thank you for your interest in our franchise program.
We are considering your request and will contact you in due course. If you have any further queries, please contact: