P2P Bitcoin Transaction

[omone1]

The exchange I know doesn't charge for bitcoin transaction is LUNO, and it has to be from LUNO to LUNO account using members emails they had registered with, even though I do trade Fiat/BTC on luno, I have not done this member transfer before. Another exchange that allows free member to member transfer is paxful, but some persons have complained of sudden block of their account and never opened again. These two scenario charges for external transactions. So are you going to make transfer free for only members and charge external?

[1715342922]

1715342922

[1715342922]

1715342922

[1715342922]

1715342922

[1715342922]

1715342922

[1715342922]

1715342922

[sunsilk]

Give more details or much better to give the complete details of what you're trying to address in here, so we can give our opinions without any guess of what you're trying to get in here.

I think it's another time that I've seen someone proposed something like this of sending bitcoin from an email. Most of the questions that I'd like to ask were already asked, if you are still there kindly answer those most interesting ones.

[adzino]

Hi guys, I need your feedback. We're developing a product. Sending, receiving Bitcoin internationally, getting paid in Bitcoin is always FREE, instant, and secure. You know, in a regular bitcoin wallet or service there are mining or transaction fees while sending Bitcoin. We won't charge any fee. So it's different from other services and wallets. Also, it's different from Lightning Network because it's very simple to use it. The receiver's email and the app are enough to send Bitcoin.

• What do you think about that?
• Would you use it? If you don't, can you explain why?
• What features would encourage you to use this service?

We would need more information on how this is going to work. How is it going to be instant? Since it's different from lightening network and again, there will be no mining or transaction fees, then how will the transactions be confirmed? I am assuming this is going to be some decentralized thing. "The receivers email and the app are enough" - coinbase does the same thing right?

[DilaraSavasci]

Sorry for the late explanation. We tried to answer all your questions in one big post. Let us know if you need more information and please share your concerns and thoughts. Here we go.


It involves a platform (third party) that eliminates friction for users in terms of ease of onboarding, ease of operation, transaction speed and transaction cost. Similar to Lightning Network and Liquid, it interacts with Bitcoin but introduces a chain of operations to ensure instant and minimal-fee Bitcoin transfers without compromising users security.

To be specific, it is:

(1) the counterparty in a 2-of-2 multisignature address when a user creates an account,
(2) the enabler of instant transactions by being the guarantor for the receiving party once the sender signed the initial transaction,
(3) the aggregator of partially-signed unspent transaction outputs (UTXOs) and merge them into cheaper transactions in terms of fees (satoshis per byte),
(4) the address book generator, mapping email addresses to Bitcoin addresses and notifying users

Obviously, the most important design choice is the addition of a third party to the system, namely the platform itself, which naturally raises questions on "trust". It is important to understand that:

• the platform is non-custodial, which means the platform by itself is unable to create any transaction that is not signed by the user first,
• users will not experience any loss of funds in case either the platform or the user's system got hacked,
• as a necessary trade-off in favor of fund security, if users lose their private keys, they will be unable to recover their funds,
• there are no operational risks for users like in Lightning Network, namely, possible loss of funds in case of getting offline or a crashed hard drive,
• everybody can participate in contrast to Blockstream Liquid, which only accepts cryptocurrency or digital asset exchanges

Cheers!



Additional information:


HOW EXACTLY DO WE DO AN INSTANT BITCOIN TRANSACTION?

In order to enable instant transactions with Bitcoin, an off-chain mechanism should be introduced to finalize the transaction without committing final state to Bitcoin chain. In the proposed design, users will create an account on the platform which is presented as a wallet application. During that process, a 2-of-2 multisignature Native Pay-to-Witness-Script-Hash (P2WSH) address is created using the public keys of the user and the platform. After that point, users may deposit to or withdraw from that specific multisignature address. This mechanism is similar to Lightning Network’s Funding Transaction to open payment channels, or Green Address wallet creation. Once the multisignature address is successfully funded by the user, they may spend their Bitcoin (e.g. create transactions) via signing their UTXOs and sending it to the platform for the final signature. The whole account creation and spending process will work as follows:

