A Case for Replace by Fee : How Bitcoin Businesses can Benefit from RBF

"Replace by Fee" or RBF has recently received a lot of talk with the merge of “Opt in RBF” by the Bitcoin Core devs. Although there has been a lot of FUD and drama being spread on social media channels regarding the change, several noted figures in the Bitcoin community , such as Erik Voorhees from Shapeshift, and Chris Pacia from OpenBazaaar, have made valid and well written statements against RBF . Their main argument is that RBF makes it easier to double spend and will reduce the capabilities of Bitcoin businesses to compete since they can no longer rely on zero confirm transactions. I think this is a valid and pragmatic point, but here I would like to make the counter argument that Bitcoin businesses stand to gain a lot from the adoption of RBF, and give coherent examples of how Bitcoin businesses can utilize RBF to provide a better customer experience, and be more cost efficient.


Point 1: Bitcoin businesses will save money on transaction fees:


The businesses that stand to gain a lot from RBF are operations that must handle large volumes of outbound Bitcoin transactions, and must pay a large amount of aggregate transaction fees. This means exchanges, brokers (like Shapeshift), and payment processors stand to gain a lot from RBF. Operations like these want to pay the lowest transaction fee possible, but at the same time it must meet customer expectation of timeliness. They don't want to underpay the transaction fee because the transaction will take a long time to confirm, and they don't want to overpay the transaction fee because it impacts their bottom line negatively. This is a difficult problem to solve, due to the fact that transaction fees are not static, and will be increasingly more volatile as the Bitcoin mining subsidy is decreased and miners must rely more on transaction fees for revenue. We have already seen instances of high transaction fee volatility, due to the spam attacks on the network. According to BlockCypher, during the spam attack on 2015, July 8^th , the average transaction fee went up 3 times, while the minimum transaction fee went up 25 times.

Transaction fees are dependent on many factors such as available network bandwidth, available size of the mempool, the miners that are active at that particular moment, and the cost of operation for those miners. So spam attacks are not the only source of volatility for transaction fees. You could see unpredictable transaction fee increases when there is a large network outage that knocks out a bunch of full nodes, or when there is an increase in the spot price of coal in China that affects operation costs for Chinese Bitcoin miners. It is important to note that the volatility of transaction fee can not solved by increasing the block size. It may have an impact of lowering the transaction fee, but it will not make transaction fees static, due to the large number of variables that affects transaction fees as mentioned above.


With RBF, Bitcoin businesses now have the capability to adjust their transaction fee on their outbound transactions in real time. This makes it far less likely for a business to overpay or underpay the transaction fee. This is easy to see if you look at RBF as a bartering process between the transaction creator and the miner. The transaction creator can start with a low offer, and progressively increase his offer until the miner accepts. This is much better alternative to the current “First Seen Safe” process where the transaction creator is stuck with the first offer he makes with no ability to make a better offer. The first offer could be flat out wrong due to the transaction creator's inability to estimate the required transaction fee, or some unpredictable event could occur immediately after the time that the transaction was created that impacts the required transaction fee.


Point 2: Double spends are not necessarily malicious

When we think of double spends, we think of people defrauding other users, but this does not always have to be the case. For example, people mistakenly send Bitcoins to the wrong address all the time with fortunes being lost in this way. I'm sure that many Bitcoin businesses past and present have also mistakenly created transactions that they'd like to take back. RBF gives you a time window where you can reverse this mistake (with some probability of success).


Many honest mistakes are made all the time in mainstream financial markets, such as the six billion dollar “fat finger” screw up at Deutsche Bank, so institutions have rules in place to deal with the fact that human beings are prone to type in an extra zero or two. Bitcoin having a feature where transactions are reversible up to a certain time period is not necessarily a bad thing. It can protect Bitcoin businesses and their customers from their own mistakes.


Additional Readings on RBF:

Opt in RBF is misunderstood , Ask questions here, Reddit thread

Mike Hearn on RBF

Atomic Cross Chain Transfer, an Overview

