Why Bitcoin SV apps need peer-to-peer transactions

Truly peer-to-peer transactions are still rare on Bitcoin SV today despite being in the title of the whitepaper written almost 12 years ago.

Today almost all applications transact in the following manner:

User => ‘Full node’ => Miners => Application

1. A user sends their transaction to some so-called ‘full node’ (potentially running on a cloud server of one of the large tech conglomerates)
2. The ‘full node’ (if configured properly) relays your transaction to a miner (which is all they can do)
3. Miners then queue up the users’ transaction to put it in the next block—this is known as ‘zero-conf’
4. The application queries some other ‘full node’ or worse, their own before finally interpreting the transaction and rendering the data on their platform

This approach is horribly inefficient and relies on two potential points of failure.

The proper, much simpler way is as follows:

User => Application => Miners

1. User sends the transaction directly to the application
2. Application broadcasts the transaction directly to a miner
3. Miner queues the transaction for the next block

At the timestamped link below, Craig Wright clarifies what this really means and how the phrase has been misinterpreted for so long. This misunderstanding has resulted in applications being implemented that do not scale along with the network.

https://www.youtube.com/watch?v=nASiBsNfYz0&t=1003

The false narrative pushed from the beginning by BTC Core that individuals need to run their own node has led to even those building on top of Bitcoin SV to develop their applications dependent on one. Additionally, the lack of scale has allowed this type of architecture to persist and made application developers complacent with this suboptimal setup.

With the Genesis upgrade, we still do not have capable tools that allow us to take full advantage of the new network features so this need to scale is not yet apparent.

However, scale can occur suddenly and with the announcement of the EHR project at the CoinGeek conference in London last month, applications need to prepare.

A possibility exists that an applications existing inefficient architecture could become unusable and obsolete virtually overnight.

P2P transactions also offer a better user experience and more streamlined application development for the service provider. For example, the Twetch SDK/API implements this methodology. A user can make a simple HTTP request to Twetch’s server, then Twetch broadcasts the transaction on the user’s behalf.

This approach is much faster as Twetch can immediately display the data from the transaction on the site without extra querying and processing thus reducing risk and complexity. Additionally, Twetch can now moderate content before it is sent to the network as opposed to accepting what the network determined as valid.

Other interesting use cases become possible with this approach that I will leave to the reader’s imagination!

A counter argument to this approach is why? If a service will accept transactions before they are sent to the network, why even send them at all? How is this different than apps today?

One reason for this approach is redundancy—a Twetch client app could easily be derived from the ledger since the data is stored there.

Another is application interoperability; this is a concept that has been discussed but not yet fully realized on Bitcoin SV. Given that data can be written on a public ledger, other applications can now interpret and use that data on their platforms. A simple yet powerful example of this is unwriter’s Bitpic.

If one thinks about it, it is non-sensical to have to upload our profile pictures on every social media application we use. Why not upload it once, then reference that same picture across applications?

Baemail does leverage Bitpic for their user’s profile pictures. This saves the user time yet also reduces the service providers overall cost, development time and risk since most of the work was done by another provider. Noticing a trend?

To fully realize the potential of the Bitcoin SV network, apps must implement peer-to-peer transactions. The benefits are clear, cost savings are obvious and opportunities for collaboration are unbounded.