Bityogi

Coupling Coupons

Feb 172015

This is a guest post from Bityogi

As of this writing version 0.10 of Bitcoin has just been released. The network in Gavin’s words is now ‘over secure’. Over 50 exchanges have propped around the world since the demise of Mt. Gox and there are now over 10,000 projects in Github that reference Bitcoin in their implementation.

However, the primary use case so far has been Bitcoin’s value in relation to FIAT. i.e, Bitcoin is being used as a currency or its replacement.

If you have been following the developments with higher level meta protocols like Mastercoin (now called OMNI), CounterParty and Colored Coins, and as these protocols start to mature, we will start seeing a lot of non-currency uses of the protocol. In fact, when Bitcoin’s chief scientist was asked on his Reddit AMA a few months ago what he was most excited about in Bitcoin development? His answer, “non-currency uses of the blockchain’s ledger-ordering ability.”

So, here is one such non-currency use case:

Coupons

“Do you accept Bitcoin?” This is a standard question that many of us die-hard Bitcoiners tend to ask when shopping.

Even for the merchants that do show an interest in it, explaining what Bitcoin is, is not that easy, especially when there is a line behind you at the cash register.

“Do you accept these coupons?” — that on the other hand is a no-brainer.

Groupon’s success has shown just how viable this market is. Groupon, and other services like it, issue coupons on behalf of small merchants and besides doing the promotion and marketing, such services guarantee that

the purchased coupon won’t get counterfeited, and
the customer won’t spend the same coupon again (double-spending).

In return Groupon get’s to keep up to 50% of the revenues from the sales of such coupons.

In some surveys, up to 40% of Groupon’s customers don’t intend to use that service again. Primarily because they can’t manage the surges such promotions generate and the high costs don’t make it profitable.

These problems can now be tackled by Bitcoin’s blockchain much more efficiently.

Merchants can issue their own coupons on the Block chain and are much more in control of the quantity they issue and therefore how much they are able to redeem back. Since the issuers are directly in control of issuance, they can fine tailor the surges their promotions generate.

And what’s even better, the issuers keep 100% of the proceeds from their coupons. Groupon and services like it are completely dis-intermediated from this. The only cost to issuers would be the issuance of such coupons on the Blockchain and the transaction fees of the network. And in a future article, I hope to elaborate how these costs are negligible.

These factors alone make building coupons on the block chain an excellent value proposition. However, this is just a tip of the iceberg in the benefits realized from such an endeavor. In Part-2 of this series, I’ll introduce the idea of creating contracts between coupons, coupling coupons; that exponentially increase the value proposition of issuing coupons over the Block chain.

Bitcoin’s Proof of Stake

Technical No Responses »

Feb 162015

A lot of attention is given to Bitcoin’s proof-of-work. It is at the center of how the network ensures its security.

A few other alternatives to proof of work, usually called proof-of-stake systems have been implemented by other distributed consensus systems like Peercoin, NXT and Bitshares.

However, I didn’t realize that Bitcoin implements any sort of proof-of stake in its protocol till last week when I heard Bitcoin’s chief scientist, Gavin Andresen give a talk about Bitcoin’s early days and things that Satoshi may have not known.

First, here is a chart of the transaction volume from Bitcoin’s early days.

Bitcoin Transaction Volume (01/2009 – 02/2011) [Source: https://www.quandl.com/BCHAIN/NTRAN-Bitcoin-Number-of-Transactions]

See those spikes around Nov 2010. Gavin described that as ‘penny flooding’ or in other words spamming of the network.

So, how did the Bitcoin developers take care of this issue?

Transaction Priority! Buried in the details of transaction-fees is the logic of how the network prioritizes transactions.

Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

This was a suggestion made by Gavin. And a problem that had been apparently nagging Satoshi for a while. Satoshi wrote a personal email to Gavin describing how this may actually solve the spamming problem. And if you’ve been paying attention to the network ever since, it looks like it has.

But it’s not like the people who have looked under the hood of how Bitcoin works don’t know about transaction priority and what it’s purpose is. It’s that many of us have never thought of it as a proof of stake in the network. At least, I did not till Gavin put it that way in his talk at Bitcore Dev in Boston.