Atomic cross chain transfers (or atomic cross chain trading, from here on referred to as ACCT for short) , makes it possible to trustlessly trade between two cryptocurrencies existing on different blockchains. This means that neither of the two parties involved in the trade is at risk of their funds being stolen. The trade either completes with both parties getting the coins that they agreed upon, or the trade fails and both parties get their coins back. The trustless nature of ACCT will eventually have a huge impact on the way cryptocurrencies are traded, as it allows complete strangers with no prior reputation to trade with each other without a third party intermediary.

The first working theoretical implementation of ACCT was first described by Noel Tiernan in this bitcointalk.org thread, and the basic details of the algorithm is described here. In this document, we are specifically interested in discussing ACCT for Bitcoin and Bitcoin derived cryptocurrencies. Bitcoin derived cryptocurrencies are forked off of the Bitcoin Core source code, and examples include Dogecoin, DASH, and Litecoin. Below are the covered topics in this document:

1. ACCT using refund transactions

2. Alternative implementation of ACCT using refund transactions

3. Vulnerabilities of ACCT using refund transactions

4. ACCT using Check Lock Time Verify

1. ACCT using refund transactions

ACCT can be currently implemented by constructing refund transactions. We discuss in detail here one implementation of this method. This implementation is based on Ross Nicoll’s CATE project.

Variables and Terms

AlphaCoin - a bitcoin derived cryptocurrency

BetaCoin - another bitcoin derived cryptocurrency

Initiator – one party of the trade, looking to sell Alpha Coin for Beta Coin.

Responder – the second party involved in the trade, looking to sell Beta Coin for Alpha Coin

X – secret number created by initiator

H(X) – hash of secret X

Privkey i / Pubkey i - private public key pairs belonging to initiator

Privkey r / Pubkey r - private public key pairs belonging to responder

TxAb - initiator's bail in transaction, for the Alpha Coin network

TxAr - initiator's refund transaction, for the Alpha Coin network

TxAp – responder's pay out transaction, for the Alpha Coin network

TxBb - responder's bail in transaction, for the Beta Coin network

TxBr – responder's refund transaction, for the Beta Coin network

TxBp – initiators pay out transaction, for the Beta Coin network

T2 - time till initiator can obtain refund

T1 - time till responder can obtain refund , where T1 < T2

Steps

Step 1.

Initiator creates secret X, and hashes it to create H(X). Initiator also creates two public private key pairs (pubkey i1,i2 / privkey i1,i2). Responder creates two public private key pairs (pubkey r1,r2 / privkey r1,r2).

Step 2.

Initiator shares H(X) and pubkey i’s with responder. Responder shares pubkey r’s with initiator.

Step 3

Initiator creates and keeps secret TxAb, the bail in transaction. The bail in transaction moves initiator's funds into an unspent that can be redeemed with knowledge of secret X and a signature from privkey r1, or it can be redeemed with signature from both privkey i1 and privkey r1.

Step 4.

Responder creates and keeps secret TxBb, his bail in transaction. The bail in transaction moves responder's funds into an unspent that can be redeemed with knowledge of secret X and a signature from privkey i2 or it can be redeemed with signature from privkey i2 and privkey r2.

Step 5.

Initiator creates TxAr, his refund transaction that spends TxAb with signature from privkey i1 and privkey r1 to an address controlled by initiator. TxAr has nLocktime set to some time in the future T2 so is not valid until that time passes. TxAr is sent to responder and the responder sends back TxAr signed with privkey r1. Initiator signs the transaction with privkey i1.

Step 6.

Responder creates refund TxBr, his refund transaction that spends TxBb with signature from privkey i2 and privkey r2. The refund TxBr has nlocktime set to some time in the future T1 (where T2 > T1 ) so is not valid until that time passes. TxBr is sent to initiator and the initiator sends back TxBr signed with privkey i2. Responder signs the transaction with privkey r2.

Step 7.

TxAb is broadcast by initiator.

Step 8.

After confirming TxAb, responder broadcasts TxBb.

Step 9.

Initiator creates payout transaction TxBp that spends TxBb by revealing secret and using privkey i2. Since the secret is now revealed to the responder, the responder creates payout transaciton TxAp that spends TxAb by using the revealed secret X and privkey r1.

Notes

If initiator fails to broadcast TxAb in step 7, the exchange has failed and no further steps need to be taken by the responder.

If responder fails to broadcast TxBb in step 8, initiator can redeem TxAb in time T2 using refund transaction TxAr.

At step 9, if initiator fails to get pay out from TxBb before time T1, responder can get refund with TxBr. If responder fails to get pay out from TxAb after time T2 has passed. Initiator can get refund with TxAr

Scripts

TxAb’s output should be a p2sh transaction to the hash of the serialized script outlined below. The reason we use a p2sh transaction is that since Bitcoin Core 10.0, any p2sh transactions are considered standard and will be relayed by 10.0 nodes.

OP_DUP OP_HASH160 [Hash160(pubkey r1)] OP_EQUALVERIFY

OP_CHECKSIGVERIFY

OP_IF

OP_DUP OP_HASH160 [Hash160(pubkey i1)] OP_EQUALVERIFY

OP_CHECKSIG

OP_ELSE

OP_HASH256 [H(x)] OP_EQUAL

OP_ENDIF

Refund transaction TxAr’s script sig will look like below:

[signature from privkey i1] [pubkey i1] 1 [signature from privkey r1] [pubkey r1]

{serialized script}

Pay out transaction TxAp’s script sig will look like below:

[X] 0 [signature from privkey r1] [pubkey r1] {serialized script}

TxBb, TxBr, and TxBp is symmetrical and replaces key pair r1 with i2 and key pair i1 with r2.

2. Alternative Implementation of ACCT using refund transactions

Noel Tiernan describes an alternative implementation, which is also implemented by Matthew Bell in project Mercury. The main advantage of this implementation was that before Bitcoin Core release 10.0.0, not all p2sh scripts were considered standard and were not relayed by nodes. This implementation required the use of only one non standard transaction in the entire ACCT protocol, as opposed to two. Thus this implementation was more likely to be propagated across the entire network.

However with the introduction of Bitcoin Core 10.0.0 on February 2015, rules for standard transactions were relaxed so that all P2SH redemption scripts are considered “standard” and are relayed by the nodes. Thus this alternative implementation no longer has this advantage. Litecoin Core has adapted the 10.0.0 changes since June 2015 with version 10.2.2, and Dogecoin Core as of September 2015 is in the process of adapting the 10.0.0 changes with its beta release of 1.10.

3. Vulnerabilities of ACCT using refund transactions

Extortion using Transaction Malleability

TxAb and TxBb could be mutated , thus making their respectable refund transactions TxAr and TxBr invalid. If refund transaction is invalid, the funds could be forever locked unless you obtain cooperation from your counterparty to resign the refund transaction. A possible attack that can be performed either by the initiator or the responder is to mutate the counterparty's funding transaction, making their refund transaction invalid. Now the attacker is in position to extort money from the counterparty.

There has been progress on several fronts to alleviate the transaction malleability problem in Bitcoin such as strict DER encoding, lowS signature enforcement, and stricter definitions for standard transactions limits mutated transaction from being relayed. However, relay rules do not prevent miners from mining mutated transactions, and do not change the behavior of old clients or clients that do not adhere to the same relay rules as the core protocol.

It is unlikely that the malleability problem will be solved in the near future. BIP 62 outlines all known malleability sources, but it is by no means an exhaustive list, since it is based on heuristics. New malleability sources could be discovered, and could also be created by changes in the protocol. Normalized Transaction ID's have been proposed as a solution, but this proposal is far from obtaining consensus from Core devs and being implemented into Bitcoin. This vulnerability makes it dangerous for ACCT using refund transactions to be deployed in production systems.

Fund Lock Attack

A trivial attack to perform is for the responder to never follow through the bail in transaction broadcast on step 8. This will lock up the initiator’s fund for time T2 without any losses by the responder. The initiator can perform a similar attack although not without locking up his own funds. He can refuse to perform his pay out transaction in step 9, but in this case it will keep responder’s fund locked up for time T1 and keep his own funds locked up for time T2.

Payout Failure

Responder could fail to obtain payout from TxAb before time T2 as in step 8. This could happen for many reasons such as the responder losing private key r, the responder losing access to the internet (DDOS, network failure), or his transaction does not make it into the blockchain (blacklisted by miner, congestion in the blockchain, failure to pay sufficient tx fee). In this case, the initiator would be able to have access to both his own fund and the responder's fund, effectively allowing him to steal responder's funds.

Note that initiator does not face the same risk if he fails to redeem TxBb before time T1, as long as he does not reveal secret X. If initiator fails to redeem TxBb before time T1. Responder can use refund transaction TxBr to redeem TxBb , but responder has no access to TxAb. However, if initiator reveals secret X (for example, TxBp is broadcast onto the network but does not make it into any blocks before time T1), the responder would be able to have access to both his own fund and the initiator's fund.

Double Spend Attack

As with any cryptocurrency transactions involving two parties, there is an opportunity for a double spend attack. This can happen if the victim does not wait for sufficient confirmations , or an attacker has access to sufficient mining power.

If the initiator can convince the responder that TxAb occurred when in didn’t, and the responder publishes TxBb, the imitator can steal from the responder by spending TxBb using TxBp and than double spending the inputs of TxAb. Likewise, if the responder can convince the initiator that TxBb occurred when it didn’t, and the responder publishes TxBp, the responder can steal from the initiator by spending TxAb using TxAp and than double spending the inputs of TxBb.

4. ACCT using Check Lock Time Verify (CLTV)

OP_CHECKLOCKTIMEVERIFY is a new op code in the works that Bitcoin Core devs will be looking to deploy with a soft fork in the near future. It is described here in BIP 65. The op code allows us to create transactions that can be spent in different ways depending on the nLockTime of the spending transaction.

ACCT using CLTV is superior in that it does not have the transaction malleability issues of ACCT using refund transactions (it does however have the same other vulnerabilities discussed in the previous section). Additionally, all transaction signing occurs on the blockchain, and the trading parties only need to exchange the hashed secret and their public keys in order for the trade to take place.

Steps

Step1.

Initiator creates secret X, and hashes it to create H(X). Initiator also creates public private key pair (pubkey i1,i2 / privkey i2,i2). Responder creates public private key pair (pubkey r1,r2 / privkey r1,r2).

Step 2.

Initiator shares H(X) and pubkey i2 with responder. Responder shares pubkey r1 with intiator.

Step 3.

Initiator creates TxAb. TxAb can be redeemed after time T2 with privkey i1. At any time TxAb can redeemed with signature from privkey r1 and reveal of secret X. Initiator broadcasts TxAb onto the network.

Step 4.

Responder confirms TxAb. Responder creates TxBb. TxBb can be redeemed after T1 time with privkey r2. At any time TxBb can be redeemed with signature fom privkey i2 and reveal of secret X. Responder broadcasts TxBb onto the network.

Step 5.

Initiator creates TxBp which spends TxBb using privkey i2 and secret X. With the revealed secret, responder can create TxAp which spends TxAb with privkey r1 and secret X.

Notes

If initiator fails to broadcast TxAb in step 3, the exchange has failed and no steps need to be taken by the responder.

If responder fails to broadcast TxBb in step 4, initiator can create refund transaction TxAr which redeems TxAb after time T2 using privkey i1.

If initiator fails to spend TxBb on step 5 before time T1, responder can create refund transaction TxBr after time T1 using privkey r2. If responder fails to spend TxAb before time T2, initiator can use TxAr to get refund from TxAb.

Script

TxAb’s output should be a pay to script hash transaction to the hash of the serialized script outlined below.

OP_IF

[T2] CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 [Hash160(pubkey i1)]

OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE

OP_DUP OP_HASH160 [Hash160(pubkey r1)] OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_DUP

OP_HASH160 H(X) OP_EQUAL

OP_ENDIF

The refund transaction TxAr has nLockTime > T2 and the input script is

[signature from privkey i1] [pubkey i1] 1 {serialized script}

The payout transaction TxAp has nLockTime < T2 and the input script is

[x] [signature from privkey r1] [pubkey r1] 0 {serialized script}

TxBb, TxBr, and TxBp is symmetrical and replaces key pairs i1 with r2 and key pairs r1 with i2