(1) user will create a random seed in the wallet application and the first private and public key is created using the "BIP-32: Hierarchical Deterministic Wallets" method. Both seed and keys will never leave the (mobile) application,
(2) user will send its public key to the platform,
(3) platform will create a 2-of-2 multisignature Native Pay-to-Witness-Script-Hash (P2WSH) address using the users and its own public key and share that address with the user,
(4) user will fund that address with Bitcoin,
(5) user will query their Bitcoin balance and UTXOs,
(6) user will create a raw Bitcoin transaction using the required amount of UTXOs as inputs and receiver addresses and amounts as outputs,
(7) user will sign the raw transaction with signature hash type SIGHASH_NONE|SIGHASH_ANYONECANPAY (where single input is signed and all the other inputs and outputs are modifiable) or SIGHASH_SINGLE|SIGHASH_ANYONECANPAY (where single input and single output is signed and all the other inputs and outputs are modifiable),
(8 ) user will send the partially-signed raw transaction to the platform to be signed and sent to the Bitcoin network,
(9) platform will receive the partially-signed raw transaction, verify it and queue it for aggregation,
(10) platform will signal the receiving party (merchant or user of the platform) instantly about payment completion and credit that user in the system in an off-chain way,
(11) platform will finalize the aggregated transaction, add the required transaction fee based on network conditions, sign it with SIGHASH_ALL and broadcast it to the network

As seen in the flow above, the platform has the capability to signal the completion of payment to the receiver, once the sender has signed the initial transaction. However, besides all the improvements, the proposed system introduces two disadvantages. The first one is, due to the use of multisignature addresses the transaction sizes are bigger than the regular Bitcoin transactions. Roughly, a single signature is 70 bytes and a compressed public key in hexadecimal format is 33 bytes, so every additional signature (which is one in our case) adds up 100 bytes to the transaction. The second disadvantage is about internal risk. The platform notifies the receiver about payment completion however that state is not reflected on-chain. Basically, the platform is carrying this internal risk until the settlement is complete. Luckily, both of these disadvantages can either be eliminated or significantly reduced. Bitcoin is on the verge of adopting Schnorr signatures, that will reduce the multisignature size overhead drastically. Instead of storing all the signatures for every required party separately, Schnorr signature scheme makes it possible to use the space for just one signature, independent of the number of required signatures. About the second disadvantage, it would be possible for the platform to manage its internal risk by sending transactions more frequently. The platform may utilize two metrics: "total accumulated Bitcoin size in pending transactions" and "passed time since the last sent transaction" to dynamically reduce its risk.


HOW DO WE DO IT FREE?

Well, it's not exactly free for the platform in general but our process reduces fees so much that we are able to offer it free for end users.

Bitcoin transaction fee is a game-theoretic construct that is measured in satoshis per byte and fluctuates depending on the congestion of the Bitcoin network in terms of pending transactions (i.e. size of mempool). Highest historic daily average Bitcoin transaction fee is estimated as 985 satoshis per byte on the 12th of December 2017, right in the middle of the Bitcoin price spike. Even today, with all the custodial exchange wallets and Lightning Network, spikes in the exchange rate still trigger jumps in transaction fee unit prices. For example, on the 20th May 2019 average transaction fee price jumped to 212 satoshis per byte. In a nutshell, there are only two parameters that can be used to decrease the transaction fee: space and time. Currently, the most cost effective scheme to create transactions is using native SegWit (bech32) addresses. Based on savings for various transaction types, our 2-of-2 multisignature address case goes as high as 49%. On the other hand, it is possible to reduce transaction fees by just being "patient". If transaction confirmation is not urgent, it is possible to wait confirmation for a couple days and pay up to 92% less.

The platform not only utilizes both of these techniques (using bech32 addresses and patient spending) but also implements additional optimizations that are only possible by design. The unique opportunities for optimization are:

(1) aggregate and spend only completely consumed UTXOs, therefore saving up one output per payment attempt, per user (i.e. do not ever create and send to change addresses)
(2) aggregate payments to same addresses together (i.e. SIGHASH_NONE|SIGHASH_ANYONECANPAY and SIGHASH_SINGLE|SIGHASH_ANYONECANPAY makes it possible to modify outputs)
(3) aggregated transactions will be relatively big (over tens of inputs and outputs) and even though the satoshi per byte unit price is slightly lower compared to the other pending transactions, the higher mining fee alone will be attractive for adding that single aggregated transaction to the blockchain

These design choices come with a disadvantage: there are no change addresses created for the user and until the whole single UTXO is spent (or withdrawn by the user) the final state will not be visible on-chain. Once again, this is a calculated risk for the platform.



HOW ARE YOU DIFFERENT THAN THE LIGHTNING NETWORK

