bitcoin
Image by stevegarfield
via www.casascius.com/photos.aspx
These images may be freely downloaded and used without royalty or compensation, both for commercial and non-commercial purposes. You may feel free to crop the images and/or hide the name Casascius if your purposes so require.
As of this weekend, GreenAddress is the first Bitcoin wallet to include a replace-by-fee option. With it, users can increase fees on their transactions with the click of a button–a feature welcomed by some, as it increases the likelihood a miner will include a transaction in a block. This can help transactions get “unstuck” in case of heavy transaction load, and benefits fee market dynamics. Others dispute the feature; critics fear that replace-by-fee could harm reliability of unconfirmed transactions, as payments can in some cases be reverted.
To test the feature, GreenAddress enabled a preview of the option on my own GreenAddress wallet several weeks ago. This, in turn, allowed me to test which parts of the broader Bitcoin ecosystem are ready for replace-by-fee – and which parts are not.
The results below are based on ad hoc experimentation from my own perspective as a user – not an official analysis conducted with scientific precision.
GreenAddress from the Sender’s Perspective
The first test, of course, was GreenAddress itself, from the sender’s perspective. (Tested on the Chrome extension version of the wallet.)
Since this weekend, the GreenAddress replace-by-fee option is switched on by default. (Users that don’t want to utilize the feature need to disable it in the “Settings” panel.) When switched on, each transaction sent from the wallet includes a replace-by-fee flag. This way, network nodes and miners know it’s eligible to be replaced by a conflicting transaction that includes a higher fee.
After sending my first replace-by-fee transaction, I was automatically redirected to the “Transactions” screen, where all past wallet-transactions are displayed. And, underneath the (still unconfirmed) replace-by-fee transaction, a new tab had appeared: “bump fee.”
While opt-in replace-by-fee as included in Bitcoin Core allows replacing any unconfirmed transaction (even if this means unconfirmed transactions are “canceled”), GreenAddress users can only resend bitcoins from the same inputs to the same outputs, but with a higher fee. It only allows users to “boost” a transaction to increase the likelihood a miner will include it in a block.
Clicking on the “bump fee” tab opens a mini-menu. On top of the menu, text displays how fast the transaction is expected to confirm. In my case, it was expected to be included in the next block. Nevertheless, the menu allowed me to bump the fee: times 1.5, times 2 or times 3.
However, and more important, if a transaction is notexpected to be mined in the first available block because the fee is too low, GreenAddress offers a different option. In that case, the mini-menu offers users the option to include a fee big enough to have the transaction included in the next two, three or six blocks.
Having bumped the fee, a new icon appears underneath the transaction, which reads “updated,” accompanied by a button to display the old transaction ID. Meanwhile, the “bump fee” button is still there, too, meaning I could bump the fee once again.
All in all a very straightforward and easy-to-use process.
What the Pools Are Doing
Wallet software in itself is not sufficient to replace transactions. (Or: bump fees.) Whether replace-by-fee is active on the Bitcoin network really depends on miners.
A series of test transactions revealed that a majority of miners currently does not apply any replace-by-fee policy. All of the big Chinese pools – AntPool, F2Pool, BTCC and BW.com – ignored the fee boosted transactions completely, as did KnCMiner. This currently adds up to more than75 percent of hash power on the network.
Other pools did apply a replace-by-fee policy, presumably the opt-in version. These include BitFury, Slush Pool, BitClub and CKPool, which adds up to nearly20 percent of all hash power. (The other 5 percent of hash power on the network is controlled by pools or miners representing less than 1 percent of hash power, which didn’t happen to mine any blocks during my tests..)
So what does this mean?
While 20 percent may seem low, it’s actually not so bad when keeping in mind the main purpose of replace-by-fee: “boosting” a fee to ensure a transaction is mined.
Of course, with only 20 percent of hash power applying a replace-by-fee policy, there’s only a 20 percent chance the very next miner will pick up the boosted transaction. But there is also about a 3-out-of-4 chance that the boosted transaction will be included in a block within one hour. And it will almost certainly be included in a block within several hours.
Needless to say, that is a significant improvement compared to transactions that won’t confirm for days, as has been the case during some “stress tests” on the network.
Users who want to (ab)use replace-by-fee to revert an unconfirmed transaction, meanwhile, only have about a 20 percent chance this will succeed. At least 75 percent of the time they’ll pay their “victim” even though they didn’t want to. (Reverting a transaction isn’t possible with GreenAddress in the first place, of course.)
Wallet Security
Users maliciously reverting unconfirmed transactions bring us to the next point.
To counter these risks, wallet software can warn users on the receiving end of a transaction if a transaction is flagged to potentially be replaced.
Of all tested wallets, however, only Mycelium (on Android) and – indeed – GreenAddress (Chrome app) show such a flag. Both wallets clearly visualize a replace-by-fee enabled transaction as such, giving users the option not to accept such a transaction until confirmed if they wish. (AirBitz apparently does it too, but I don’t have the right operating system to test this myself.)
Interestingly, Bitcoin Core doesn’t flag for incoming opt-in replace-by-fee transactions, and as such Bitcoin Core forks Bitcoin Classic, Bitcoin XT and Bitcoin Unlimited don’t either. Rather, these wallets simply show both the original and the replacement transaction as unconfirmed. Until one of these transactions makes it into a block, of course, at which point the confirmed transaction is shown as confirmed – and the conflicting transaction as rejected.
Blockchain (web), Bither (iOS 7), Blocktrail (iOS 7 and web), Breadwallet (iOS 7), Coinbase (web), Copay (iOS 7) and Electrum (desktop) don’t flag for replace-by-fee transactions either. Blocktrail, Bither and Breadwallet simply show both the original and the boosted transactions as two different incoming transactions, while Copay and Coinbase ignore the latter. For Electrum, it depends on which Electrum server the wallet software connects to, but in most cases it shows only the newest transaction.
(When asked why their software doesn’t flag for replace-by-fee transactions, both Bitcoin Core and Electrum developers explained that unconfirmed transactions shouldn’t be trusted either way, and a flagging system could give users a false sense of security.)
Editors note: Shortly before publication, Bitcoin Core developers pointed out that an RBF-notification might be added soon, after all.
While unable to test it myself, Bitcoin Wallet (Android) applies yet another strategy: it doesn’t show replace-by-fee flagged transactions at all, unless and until it has at least one confirmation.
(Bitcoin Wallet developer Andreas Schildbach told me adding a flagging system in the software would be tricky, and he believes this is the most responsible solution for now.)
Payment Processors
I tested the big two payment processors: BitPay and Coinbase. This time around, I didn’t actually try to replace (“boost”) my transaction. I just wanted to see how they’d handle the flag.
Perhaps unsurprisingly – CEO Stephen Pair supports opt-in replace-by-fee – BitPay seemed to handle replace-by-fee payments without any problems. Having paid for a pizza delivery through Bitcoin’s biggest payment processor, the order was immediately confirmed on-screen. As such, it didn’t feel like I was waiting too long for my transaction to come through.
It did, however, take several minutes – seemingly until a block was found – until I also received a confirmation email. Presumably this is because BitPay does wait “behind the screens” until a transaction is included in a block, to make sure they can’t be defrauded.
While it worked well for me, it did leave me wondering what would happen if the transaction had taken significantly longer to confirm. If that would have meant I had to wait longer for my pizza to arrive, a warning might have been in place…
Coinbase did not handle my first replace-by-fee transaction well: my payment for Reddit Gold, made several weeks ago, was not acknowledged at all. Not before it was included in a block, and not after it was included in a block. After seeing the payment request page time out twice, the order was eventually canceled. (I had to email Reddit to get my gold.)
However, a second, more recent try suggests Coinbase has improved its service since: my Wikimedia donation was confirmed instantly. Moreover, a message popped up telling me they’d wait for a confirmation due to a low fee. Wrong reason, but right service.
Block Explorers
Finally, I did a quick round to see how different block explorers handle opt-in replace-by-fee transactions.
The first block explorer I tested, Blocktrail, clearly visualizes replace-by-fee transactions. It was the only block explorer that not only flags a transaction when eligible for double-spends, it also warns users if a conflicting transaction is detected. And, once that conflicting transaction is included in a block, it’s made clear that the replaced transaction was double-spent, and won’t confirm.
Blockchain.info does not flag replaceable transactions, and instead just shows a transaction as unconfirmed. It’s only after a conflicting transaction is sent that Blockchain.info visualizes a note warning users of a potential double-spend, though still no mention of replace-by-fee. And, after a conflicting transaction is included in a block, Blockchain.info issues no additional warning; it seems as if there is still a small chance the original transaction might confirm.
As for other block explorers …
Much like Blockchain.info, Blockcypher does not visualize a replace-by-fee flag, but it does show a double-spend warning after a second transaction is sent. BitPay’s open source block explorer insight.bitpay.com, bitcoinchain.com and chain.so show only the first initial transaction, with no replace-by-fee flag.
The post GreenAddress Is First Bitcoin Wallet to Launch Replace-By-Fee Bitcoin Transactions; Miner Adoption Slow appeared first on Bitcoin Magazine.
GreenAddress Is First Bitcoin Wallet to Launch Replace-By-Fee Bitcoin Transactions; Miner Adoption Slow
No comments:
Post a Comment