Noffee Coin : A coin that can't be used to buy your coffee in the morning.

This is a proposal to create Noffee coin. The world's first cryptocurrency created specifically so that you won't be able to buy your coffee with it in the morning (portmanteau of No Coffee). It is also ironically called Noffee because it is predicted that the transaction fee will be very large due to the restrictive amount of space available on each block. 

The goal of this cryptocurrency is to create a blockchain that is small enough that you could easily run a full node on your smart phone even with 10 years of past blockchain data. Now you could be asking, "why would I want to run this on my mobile phone if I can't buy my coffee with it?" Well there are many transactions in the real world that are done with very large briefcases full of US dollars. Noffee coin would be a perfect replacement for such situations. Since the exchanged amount is so huge and the stakes are large, it is imperative that you run a full node and it is no problem waiting three hours to get your six confirms. I have no idea what kind of transactions they could be, but a more imaginative person could figure that out.

The current proposals are:

- 30 minute block time
- 1 kilobyte block size limit 
- Equivalent block reward and halving schedule as Bitcoin. We will halve the block reward every 70000 blocks, which will be about 4 years (same time duration as Bitcoin)

There will be roughly a max of 8 transactions per hour. This means that even with completely full blocks for 10 years, the total blockchain size will be about 170 megabytes. I think a lot of cool stuff can be done with this project, but you definitely will not be able to buy your coffee with it. I am now looking for initial comments and questions regarding the project.

Further things to consider are whether we should further reduce Noffee coin's hardware requirements by putting in things to restrict bandwidth usage in the p2p communication protocol, limit the growth of UTXO's (high dust and minimum tx fee), and reduce computing requirements in the script processing (or remove the entire thing altogether). I like the idea of a "Minimum Viable Block Chain" that would scrap the entire scripting language of Bitcoin as it introduces a significant amount of complexity into the consensus protocol.

 If there is enough interest, especially from other developers that can help out, I will proceed in refining the proposal further and will create the cryptocurrency that everyone deserves. If there is no interest, well maybe this is at least a funny way to think about the block size debate.

Coffee icon made by Freepik from www.flaticon.com is licensed under CC BY 3.0

Front running Decentralized Exchanges: The problem with Augur, Bitshares, Nxt, and Counterparty

Decentralized exchanges have been raved about for a while now in the Bitcoin space and has been crowned as the future saviour of our financial exchange infrastructure (even Mark Karpeles of Mt. Gox fame is talking about it ) . But unfortunately, this is a very hard problem and the current batch of decentralized exchanges have one system breaking issue that makes them entirely unusable. I’m specifically talking about decentralized exchanges where the actual process of matching orders happens on the blockchain. This includes the likes of Nxt, BitShares, Counterparty, and Augur which has a built in limit order book, or some approximation of the limit order book, on the protocol consensus level (Augur is not branded as a decentralized exchange, but you can think of them as an exchange for a specific asset class which is prediction of future events).  All of these platforms allow you to issue assets and trade them on the blockchain. The basic premise  is that you can submit an order to trade like you would submit a transaction to the blockchain, and then the underlying protocol would act as an order book and match up the orders automatically and execute them for you.

This sounds awesome, and if it works it would be a cure for the cancer of incompetent centralized exchanges in the cryptocurrency ecosystem. Unfortunately, the currently available solutions cures the cancer, but also kills the patient.  The basic problem is that the miners can ruthlessly front run you without any repercussion. This is made possible simply by the fact that in a bitcoin derived distributed system, a miner can see all the transaction before they are put into a block, and they are free to put in their own transaction into the block before your transaction happens. For example, let’s say I submit a large order to buy some asset on the Counterparty exchange. This order finds its way to a Bitcoin miner (Counterparty is built on top of the Bitcoin blockchain) who says, “hey, that’s a fat and juicy order that will drive up the price, let’s create our own order to buy the asset and put it in the blockchain before he does”. Then, if the miner is able to mine this particular block, he would have gained an easy risk free profit by utilizing the information in my order.