Lighting Network is a payment solution built on top of Bitcoin, that promises an instant, trustless and cheap way of making transactions. Lightning Network, is a peer-to-peer network, where peers are able to "lock" their Bitcoin on chain and able to transfer it to other parties via "channels". It is designed to create a network of micropayment channels that will address the scalability problem of the Bitcoin network. LN offers instant transactions on its off-chain payment channels, where on-chain transaction finality is reached after a number of transactions are routed off-chain, through a single channel or several channels based on channel liquidity and available nodes.

The routing capability of each lightning channel is determined by the funds locked on-chain by each peer with a significant trade-off which requires that both the sending and receiving end of a given channel must be funded at least by the amount of the transfer for a seamless routing. This brings about a serious liquidation shortage if a Bitcoin amount x must be routed through n number of channels. In such a case, not only must the entire route be funded with the amount of 2xn but also each of the locked funds yn on both the receiving and sending ends of the nodes must be greater than or equal to the amount of transfer x (yn ≥ x).

For example, if Peer A wants to transfer $10 to Peer C and this payment will be routed through Peer B then;
The route A -> B -> C must be funded with at least 2 x 2 x $10 = $40
with the following channel fund distribution:

A -> $10 on sending end (sending to B),
B -> $10 on receiving end (Receiving from A) + $10 on sending end (Sending to C) = $20,
C -> $10 on receiving end (Receiving from B)
 
It is also critical to mention that this type of routing also requires that each of the peers A, B and C must maintain full Bitcoin nodes at all times that are never allowed to go offline. This requirement is to prevent the so-called fraudulent channel close where one peer (online) broadcasts the entire channel fund to the Bitcoin blockchain without the knowledge of the other (offline). It is also a major issue for user onboarding since opening, maintaining and funding an LN node require a relatively significant amount of technical know-how.  To mitigate this issue, LN is working on so-called “Watchtowers” which are basically third party operators that are responsible for node maintenance. This is a trade-off in LN’s trustless structure in favor of better user experience where receiving parties must trust the watchtower operators with their funds. Another common trade-off is observed in third party products built on top of the LN where custodial wallets are generated on hosted LN nodes where wallet owners trust the third party products with channel liquidity, channel uptime and their funds.

Another shortcoming of the Lightning Network emerges in case of merchant payments where a merchant must keep all of their channels liquid enough to be able to continuously receive payments. If Peer C was a merchant in the above example they would not be able to transfer the $10 they received from A to a non-LN wallet if they wanted to keep receiving payments from the same channel. This problem is exacerbated by the recent beta release of “Lightning Loop” which allows a peer to transfer part of their locked channel funds to another wallet without closing the channel. If Peer C had used Lightning Loop to pull $5 from the channel before the transfer occurred they wouldn’t have been able to receive $10 from Peer A because of insufficient liquidation on their receiving end.

[stompix]

It involves a platform (third party)

~snip

Obviously, the most important design choice is the addition of a third party to the system, namely the platform itself, which naturally raises questions on "trust".

Ok, so not a troll at all indeed, but

Rather than trusting an unknown 3rd party with no reputation and no way to force him to obbery customer protection laws in your country with hundred of dolalrs all in order to avoid paying 10 cents for a tx most would rather use a credit card and a bank.

Second

