s7r [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-08 📝 Original message:raymo via bitcoin-dev ...

📅 Original date posted:2021-08-08
📝 Original message: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?