Bitshare’s Daniel Larimer has a very informative article called “How Bitshares prevents frontrunning ” , which describes the problem better than I can, but unfortunately makes a terrible conclusion. The conclusion of the article is that they can’t prevent frontrunning, so you should just assume that you are being front run. This conclusions seems to be missing the whole entire point of having a limit order book. If you cannot provide a fair and orderly execution, you should just provide an auction system where orders are not automatically executed and users can choose the orders they execute against. Using a limit order book gives a dangerous illusion that the system is fair, when it is inherently rigged in favor of the miners.

Another great feature of the limit order book that is lost upon these decentralized exchanges is that it rewards traders that reveal price information by giving them priority of trade execution. This feature has a lot of social benefits because it encourages people with new price information to disclose it to the rest of the world and improve the price accuracy of the underlying asset. However,  in these decentralized exchanges, the miners are always favoured to have the priority of execution, thus traders have no incentive to reveal price information. This is going to be particularly system breaking for Augur whose main premise is to provide a decentralized prediction system. If traders with information are not given priority of execution, they cannot extract value out of their information because the miners will take all or most of the value by front running them. If traders cannot extract value out of their information, they will simply not use Augur.  Unless they can provide some solution for this problem, my opinion is that this project will be a complete failure.

One argument I’ve heard against this problem is that the situation is not any worse than a centralized exchange. They are kind of right because a centralized exchange can also front run you. But they are wrong because a centralized exchange faces serious damage in its reputation and business if it is revealed that they are front running. Bitcoin hard liners will scoff at this idea but believe it or not, some systems work fine based on reputation and trust. Miners face no such disincentives for front running. These decentralized exchanges have basically anointed the miners to collectively act as a fair exchange, but the miners never agreed to it. The miners are in the business of following consensus rules and getting block rewards, not running an exchange. If they can skim some tasty frontrunning profits on the side in addition to collecting their block rewards, why not?

No practical technical solutions exists to solve this problem currently. The only thing that mitigates front running is enforcing random ordering of transactions within a block, cutting down the possibility of front running to 50% within the same block. But this only mitigates, and does not remove it entirely. A two phase commit and reveal system is another potential solution. This is when orders enter the block encrypted so that the miner cannot see your orders, and then once they are confirmed in the block, the order is decrypted so everyone can resolve the state of the order book. Unfortunately, this suffers from the problem that people can selectively choose not to decrypt their order, thus destroying the integrity of the order book. You could use a trusted arbiter whose job is to encrypt and decrypt orders, instead of having each participant encrypt their own orders. The problem of course is that the arbiter now has the ability to front run instead of the miner, but this is a better proposition because the arbiter’s sole job depends on him being trustworthy.

It may also be possible to use time locked encryption , to turn the two phase commit and reveal system into a one phase commit and reveal system. This would prevent people from selectively decrypting their order, since decryption does not rely on revealing a secret and relies on computation time. But in practice, time locked encryption is very hard to implement since you need access to large computational power, and have to estimate accurately the computational power of your adversaries.

There may be a simple solution, which is economic in nature as opposed to technical. The solution is to pay miners to be fair. If miners are getting a large share of profit from validating exchange related activities, they may be incentivized to play fair and encourage trading to continue at a healthy volume. This can be done by attaching high transaction fees on exchange related transactions or paying miners out of band. Some miners could also choose to establish themselves as a trustworthy entity that specializes in processing exchange related orders (and charge people for it). Now this solution raises many important and difficult questions. How much should the miners be paid for this service? If miners are essentially acting as an exchange, does it subject them to securities and exchange regulations? Should they be subject to third party audits to make sure their system is fair? Is there really any benefit to a decentralized exchange if the system is ultimately reliant on trust? Developers on Augur, Bitshares, Counterparty, and Nxt needs to seriously consider these questions if they want their exchanges to be taken seriously.  

In summary, the current batch of decentralized exchanges have serious problems with no good solutions in sight. The inherent architecture of the blockchain makes the task of frontrunning a decentralized order book trivial as a miner. Anyone using these exchanges for trading purposes should consider the consequences of miners having perfect information against you.

Bitcoin devs do not have consensus on blocksize

This is a repost from reddit that I made in 5/6/2015 regarding the block size argument. You can see the full thread here: http://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/

