path: root/f7/3c24a57617475da1b0844c050df7a951082da3

Return-Path: <raymo@riseup.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1D865C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 19:07:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0C5B960789
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 19:07:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.822
X-Spam-Level: 
X-Spam-Status: No, score=-2.822 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.01, RCVD_IN_MSPIKE_WL=-0.01,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=riseup.net
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ut21fIE6AXbh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 19:07:41 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 08AEC60788
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 19:07:40 +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 4GDHDX4gzCzDrgb;
 Mon, 28 Jun 2021 12:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1624907260; bh=JKTuMfLPNgZL5hWVxvOs4/WaI5Lne8fDeHWT/+O1J3s=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=OrkPTg0r5rMCDJQAtiOBpzKQl4j5CjyVYgAViuwQU9AF/LvxjWsOgr6qJj3Rv1tCE
 1I26Uu5gmyeTXc3sBgHeCrzm5X5/3k8kxiJvkZBnha4ipzoeB37lC1YjKertSmy8Ja
 VqkbVu991/9ytSeLHz5InhzKMmSuA7Qt0Wgv1F3E=
X-Riseup-User-ID: 521FFAFD0ECA044C8360A17CA70AC48516C36C97E2A6D5D398F323F62321C9F1
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4GDHDX3Xygz20d3;
 Mon, 28 Jun 2021 12:07:40 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 28 Jun 2021 12:07:40 -0700
From: raymo@riseup.net
To: Alex Schoof <alex.schoof@gmail.com>
In-Reply-To: <CA+2b5C2m6m2-OHKa7dVGiQcQG-dv82xQQQc45QrmeDz6HS2skQ@mail.gmail.com>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
 <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
 <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
 <edee179d873eb9db551204561db17e90@riseup.net>
 <A5gXRNtpLIWjF8Uq7CRLiwl9mb1eEY7IW7AQfQL_7uW9cXCKLn6FdOyYKBq1Dl1L-vgCBwFUgC873WyEEpS6K9F7ct4mdwRMKco01xsWhHg=@protonmail.com>
 <c2e7b6336190c5dae6383abb284c335b@riseup.net>
 <zs9XYSRzwoyhcfqXvyXG67bZqNTUt5_0DZwjrsyEKrvFbaxhX6jEAXBXPP01HnkxgApU8oGMXdOBVdgSHXBFrKAYLzCg_OmoIvO2EfsqJJg=@protonmail.com>
 <16131549ac084b58fc6cde894e43babe@riseup.net>
 <CA+2b5C2m6m2-OHKa7dVGiQcQG-dv82xQQQc45QrmeDz6HS2skQ@mail.gmail.com>
Message-ID: <878e0de9f6b08d8aad07fc7b7760e01b@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 28 Jun 2021 19:09:57 +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, 28 Jun 2021 19:07:42 -0000


Hey Alex,

Your scenario works perfectly unless we put some restrictions on
accepting transaction by creditor (in our case Bob). 
These are restrictions:
Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
transaction input.
Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
regardless of transaction length or input/output amounts. 
Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
6,000 remined fee must be paid by she and Bob in proportion to their
outputs amounts)
Alice can issue a transaction the has maximum 20,000 outputs for
creditors (Bob and others).
The rest (if exist) is change back to Alice address.
The GT is formed based on MT.
Bob considers a transaction couple (MT, GT) valid only if they respect
these rules.

Let’s put it in practice using some numbers (although you can find more
detailed explanation in paper).

The MT would be like that:
Input: 40,000 Satoshi
Outputs:
Bob: 20,000
BTC-fee: 10,000
Change back to Alice: 10,000

Based on this MT the GT will be
Input: 40,000 Satoshi
Outputs:
Bob: 20,000 – 20,000*70% = 6,000
BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change
back) = 25,500
Change back to Alice: 10,000 – 10,000*15% = 8,500

Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
to put his fraudulent transaction instead the GT in next block. 
Alice already got 20,000 Sat profit from Bob. Now she can earn another
14,999 Sat profit from Charlie because of same UTXO worth 40,000
Satoshi.
Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
or services.
Is she a winner? 
I am not sure! 
What do you think?
By the way, we can tune the kI and kC coefficients to reduce this 34,999
to 30,000 or even less.
In this case Alice rationally prefers to not cheat on Bob.
The complementary protection would be the mentioned BIP for miners.
That BIP not only solve all these .01% risks but also would be a huge
improvement of adapting smart contracts (and consequently DeFi) on top
of current Bitcoin with lowest cost, but it is another story for another
day.

Raymo


On 2021-06-28 17:58, Alex Schoof wrote:
> Hey Raymo,
> 
> Here’s a scenario: 
> 
> Alice has one UTXO. 
> 
> Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives
> whatever goods and services to Alice. 
> 
> Alice then goes and spends that UTXO to Charlie with a higher fee than
> the GT she sent to Bob. Charlie has no idea that Bob exists, because
> he gets a valid UTXO. Bob can try to publish the GT, but if Alice
> crafts the fees right, the TX to Charlie will be confirmed first.
> Alice now has goods from both Bob and Charlie, and has only paid one
> of them. She has is able to double spend because: (1) the gossip
> network you describe for sabu only protects people if everyone is on
> sabu and playing by the rules, it does not prevent spending outside of
> sabu; and (2) there is nothing encumbering the onchain UTXO and
> preventing it from being spent outside of a sabu payment. 
> 
> The reason people keep brining up Lightning is because Lightning
> solves this problem by having a channel-open involve locking funds in
> a 2-of-2 multisig, preventing them from being spent outside of
> lightning until the channel is torn down. 
> 
> If there is nothing stopping someone from spending onchain funds
> outside of the context of your system, then your system does not
> prevent double spends.
> 
> Hope that explanation helps. 
> 
> Alex
> 
> On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>>> What prevents the creditor from signing a transaction that is
>> neither a valid MT nor a GT?
>> Please stop comparing Sabu and Lightning. Otherwise, it won't let
>> you
>> true understanding of Sabu.
>> In Sabu protocol, only the issuer (the UTXO owner) can sign the
>> transaction and decide how much money goes to whom. The engaged
>> UTXO(s)
>> belonged to issuer and the creditor never put UTXO in transaction,
>> thus
>> never can sign the transaction because he has no ownership on the
>> used
>> UTXOs.
>> As I already wrote in paper, the issuer creates and signs a
>> transaction
>> and delivers it to creditor(s). If a creditor intends to send all or
>> part of his money to another person (AKA spending his money), he
>> will
>> ask for a new signed transaction from issuer, in which a part of his
>> credit will transfer to another creditor.
>>
>> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network
>> of
>> doc-watchers which maybe it was the cause you always compare it to
>> Lightning.
>> I am not presenting lightning neither condemning it.
>> I am presenting Sabu protocol.
>> Please let concentrate on how Sabu works or not works.
>>
>> On 2021-06-28 15:28, ZmnSCPxj wrote:
>>> Good morning Raymo,
>>>
>>>> Hi ZmnSCPxj,
>>>>
>>>> Why you get the signal “trust the Gazin wallet”?
>>>> Sabu is a protocol and the Gazin wallet will be an implementation
>> of
>>>> that protocol. We will implement it in react-native language to
>> support
>>>> both Android and iPhone. Of course it will be open source and
>> GPL3.
>>>> Here is the repository and yet is empty :)
>>>> https://github.com/raymaot/Gazin
>>>>
>>>> I wonder why you do not look carefully into the proposal! IMHO
>> the Sabu
>>>> will be far better than Lightning.
>>>> Can’t you see the fact that in Sabu you do not need open and
>> close
>>>> channels ever? Can you imagine only this feature how dramatically
>>>> decrease the transactions cost and how increase the distribution
>> of
>>>> nodes and improve privacy level? it makes every mobile wallet act
>> like a
>>>> lightning network.
>>>> Did you note the fact that in Sabu protocol there is no routing?
>> And the
>>>> only people knew about a transaction are issuer and creditor? No
>> one
>>>> else won’t be aware of transactions and million transactions
>> per second
>>>> can be sent and received and repeal dynamically without any
>> footprint on
>>>> any DLT?
>>>>
>>>> The English is not my mother language and probably my paper is
>> not a
>>>> smooth and easy to read paper, but these are not good excuse to
>> not even
>>>> reading a technical paper carefully and before understanding it
>> or at
>>>> least trying to understanding it start to complaining.
>>>
>>>
>>> What prevents the creditor from signing a transaction that is
>> neither
>>> a valid MT nor a GT?
>>>
>>> Nothing.
>>>
>>> In Lightning, sure one side can sign a transaction that is not a
>> valid
>>> commitment transaction, but good luck getting the other side to
>> *also*
>>> sign the transaction; it will not.
>>> Thus, you need n-of-n.
>>>
>>> 1-of-1 is simply not secure, full stop, you need to redesign the
>> whole
>>> thing to use *at least* 2-of-2.
>>> At which point you will have reinvented Lightning.
>>>
>>> Otherwise, you are simply trusting that the wallet is implemented
>>> correctly, and in particular, that any creditor will not simply
>> insert
>>> code in your open-source software to sign invalid transactions.
>>>
>>> With a 1-of-1, any invalid-in-Sabu transaction can still be valid
>> in
>>> the Bitcoin blockchain layer, thus the scheme is simply insecure.
>>>
>>> Features are meaningless without this kind of basic
>> trust-minimization security.
>>>
>>> Regards,
>>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>  -- 
> 
> Alex Schoof