[bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

[James Hilliard via bitcoin-dev]

Recently a large merchant payment processor has decided to drop
support for BIP21 payment URI's in favor of accepting exclusively
BIP70 payments which has brought to light a number of problems with
BIP70:

1. Many wallets do not support BIP70 and have no near term intention
of doing so.
2. BIP70 requires large complex PKI dependencies such as X.509 and TLS
support(usually via openssl) which have a large attack surface and
poor track record when it comes to vulnerabilities.
3. Signing transactions with keys resident in the same application as
that which handles TLS greatly increases the possibility of keys being
leaked due to vulnerabilities in TLS libraries such as
openssl(heartbleed etc).
4. Sending payments first to a BIP70 compatible wallet before sending
to the merchant increases fees and uses more block space than sending
directly since it is often not feasible for users to fully migrate
funds to a BIP70 compatible wallet.
5. Paying a BIP70 invoice with an incompatible wallet currently
requires manual non-user-friendly workarounds such as
https://github.com/achow101/payment-proto-interface

I propose that we move the BIP70 protocol implementation into a
browser extension that can communicate with wallets over a simple IPC
mechanism such as
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
in addition to acting as a translation layer that can convert BIP70
URL's into standard BIP21 URI's for wallets that do not wish to
support BIP70 or other custom schemes.

This will provide a number of advantages over the current method of
implementing BIP70 directly within wallets:

1. It removes complex/risky dependencies from wallets and moves them
into the browser which already has to implement full PKI support.
2. It re-enables payment support for wallets that only support
BIP21/normal addresses.
3. It makes offline/custom signing schemes easier to use with BIP70.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

[Damian Williamson via bitcoin-dev]

Happy New Year all.

This proposal has been further amended with several minor changes and a
few additions.

I believe that all known issues raised so far have been sufficiently
addressed. Either that or, I still have more work to do.

## BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For
Ordering Transactions In Blocks

Schema:  
##  
Document: BIP Proposal  
Title: UTPFOTIB - Use Transaction Priority For Ordering Transactions In
Blocks  
Published: 26-12-2017  
Revised: 01-01-2018  
Author: Damian Williamson   
Licence: Creative Commons Attribution-ShareAlike 4.0 International
License.  
URL: http://thekingjameshrmh.tumblr.com/post/168948530950/bip-proposal-
utpfotib-use-transaction-priority-for-order  
##

### 1. Abstract

This document proposes to address the issue of transactional
reliability in Bitcoin, where valid transactions may be stuck in the
transaction pool for extended periods or never confirm.

There are two key issues to be resolved to achieve this:

1.  The current transaction bandwidth limit.
2.  The current ad-hoc methods of including transactions in blocks
resulting in variable and confusing confirmation times for valid
transactions, including transactions with a valid fee that may never
confirm.

It is important with any change to protect the value of fees as these
will eventually be the only payment that miners receive. Rather than an
auction model for limited bandwidth, the proposal results in a fee for
priority service auction model.

It would not be true to suggest that all feedback received so far has
been entirely positive although, most of it has been constructive.

The previous threads for this proposal are available here:  
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/s
ubject.html

In all parts of this proposal, references to a transaction, a valid
transaction, a transaction with a valid fee, a valid fee, etc. is
defined as any transaction that is otherwise valid with a fee of at
least 0.1000 BTC/KB as defined as the dust level, interpreting from
Bitcoin Core GUI. Transactions with a fee lower than this rate are
considered dust.

In all parts of this proposal, dust and zero-fee transactions are
always ignored and/or excluded unless specifically mentioned.

It is generally assumed that miners currently prefer to include
transactions with higher fees.

### 2. The need for this proposal

We all must learn to admit that transaction bandwidth is still lurking
as a serious issue for the operation, reliability, safety, consumer
acceptance, uptake and, for the value of Bitcoin.

I recently sent a payment which was not urgent so; I chose three-day
target confirmation from the fee recommendation. That transaction has
still not confirmed after now more than six days - even waiting twice
as long seems quite reasonable to me (note for accuracy: it did
eventually confirm). That transaction is a valid transaction; it is not
rubbish, junk or, spam. Under the current model with transaction
bandwidth limitation, the longer a transaction waits, the less likely
it is ever to confirm due to rising transaction numbers and being
pushed back by transactions with rising fees.

I argue that no transactions with fees above the dust level are rubbish
or junk, only some zero fee transactions might be spam. Having an ever-
increasing number of valid transactions that do not confirm as more new
transactions with higher fees are created is the opposite of operating
a robust, reliable transaction system.

While the miners have discovered a gold mine, it is the service they
provide that is valuable. If the service is unreliable they are not
worth the gold that they mine. This is reflected in the value of
Bitcoin.

Business cannot operate with a model where transactions may or may not
confirm. Even a business choosing a modest fee has no guarantee that
their valid transaction will not be shuffled down by new transactions
to the realm of never confirming after it is created. Consumers also
will not accept this model as Bitcoin expands. If Bitcoin cannot be a
reliable payment system for confirmed transactions then consumers, by
and large, will simply not accept the model once they understand.
Bitcoin will be a dirty payment system, and this will kill the value of
Bitcoin.

Under the current system, a minority of transactions will eventually be
the lucky few who have fees high enough to escape being pushed down the
list.

Once there are more than x transactions (transaction bandwidth limit)
every ten minutes, only those choosing twenty-minute confirmation (2
blocks) from the fee recommendations will have initially at most a
fifty percent chance of ever having their payment confirm by the time
2x transactions is reached. Presently, not even using fee
recommendations can ensure a sufficiently high fee is paid to ensure
transaction confirmation.

I also argue that the current auction model for limited transaction
bandwidth is wrong, is