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??

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.

Arf'ın çalışma stili Lightning Network'e çok benziyor, ülkemizde Paypal'ın yasak olduğunu varsayarsak P2P transfer yaparken kullanmak için uygun bir alternatif oluşturulmuş. Yukarıdaki arkadaşların söylediğinin tam tersine sistemde Lightning Network benzeri bir yapı varsa işlemlerin sizin de dediğiniz gibi anlık olarak gerçekleşmesi gerekiyor çünkü mikro ödemeler için geliştirilmiş bir ağdan bahsediyoruz. Ben BTC'nin kafa karıştırdığını ve e-mail ile alınıp/verilmesi gerektiğini düşünen biri olarak uygulamanızı çok başarılı buldum, başarılarınızın devamını diliyorum.

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

Doğru, aklımdan çıkmış. Halmater'in de dediği gibi son kullanıcıya ulaşmak zor olsa da proje son derece mantıklı, BTC'nin zaten toplumun geneline yayılması için e-mail benzeri bir sisteme geçmesi gerekiyordu, bizden böyle bir proje çıktığı için desteklerim. Kanada'da bile IBAN muhabbetine çözüm olması açısından insanlar e-mail sistemi ile birbirine para gönderiyor. Özellikle ağ LN benzeri olduğu için BTC'nin karşı tarafa ne kadar sürede ulaşacağını merak ediyorum. LN'de kanallar vardı, bunda da var mı? Uygulamayı test etmek istiyorum, benimle beraber test etmek isteyen bir Bitcointalk üyesi varsa bekliyorum.  

iOS’da bana create wallet seçeneği çıkmadı, ben mi yanlış anladım acaba? Sadece e-mail adresi ve cüzdanımı import edeceğim alan vardı.

Ben merak ettiğim için indirdim ama cüzdanımın import edilmesi isteniyor. Bir kullanıcı uygulamanıza nasıl güvenebilir? Sizin import edilen seedlere ulaşma imkanınız var mı?

betaya nasıl kaydoluyoruz?

Ben projeyi inceledim ve bayağı beğendim.

Transferler sırasında e-postalar kullanılıyor üstelik sistem Lightning Network gibi işliyor. Sanırım transferler sırasında e-postaların kullanılması Kanada'nın bankacılık sisteminden esinlenilmiş, sistemin genel yapısı Paypal&Lightning Network karışımı gözüküyor dolayısıyla transfer ücretleri çok düşük oluyor fakat şöyle bir sorun var. Bitcoin'in transfer ücreti olmaması gibi bir şey söz konusu olamaz, transfer konu içeriğinde yazdığınız gibi ücretsiz değil sadece çok daha düşük bir rakam. Sonuç olarak Lightning Network ile harmanlanan Paypal yaratmışsınız. Ben fikir olarak beğensem de ucuz transferden yararlanılabilmesi için her iki tarafın da sizin sisteminize dahil olması gerekiyor. Bu durumda etkili bir reklam çalışması yapmadığınız sürece son kullanıcıya ulaşmanız çok zor, üstelik reklama harcadığınız parayı kullanıcıdan geri de alamazsınız çünkü en başta ucuz transfer ücreti vaadetmiştiniz. O halde bu kısır döngü nasıl kırılacak?  

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


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.