((1) to (11) not going to quote the entire process

This is too damn well written for a real newbie
Please move the topic to Project Development as you're going to get far better feedback than here.
I remember the discussions about _ANYONECANPAY when Lighthouse was being developed but ironic, that hit scaling problems too.

[carter34]

Well I would rather choose to pay the fees for my transaction to be processed and send than entrusting in a third party. Crypto should be allowed to freely function rather than being bridged along the line .

[DilaraSavasci]

It involves a platform (third party)

~snip

Obviously, the most important design choice is the addition of a third party to the system, namely the platform itself, which naturally raises questions on "trust".

Ok, so not a troll at all indeed, but

Rather than trusting an unknown 3rd party with no reputation and no way to force him to obbery customer protection laws in your country with hundred of dolalrs all in order to avoid paying 10 cents for a tx most would rather use a credit card and a bank.

Second

((1) to (11) not going to quote the entire process

This is too damn well written for a real newbie
Please move the topic to Project Development as you're going to get far better feedback than here.
I remember the discussions about _ANYONECANPAY when Lighthouse was being developed but ironic, that hit scaling problems too.

Thanks for the answer and the suggestion. Obviously, many of the people in this forum are technically astute to understand how on-chain transactions work and why it is important to stay on-chain. It will take some time before a critical mass of people can trust us.

However, for every 1 person who can run their own Bitcoin/Lightning Node or onboard a pure non-custodial Bitcoin wallet, there are 1,000 people who have no technical know-how to pull that off but would be willing to use Bitcoin everyday since they don't have a bank account. As a matter of fact, there are 250M people in the world fitting that description. So, it's not really question of "I'd use my credit card than trusting an unknown 3rd party" but rather one of "I have a smartphone and internet access but no bank account, how can I make online payments?" That's the vision of the team behind this product. 1) Abstract everything technical 2) Make everything fast and free 3) Don't jeopardize user funds.

PS: I'm new in the forum not in Bitcoin. 

[DilaraSavasci]

UPDATE: Our app released in App Store & Google Play. You can take a look if you're interested.

https://www.arf.one/?utm_source=bitcointalk&utm_medium=referral&utm_campaign=arf-016-P2P&utm_content=Beta-tester

[bitcoinposts]

i am regular buyer of bitcoin from Localbitcoins  websites  . LocalBitcoins are safe and secure escrow transactions based peer to peer transaction In India most of the users are solely depending on localbitcoins for bitcoin transactions

[DilaraSavasci]

i am regular buyer of bitcoin from Localbitcoins  websites  . LocalBitcoins are safe and secure escrow transactions based peer to peer transaction In India most of the users are solely depending on localbitcoins for bitcoin transactions

I understand your concerns about safety and security. This is important for us too for that our wallet is noncustodial. The transactions will be showed up in Stellar soon. We're in a collaboration process.
You can't buy/sell Bitcoin in our network yet. Just instant, free and secure P2P transactions are available.

[fiulpro]

Hi guys, I need your feedback. We're developing a product. Sending, receiving Bitcoin internationally, getting paid in Bitcoin is always FREE, instant, and secure. You know, with a regular bitcoin wallet there are mining and transaction fees while sending Bitcoin. We won't charge any fee.

If your transactions are done on the chain and not in some online wallets in which you simply move balances then your transactions can't be FREE. Also, they can't be INSTANT since the customer has to wait for at least one confirmation to move the funds.
Are you planning to pay for those from your own pocket? I'm not sure how you plan on doing this.

So,

.

• What do you think about that?
• Would you use it? If you don't, can you explain why?
• What features would encourage you to use this service?

1) Unless you tell us more about how you plan to achieve this, I'm a bit suspicious
2) Why would I use a service to send bitcoins when I can simply send them myself?
3) None really, I'm against using and trusting a 3rd party when it comes to irreversible transactions.

Exactly .

The network confirmations are something that will anyways be there always .

What you guys are earning from it??
Nothing ! Actually.

Why would you even do it??
Fame on the account of your own money?

Why would people trust a 3rd party ??
Isn't regular frauds more than enough??

[DilaraSavasci]

Exactly .

The network confirmations are something that will anyways be there always .

What you guys are earning from it??
Nothing ! Actually.

Why would you even do it??
Fame on the account of your own money?

Why would people trust a 3rd party ??
Isn't regular frauds more than enough??

Here's my answer
PS: We earn from merchants. If you have more than 10,000 customers, we take 2% commissions from you!

Sorry for the late explanation. We tried to answer all your questions in one big post. Let us know if you need more information and please share your concerns and thoughts. Here we go.


It involves a platform (third party) that eliminates friction for users in terms of ease of onboarding, ease of operation, transaction speed and transaction cost. Similar to Lightning Network and Liquid, it interacts with Bitcoin but introduces a chain of operations to ensure instant and minimal-fee Bitcoin transfers without compromising users security.

To be specific, it is:

(1) the counterparty in a 2-of-2 multisignature address when a user creates an account,
(2) the enabler of instant transactions by being the guarantor for the receiving party once the sender signed the initial transaction,
(3) the aggregator of partially-signed unspent transaction outputs (UTXOs) and merge them into cheaper transactions in terms of fees (satoshis per byte),
(4) the address book generator, mapping email addresses to Bitcoin addresses and notifying users

Obviously, the most important design choice is the addition of a third party to the system, namely the platform itself, which naturally raises questions on "trust". It is important to understand that:

