raymo via bitcoin-dev wrote:
TL,DR: you were explained by ZmnSCPxj why this protocol will not work.
The possibility for just one party to sign will not work. I will explain
again why but in much more simpler description.
Check out this simple transaction to learn more about how the system
works.
Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
she can spend it by create a transaction and sign it and broadcast it to
Bitcoin network.
Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
Satoshi from Alice in exchange.
Alice gets this 5$ and prepare a Main transaction that represents this
liability of Alice to Bob.
Main Transaction (20,000 Sat input):
* Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
has to pay 3,000 as BTC fee)
* Alice (issuer): 6,000 Sat
* BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
This is a valid transaction and both Bob and/or Alice can send it to
Bitcoin network, but none of them are interested in doing so. Because
they will lose 5,000 Satoshi of their own money as Bitcoin transaction
fee.
Alongside this transaction Alice (the issuer) has to create the
Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
not consider the deal completed. The Guarantee Transaction is another
valid Bitcoin transaction. It is created based on Main Transaction and
will cut a part of Bob and Alice money in favor of transaction fee.
Guarantee Transaction (20,000 Sat input):
* Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
* Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
* BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from
Bob) + 3,480 (from Al-ice) = 15,739 Sat
The Guarantee Transaction applies when the issuer does not live up to
its promise and intends to spend the promised UTXO(s) in a way other
than that agreed upon. We already knew the fact that Sabu is not a
custodial solution, neither a M of N signature schema. As a result, the
UTXO owner always can spend the already promised UTXO(s) in Sabu
protocol or out of Sabu on Bitcoin blockchain, Contrary to what was
promised.
When the Alice (issuer) breaks such a promise and sends the fraudulent
transaction to the Bitcoin network, Bob's wallet realizes that she
(issuer) is spending the promised UTXO(s) and it sends the Guarantee
Transaction(s) to the network as a last resort. The miners will face two
(or more) transactions which are spending same UTXO(s), but one of them
is paying notably higher Bitcoin transaction fee, thus they chose the
highest fee payer transaction, which is the Guarantee Transaction. The
miner will put the Guarantee Transaction in next block and reject the
rest double-spend transactions. Certainly, poor Bob cannot recoup all
his Satoshis. But he can retrieve a portion of his money and forces
Alice to lose some of her money as well. tit for tat!
Because of this mechanism, the issuer will try to not cheat on creditor.
By the way there are some attacks that have very small chance to succeed
but the risk to reward ratio for these scenarios are too high to be
considered as a real possible attack threat. I will review them a little
later in this post.
You said that the guarantee transaction is created based on Main
Transaction, how do you mean? If it is a child transaction of the Main
Transaction it already doesn't work because Alice needs to broadcast the
*Main Transaction* to the blockchain in order for the Guarantee
transaction to be accepted, and of she does this, Bob doesn't care
because the transaction pays to him already the correct agreed amount.
If you did not mean this, still it won't work, because
Simple:
1. Alice will create transaction #3, or call it Sabu-killing-transaction
(20,000 Sat input):
* Alice (issuer): 15,000 Sat
* BTC Fee: 5,000 Sat
PERIOD.
When Bob tries to broadcast the "guarantee transaction" he will get an
error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much
larger fee in the guarantee transaction will not matter. You have to
assume a miner will violate the Bitcoin protocol and somehow drop
Sabu-killing-transaction from mempool and consider the Guarantee
transaction only. This is very unlikely to happen and you might also
need connection direct with the miners because most full nodes will not
even accept the Guarantee transaction to their mempools in order to
further broadcast it until it reaches the miners.
With the simple attack described above Alice's chance to fraud Bob are,
from my point of view, 99%.
(the only way to replace a transaction is Replace-By-Fee but this
implies the transaction that IS TO BE REPLACED has a certain flag set,
and it is optional).
Given the Sabu-Killing-transaction comes first, Alice will of course
create it without this flag set so even if you add to Sabu the
requirement of RBF enabled to the Guarantee transaction it will not
work, because it's the other way around.
The second question is just for an observation that it has no real
benefits over Lightning even if #1 wasn't true:
2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he
is connected to the internet, otherwise if he loses connection to the
internet or energy supply, Alice attack will succeed entirely with 100%
chances. So this means Bob needs to always be online like forever and ever.
The 3rd one is hypothetical and you don't even have to answer it:
3. How does Bob (first creditor) spend the coins received / how does Bob
become an issuer himself in relation to Dave (another creditor)? What
happens if Alice tries to fraud Bob after Bob spent its Sabu credit to
Dave? Dave has to hold all parent "guarantee transactions" and watch the
network for any potential fraudulent transactions that cancels his credit?
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
