path: root/3a/85eb7859241ef63f11fa4fad9d3f1184b369de

Return-Path: <raymo@riseup.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8873FC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 16:22:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 65B7682FCE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 16:22:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=riseup.net
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zWtCph9G2JJG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 16:22:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 35F6382F9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 16:22:30 +0000 (UTC)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
 by mx1.riseup.net (Postfix) with ESMTPS id 4Gk1ZY3h2kzDyXV;
 Mon,  9 Aug 2021 09:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1628526149; bh=yNi3t3MVgEuyTP2AcBt3N/s0/LmvdVVljXSySGFqMwM=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=Y7T28yuc3nWwIUpecnofwpuQvDYfP6Vxo6c563UOgDFaP7arJFxR9CQCz5APud5RI
 0HRueQSuXhDwgSut3UBxlg0AGTiTqE/eo9SRNDzVLrohUgPpurXtKL1m2kWv5LPeZa
 vD5jnz/2Sq4zRxDSCz/4b7pqNfmxIZVy7iNA5e48=
X-Riseup-User-ID: 640E109BA4DCA0D3D2899FD549FFA62853392C866C0DCBC6566F76773B449EE2
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4Gk1ZY288Fz1y5K;
 Mon,  9 Aug 2021 09:22:29 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 09 Aug 2021 09:22:29 -0700
From: raymo@riseup.net
To: s7r <s7r@sky-ip.org>
In-Reply-To: <f5720b0e-d660-473e-00fa-aa275d062e30@sky-ip.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>
 <f5720b0e-d660-473e-00fa-aa275d062e30@sky-ip.org>
Message-ID: <9403a01d93b3fe2e871517304b552194@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 09 Aug 2021 16:57:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
 Million Transactions Per Second with stronger privacy
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2021 16:22:31 -0000

Hi s7r,
I already answered to ZmnSCPxj's comments.

Let’s go to yours.

> If it is a child transaction of the Main Transaction
Sorry for my shortcoming in English, because it caused the
misunderstanding of proposal.
There is not any relation between Main Transaction and Guarantee
transaction. when I said “the Guarantee Transaction is created based on
Main Transaction” I was intended only the numbers. I mean the output
amounts of Guarantee Transaction are calculated relatively based on Main
Transaction output amounts, in order to make a Guarantee Transaction
with relatively higher transaction fee. So, either of MT or GT can be
broadcasted or toke place in next block independently.  

> When Bob tries to broadcast the "guarantee transaction" he will get an error: 
> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
Here is the part which I am not sure you are right about it. I do not
know in detail and I'm not sure how miners will react to the two
double-spend transactions and which one they will prefer.
Will they use the first seen transaction for block pre-image, or will
use the transaction with higher transaction fee?
We need the help of Bitcoin core developers to clarify this transaction
selection mechanism. 
If miners prefer the highest fee my scenario still is valid. But if
miners always keep the first transaction received and drop subsequent
transactions, I have three different solution to solve that I will
explain in later posts.

> 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.
Somehow you are right. Definitely Bob can delegate this task to a
doc-watcher, pretty much like watch-tower in Lightning, but due to the
small amount of creditor's credits and the fact that this amount is
scattered among many different issuers, I removed this part from the
original design of Sabu architecture.
BTW major creditors, such as stores that receives debt-documents worth
thousands of dollars a day, should (and better say must) always be
online to protect their money. This job also creates a safe margin for
other creditors.
IMHO at the moment the protocol is good enough to start, but we can
always talk about improving the protocol.

> 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?
I already explained it in response of Billy here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html

just look for “how normal transactions happen in their entirety.”

Looking forward to hear from core developers about “how miners will
react to the two double-spend transactions and which one they will
prefer”.

Regards
Raymo


On 2021-08-09 00:03, s7r wrote:
> 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?