path: root/31/05ca359dab74888cdb612e4345c7fa937ab746

Return-Path: <raymo@riseup.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3A390C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 09:52:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 21CD660723
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 09:52:40 +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 9Q2onvkmq6Lb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 09:52:39 +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 265B560720
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 09:52:39 +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 4GD2w64S9QzDt8R;
 Mon, 28 Jun 2021 02:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1624873958; bh=Ik5yFQC2byc2dR1FuAHefCGF4IRTOGp/WAqjHF7X/ac=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=SMw9j7hXAwWKlpJDIc1b4c6Mid4j3x2z/ulystl7/+KpC/uUdE5iT8ZTtbAfEToNG
 9rdZWQxYAt8N98yyZgw2m8WzYb56Sv+HREGcxAFoTKs46ghZnJ+4Hw34jNQUiu7qnQ
 aWbAMWBDks9AFCVDelI3QSlIHMtDvkocZMXOgEJc=
X-Riseup-User-ID: 43FE95AE4871D3D7C91D8021C7713611C3B964C2D3E71B21C71FE443266A93B2
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4GD2w62tp9z20b5;
 Mon, 28 Jun 2021 02:52:38 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 28 Jun 2021 02:52:38 -0700
From: raymo@riseup.net
To: James Hilliard <james.hilliard1@gmail.com>
In-Reply-To: <CADvTj4rD90A7FeBw8T_SvDupm0z7CfuXKZ2S=hR0A8CFv0-bSg@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>
 <CADvTj4rD90A7FeBw8T_SvDupm0z7CfuXKZ2S=hR0A8CFv0-bSg@mail.gmail.com>
Message-ID: <795618e761cd97c9216533cc82ed4624@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 28 Jun 2021 10:05:59 +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 09:52:40 -0000


Hi James,
Sorry for not responding in detail.
So, lets jump in the critiques.

> You're making the assumption that miners won't build on top of a block
with transactions they have not seen before or transactions that may
contain double spends of unconfirmed inputs
No, it is a wish. I hope in future miners consider this rule as well.
But for now, I absolutely do not count on this restriction. So, miner
can/will accept a valid block which contains some valid transactions
which they didn’t aware of those transactions in advance.
In order to explain how economically this won’t happened, I have to
refer you to the fact that a conspiracy between a miner(mining pool) and
a group of issuers to mine a block full of cheating transaction will
makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
now). The 1.2 is coming from average(max) 6,000 transaction per block *
max 20K Satoshi cheating benefit for each promised used UTXO in a
debt-doc(transaction).
In order to achieve this conspiracy, the mining pool has to mine the
block in stealth, lonely and without broadcasting any of transactions to
Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
they have to change the block header and restart again. After all, if
they succeed, they have to divide this extra dirty 1.2 BTC in between. I


I am not expert in mining pool calculations; you may help me to answer
these questions?

Consider these given facts: 

More hashrate = more success chance.
More hashrate = more electric cost = less profit per each participator
There is a minimum hashrate to have a minimum chance to solve the puzzle
in next 10 minutes, otherwise it doesn't make sense to participate in an
activity that doesn't fit the minimum hope. 
How much is this minimum hashrate? 
How much costs this hashrate? 
Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
be economically cost effective (risk to reward) to dedicate your
hashrate to mine this block? I am not sure. But if you show me the
opposite by facts and numbers, I will highly appreciate you.

> What would this BIP look like?
> We suppose the miners always control transactions with doc-watchers
As I told before, these assumptions are my wishes and I never relayed on
these wishes. These are for future. For now, I just count on the
calculation that asked you to help.

> there can be significant latency between the time a transaction is
actually broadcast and hits the miners mempool and the time the miners
actually switch to mining on top it

It is great. Although this latency could be lesser (in case of empty
mempools), but Sabu likes this latency. Because the creditors will have
more time to be aware of a fraudulent activity from issuer and existence
of a cheating transaction in mempool, so they have more time to send and
broad cast the GT to network. More latency, more chance in batch update.
So more chance for miners to face two or three transactions which are
using same UTXO but sending to different addresses and paying different
fees. 
More latency increases the chance of putting the higher-fee-payer
transaction in next block.

Regards
Raymo


On 2021-06-28 08:23, James Hilliard wrote:
> On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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.
> 
> Considering that you have not effectively addressed any of the inaccurate
> assumptions made regarding how mining works that I pointed out earlier
> I assume your proposal is not viable in practice.
> 
> See:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
> 
>>
>> > All the benefits your scheme claims, are derived from the trust assumption
>> No, All the benefits my scheme claims, are derived from economically
>> rational decision of both issuer and creditors.
>>
>> Regards
>> Raymo
>>
>>
>>
>> On 2021-06-28 05:20, ZmnSCPxj wrote:
>> > Good morning Raymo,
>> >
>> >>
>> >> It looks you already missed the entire design of Sabu and its
>> >> restrictions. First of all, the Gazin wallet always controls the Sabu
>> >> restrictions for every transaction in order to consider it as a valid
>> >> transaction in a valid deal. That is, the creditor wallet controls the
>> >> MT and GT in first place.
>> >
>> > Stop right there.
>> >
>> > From the above, what I get is, "trust the Gazin wallet".
>> > Thus, the suggestion to just use Coinbase.
>> > At least it has existed longer and has more current users that trust
>> > it, rather than this Gazin thing.
>> >
>> >
>> > Is Gazin open-source?
>> >
>> > * If Gazin is open-source, I could download the source code, make a
>> > local copy that gives me a separate copy of the keys, and use the keys
>> > to sign any transaction I want.
>> > * If Gazin is not open-source, then why should I trust the Gazin
>> > wallet until my incoming funds to an open-source wallet I control have
>> > been confirmed deeply?
>> >
>> > Lightning is still superior because:
>> >
>> > * It can be open-sourced completely and even though I have keys to my
>> > onchain funds, I *still* cannot steal the funds of my counterparty.
>> > * Even if I connect my open-source node to a node with a closed-source
>> > implementation, I know I can rely on receives from that node without
>> > waiting for the transaction to be confirmed deeply.
>> >
>> >
>> > All the benefits your scheme claims, are derived from the trust
>> > assumption, which is uninteresting, we already have those, they are
>> > called custodial wallets.
>> > Lightning allows for non-custodiality while achieving high global TPS
>> > and low fees.
>> > And a central idea of Lightning is the requirement to use an n-of-n to
>> > form smaller sub-moneys from the global money.
>> >
>> > Regards,
>> > ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev