Feed aggregator

Apache Mesos for Beginners: 3 Videos to Help You Get Started

LXer -

How do you get started learning Apache Mesos? In this series highlighting presentations from MesosCon North America, we have showcased several large complex Mesos projects that elegantly solve difficult problems (see Mesos Large-Scale Solutions, below).

Stealth Transactions and Reusable Payment Codes: How Bitcoin Addresses Can Be Hidden in Plain Sight

Bitcoin Magazine -

Bitcoin, right now, is not really anonymous. While Bitcoin addresses aren't necessarily linked to real-world identities, they can be. Monitoring the unencrypted peer-to-peer network, analysis of the public blockchain and know your customer (KYC) policy or anti-money laundering (AML) regulation can reveal a lot about who's using bitcoin and for what.

This is not great from a privacy perspective. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors, to name some examples.

Additionally, bitcoins being traceable, possibly “tainted,” and potentially worth less than other bitcoins is at odds with fungibility. This could even challenge bitcoin's value proposition as money.

But there are potential solutions to increase privacy and improve fungibility.

One solution to address this issue – Stealth Transactions – was introduced in 2014; and a new twist on this concept – Reusable Payment Codes – was proposed last year.

The Problem

In part to increase privacy (there are security benefits as well), it is recommended that Bitcoin users generate a brand new address for each transaction they receive. While this is not an airtight solution in itself, this can make it significantly harder to connect addresses to real world identities ‒ both on the sending and the receiving end of the transaction.

However, this also means that the receiver must share a new Bitcoin address with the sender each time a transaction is to be made. This can be a bit of a hassle and in some cases even impossible (think of donation addresses posted on websites). And it’s not ideal from a privacy perspective either: If the new addresses are shared over an insecure channel, privacy is potentially lost entirely.

Stealth Transactions, first proposed in 2014 by Bitcoin Core developer Peter Todd, are designed to solve these problems. They use several cryptographic tricks, mostly based on Diffie-Hellman key exchange, to let users accept payments on addresses they never generated, nor have even seen before.

Under the Hood

This is how Stealth Transactions work “under the hood.”

[Authors note: Since completion of this article, it was brought to my attention that there are actually several slightly different ways to construct Stealth Transactions. The strategy described here is only one particular option.]

Stealth Transactions require the sender and receiver of a transaction to have a (basically non-Bitcoin-related) cryptographic public and private key pair, each. We'll call these the “stealth private keys” and the “stealth public keys.” These “stealth keys” are used in several ways.

The first way is a fairly basic use-case of cryptography, which is, for example, used to encrypt emails. In short (and a bit simplified), the sender can take the receiver's stealth public key and use it to encrypt a message. The receiver – and only the receiver – will be able to decrypt this message with his stealth private key.

(This works the other way around as well, of course: The receiver could encrypt a message for the sender – but that's not really relevant for Stealth Transactions.)

The second trick is slightly more complex. But, again, in simplified form, both stealth private keys can be combined through a mathematical formula, to create a Bitcoin private key. This Bitcoin private key can, in turn, be used to generate a corresponding Bitcoin address.So, using each other’s stealth private key in combination with their own, both sender and receiver can generate this Bitcoin private key and Bitcoin address.

And there is a third trick, in simplified form: This Bitcoin address (but not the corresponding Bitcoin private key) can also be derived from one of the stealth private keys and one of the stealth public keys. As such, either the sender or the receiver can generate the Bitcoin address by combining their own stealth private key with the other's stealth public key.

In Practice

To make a Stealth Transaction, these three tricks are cleverly combined:

Possibly even before any payment was going to be made, the receiver generates a stealth key pair. It's this stealth public key that he,for example, posts on his website as a donation address. (As such, it’s also called the “Stealth Address.”) He doesn't share his stealth private key with anyone at all.

When the sender wants to pay the receiver, he generates a “throwaway” stealth private key for himself; specifically for that one transaction. (It’s actually a “nonce”; just a random string of numbers – but has the same effect.) He then takes the receiver's stealth public key (or Stealth Address) and combines this with his own throwaway stealth private key, to generate a Bitcoin address and sends bitcoins to this Bitcoin address. (Well, almost... but let's assume that for a moment.)

At this point, no onecan spend the bitcoins on this address because no one knows (nor is able to generate) the corresponding Bitcoin private key.

But here's the heart of the trick: the sender can allow the receiver to spend the bitcoins by sharing his throwaway stealth private key with him. With that throwaway stealth private key, the receiver would have both stealth private keys required to generate the Bitcoin private key.

Interestingly, this is accomplished all at once, within the transaction that funds the Bitcoin address. Specifically, the sender includes a so-called OP_RETURN “message” in that transaction. This message consists of his throwaway private key, but encrypted using the receiver's public key, so no one but the receiver can decrypt it.

To receive this transaction, the receiver monitors the blockchain for OP_RETURN transactions and tries to decrypt all of them. Once he finds a decryptable OP-RETURN message, he also finds the throwaway stealth private key to combine with his own stealth private key, with which he can generate the Bitcoin private key to spend the bitcoins in that transaction.

The receiver will have received a secure payment on an address he didn't even own until the actual payment was made. Meanwhile, the outside world might not even know it was a Stealth Transaction; all they see is a normal Bitcoin-transaction with an undecipherable OP_RETURN message attached.

Reusable Payment Codes

While Stealth Transactions offer a novel solution, the requirement to monitor the blockchain for OP_RETURN transactions do limit their potential. Specifically, light wallets typically don't store the entire blockchain and are, therefore, unable to receive Stealth Transactions. (DarkWallet, the only wallet that allows for Stealth Transactions so far, “outsources” this task to a server, which is not ideal for privacy.)

Reusable Payment Codes, introduced by Bitcoin developer Justus Ranvier in late 2015, are designed to solve this problem. They use another Bitcoin innovation designed by Bitcoin Core developer Dr. Pieter Wuille: The Hierarchical Deterministic (HD) key creation and transfer protocol. In short, this protocol allows for the creation of a series of seemingly independent Bitcoin private keys and addresses from a single seed.

With Reusable Payment Codes, the sender sends a so-called “extended public key” to the receiver through an otherwise normal transaction. With this extended public key and the (“stealth”) public key as published by the receiver, the sender is able to generate a series of Bitcoin addresses to send bitcoins to. The receiver, meanwhile, can use this extended public key to combine it with his own (“stealth”) private key to generate the corresponding Bitcoin private keys.

As such, the sender can send an almost unlimited amount of transactions to the receiver, to addresses that can only be “linked together” by the sender and the receiver. Onlookers will see normal Bitcoin transactions ‒ not knowing they all go to the same receiver; all while the receiver hasn’t published any of them anywhere.

However, since light wallets don’t monitor the blockchain, the initial “notification” transaction to serve as a “piggy back” for the seed-data is recognizable, as such, to the outside world. This might reveal who is transacting if the addresses can be linked to real-world identities. Even then, it would reveal only who is transacting; not how much or on which subsequent addresses.

Thanks to Martijn Meijering, Justus Ranvier, and Blockstream president Adam Back for info and feedback.

The post Stealth Transactions and Reusable Payment Codes: How Bitcoin Addresses Can Be Hidden in Plain Sight appeared first on Bitcoin Magazine.

Here’s How Bitcoin's Lightning Network Could Fail

Bitcoin Magazine -

The Lightning Network is viewed by many in the Bitcoin community as the network’s best hope for long-term scalability. The concept uses payment channels to perform bitcoin transactions off-chain, with the blockchain acting as a sort of backup court system for situations where someone decides not to play nice. The creators of this system for instant micropayments estimate that it could eventually be used to process billions of transactions per second.

While a combination of smart contracts and game theory are used to make sure the system works properly for everyone, Bitcoin Core contributor, Peter Todd, explained a possible failure mode of the Lightning Network at the Bitcoin in Use conference late last month.

Editor's note added at 1:11 EST: The failure mode discussed in this article has been known since the early development of the Lightning Network and is discussed in the white paper. This article is not an attempt to give Peter Todd credit for discovery of the failure mode; he simply provided an overview of the issue during a recent talk.

The Lightning Network’s Failure Mode

The Lightning Network failure scenario described by Todd, takes place when a large number of people on the Bitcoin network need to settle their Lightning Network disputes on the blockchain in a relatively short period of time.

“We do have a failure mode which is: Imagine a whole bunch of these [settlements] have to happen at once,” Todd explained. “There’s only so much data that can go through the bitcoin network and if we had a large number of Lightning channels get closed out very rapidly, how are we going to get them all confirmed? At some point, you run out of capacity.”

In a scenario where a large number of people need to settle their Lightning contracts on the blockchain, the price for doing so could increase substantially as the available space in bitcoin blocks becomes sparse. “At some point some people start losing out because the cost is just higher than what they can afford,” Todd said. “If you have a very large percentage of the network using Lightning, potentially this cost is very high. Potentially, we could get this mass outbreak of failure.”

The way the Lightning Network works, a user must be able to issue a breach remedy transaction in order to keep their counterparty honest. If a user is unable to make the proper transaction on the blockchain in a certain amount of time, their counterparty may be able to take control of bitcoins tied up in the smart contract between the two parties.

What Are the Possible Solutions?

Any situation that allows for coins to be stolen obviously needs to be avoided and according to Todd, there are some theoretical solutions available for this problem. For one, an adaptive block size limit could allow miners to increase capacity in these sorts of failure scenarios. Another possible solution would be to allow users of the Lightning Network to reserve space in future blocks to make sure they can broadcast a transaction on the blockchain before the expiration of a timelock.

Having said that, Todd indicated that a real, vetted solution is not available for this issue at this time. “There’s a whole lot of complexity and we’re not really at the point there where I could go and confidentially say, ‘Yes, we’re going to have the whole world buying coffees with these systems,’” he said. “There’s tons more engineering to be done and I think it’s going to be a slow process ‒ figuring out how all this works.”

What Could Cause This Scenario?

One of the main reasons Todd is concerned about this disaster scenario is that users could be lulled into complacency due to their ignorance as to what everyone else on the network is doing. “It’s very hard for me as a Lightning user to know how many other people are potentially vulnerable to the failure of a whole bunch of Lightning channels all at once,” Todd explained. “I don’t know that information; I can’t necessarily react to that.”

One possible catalyst for the Lightning Network’s failure mode, which has also been articulated by BitGo Engineer, Jameson Lopp, could be too much centralization in the network topology. If a number of big players on the network all fail at once, all of the counterparties connected to those nodes will need to settle their smart contracts on-chain in a timely manner.

“In the Lightning world, your Mt. Gox may not be able to steal your money, but it may cause you to have to do a transaction within a few days, and there might be a million other people like that,” Todd explained.

The post Here’s How Bitcoin's Lightning Network Could Fail appeared first on Bitcoin Magazine.


Subscribe to debianHELP aggregator