Feed for tag: payments
Payee Pay Fee

Lightning Network is currently starting to build up, it has recently passed 2 Million dollars in capacity, but its still far from being perfect, there’s currently very little ways of assessing how much fees a payer will pay, although its currently mostly a negligible value, it may not be in the future.

A use case of the Payee paying the fees of the transaction is used in almost every exchange platform, because on the main blockchain you can assess the current average fees and even figure out how much, on average, it will take your payment to be accepted by the network if you sent it with a definite amount, this currently does not exist in Lightning.

If the payee pays the fees the payer can route the payment towards complicit nodes that charge way higher fees than average.

BTCPay Server Payment Request: Invoice Clients and Get Paid in BTC by Sharing a Simple Link

The team at BTC Pay Server published an article introducing their Payment Requests feature.

It allows you to get paid in cryptocurrency just by sharing a simple URL using a new type of time-sensitive inoice page built into BTCPay.

BTCPay Server is an open-source cross platform, self-hosted bitcoin server compatible with Bitpay API.

Atomic Multi-Path Payments Over Lightning

Olauluwa Osuntokun posted to the lighting network developer’s mailing list a proposal for extending the complexity and utility of payment paths. The scheme is called “Atomic Multi-path Payments” (AMP) and Osuntokun claims “the beauty of the scheme is that is requires no fundamental changes to the [current] protocol”. The purpose of the scheme is to provide a way for a sender to break payments up into “chunks”. There is unusued space in data trasmitted between lighting nodes as a byproduct of tor compliance. This unusued space has been isolated as a 65 bytes that can be used as processing instructions for nodes along the payment path.

When considering payments that are broken into chunks, it is an excellent idea both technically and economically. Relay and processing becomes subdivided further than presently among nodes. More nodes increases security by reducing probability of select certain paths redundantly. Economically, single payments dispursed over a wider set of nodes provides a more fair (probabilisitically speaking) distrobution of work.