To: raymo@riseup.net,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com>
 <CAGpPWDZtRnnv-Hinn4x=9ukJcuHkZv-6Yt32AK-9e+BJ=6r-kA@mail.gmail.com>
 <f46159f0286fe48720bc3f3fead1b575@riseup.net>
 <CAJowKgKELBmLdA-w5ghGoiWe5RQdNkKsV3OGRFbDJCOeA04AWw@mail.gmail.com>
 <d8b3ba5b940473165ad72d689a01602a@riseup.net>
 <CAGpPWDYAJE4jh=G2g=KSRuLLucEAyZGAD+r4XMpcmw6nk4+Wbg@mail.gmail.com>
 <e843b5c28690557402b72fcd158dc1c2@riseup.net>
 <CAGpPWDYPutiURUtenkU_zr4nW_tZVe5oWykXxWCDyROwqTdW5Q@mail.gmail.com>
 <6016816a7ea36b8a88f48d69462d0308@riseup.net>
 <0555e82561666007e7ce367e3a204f53@riseup.net>
From: s7r <s7r@sky-ip.org>
Message-ID: <f5720b0e-d660-473e-00fa-aa275d062e30@sky-ip.org>
Date: Mon, 9 Aug 2021 03:03:31 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <0555e82561666007e7ce367e3a204f53@riseup.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
 Million Transactions Per Second with stronger privacy
Precedence: list

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?