path: root/a4/79954cbd5b4b833d27df9e31a9cdee0294947e

Return-Path: <james.hilliard1@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CEAEFC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 11:28:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B8289400AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 11:28:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 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,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JIVvooebZWsb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 11:28:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com
 [IPv6:2607:f8b0:4864:20::335])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5C28640003
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 11:28:26 +0000 (UTC)
Received: by mail-ot1-x335.google.com with SMTP id
 v6-20020a0568300906b0290464d9be9510so6908945ott.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 04:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=MTdxpsVoxV0hAUbGyqHE+S/qb2g0cfrT98TfGJPnVXg=;
 b=hQXjosQJ3sGswVVnK728ASxmK6WDfe7N9HVDSKKppxc8HAx0HvZsjxL6pwNxGgtnxb
 7XLwLgSfh/2kgMHpt8Br9vuXUKUXTc0kHFLoA1XQ8voFy4DGqDMAr6dy7Dmmb4VwiVr4
 AdQeRIM9h2WhQb9GYWyt0SWcmUOItTGizSq8I5ic4QZdl+bpDob9jDN1mtNLpw5N5wkc
 GEEpz5KCanD8Wm0vR1ZSkJFIgjRbXD1wiIjCluz0B3sCRZ/vOBka1oYx2Gbjm1NmYK3J
 rzT+kUi28QGdkUhIy57v9s3ebsFs/4elkv9lY9UvGVimdctpAbpcj3uqHlzfx1SmTDTB
 ufMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=MTdxpsVoxV0hAUbGyqHE+S/qb2g0cfrT98TfGJPnVXg=;
 b=Hcymo1BGy2VophD/vRFhcPI3gI1/NEOM0lPMSMPe2kvmT/W+6RMvVxfypyPSarKxAH
 uI22F7SlTumWSJG3MgSQFPmY5B0FS6A++ZY42/UnScX8Rx8UH7s5u1mqpIEEE2jMYcZE
 fuPne7gkvfr4HYskXteTDgWwa6qGbVt/xCZgxp1s7Zs4YPIPKekKXUhUX/tueVAQ1e1D
 dxR0b6vI09aKMzOUCIGTRbreyE+8hqnxu5Z6uFzUYA3UKxHGPfp0ycac5yFeOjrC67Ng
 z2iwtfT6N3cM73H+UN6lTMk2jWqj4Qe4D3D/30zxnJqbWPetaFnINCrV3IPM9u+i1cZL
 l7Hg==
X-Gm-Message-State: AOAM531qBWhBa6bHp0OZttSvChHO5dCjU3+gywKi0icV7WPRLTHGTNwd
 +EnJeeC4rfnrO2xG1hId/jrcynHDKkoMz3qHrHo=
X-Google-Smtp-Source: ABdhPJy9duv9wxrVLHVDTTROR/H5GQoTFquknIJttALizjjuG7H4A7Qal0n962+/Im6pHZ9jjDvPgq3Pbzh+LcPC/XU=
X-Received: by 2002:a9d:634d:: with SMTP id y13mr20977632otk.294.1624879705126; 
 Mon, 28 Jun 2021 04:28:25 -0700 (PDT)
MIME-Version: 1.0
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>
 <795618e761cd97c9216533cc82ed4624@riseup.net>
In-Reply-To: <795618e761cd97c9216533cc82ed4624@riseup.net>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Mon, 28 Jun 2021 05:28:13 -0600
Message-ID: <CADvTj4qQ=xcpCZRigkXGm2CzduO=AXc22GjghSe6RA37XjrPzA@mail.gmail.com>
To: raymo@riseup.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 11:28:27 -0000

On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup.net> wrote:
>
>
> 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.

There's only one practical approach I'm aware of for miners to actually
do this, and that would be to effectively make mining centralized.
So I would highly discourage this sort of policy when it comes to mining.

> 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=E2=80=99t aware of those transactions in advance.

Mempools among miners are generally not fully in sync with each other,
rejecting valid blocks due to disagreements over which transactions were
broadcast would destabilize the network as you'd get a bunch of network
forks.

> In order to explain how economically this won=E2=80=99t 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).

But there's no risk really for a miner to choose the most profitable
transactions to mine as long as they are valid per the network rules,
that is unless you make mining fully centralized.

> 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

Miners regularly change block headers, and if they don't broadcast the
transactions there wouldn't really be a time limit, so even a relatively sm=
all
miner would be able to stealthily mine the transactions given enough time.

>
>
> I am not expert in mining pool calculations; you may help me to answer
> these questions?
>
> Consider these given facts:
>
> More hashrate =3D more success chance.
> More hashrate =3D more electric cost =3D less profit per each participato=
r
> 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.

Why would they need to solve the block within 10 minutes?

> How much is this minimum hashrate?

I don't think there is a minimum.

> How much costs this hashrate?

Miners just use pools to reduce variance, there isn't a set minimum size to
solo mine, only how much variance the miner can tolerate.

> 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.

All that matters is if that extra is more than they would otherwise get.

>
> > 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.

The reason I ask is because I don't think this is possible to do
without massively
centralizing mining.

>
> > 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.

Actually it's the opposite, if pools updated their templates every second
the GT transaction could almost immediately replace the fraudulent transact=
ion,
however due to the batch updating if the fraudulent transaction ended up
in a template it could take a significant amount of time for it to be purge=
d
from all the mining pool templates, no matter the fee difference.

Ultimately this means that one should always expect miners to mine the
first seen transaction for a significant period of time, with no guarantees
that it would be replaced.

>
> 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 =E2=80=9Ctrust the Gazin wallet=E2=80=9D?
> >> Sabu is a protocol and the Gazin wallet will be an implementation of
> >> that protocol. We will implement it in react-native language to suppor=
t
> >> 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 Sab=
u
> >> will be far better than Lightning.
> >> Can=E2=80=99t you see the fact that in Sabu you do not need open and c=
lose
> >> 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 t=
he
> >> only people knew about a transaction are issuer and creditor? No one
> >> else won=E2=80=99t be aware of transactions and million transactions p=
er 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 ev=
en
> >> 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 inaccura=
te
> > 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/01909=
1.html
> >
> >>
> >> > All the benefits your scheme claims, are derived from the trust assu=
mption
> >> 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 Sa=
bu
> >> >> restrictions for every transaction in order to consider it as a val=
id
> >> >> 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 ke=
ys
> >> > 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 ha=
ve
> >> > been confirmed deeply?
> >> >
> >> > Lightning is still superior because:
> >> >
> >> > * It can be open-sourced completely and even though I have keys to m=
y
> >> > 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-sour=
ce
> >> > 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 TP=
S
> >> > 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