I am making this post to show to the public what the most active developers in Bitcoin, more specifically Bitcoin Core, think about block size increases. Contrary to what the public may think, there is no consensus amongst the developers regarding Gavin Andresen’s proposal to increase the block size to 20mb (Thanks to Peter Todd who brought this up during his Bitdevs NYC talk which I attended). The only devs that have come out in strong favor of this proposal is Gavin and Mike Hearn.

The rest are against any increase, prefer a smaller increase, or have not expressed an opinion either way but is asking for further research, development, and answers before we proceed. I believe that the public opinion has been highly swayed by Gavin, and we should strongly consider what others who have spent numerous hours on the protocol have to say on the topic. If any information here is inaccurate , or if there are others who I’ve missed , please let me know and I will edit them in. I’ve probably missed a lot of good comments from other developers because it is scattered all over the internet and my google-fu is not good (And please excuse my ham fisted way of labeling developer contribution by the # of commits on github. ).

I also apologize in advance if any developers feel like they are being called out. But I believe strongly that it's important to have public statements that have been made on the internet to be consolidated in one place for such an important topic. Especially when we have dangerous misconceptions where users think that increasing blocksize is a single parameter optimization with no costs like increasing the size of your race car engine. The topic of block size is not a technical issue, it is a political issue at heart. There are real trade offs involved, with people and entities who stands to gain on both sides of the debate.

For 20mb increase
Gavin Andresen
Current Affiliations: MIT Digital Currency Initiative, Coinbase
Bitcoin core: top 5 core developer by # of commits. Has commit access.
Comments: http://gavinandresen.ninja/

Mike Hearn
Current Affiliations: Lighthouse
Bitcoin core: top 100 core developer by # of commits. Creator of Bitcoinj .
Comments: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Skeptics of 20mb increase (Note that some people here do favor a block size increase, but none has strongly committed to 20 megabytes as the exact size.)

Pieter Wuille
Current Affiliations: Blockstream
Bitcoin core: top 5 core developer by # of commits. Has commit access.
Comments: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07466.html

Wladaimir J. Van der Laan
Current Affiliations: MIT Digital Currency Initiative
Bitcoin core: top 5 developer by # of commits. Has commit access.
Comments: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07472.html

Gregory Maxwell
Current Affiliations: Blockstream
Bitcoin core: top 20 core developer by # of commits. Has commit access.
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090559/
https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqycy4h

Jeff Garzik
Current Affiliations: BitPay
Commit access: top 20 core developer by # of commits. Has commit access.
Comments: https://twitter.com/anjiecast/status/595610865979629568
http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html

Matt Corallo
Current Affiliations: Blockstream
Bitcoin Core : top 10 core developer by # of commits
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090292/

Peter Todd
Current Affiliations: Viacoin,Dark Wallet, Coinkite, Smartwallet, Bitt
Bitcoin Core: top 20 core developer by # of commits
Comments: https://www.reddit.com/r/Bitcoin/comments/34y9ws/it_must_be_done_but_is_not_a_panacea/cqza6rq?context=3
https://www.youtube.com/watch?v=lNL1a7aKThs

Luke Dashjr
Current Affiliations: Eligius Mining Pool
Bitcoin Core: top 10 core developer by # of commits
Comments: http://www.reddit.com/r/Bitcoin/comments/34y48z/mike_hearn_the_capacity_cliff_and_why_we_cant_use/cqzadpn

Bryan Bishop
Current Affiliations: LedgerX
Bitcoin Core: various @ https://github.com/kanzure
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090516/

Multisig Cryptocurrency to Cryptocurrency Exchange

Below is a draft of a paper that I have been working on that explains how a multisignature cryptocurrency to cryptocurrency exchange should be designed. Multisignature has been around for a while but has yet to be used in an exchange. I believe it is an idea worth exploring in light of the near constant bad news we hear from various exchanges that gets broken into by attackers. The paper covers how such a exchange should be designed, and goes over some of the advantages and disadvantages of the design over a traditional exchange that uses a single exchange controlled private key to handle cryptocurrencies.

Multisig CryptoCurrency to CryptoCurrency Exchange , Draft 2/24/2015