Quote from: fiulpro on July 14, 2019, 06:19:22 PM

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!

Quote from: DilaraSavasci on May 27, 2019, 01:24:56 PM

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 Networks 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 LNs 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 wouldnt have been able to receive $10 from Peer A because of insufficient liquidation on their receiving end.