• the platform is non-custodial, which means the platform by itself is unable to create any transaction that is not signed by the user first,
• users will not experience any loss of funds in case either the platform or the user's system got hacked,
• as a necessary trade-off in favor of fund security, if users lose their private keys, they will be unable to recover their funds,
• there are no operational risks for users like in Lightning Network, namely, possible loss of funds in case of getting offline or a crashed hard drive,
• everybody can participate in contrast to Blockstream Liquid, which only accepts cryptocurrency or digital asset exchanges

Cheers!



Additional information:


HOW EXACTLY DO WE DO AN INSTANT BITCOIN TRANSACTION?

In order to enable instant transactions with Bitcoin, an off-chain mechanism should be introduced to finalize the transaction without committing final state to Bitcoin chain. In the proposed design, users will create an account on the platform which is presented as a wallet application. During that process, a 2-of-2 multisignature Native Pay-to-Witness-Script-Hash (P2WSH) address is created using the public keys of the user and the platform. After that point, users may deposit to or withdraw from that specific multisignature address. This mechanism is similar to Lightning Network’s Funding Transaction to open payment channels, or Green Address wallet creation. Once the multisignature address is successfully funded by the user, they may spend their Bitcoin (e.g. create transactions) via signing their UTXOs and sending it to the platform for the final signature. The whole account creation and spending process will work as follows:

(1) user will create a random seed in the wallet application and the first private and public key is created using the "BIP-32: Hierarchical Deterministic Wallets" method. Both seed and keys will never leave the (mobile) application,
(2) user will send its public key to the platform,
(3) platform will create a 2-of-2 multisignature Native Pay-to-Witness-Script-Hash (P2WSH) address using the users and its own public key and share that address with the user,
(4) user will fund that address with Bitcoin,
(5) user will query their Bitcoin balance and UTXOs,
(6) user will create a raw Bitcoin transaction using the required amount of UTXOs as inputs and receiver addresses and amounts as outputs,
(7) user will sign the raw transaction with signature hash type SIGHASH_NONE|SIGHASH_ANYONECANPAY (where single input is signed and all the other inputs and outputs are modifiable) or SIGHASH_SINGLE|SIGHASH_ANYONECANPAY (where single input and single output is signed and all the other inputs and outputs are modifiable),
(8 ) user will send the partially-signed raw transaction to the platform to be signed and sent to the Bitcoin network,
(9) platform will receive the partially-signed raw transaction, verify it and queue it for aggregation,
(10) platform will signal the receiving party (merchant or user of the platform) instantly about payment completion and credit that user in the system in an off-chain way,
(11) platform will finalize the aggregated transaction, add the required transaction fee based on network conditions, sign it with SIGHASH_ALL and broadcast it to the network

As seen in the flow above, the platform has the capability to signal the completion of payment to the receiver, once the sender has signed the initial transaction. However, besides all the improvements, the proposed system introduces two disadvantages. The first one is, due to the use of multisignature addresses the transaction sizes are bigger than the regular Bitcoin transactions. Roughly, a single signature is 70 bytes and a compressed public key in hexadecimal format is 33 bytes, so every additional signature (which is one in our case) adds up 100 bytes to the transaction. The second disadvantage is about internal risk. The platform notifies the receiver about payment completion however that state is not reflected on-chain. Basically, the platform is carrying this internal risk until the settlement is complete. Luckily, both of these disadvantages can either be eliminated or significantly reduced. Bitcoin is on the verge of adopting Schnorr signatures, that will reduce the multisignature size overhead drastically. Instead of storing all the signatures for every required party separately, Schnorr signature scheme makes it possible to use the space for just one signature, independent of the number of required signatures. About the second disadvantage, it would be possible for the platform to manage its internal risk by sending transactions more frequently. The platform may utilize two metrics: "total accumulated Bitcoin size in pending transactions" and "passed time since the last sent transaction" to dynamically reduce its risk.


HOW DO WE DO IT FREE?

Well, it's not exactly free for the platform in general but our process reduces fees so much that we are able to offer it free for end users.

Bitcoin transaction fee is a game-theoretic construct that is measured in satoshis per byte and fluctuates depending on the congestion of the Bitcoin network in terms of pending transactions (i.e. size of mempool). Highest historic daily average Bitcoin transaction fee is estimated as 985 satoshis per byte on the 12th of December 2017, right in the middle of the Bitcoin price spike. Even today, with all the custodial exchange wallets and Lightning Network, spikes in the exchange rate still trigger jumps in transaction fee unit prices. For example, on the 20th May 2019 average transaction fee price jumped to 212 satoshis per byte. In a nutshell, there are only two parameters that can be used to decrease the transaction fee: space and time. Currently, the most cost effective scheme to create transactions is using native SegWit (bech32) addresses. Based on savings for various transaction types, our 2-of-2 multisignature address case goes as high as 49%. On the other hand, it is possible to reduce transaction fees by just being "patient". If transaction confirmation is not urgent, it is possible to wait confirmation for a couple days and pay up to 92% less.

The platform not only utilizes both of these techniques (using bech32 addresses and patient spending) but also implements additional optimizations that are only possible by design. The unique opportunities for optimization are:

(1) aggregate and spend only completely consumed UTXOs, therefore saving up one output per payment attempt, per user (i.e. do not ever create and send to change addresses)
(2) aggregate payments to same addresses together (i.e. SIGHASH_NONE|SIGHASH_ANYONECANPAY and SIGHASH_SINGLE|SIGHASH_ANYONECANPAY makes it possible to modify outputs)
(3) aggregated transactions will be relatively big (over tens of inputs and outputs) and even though the satoshi per byte unit price is slightly lower compared to the other pending transactions, the higher mining fee alone will be attractive for adding that single aggregated transaction to the blockchain

These design choices come with a disadvantage: there are no change addresses created for the user and until the whole single UTXO is spent (or withdrawn by the user) the final state will not be visible on-chain. Once again, this is a calculated risk for the platform.



HOW ARE YOU DIFFERENT THAN THE LIGHTNING NETWORK

Lighting Network is a payment solution built on top of Bitcoin, that promises an instant, trustless and cheap way of making transactions. Lightning Network, is a peer-to-peer network, where peers are able to "lock" their Bitcoin on chain and able to transfer it to other parties via "channels". It is designed to create a network of micropayment channels that will address the scalability problem of the Bitcoin network. LN offers instant transactions on its off-chain payment channels, where on-chain transaction finality is reached after a number of transactions are routed off-chain, through a single channel or several channels based on channel liquidity and available nodes.

The routing capability of each lightning channel is determined by the funds locked on-chain by each peer with a significant trade-off which requires that both the sending and receiving end of a given channel must be funded at least by the amount of the transfer for a seamless routing. This brings about a serious liquidation shortage if a Bitcoin amount x must be routed through n number of channels. In such a case, not only must the entire route be funded with the amount of 2xn but also each of the locked funds yn on both the receiving and sending ends of the nodes must be greater than or equal to the amount of transfer x (yn ≥ x).

For example, if Peer A wants to transfer $10 to Peer C and this payment will be routed through Peer B then;
The route A -> B -> C must be funded with at least 2 x 2 x $10 = $40
with the following channel fund distribution:

A -> $10 on sending end (sending to B),
B -> $10 on receiving end (Receiving from A) + $10 on sending end (Sending to C) = $20,
C -> $10 on receiving end (Receiving from B)
 
It is also critical to mention that this type of routing also requires that each of the peers A, B and C must maintain full Bitcoin nodes at all times that are never allowed to go offline. This requirement is to prevent the so-called fraudulent channel close where one peer (online) broadcasts the entire channel fund to the Bitcoin blockchain without the knowledge of the other (offline). It is also a major issue for user onboarding since opening, maintaining and funding an LN node require a relatively significant amount of technical know-how.  To mitigate this issue, LN is working on so-called “Watchtowers” which are basically third party operators that are responsible for node maintenance. This is a trade-off in LN’s trustless structure in favor of better user experience where receiving parties must trust the watchtower operators with their funds. Another common trade-off is observed in third party products built on top of the LN where custodial wallets are generated on hosted LN nodes where wallet owners trust the third party products with channel liquidity, channel uptime and their funds.

Another shortcoming of the Lightning Network emerges in case of merchant payments where a merchant must keep all of their channels liquid enough to be able to continuously receive payments. If Peer C was a merchant in the above example they would not be able to transfer the $10 they received from A to a non-LN wallet if they wanted to keep receiving payments from the same channel. This problem is exacerbated by the recent beta release of “Lightning Loop” which allows a peer to transfer part of their locked channel funds to another wallet without closing the channel. If Peer C had used Lightning Loop to pull $5 from the channel before the transfer occurred they wouldn’t have been able to receive $10 from Peer A because of insufficient liquidation on their receiving end.